Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1295578 > unrolled thread

firmware_class warnings on resume

Back to article view | Back to linux.kernel

Contents

  firmware_class warnings on resume Andy Lutomirski <luto@amacapital.net> - 2015-12-20 13:30 +0100
    Re: firmware_class warnings on resume Laura Abbott <labbott@redhat.com> - 2015-12-21 19:00 +0100
      Re: firmware_class warnings on resume Andy Lutomirski <luto@amacapital.net> - 2015-12-21 23:50 +0100

#1295578 — firmware_class warnings on resume

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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [next] | [standalone]

#1296124

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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1296268

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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web