On Wed, Jan 21, 2026 at 10:27:51AM +0100, Martin Wilck wrote:
> On Tue, 2026-01-20 at 23:23 -0500, Benjamin Marzinski wrote:
> > while uevent_listen() was grabbing new uevents, "multipathd show
> > status"
> > would still show show busy as "False". Add a check there, to make
> > catch
> > multipathd's uevent processing earlier. Also, access servicing_uev
> > (as
> > well as the new variable, adding_uev) atomically, just to make sure
> > that
> > the compiler doesn't do stupid things trying to optimize them.
> >
> > Signed-off-by: Benjamin Marzinski <[email protected]>
>
> access to servicing_uev is protected by uevq_lockp. The
> atomic annotation isn't necessary for it, AFAICT.
True. I can remove that.
> I have to admit that I wasn't fully aware of the semantics of "busy".
> Naïvely, one would assume that it means "some thread of multipathd is
> doing something". But your intention in 69cb2d8 ("multipath: add "count
> paths" multipathd command") was that it means "states of paths and/or
> maps are imminent because of current uevent processing". With that in
> mind, taking "adding_uev" into account makes sense. I'm not so sure
> about the practical relevance, though. How likely is it to hit a
> situation where the uevent listener is working but the uevent
> dispatcher hasn't been woken up yet?
I saw it happen at the start of a uevent surge. To be honest, I don't
know why uevent_receive_events() took so long to return, but it seemed
like extending the check is a pretty painless way to catch that.
-Ben
> Martin
