[Skiboot] [PATCH] ipmi: ensure forward progress on ipmi_queue_msg_sync()
stewart at linux.ibm.com
Wed May 15 14:13:26 AEST 2019
Oliver <oohall at gmail.com> writes:
> On Wed, May 1, 2019 at 5:06 PM Stewart Smith <stewart at linux.ibm.com> wrote:
>> BT responses are handled using a timer doing the polling. To hope to
>> get an answer to an IPMI synchronous message, the timer needs to run.
>> We can't just check all timers though as there may be a timer that
>> wants a lock that's held by a code path calling ipmi_queue_msg_sync(),
>> and if we did enforce that as a requirement, it's a pretty subtle
>> API that is asking to be broken.
>> So, if we just run a poll function to crank anything that the IPMI
>> backend needs, then we should be fine.
>> This issue shows up very quickly under QEMU when loading the first
>> flash resource with the IPMI HIOMAP backend.
>> Reported-by: Cédric Le Goater <clg at kaod.org>
>> Signed-off-by: Stewart Smith <stewart at linux.ibm.com>
> Merged to master as of v6.3-2-gf01cd777adb1
> I'm a little bit iffy on this since we adding hacks for specific
> pollers seems kind of jank, but I don't have any better ideas right
Yeah, I was a bit the same. I came down on this design being a bit less
likely to cause unintented consequences at least.
In an ideal world, nothing would do a sync call except the abort() code
path where we have really no option but to kill the world.
OPAL Architect, IBM.
More information about the Skiboot