Alyssa,
On 3/20/23 05:54, Christoph Hellwig wrote:
> From: Alyssa Ross <hi@xxxxxxxxx>
>
> LOOP_CONFIGURE is, as far as I understand it, supposed to be a way to
> combine LOOP_SET_FD and LOOP_SET_STATUS64 into a single syscall. When
> using LOOP_SET_FD+LOOP_SET_STATUS64, a single uevent would be sent for
> each partition found on the loop device after the second ioctl(), but
> when using LOOP_CONFIGURE, no such uevent was being sent.
>
> In the old setup, uevents are disabled for LOOP_SET_FD, but not for
> LOOP_SET_STATUS64. This makes sense, as it prevents uevents being
> sent for a partially configured device during LOOP_SET_FD - they're
> only sent at the end of LOOP_SET_STATUS64. But for LOOP_CONFIGURE,
> uevents were disabled for the entire operation, so that final
> notification was never issued. To fix this, reduce the critical
> section to exclude the loop_reread_partitions() call, which causes
> the uevents to be issued, to after uevents are re-enabled, matching
> the behaviour of the LOOP_SET_FD+LOOP_SET_STATUS64 combination.
>
> I noticed this because Busybox's losetup program recently changed from
> using LOOP_SET_FD+LOOP_SET_STATUS64 to LOOP_CONFIGURE, and this broke
> my setup, for which I want a notification from the kernel any time a
> new partition becomes available.
>
> Signed-off-by: Alyssa Ross <hi@xxxxxxxxx>
> [hch: reduced the critical section]
> Signed-off-by: Christoph Hellwig <hch@xxxxxx>
> Fixes: 3448914e8cc5 ("loop: Add LOOP_CONFIGURE ioctl")
>
Can you please add the testcase in the blktests to test the
above mentioned behavior ?
-ck
