On Fri, Jun 11, 2021 at 11:11 AM Pavel Tatashin
[off-list ref] wrote:

On Fri, Jun 11, 2021 at 10:47 AM Tetsuo Handa
[off-list ref] wrote:

quoted

On 2021/06/10 1:46, Tyler Hicks wrote:

quoted

Thanks for doing this. I haven't had a chance to retry this commit with
lockdep but I did re-review it and didn't think that it would be the
cause of this lockdep report since it strictly reduced the usage of the
loop_ctl_mutex.

Well, I made commit 310ca162d779efee ("block/loop: Use global lock for ioctl() operation.")
because per device lock was not sufficient. Did commit 6cc8e7430801fa23 ("loop: scale loop
device by introducing per device lock") take this problem into account?

This was my intention when I wrote 6cc8e7430801fa23 ("loop: scale loop
device by introducing per device lock"). This is why this change does
not simply revert 310ca162d779efee ("block/loop: Use global lock for
ioctl() operation."), but keeps loop_ctl_mutex to protect the global
accesses.  loop_control_ioctl() is still locked by global
loop_ctl_mutex.

From commit log of:
 310ca162d779efee ("block/loop: Use global lock for ioctl() operation.")

    Since ioctl() request on loop devices is not frequent operation, we don't
    need fine grained locking. Let's use global lock in order to allow safe
    traversal at loop_validate_file().

Unfortunately using a global lock is not scalable here. At Microsoft
we had a slow startup issue because we have several loop devices per
every container. Also, this report:
https://lore.kernel.org/lkml/20210217145629.GA4503@xsang-OptiPlex-9020/ (local)

Pasha