[Skiboot] [PATCH] ipmi: ensure forward progress on ipmi_queue_msg_sync()

[Stewart Smith]

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

Thanks.

> 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
> now.

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.

-- 
Stewart Smith
OPAL Architect, IBM.