[Skiboot] [PATCH] FSP: Do not process incoming FSP messages in fsp_sync_msg path

[Stewart Smith]

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
astbmc platform.

Next step: moving the calls to preload resources earlier in boot,
knocking a bunch of time off boot.