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.
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?
Martin
