[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <fzi7oikkjqedbhfi57c2rc6z3icvwra3uoqk5pgz7rmiqczfcj@w33zdcy6d3ax>
Date: Tue, 15 Apr 2025 18:33:08 +0200
From: Jan Kara <jack@...e.cz>
To: Thomas Weißschuh <thomas.weissschuh@...utronix.de>
Cc: Jan Kara <jack@...e.cz>, Jens Axboe <axboe@...nel.dk>,
Martijn Coenen <maco@...roid.com>, Alyssa Ross <hi@...ssa.is>, Christoph Hellwig <hch@....de>,
Greg KH <greg@...ah.com>, John Ogness <john.ogness@...utronix.de>,
linux-block@...r.kernel.org, linux-kernel@...r.kernel.org, stable@...r.kernel.org
Subject: Re: [PATCH v2] loop: properly send KOBJ_CHANGED uevent for disk
device
On Tue 15-04-25 13:07:48, Thomas Weißschuh wrote:
> On Tue, Apr 15, 2025 at 12:24:55PM +0200, Jan Kara wrote:
> > On Tue 15-04-25 10:51:47, Thomas Weißschuh wrote:
> > > The original commit message and the wording "uncork" in the code comment
> > > indicate that it is expected that the suppressed event instances are
> > > automatically sent after unsuppressing.
> > > This is not the case, instead they are discarded.
> > > In effect this means that no "changed" events are emitted on the device
> > > itself by default.
> > > While each discovered partition does trigger a changed event on the
> > > device, devices without partitions don't have any event emitted.
> > >
> > > This makes udev miss the device creation and prompted 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: 498ef5c777d9 ("loop: suppress uevents while reconfiguring the device")
> > > Cc: stable@...r.kernel.org
> > > Signed-off-by: Thomas Weißschuh <thomas.weissschuh@...utronix.de>
> >
> > Thanks for the fix! When reading the code, I'm a bit curious: What is
> > actually generating events for partitions with loop_change_fd() call?
> > Because there loop_reread_partitions() still happens with uevents
> > supressed... I suspect event supressing there should be shorter.
>
> Makes sense.
> For loop_configure() this was fixed in
> commit bb430b694226 ("loop: LOOP_CONFIGURE: send uevents for partitions").
> I guess we need the same for loop_change_fd().
>
> I'm not entirely sure on how to order the commits or if they should be
> folded together.
> My current preference is to first have the current patch under discussion and
> then the fix for loop_change_fd().
Yeah, whatever. I was asking mainly to make sure my understanding of the
current code is correct :). With this one feel free to add:
Reviewed-by: Jan Kara <jack@...e.cz>
Honza
--
Jan Kara <jack@...e.com>
SUSE Labs, CR
Powered by blists - more mailing lists