[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20170330040643.GO28800@wotan.suse.de>
Date: Thu, 30 Mar 2017 06:06:43 +0200
From: "Luis R. Rodriguez" <mcgrof@...nel.org>
To: Ben Gamari <ben@...rt-cactus.org>
Cc: Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Yves-Alexis Perez <corsac@...sac.net>,
linux-kernel@...r.kernel.org, stable@...r.kernel.org,
"Luis R. Rodriguez" <mcgrof@...nel.org>,
Ming Lei <ming.lei@...onical.com>,
Bjorn Andersson <bjorn.andersson@...aro.org>
Subject: Re: [PATCH 4.8 50/96] firmware: fix usermode helper fallback loading
On Fri, Mar 24, 2017 at 04:01:58PM -0400, Ben Gamari wrote:
> Greg Kroah-Hartman <gregkh@...uxfoundation.org> writes:
>
> > On Fri, Jan 06, 2017 at 10:54:38PM +0100, Yves-Alexis Perez wrote:
> >> On Fri, 2017-01-06 at 22:43 +0100, Greg Kroah-Hartman wrote:
> >> > 4.8-stable review patch. If anyone has any objections, please let me know.
> >>
> >> Hi Greg,
> >>
> >> Ben Gamari think there was a regression in that patch so I'm adding him to
> >> recipients so he can voice concerns if needed.
> >
> > Given the lack of response, I'm going to assume all is fine :)
> >
> Oh dear, sorry for the late response; this was stuck in the pergatory of
> my inbox.
>
> It's been a while since I've looked at this, but I believe the alleged
> regression in this pastch is the reason I have the attached patch in my
> tree. I seem to recall that it was the ath10k driver which triggered the
> issue.
>
> Unfortunately I can't recall which driver was affected by this. I'll
> have to see what happens when I revert the attached patch.
>
> Cheers,
>
> - Ben
>
>
>
> Author: Ben Gamari <ben@...rt-cactus.org>
> Date: Mon Jan 2 00:38:05 2017 -0500
>
> firmware_class: Ensure buf is non-NULL in __fw_load_abort
>
> I have observed that this can be NULL.
>
> diff --git a/drivers/base/firmware_class.c b/drivers/base/firmware_class.c
> index ac350c518e0c..fd0be24911fc 100644
> --- a/drivers/base/firmware_class.c
> +++ b/drivers/base/firmware_class.c
> @@ -546,7 +546,8 @@ static void __fw_load_abort(struct firmware_buf *buf)
> * There is a small window in which user can write to 'loading'
> * between loading done and disappearance of 'loading'
> */
> - if (fw_state_is_done(&buf->fw_st))
> +
> + if (!buf || fw_state_is_done(&buf->fw_st))
> return;
>
> list_del_init(&buf->pending_list);
We discussed this a while back and went with a more elegant fix, see:
commit 191e885a2e130e639bb0c8ee350d7047294f2ce6
Luis
Powered by blists - more mailing lists