firmware_class warnings on resume

firmware_class warnings on resume

[Andy Lutomirski]

I hit this warning fairly frequently when resuming 4.4-rc5:

        ret = usermodehelper_read_trylock();
        if (WARN_ON(ret)) {
            dev_err(device, "firmware: %s will not be loaded\n",
                name);
            goto out;
        }

It seems like it could be improved in two ways fairly easily:

1. Shouldn't firmware_class try the direct load before trying to get
the usermodehelper lock?

2. Why is the !NOWAIT case doing a trylock?  That seems wrong.

--Andy

-- 
Andy Lutomirski
AMA Capital Management, LLC

Re: firmware_class warnings on resume

[Laura Abbott]

On 12/20/2015 04:20 AM, Andy Lutomirski wrote:
> I hit this warning fairly frequently when resuming 4.4-rc5:
>
>          ret = usermodehelper_read_trylock();
>          if (WARN_ON(ret)) {
>              dev_err(device, "firmware: %s will not be loaded\n",
>                  name);
>              goto out;
>          }
>
> It seems like it could be improved in two ways fairly easily:
>
> 1. Shouldn't firmware_class try the direct load before trying to get
> the usermodehelper lock?
>
> 2. Why is the !NOWAIT case doing a trylock?  That seems wrong.
>
> --Andy
>

  
I saw the same warning coming from the bluetooth stack, see the thread
http://article.gmane.org/gmane.linux.kernel/1950940 and
http://article.gmane.org/gmane.linux.kernel/1940130.
At least in the bluetooth case, the conclusion was the firmware request
should not be happening at that point in time and the reset_resume function
should be implemented instead. I put that work aside and haven't picked
it up again.

Thanks,
Laura

Re: firmware_class warnings on resume

[Andy Lutomirski]

On Mon, Dec 21, 2015 at 9:54 AM, Laura Abbott <labbott@redhat.com> wrote:
> On 12/20/2015 04:20 AM, Andy Lutomirski wrote:
>>
>> I hit this warning fairly frequently when resuming 4.4-rc5:
>>
>>          ret = usermodehelper_read_trylock();
>>          if (WARN_ON(ret)) {
>>              dev_err(device, "firmware: %s will not be loaded\n",
>>                  name);
>>              goto out;
>>          }
>>
>> It seems like it could be improved in two ways fairly easily:
>>
>> 1. Shouldn't firmware_class try the direct load before trying to get
>> the usermodehelper lock?
>>
>> 2. Why is the !NOWAIT case doing a trylock?  That seems wrong.
>>
>> --Andy
>>
>
>  I saw the same warning coming from the bluetooth stack, see the thread
> http://article.gmane.org/gmane.linux.kernel/1950940 and
> http://article.gmane.org/gmane.linux.kernel/1940130.
> At least in the bluetooth case, the conclusion was the firmware request
> should not be happening at that point in time and the reset_resume function
> should be implemented instead. I put that work aside and haven't picked
> it up again.

That's exactly the issue I'm seeing, and I think you're right.

Still, I think the firmware_class code is wrong, too.  If it wants to
warn, it should warn that firmware was requested too early in resume.
Using trylock as an excuse to fail a firmware load seems completely
bogus to me.

>
> Thanks,
> Laura



-- 
Andy Lutomirski
AMA Capital Management, LLC