linux-kernel - Re: [PATCH] loop: Properly send KOBJ

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <2025031759-unlined-candle-1d91@gregkh>
Date: Mon, 17 Mar 2025 15:33:55 +0100
From: Greg KH <greg@...ah.com>
To: Thomas Weißschuh <thomas.weissschuh@...utronix.de>
Cc: Jens Axboe <axboe@...nel.dk>, Martijn Coenen <maco@...roid.com>,
	Alyssa Ross <hi@...ssa.is>, John Ogness <john.ogness@...utronix.de>,
	linux-block@...r.kernel.org, linux-kernel@...r.kernel.org,
	stable@...r.kernel.org
Subject: Re: [PATCH] loop: Properly send KOBJ_CHANGED uevent for disk device

On Mon, Mar 17, 2025 at 03:13:25PM +0100, Thomas Weißschuh wrote:
> The wording "uncork" in the code comment indicates that it is expected that
> the suppressed event instances are automatically sent after unsuppressing.
> This is not the case, they are discarded.
> In effect this means that no "changed" events are emitted on the device
> itself by default. On the other hand each discovered partition does trigger
> a "changed" event on the loop device itself. Therefore no event is emitted for
> devices without partitions.
> 
> This leads to udev missing the device creation and prompting workarounds in
> userspace, see the linked util-linux/losetup bug.
> 
> Explicitly emit the events and drop the confusingly worded comments.
> 
> Link: https://github.com/util-linux/util-linux/issues/2434
> Fixes: 3448914e8cc5 ("loop: Add LOOP_CONFIGURE ioctl")
> Cc: stable@...r.kernel.org
> Signed-off-by: Thomas Weißschuh <thomas.weissschuh@...utronix.de>
> ---
>  drivers/block/loop.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/block/loop.c b/drivers/block/loop.c
> index c05fe27a96b64f1f1ea3868510fdd0c7f4937f55..fbc67ff29e07c15f2e3b3e225a4a37df016fe9de 100644
> --- a/drivers/block/loop.c
> +++ b/drivers/block/loop.c
> @@ -654,8 +654,8 @@ static int loop_change_fd(struct loop_device *lo, struct block_device *bdev,
>  
>  	error = 0;
>  done:
> -	/* enable and uncork uevent now that we are done */
>  	dev_set_uevent_suppress(disk_to_dev(lo->lo_disk), 0);
> +	kobject_uevent(&disk_to_dev(lo->lo_disk)->kobj, KOBJ_CHANGE);

Why not just remove the place where the uevent was suppressed to start
with?  It feels by manually sending a change event, you are doing
exactly what the suppress was trying to prevent, which makes me think
this is wrong.

thanks,

greg k-h