hiomap: Handle SIGTERM to ensure delivery of HIOMAP BMC status
We need to jump through a few hoops to ensure that the host firmware
reliably receives indication of changes to the HIOMAP daemon's state
over the IPMI transport. This is driven partly by IPMI's design, partly
by ipmid's implementation, and partly by the original design of the
HIOMAP DBus transport interface.
A long comment has been added outlining the race conditions eliminated
by this change and its related patches, however it's worth drawing
attention to the issue not addressed there - the original design of the
HIOMAP DBus transport:
The HIOMAP BMC status is composed of two distinct types of data:
1. Stateful: BMC_EVENT_DAEMON_READY and BMC_EVENT_FLASH_CONTROL_LOST
2. Events: BMC_EVENT_PROTOCOL_RESET and BMC_EVENT_WINDOW_RESET
The data types described by 1 and 2 map directly onto the DBus concepts
of Properties and Signals. Originally the specification for the HIOMAP
DBus transport exploited this direct mapping, however experience from
dealing with SIGTERM handling has shown that it was a poor mapping to
exploit.
On shutdown the HIOMAP daemon, mboxd, needs to atomically both clear the
BMC_EVENT_DAEMON_READY bit and set the BMC_EVENT_PROTOCOL_RESET bit.
With the data exposed as distinct types this results on two messages
emitted on the bus: A PropertiesChanged signal to advertise the update
to BMC_EVENT_DAEMON_READY, and a raw signal to advertise the update to
BMC_EVENT_PROTOCOL_RESET.
With two separate signals to be processed by ipmid's event loop it is
hard to ensure both will be propagated to the host before the SIGTERM
from systemd is processed by ipmid.
The solution to eliminate the race is to rework the events exposed as
signals into properties and live with the slight mismatch of intent.
This results in the removal of the associated signal handling code in
the plugin.
Change-Id: Ic05c40b52138c132eface6f8d873088e7e66585b
Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
1 file changed