Re: [PATCH] firmware: fix async/manual firmware loading

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, Nov 10, 2016 at 7:55 AM, Greg Kroah-Hartman
<gregkh@xxxxxxxxxxxxxxxxxxx> wrote:
> On Wed, Nov 09, 2016 at 09:39:21PM +0100, Luis R. Rodriguez wrote:
>> On Sun, Oct 30, 2016 at 03:50:48PM +0100, Yves-Alexis Perez wrote:
>> > From: Yves-Alexis Perez <corsac@xxxxxxxxxx>
>> >
>> > wait_for_completion_interruptible_timeout() return value is either
>> > -ERESTARTSYS (in case it was interrupted), 0 (in case the timeout expired)
>> > or the number of jiffies left until timeout. The return value is stored in
>> > a long, but in _request_firmware_load() it's silently casted to an int,
>> > which can overflow and give a negative value, indicating an error.
>> >
>> > Fix this by re-using the timeout variable and only set retval when it's
>> > safe.
>>
>> Please amend the commit log as I noted in the previous response, and
>> resend.
>>
>> > Signed-off-by: Yves-Alexis Perez <corsac@xxxxxxxxxx>
>> > Cc: Ming Lei <ming.lei@xxxxxxxxxxxxx>
>> > Cc: "Luis R. Rodriguez" <mcgrof@xxxxxxxxxx>
>> > Cc: Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx>
>>
>> Other than the commit log you can add on you resend:
>>
>> Acked-by: Luis R. Rodriguez.
>>
>> Modulo I don't personally thing this this is sable material but I'll let
>> Greg decide.
>
> Does it fix a regression?

Not that I am aware of, but if you consider the reported the developer then yes.

> A reported issue with an older kernel version
> that people have hit?

Definitely not.

>  It shouldn't be hard to figure out if a patch should be in stable or not...

Well with the only caveat now that I am suggesting we consider remove
this logic completely as only 2 drivers were using it explicitly
(second argument to request_firmware_nowait() set to false), it seems
they had good reasons for it but ... this has been broken for ages and
we seem to be happy to compartamentalize the UMH further, its unclear
why we would want to expand and "fix" that instead of just removing
crap that never worked. Thoughts?

  Luis
--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Linux Kernel]     [Kernel Development Newbies]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Hiking]     [Linux Kernel]     [Linux SCSI]