[Skiboot] [PATCH] FSP: Do not process incoming FSP messages in fsp_sync_msg path
stewart at linux.vnet.ibm.com
Tue Mar 24 17:06:04 AEDT 2015
Benjamin Herrenschmidt <benh at kernel.crashing.org> writes:
> On Tue, 2015-03-10 at 11:52 +0530, Vasant Hegde wrote:
>> Presently we process incoming messages from FSP all the time.
>> Our fsp_fetch_data function holds lock and calls fsp_sync_msg.
>> Due to our callback mechanism its possible that in some cases
>> we may hit recursive lock issue in fsp_fetch_data.
>> Sample code path:
>> fsp_fetch_data ->
>> fsp_sync_msg ->
>> Incoming message (ex: OCC LID load) ->
>> notify registered client (ex: fsp_occ_msg) ->
>> fsp_fetch_data -> Lock issue!
>> This patch adds support to queue incoming messages in fsp_fetch_data
>> path. That way we are sure that we will not hit above scenario. Also
>> I have changed locking code in fsp_fetch_data. Now we just hold lock
>> to update flag.
> This is not right. You are papering over the problem, if something else
> from the pollers decide to load a LID, kaboom. Plus the above shouldn't
> happen once you implement the queueing & preloading.
(in patches just posted to list, going t push shortly) I've instead just
implemented a queue of LIDs to load, a platform API for starting preload
and waiting for load to finish and reworked the code to just do standard
async messages rather than fsp_sync_msg.
I've pointed Joel at these in the hope he'll do something here for
Next step: moving the calls to preload resources earlier in boot,
knocking a bunch of time off boot.
More information about the Skiboot