From: John Stultz <john.stultz@linaro.org>
To: "Yang, Fei" <fei.yang@intel.com>
Cc: Greg KH <gregkh@linuxfoundation.org>,
Felipe Balbi <balbi@kernel.org>,
"andrzej.p@collabora.com" <andrzej.p@collabora.com>,
Vincent Pelletier <plr.vincent@gmail.com>,
Linux USB List <linux-usb@vger.kernel.org>,
lkml <linux-kernel@vger.kernel.org>, Josh Gao <jmgao@google.com>,
Alistair Strachan <astrachan@google.com>,
"Shen, JingX" <jingx.shen@intel.com>,
Alan Stern <stern@rowland.harvard.edu>
Subject: Re: [PATCH V2] usb: gadget: f_fs: don't free buffer prematurely
Date: Thu, 25 Apr 2019 09:19:34 -0700 [thread overview]
Message-ID: <CALAqxLXqn4jtdJgH56mnbnGFuD4ei8zHmB5Q5QnbaLLux9fpHA@mail.gmail.com> (raw)
In-Reply-To: <02E7334B1630744CBDC55DA8586225837F82FB35@ORSMSX102.amr.corp.intel.com>
On Thu, Apr 25, 2019 at 9:01 AM Yang, Fei <fei.yang@intel.com> wrote:
>
> > On Wed, Apr 24, 2019 at 9:50 AM Greg KH <gregkh@linuxfoundation.org> wrote:
> > >
> > > On Tue, Apr 02, 2019 at 10:26:51AM +0700, John Stultz wrote:
> > > > On Wed, Mar 20, 2019 at 11:21 AM John Stultz <john.stultz@linaro.org> wrote:
> > > > > On Wed, Mar 20, 2019 at 9:40 AM John Stultz <john.stultz@linaro.org> wrote:
> > > > > > On Tue, Mar 19, 2019 at 10:32 PM <fei.yang@intel.com> wrote:
> > > > > > Elsewhere it seems the ffs driver takes effort to drop any locks
> > > > > > before calling usb_ep_dequeue(), so this seems like that should
> > > > > > be addressed, but it also seems like recent change to the dwc3
> > > > > > driver has been made to avoid sleeping in that path (see fec9095bdef4 ("usb:
> > > > > > dwc3: gadget: remove wait_end_transfer")), which may be why I'm
> > > > > > not seeing the problem with mainline (and your patch here, of coarse).
> > > > > > But that also doesn't clarify if its still a potential issue w/
> > > > > > non-dwc3 platforms.
> > > > >
> > > > > Felipe: Given Alan's point, does it make sense to mark the commits
> > > > > that remove the possible sleep from wait_event_lock_irq() in
> > > > > dwc3_gadget_ep_dequeue() for -stable?
> > > > >
> > > > > Against 4.19.30, the following set manages to cherry-pick cleanly:
> > > > > git cherry-pick 1a22ec643580626f439c8583edafdcc73798f2fb
> > > > > git cherry-pick 09fe1f8d7e2f461275b1cdd832f2cfa5e9be346d
> > > > > git cherry-pick c3acd59014148470dc58519870fbc779785b4bf7
> > > > > git cherry-pick 7746a8dfb3f9c91b3a0b63a1d5c2664410e6498d
> > > > > git cherry-pick d5443bbf5fc8f8389cce146b1fc2987cdd229d12
> > > > > git cherry-pick d4f1afe5e896c18ae01099a85dab5e1a198bd2a8
> > > > > git cherry-pick fec9095bdef4e7c988adb603d0d4f92ee735d4a1
> > > > > # To get things building, revert modified -stable fix git revert
> > > > > 25ad17d #pick actual upstream fix replacing the previous git
> > > > > cherry-pick bd6742249b9ca918565e4e3abaa06665e587f4b5
> > > > >
> > > > > (Though I'm always a bit hesitant with -stable backports on
> > > > > subsystems I don't know well. So I'm not sure if this set is fully
> > > > > correct.)
> > > > >
> > > > > This set seems to avoid the crash on reboot I was seeing.
> > > > >
> > > > > And of course, I'm sure getting that set backported to 4.14 and
> > > > > 4.9 (and maybe even 4.4, I need to check) will be less clean.
> > > >
> > > > Also, I just wanted to follow up on this as well. Does the above
> > > > set of cherry-picks look ok to others for 4.19-stable? Does anyone
> > > > have suggestions on how they'd like to see backports to 4.14, 4.9 and 4.4?
> > >
> > > If they are ok, can someone send me the commits as a series of
> > > patches, as doing the above really doesn't help much :)
> >
> > Yea, so I'm happy to send that set to you for 4.19, assuming Felipe or someone else OKs it.
> > I'm still at a bit of a loss for what to do for older (4.14/4.9/4.4) -stable kernels, as its going to be difficult to backport those.
>
> The patch mentioned in the title of this thread doesn't apply to older kernels. The kernel panic was introduced in 5.0-rcX.
Right. On older kernels there was a separate issue that seems to be
dwc3 specific that was biting me in a similar way. That's what the sha
list above references.
thanks
-john
WARNING: multiple messages have this Message-ID (diff)
From: John Stultz <john.stultz@linaro.org>
To: "Yang, Fei" <fei.yang@intel.com>
Cc: Greg KH <gregkh@linuxfoundation.org>,
Felipe Balbi <balbi@kernel.org>,
"andrzej.p@collabora.com" <andrzej.p@collabora.com>,
Vincent Pelletier <plr.vincent@gmail.com>,
Linux USB List <linux-usb@vger.kernel.org>,
lkml <linux-kernel@vger.kernel.org>, Josh Gao <jmgao@google.com>,
Alistair Strachan <astrachan@google.com>,
"Shen, JingX" <jingx.shen@intel.com>,
Alan Stern <stern@rowland.harvard.edu>
Subject: [V2] usb: gadget: f_fs: don't free buffer prematurely
Date: Thu, 25 Apr 2019 09:19:34 -0700 [thread overview]
Message-ID: <CALAqxLXqn4jtdJgH56mnbnGFuD4ei8zHmB5Q5QnbaLLux9fpHA@mail.gmail.com> (raw)
On Thu, Apr 25, 2019 at 9:01 AM Yang, Fei <fei.yang@intel.com> wrote:
>
> > On Wed, Apr 24, 2019 at 9:50 AM Greg KH <gregkh@linuxfoundation.org> wrote:
> > >
> > > On Tue, Apr 02, 2019 at 10:26:51AM +0700, John Stultz wrote:
> > > > On Wed, Mar 20, 2019 at 11:21 AM John Stultz <john.stultz@linaro.org> wrote:
> > > > > On Wed, Mar 20, 2019 at 9:40 AM John Stultz <john.stultz@linaro.org> wrote:
> > > > > > On Tue, Mar 19, 2019 at 10:32 PM <fei.yang@intel.com> wrote:
> > > > > > Elsewhere it seems the ffs driver takes effort to drop any locks
> > > > > > before calling usb_ep_dequeue(), so this seems like that should
> > > > > > be addressed, but it also seems like recent change to the dwc3
> > > > > > driver has been made to avoid sleeping in that path (see fec9095bdef4 ("usb:
> > > > > > dwc3: gadget: remove wait_end_transfer")), which may be why I'm
> > > > > > not seeing the problem with mainline (and your patch here, of coarse).
> > > > > > But that also doesn't clarify if its still a potential issue w/
> > > > > > non-dwc3 platforms.
> > > > >
> > > > > Felipe: Given Alan's point, does it make sense to mark the commits
> > > > > that remove the possible sleep from wait_event_lock_irq() in
> > > > > dwc3_gadget_ep_dequeue() for -stable?
> > > > >
> > > > > Against 4.19.30, the following set manages to cherry-pick cleanly:
> > > > > git cherry-pick 1a22ec643580626f439c8583edafdcc73798f2fb
> > > > > git cherry-pick 09fe1f8d7e2f461275b1cdd832f2cfa5e9be346d
> > > > > git cherry-pick c3acd59014148470dc58519870fbc779785b4bf7
> > > > > git cherry-pick 7746a8dfb3f9c91b3a0b63a1d5c2664410e6498d
> > > > > git cherry-pick d5443bbf5fc8f8389cce146b1fc2987cdd229d12
> > > > > git cherry-pick d4f1afe5e896c18ae01099a85dab5e1a198bd2a8
> > > > > git cherry-pick fec9095bdef4e7c988adb603d0d4f92ee735d4a1
> > > > > # To get things building, revert modified -stable fix git revert
> > > > > 25ad17d #pick actual upstream fix replacing the previous git
> > > > > cherry-pick bd6742249b9ca918565e4e3abaa06665e587f4b5
> > > > >
> > > > > (Though I'm always a bit hesitant with -stable backports on
> > > > > subsystems I don't know well. So I'm not sure if this set is fully
> > > > > correct.)
> > > > >
> > > > > This set seems to avoid the crash on reboot I was seeing.
> > > > >
> > > > > And of course, I'm sure getting that set backported to 4.14 and
> > > > > 4.9 (and maybe even 4.4, I need to check) will be less clean.
> > > >
> > > > Also, I just wanted to follow up on this as well. Does the above
> > > > set of cherry-picks look ok to others for 4.19-stable? Does anyone
> > > > have suggestions on how they'd like to see backports to 4.14, 4.9 and 4.4?
> > >
> > > If they are ok, can someone send me the commits as a series of
> > > patches, as doing the above really doesn't help much :)
> >
> > Yea, so I'm happy to send that set to you for 4.19, assuming Felipe or someone else OKs it.
> > I'm still at a bit of a loss for what to do for older (4.14/4.9/4.4) -stable kernels, as its going to be difficult to backport those.
>
> The patch mentioned in the title of this thread doesn't apply to older kernels. The kernel panic was introduced in 5.0-rcX.
Right. On older kernels there was a separate issue that seems to be
dwc3 specific that was biting me in a similar way. That's what the sha
list above references.
thanks
-john
next prev parent reply other threads:[~2019-04-25 16:19 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-03-20 5:32 [PATCH V2] usb: gadget: f_fs: don't free buffer prematurely fei.yang
2019-03-20 5:32 ` [V2] " fei.yang
2019-03-20 5:56 ` [PATCH V2] " Josh Gao
2019-03-20 5:56 ` [V2] " Josh Gao
2019-03-20 5:59 ` [PATCH V2] " Josh Gao
2019-03-20 5:59 ` [V2] " Josh Gao
2019-03-20 17:30 ` [PATCH V2] " Yang, Fei
2019-03-20 17:30 ` [V2] " fei.yang
2019-03-20 16:40 ` [PATCH V2] " John Stultz
2019-03-20 16:40 ` [V2] " John Stultz
2019-03-20 16:52 ` [PATCH V2] " Alan Stern
2019-03-20 16:52 ` [V2] " Alan Stern
2019-03-20 16:55 ` [PATCH V2] " John Stultz
2019-03-20 16:55 ` [V2] " John Stultz
2019-03-20 18:21 ` [PATCH V2] " John Stultz
2019-03-20 18:21 ` [V2] " John Stultz
2019-04-02 3:26 ` [PATCH V2] " John Stultz
2019-04-02 3:26 ` [V2] " John Stultz
2019-04-24 16:50 ` [PATCH V2] " Greg KH
2019-04-24 16:50 ` [V2] " Greg Kroah-Hartman
2019-04-25 3:53 ` [PATCH V2] " John Stultz
2019-04-25 3:53 ` [V2] " John Stultz
2019-04-25 16:01 ` [PATCH V2] " Yang, Fei
2019-04-25 16:01 ` [V2] " fei.yang
2019-04-25 16:19 ` John Stultz [this message]
2019-04-25 16:19 ` John Stultz
2019-03-20 23:28 ` [PATCH V2] " Yang, Fei
2019-03-20 23:28 ` [V2] " fei.yang
2019-03-20 23:42 ` [PATCH V2] " John Stultz
2019-03-20 23:42 ` [V2] " John Stultz
2019-04-02 3:25 ` [PATCH V2] " John Stultz
2019-04-02 3:25 ` [V2] " John Stultz
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CALAqxLXqn4jtdJgH56mnbnGFuD4ei8zHmB5Q5QnbaLLux9fpHA@mail.gmail.com \
--to=john.stultz@linaro.org \
--cc=andrzej.p@collabora.com \
--cc=astrachan@google.com \
--cc=balbi@kernel.org \
--cc=fei.yang@intel.com \
--cc=gregkh@linuxfoundation.org \
--cc=jingx.shen@intel.com \
--cc=jmgao@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=plr.vincent@gmail.com \
--cc=stern@rowland.harvard.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.