search for: shotdown

...ote: we only let refcount go to 0 on device release. This works well but we now access the ref counter twice so there's a race: all users might see a high count and decide to defer freeing resources. In the end no one initiates freeing resources until the last reference is gone (which is on VM shotdown so might happen after a looooong time). Let's do what we probably should have done straight away: switch from kref to plain atomic, documenting the semantics, return the refcount value atomically after decrement, then use that to avoid the deadlock. Reported-by: Qin Chuanyu <qinchuanyu at...

...ote: we only let refcount go to 0 on device release. This works well but we now access the ref counter twice so there's a race: all users might see a high count and decide to defer freeing resources. In the end no one initiates freeing resources until the last reference is gone (which is on VM shotdown so might happen after a looooong time). Let's do what we probably should have done straight away: switch from kref to plain atomic, documenting the semantics, return the refcount value atomically after decrement, then use that to avoid the deadlock. Reported-by: Qin Chuanyu <qinchuanyu at...

...int I remain concerned about is the UPS getting confused about receiving the same commands over different protocols/media in short sequence. Or similar but conflicting commands because one driver knows how to request "load.off" and another knows about "shutdown.stayoff" or "shotdown.reboot" leading to different code paths in the UPS controller - can't exclude some firmware getting wedged about this. In this case `upsdrvctl shutdown` should somehow know to only try one of the drivers at a time (perhaps `sdorder` can be useful to at least somehow separate these attempt...

...ed about is the UPS getting confused about > receiving the same commands over different protocols/media in short > sequence. Or similar but conflicting commands because one driver knows how > to request "load.off" and another knows about "shutdown.stayoff" or > "shotdown.reboot" leading to different code paths in the UPS controller - > can't exclude some firmware getting wedged about this. > > In this case `upsdrvctl shutdown` should somehow know to only try one of > the drivers at a time (perhaps `sdorder` can be useful to at least somehow &gt...

This fixes a deadlock with vhost reported in the field, as well as a theoretical race issue found by code review. Patches 1+2 are needed for stable. Thanks to Qin Chuanyu for reporting the issue! Michael S. Tsirkin (3): kref: add kref_sub_return vhost: fix ref cnt checking deadlock vhost: fix a theoretical race in device cleanup include/linux/kref.h | 33

This fixes a deadlock with vhost reported in the field, as well as a theoretical race issue found by code review. Patches 1+2 are needed for stable. Thanks to Qin Chuanyu for reporting the issue! Michael S. Tsirkin (3): kref: add kref_sub_return vhost: fix ref cnt checking deadlock vhost: fix a theoretical race in device cleanup include/linux/kref.h | 33

P.S. To articulate better what I am unclear about from your message: `nutshutdown` seems to run `@SBINDIR@/upsdrvctl shutdown`. >From my understanding, this would command - all - `ups.conf` UPS to shutdown. So this would already include the UPS monitored by any failover/multiplexing driver. In contrast, `upsdrvctl shutdown` would start up all these drivers again, respectively. What kind of