RE: [PATCH V2] usb: gadget: f_fs: don't free buffer prematurely

[Yang, Fei]

> On Wed, Apr 24, 2019 at 9:50 AM Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx> 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@xxxxxxxxxx> wrote:
> > > > On Wed, Mar 20, 2019 at 9:40 AM John Stultz <john.stultz@xxxxxxxxxx> wrote:
> > > > > On Tue, Mar 19, 2019 at 10:32 PM <fei.yang@xxxxxxxxx> 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.