On 2022/02/05 9:28, Tetsuo Handa wrote: > Ping? > > I sent https://lkml.kernel.org/r/20220129071500.3566-1-penguin-kernel@xxxxxxxxxxxxxxxxxxx > based on ideas from your series. > I tested my latest series and found that there are two problems. One is that there still is disk->open_mutex => loop_validate_mutex => lo->lo_mutex chain. We would need to consider something like https://lkml.kernel.org/r/fffda32f-848a-712b-f50e-8a6d7d086039@xxxxxxxxxxxxxxxxxxx if we go with avoiding lo->lo_mutex while holding disk->open_mutex. The other is that my latest series which does not hold lo->lo_mutex from lo_open() causes occasional I/O error (due to if (lo->lo_state != Lo_bound) return BLK_STS_IOERR; check in loop_queue_rq()) when systemd-udevd opens a loop device and reads from it before loop_configure() updates lo->lo_state to Lo_bound. (And I think the same problem exists for your series because we assumed that we need to care about only loop_control_remove().) If we want to avoid I/O error, open() of a loop device (currently lo_open()) needs to wait for loop_configure() to complete, by waiting for lo->lo_mutex to be released. But this implies that we can't avoid lo->lo_mutex while holding disk->open_mutex. Use of task work context (my previous series which is intended for waiting for __loop_clr_fd() to complete) will allow waiting for lo->lo_mutex without holding disk->open_mutex, but we want to avoid task work context if possible... [ 3069.404881] loop184: detected capacity change from 0 to 2048 [ 3069.452117] loop185: detected capacity change from 0 to 2048 [ 3069.457155] I/O error, dev loop185, sector 0 op 0x0:(READ) flags 0x80700 phys_seg 1 prio class 0 [ 3069.465309] loop186: detected capacity change from 0 to 2048 [ 3069.506238] loop187: detected capacity change from 0 to 2048 [ 3069.525483] loop188: detected capacity change from 0 to 2048 [ 3069.551447] loop189: detected capacity change from 0 to 2048 [ 3069.576062] loop190: detected capacity change from 0 to 2048 [ 3069.592206] loop191: detected capacity change from 0 to 2048 [ 3069.681413] loop192: detected capacity change from 0 to 2048 [ 3069.911000] loop193: detected capacity change from 0 to 2048 [ 3070.049889] loop194: detected capacity change from 0 to 2048 [ 3070.063847] loop195: detected capacity change from 0 to 2048 [ 3070.168926] loop196: detected capacity change from 0 to 2048 [ 3070.242869] loop197: detected capacity change from 0 to 2048 [ 3070.383477] loop198: detected capacity change from 0 to 2048 [ 3070.439035] loop199: detected capacity change from 0 to 2048 [ 3070.464548] loop200: detected capacity change from 0 to 2048 [ 3070.501891] loop201: detected capacity change from 0 to 2048 [ 3070.513600] loop202: detected capacity change from 0 to 2048 [ 3070.523923] I/O error, dev loop202, sector 0 op 0x0:(READ) flags 0x80700 phys_seg 1 prio class 0 [ 3070.531281] I/O error, dev loop202, sector 0 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0 [ 3070.541353] Buffer I/O error on dev loop202, logical block 0, async page read [ 3070.684234] loop203: detected capacity change from 0 to 2048 [ 3070.705911] loop204: detected capacity change from 0 to 2048 [ 3070.716153] loop205: detected capacity change from 0 to 2048 [ 3070.735178] loop206: detected capacity change from 0 to 2048 [ 3070.833832] loop207: detected capacity change from 0 to 2048 [ 3070.835086] I/O error, dev loop207, sector 0 op 0x0:(READ) flags 0x80700 phys_seg 1 prio class 0 [ 3070.851433] loop208: detected capacity change from 0 to 2048 [ 3070.873609] loop209: detected capacity change from 0 to 2048 [ 3070.890193] loop210: detected capacity change from 0 to 2048
