* Backporting dwc3 gadget fixes
@ 2019-01-23 0:37 Evan Green
2019-01-23 6:32 ` Felipe Balbi
0 siblings, 1 reply; 9+ messages in thread
From: Evan Green @ 2019-01-23 0:37 UTC (permalink / raw)
To: stable, Felipe Balbi
Cc: Alan Stern, Sam Protsenko, bo.he, Doug Anderson, Stephen Boyd,
Matthias Kaehlcke
Hello stablers,
With the following revert being backported to stable:
a9c859033f6ec Revert "usb: gadget: ffs: Fix BUG when userland exits
with submitted AIO transfers"
The original bug it fixed is back. I wonder if we should be
backporting the series that seems to quietly fix that issue:
fec9095bdef4e usb: dwc3: gadget: remove wait_end_transfer
d4f1afe5e896c usb: dwc3: gadget: move requests to cancelled_list
d5443bbf5fc8f usb: dwc3: gadget: introduce cancelled_list
7746a8dfb3f9c usb: dwc3: gadget: extract dwc3_gadget_ep_skip_trbs()
c3acd59014148 usb: dwc3: gadget: use num_trbs when skipping TRBs on ->dequeue()
09fe1f8d7e2f4 usb: dwc3: gadget: track number of TRBs per request
1a22ec6435806 usb: dwc3: gadget: combine unaligned and zero flags
(Patch 1/8 of the original series was already backported). I know we
saw this with 4.19, I'm not sure which other versions it would go
into.
I'll re-paste the stack from the original commit that got reverted. I
can easily reproduce this by connecting a host when our device is in
gadget mode, then attempting to gracefully reboot the system:
[ 382.200896] BUG: scheduling while atomic: screen/1808/0x00000100
[ 382.207124] 4 locks held by screen/1808:
[ 382.211266] #0: (rcu_callback){....}, at: [<c10b4ff0>]
rcu_process_callbacks+0x260/0x440
[ 382.219949] #1: (rcu_read_lock_sched){....}, at: [<c1358ba0>]
percpu_ref_switch_to_atomic_rcu+0xb0/0x130
[ 382.230034] #2: (&(&ctx->ctx_lock)->rlock){....}, at:
[<c11f0c73>] free_ioctx_users+0x23/0xd0
[ 382.230096] #3: (&(&ffs->eps_lock)->rlock){....}, at:
[<f81e7710>] ffs_aio_cancel+0x20/0x60 [usb_f_fs]
[ 382.230160] Modules linked in: usb_f_fs libcomposite configfs bnep
btsdio bluetooth ecdh_generic brcmfmac brcmutil intel_powerclamp
coretemp dwc3 kvm_intel ulpi udc_core kvm irqbypass crc32_pclmul
crc32c_intel pcbc dwc3_pci aesni_intel aes_i586 crypto_simd cryptd
ehci_pci ehci_hcd gpio_keys usbcore basincove_gpadc industrialio
usb_common
[ 382.230407] CPU: 1 PID: 1808 Comm: screen Not tainted 4.14.0-edison+ #117
[ 382.230416] Hardware name: Intel Corporation Merrifield/BODEGA BAY,
BIOS 542 2015.01.21:18.19.48
[ 382.230425] Call Trace:
[ 382.230438] <SOFTIRQ>
[ 382.230466] dump_stack+0x47/0x62
[ 382.230498] __schedule_bug+0x61/0x80
[ 382.230522] __schedule+0x43/0x7a0
[ 382.230587] schedule+0x5f/0x70
[ 382.230625] dwc3_gadget_ep_dequeue+0x14c/0x270 [dwc3]
[ 382.230669] ? do_wait_intr_irq+0x70/0x70
[ 382.230724] usb_ep_dequeue+0x19/0x90 [udc_core]
[ 382.230770] ffs_aio_cancel+0x37/0x60 [usb_f_fs]
[ 382.230798] kiocb_cancel+0x31/0x40
[ 382.230822] free_ioctx_users+0x4d/0xd0
[ 382.230858] percpu_ref_switch_to_atomic_rcu+0x10a/0x130
[ 382.230881] ? percpu_ref_exit+0x40/0x40
[ 382.230904] rcu_process_callbacks+0x2b3/0x440
[ 382.230965] __do_softirq+0xf8/0x26b
[ 382.231011] ? __softirqentry_text_start+0x8/0x8
[ 382.231033] do_softirq_own_stack+0x22/0x30
[ 382.231042] </SOFTIRQ>
[ 382.231071] irq_exit+0x45/0xc0
[ 382.231089] smp_apic_timer_interrupt+0x13c/0x150
[ 382.231118] apic_timer_interrupt+0x35/0x3c
Felipe/others, any thoughts about this?
-Evan
^ permalink raw reply [flat|nested] 9+ messages in thread* Re: Backporting dwc3 gadget fixes 2019-01-23 0:37 Backporting dwc3 gadget fixes Evan Green @ 2019-01-23 6:32 ` Felipe Balbi 2019-01-23 6:55 ` He, Bo 0 siblings, 1 reply; 9+ messages in thread From: Felipe Balbi @ 2019-01-23 6:32 UTC (permalink / raw) To: Evan Green, stable Cc: Alan Stern, Sam Protsenko, bo.he, Doug Anderson, Stephen Boyd, Matthias Kaehlcke [-- Attachment #1: Type: text/plain, Size: 1227 bytes --] Hi Evan, Evan Green <evgreen@google.com> writes: > Hello stablers, > > With the following revert being backported to stable: > a9c859033f6ec Revert "usb: gadget: ffs: Fix BUG when userland exits > with submitted AIO transfers" > > The original bug it fixed is back. I wonder if we should be Is it so that the original bug only happens with dwc3? If so, then we should definitely backport the series below. > backporting the series that seems to quietly fix that issue: > fec9095bdef4e usb: dwc3: gadget: remove wait_end_transfer > d4f1afe5e896c usb: dwc3: gadget: move requests to cancelled_list > d5443bbf5fc8f usb: dwc3: gadget: introduce cancelled_list > 7746a8dfb3f9c usb: dwc3: gadget: extract dwc3_gadget_ep_skip_trbs() > c3acd59014148 usb: dwc3: gadget: use num_trbs when skipping TRBs on ->dequeue() > 09fe1f8d7e2f4 usb: dwc3: gadget: track number of TRBs per request > 1a22ec6435806 usb: dwc3: gadget: combine unaligned and zero flags > > (Patch 1/8 of the original series was already backported). I know we > saw this with 4.19, I'm not sure which other versions it would go > into. We could ask Greg to backport at least for v4.14. I'm not sure this applies to v4.9. -- balbi [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 832 bytes --] ^ permalink raw reply [flat|nested] 9+ messages in thread
* RE: Backporting dwc3 gadget fixes 2019-01-23 6:32 ` Felipe Balbi @ 2019-01-23 6:55 ` He, Bo 2019-01-23 18:46 ` Evan Green 0 siblings, 1 reply; 9+ messages in thread From: He, Bo @ 2019-01-23 6:55 UTC (permalink / raw) To: Felipe Balbi, Evan Green, stable Cc: Alan Stern, Sam Protsenko, Doug Anderson, Stephen Boyd, Matthias Kaehlcke the issue is not seen on 4.9, I check the commit cf3113d8 is first introduced in kernel 4.11-rc2. commit cf3113d893d4427b166ec8695460efa7aa660923 Author: Felipe Balbi <felipe.balbi@linux.intel.com> Date: Fri Feb 17 11:12:44 2017 +0200 usb: dwc3: gadget: properly increment dequeue pointer on ep_dequeue If request was already started, this means we had to stop the transfer. With that we also need to ignore all TRBs used by the request, however TRBs can only be modified after completion of END_TRANSFER command. So what we have to do here is wait for END_TRANSFER completion and only after that jump over TRBs by clearing HWO and incrementing dequeue pointer. Note that we have 2 possible types of transfers here: i) Linear buffer request ii) SG-list based request SG-list based requests will have r->num_pending_sgs set to a valid number (> 0). Linear requests, normally use a single TRB. For each of these two cases, if r->unaligned flag is set, one extra TRB has been used to align transfer size to wMaxPacketSize. All of these cases need to be taken into consideration so we don't mess up our TRB ring pointers. Tested-by: Janusz Dziedzic <januszx.dziedzic@intel.com> Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com> -----Original Message----- From: Felipe Balbi <felipe.balbi@linux.intel.com> Sent: Wednesday, January 23, 2019 2:32 PM To: Evan Green <evgreen@google.com>; stable@vger.kernel.org Cc: Alan Stern <stern@rowland.harvard.edu>; Sam Protsenko <semen.protsenko@linaro.org>; He, Bo <bo.he@intel.com>; Doug Anderson <dianders@chromium.org>; Stephen Boyd <swboyd@chromium.org>; Matthias Kaehlcke <mka@chromium.org> Subject: Re: Backporting dwc3 gadget fixes Hi Evan, Evan Green <evgreen@google.com> writes: > Hello stablers, > > With the following revert being backported to stable: > a9c859033f6ec Revert "usb: gadget: ffs: Fix BUG when userland exits > with submitted AIO transfers" > > The original bug it fixed is back. I wonder if we should be Is it so that the original bug only happens with dwc3? If so, then we should definitely backport the series below. > backporting the series that seems to quietly fix that issue: > fec9095bdef4e usb: dwc3: gadget: remove wait_end_transfer > d4f1afe5e896c usb: dwc3: gadget: move requests to cancelled_list > d5443bbf5fc8f usb: dwc3: gadget: introduce cancelled_list > 7746a8dfb3f9c usb: dwc3: gadget: extract dwc3_gadget_ep_skip_trbs() > c3acd59014148 usb: dwc3: gadget: use num_trbs when skipping TRBs on > ->dequeue() > 09fe1f8d7e2f4 usb: dwc3: gadget: track number of TRBs per request > 1a22ec6435806 usb: dwc3: gadget: combine unaligned and zero flags > > (Patch 1/8 of the original series was already backported). I know we > saw this with 4.19, I'm not sure which other versions it would go > into. We could ask Greg to backport at least for v4.14. I'm not sure this applies to v4.9. -- balbi ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Backporting dwc3 gadget fixes 2019-01-23 6:55 ` He, Bo @ 2019-01-23 18:46 ` Evan Green 2019-01-29 10:22 ` Greg KH 0 siblings, 1 reply; 9+ messages in thread From: Evan Green @ 2019-01-23 18:46 UTC (permalink / raw) To: He, Bo Cc: Felipe Balbi, stable, Alan Stern, Sam Protsenko, Doug Anderson, Stephen Boyd, Matthias Kaehlcke Hi Felipe, Well, I've only tried on the one device that has a dwc3 controller. Given that the bug was "scheduling while atomic", the stack trace always had dwc3_gadget_ep_dequeue doing the sleeping, and it only happened when I had a gadget plugged in, I felt pretty solid that this was the same bug. Also, Matthias pointed out I was looking at an older series when I was figuring out which patches went together. Check my work, but the series seems to be here: https://patchwork.kernel.org/project/linux-usb/list/?series=42875 The first 3 patches are already backported. Then there were a couple extra I had missed before. So the complete set would look like: d53701067f04 usb: dwc3: gadget: check if dep->frame_number is still valid 3451f6affaef usb: dwc3: gadget: remove unnecessary dev_info() 1517265228b4 usb: dwc3: trace: log ep commands in hex 25abad6a0584 usb: dwc3: gadget: return errors from __dwc3_gadget_start_isoc() fec9095bdef4e usb: dwc3: gadget: remove wait_end_transfer d4f1afe5e896c usb: dwc3: gadget: move requests to cancelled_list d5443bbf5fc8f usb: dwc3: gadget: introduce cancelled_list 7746a8dfb3f9c usb: dwc3: gadget: extract dwc3_gadget_ep_skip_trbs() c3acd59014148 usb: dwc3: gadget: use num_trbs when skipping TRBs on ->dequeue() 09fe1f8d7e2f4 usb: dwc3: gadget: track number of TRBs per request 1a22ec6435806 usb: dwc3: gadget: combine unaligned and zero flags Though perhaps only the stuff up through "move requests to cancelled_list" is the important stuff... Felipe might be able to say better. -Evan ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Backporting dwc3 gadget fixes 2019-01-23 18:46 ` Evan Green @ 2019-01-29 10:22 ` Greg KH 2019-01-29 19:15 ` Evan Green 0 siblings, 1 reply; 9+ messages in thread From: Greg KH @ 2019-01-29 10:22 UTC (permalink / raw) To: Evan Green Cc: He, Bo, Felipe Balbi, stable, Alan Stern, Sam Protsenko, Doug Anderson, Stephen Boyd, Matthias Kaehlcke On Wed, Jan 23, 2019 at 10:46:52AM -0800, Evan Green wrote: > Hi Felipe, > Well, I've only tried on the one device that has a dwc3 controller. > Given that the bug was "scheduling while atomic", the stack trace > always had dwc3_gadget_ep_dequeue doing the sleeping, and it only > happened when I had a gadget plugged in, I felt pretty solid that this > was the same bug. > > Also, Matthias pointed out I was looking at an older series when I was > figuring out which patches went together. Check my work, but the > series seems to be here: > https://patchwork.kernel.org/project/linux-usb/list/?series=42875 > > The first 3 patches are already backported. Then there were a couple > extra I had missed before. So the complete set would look like: > > d53701067f04 usb: dwc3: gadget: check if dep->frame_number is still valid > 3451f6affaef usb: dwc3: gadget: remove unnecessary dev_info() > 1517265228b4 usb: dwc3: trace: log ep commands in hex > 25abad6a0584 usb: dwc3: gadget: return errors from __dwc3_gadget_start_isoc() > fec9095bdef4e usb: dwc3: gadget: remove wait_end_transfer > d4f1afe5e896c usb: dwc3: gadget: move requests to cancelled_list > d5443bbf5fc8f usb: dwc3: gadget: introduce cancelled_list > 7746a8dfb3f9c usb: dwc3: gadget: extract dwc3_gadget_ep_skip_trbs() > c3acd59014148 usb: dwc3: gadget: use num_trbs when skipping TRBs on ->dequeue() > 09fe1f8d7e2f4 usb: dwc3: gadget: track number of TRBs per request > 1a22ec6435806 usb: dwc3: gadget: combine unaligned and zero flags > > Though perhaps only the stuff up through "move requests to > cancelled_list" is the important stuff... Felipe might be able to say > better. Can someone send me a correct list of exactly what patches to commit, to what kernel tree(s), and in what order? Ideally you would have also tested them yourself... As it is, this "random list of commits" doesn't make me feel good about backporting. thanks, greg k-h ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Backporting dwc3 gadget fixes 2019-01-29 10:22 ` Greg KH @ 2019-01-29 19:15 ` Evan Green 2019-02-04 9:11 ` Greg KH 0 siblings, 1 reply; 9+ messages in thread From: Evan Green @ 2019-01-29 19:15 UTC (permalink / raw) To: Greg KH Cc: He, Bo, Felipe Balbi, stable, Alan Stern, Sam Protsenko, Doug Anderson, Stephen Boyd, Matthias Kaehlcke On Tue, Jan 29, 2019 at 2:22 AM Greg KH <gregkh@linuxfoundation.org> wrote: > > On Wed, Jan 23, 2019 at 10:46:52AM -0800, Evan Green wrote: > > Hi Felipe, > > Well, I've only tried on the one device that has a dwc3 controller. > > Given that the bug was "scheduling while atomic", the stack trace > > always had dwc3_gadget_ep_dequeue doing the sleeping, and it only > > happened when I had a gadget plugged in, I felt pretty solid that this > > was the same bug. > > > > Also, Matthias pointed out I was looking at an older series when I was > > figuring out which patches went together. Check my work, but the > > series seems to be here: > > https://patchwork.kernel.org/project/linux-usb/list/?series=42875 > > > > The first 3 patches are already backported. Then there were a couple > > extra I had missed before. So the complete set would look like: > > > > d53701067f04 usb: dwc3: gadget: check if dep->frame_number is still valid > > 3451f6affaef usb: dwc3: gadget: remove unnecessary dev_info() > > 1517265228b4 usb: dwc3: trace: log ep commands in hex > > 25abad6a0584 usb: dwc3: gadget: return errors from __dwc3_gadget_start_isoc() > > fec9095bdef4e usb: dwc3: gadget: remove wait_end_transfer > > d4f1afe5e896c usb: dwc3: gadget: move requests to cancelled_list > > d5443bbf5fc8f usb: dwc3: gadget: introduce cancelled_list > > 7746a8dfb3f9c usb: dwc3: gadget: extract dwc3_gadget_ep_skip_trbs() > > c3acd59014148 usb: dwc3: gadget: use num_trbs when skipping TRBs on ->dequeue() > > 09fe1f8d7e2f4 usb: dwc3: gadget: track number of TRBs per request > > 1a22ec6435806 usb: dwc3: gadget: combine unaligned and zero flags > > > > Though perhaps only the stuff up through "move requests to > > cancelled_list" is the important stuff... Felipe might be able to say > > better. > > Can someone send me a correct list of exactly what patches to commit, to > what kernel tree(s), and in what order? Ideally you would have also > tested them yourself... > > As it is, this "random list of commits" doesn't make me feel good about > backporting. Ok here's my recommendation, in short form: cherry-pick 1dbcd8d42c02..fec9095bdef4 to 4.19. Long form rationale below: The series these fixes came from is this: https://patchwork.kernel.org/project/linux-usb/list/?series=42875 The first three are already in stable. I recommend picking the below commits, which I've listed in git log order, so the apply order would be bottom-up: fec9095bdef4e usb: dwc3: gadget: remove wait_end_transfer d4f1afe5e896c usb: dwc3: gadget: move requests to cancelled_list d5443bbf5fc8f usb: dwc3: gadget: introduce cancelled_list 7746a8dfb3f9c usb: dwc3: gadget: extract dwc3_gadget_ep_skip_trbs() c3acd59014148 usb: dwc3: gadget: use num_trbs when skipping TRBs on ->dequeue() 09fe1f8d7e2f4 usb: dwc3: gadget: track number of TRBs per request 1a22ec6435806 usb: dwc3: gadget: combine unaligned and zero flags The remaining commits of the series appear to me to fix a different problem from the crash I'm seeing. Plus, this commit: 25abad6a0584 usb: dwc3: gadget: return errors from __dwc3_gadget_start_isoc() won't apply cleanly without first taking this commit: d92021f66063 usb: dwc3: Add workaround for isoc start transfer failure The patches I'm recommending apply cleanly on linux-stable/linux-4.19.y. For 4.14, the landscape has shifted around so much that these patches don't apply cleanly. I was able to fix them up manually, and could send that out if desired, but I'm not able to test chose changes. -Evan ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Backporting dwc3 gadget fixes 2019-01-29 19:15 ` Evan Green @ 2019-02-04 9:11 ` Greg KH 2019-02-04 21:13 ` Evan Green 0 siblings, 1 reply; 9+ messages in thread From: Greg KH @ 2019-02-04 9:11 UTC (permalink / raw) To: Evan Green Cc: He, Bo, Felipe Balbi, stable, Alan Stern, Sam Protsenko, Doug Anderson, Stephen Boyd, Matthias Kaehlcke On Tue, Jan 29, 2019 at 11:15:50AM -0800, Evan Green wrote: > On Tue, Jan 29, 2019 at 2:22 AM Greg KH <gregkh@linuxfoundation.org> wrote: > > > > On Wed, Jan 23, 2019 at 10:46:52AM -0800, Evan Green wrote: > > > Hi Felipe, > > > Well, I've only tried on the one device that has a dwc3 controller. > > > Given that the bug was "scheduling while atomic", the stack trace > > > always had dwc3_gadget_ep_dequeue doing the sleeping, and it only > > > happened when I had a gadget plugged in, I felt pretty solid that this > > > was the same bug. > > > > > > Also, Matthias pointed out I was looking at an older series when I was > > > figuring out which patches went together. Check my work, but the > > > series seems to be here: > > > https://patchwork.kernel.org/project/linux-usb/list/?series=42875 > > > > > > The first 3 patches are already backported. Then there were a couple > > > extra I had missed before. So the complete set would look like: > > > > > > d53701067f04 usb: dwc3: gadget: check if dep->frame_number is still valid > > > 3451f6affaef usb: dwc3: gadget: remove unnecessary dev_info() > > > 1517265228b4 usb: dwc3: trace: log ep commands in hex > > > 25abad6a0584 usb: dwc3: gadget: return errors from __dwc3_gadget_start_isoc() > > > fec9095bdef4e usb: dwc3: gadget: remove wait_end_transfer > > > d4f1afe5e896c usb: dwc3: gadget: move requests to cancelled_list > > > d5443bbf5fc8f usb: dwc3: gadget: introduce cancelled_list > > > 7746a8dfb3f9c usb: dwc3: gadget: extract dwc3_gadget_ep_skip_trbs() > > > c3acd59014148 usb: dwc3: gadget: use num_trbs when skipping TRBs on ->dequeue() > > > 09fe1f8d7e2f4 usb: dwc3: gadget: track number of TRBs per request > > > 1a22ec6435806 usb: dwc3: gadget: combine unaligned and zero flags > > > > > > Though perhaps only the stuff up through "move requests to > > > cancelled_list" is the important stuff... Felipe might be able to say > > > better. > > > > Can someone send me a correct list of exactly what patches to commit, to > > what kernel tree(s), and in what order? Ideally you would have also > > tested them yourself... > > > > As it is, this "random list of commits" doesn't make me feel good about > > backporting. > > Ok here's my recommendation, in short form: cherry-pick > 1dbcd8d42c02..fec9095bdef4 to 4.19. > > Long form rationale below: > The series these fixes came from is this: > https://patchwork.kernel.org/project/linux-usb/list/?series=42875 > > The first three are already in stable. I recommend picking the below > commits, which I've listed in git log order, so the apply order would > be bottom-up: > fec9095bdef4e usb: dwc3: gadget: remove wait_end_transfer > d4f1afe5e896c usb: dwc3: gadget: move requests to cancelled_list > d5443bbf5fc8f usb: dwc3: gadget: introduce cancelled_list > 7746a8dfb3f9c usb: dwc3: gadget: extract dwc3_gadget_ep_skip_trbs() > c3acd59014148 usb: dwc3: gadget: use num_trbs when skipping TRBs on ->dequeue() > 09fe1f8d7e2f4 usb: dwc3: gadget: track number of TRBs per request > 1a22ec6435806 usb: dwc3: gadget: combine unaligned and zero flags This first patch here, breaks the build on 4.20 and 4.19 :( So I don't know how you tested this. Can you provide me a full patch series, properly backported, that applies to 4.20.y and 4.19.y, so that I can get this in a tested format that can be applied properly? thanks, greg k-h ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Backporting dwc3 gadget fixes 2019-02-04 9:11 ` Greg KH @ 2019-02-04 21:13 ` Evan Green 2019-02-11 13:41 ` Greg KH 0 siblings, 1 reply; 9+ messages in thread From: Evan Green @ 2019-02-04 21:13 UTC (permalink / raw) To: Greg KH Cc: He, Bo, Felipe Balbi, stable, Alan Stern, Sam Protsenko, Doug Anderson, Stephen Boyd, Matthias Kaehlcke On Mon, Feb 4, 2019 at 1:12 AM Greg KH <gregkh@linuxfoundation.org> wrote: > > On Tue, Jan 29, 2019 at 11:15:50AM -0800, Evan Green wrote: > > On Tue, Jan 29, 2019 at 2:22 AM Greg KH <gregkh@linuxfoundation.org> wrote: > > > > > > On Wed, Jan 23, 2019 at 10:46:52AM -0800, Evan Green wrote: > > > > Hi Felipe, > > > > Well, I've only tried on the one device that has a dwc3 controller. > > > > Given that the bug was "scheduling while atomic", the stack trace > > > > always had dwc3_gadget_ep_dequeue doing the sleeping, and it only > > > > happened when I had a gadget plugged in, I felt pretty solid that this > > > > was the same bug. > > > > > > > > Also, Matthias pointed out I was looking at an older series when I was > > > > figuring out which patches went together. Check my work, but the > > > > series seems to be here: > > > > https://patchwork.kernel.org/project/linux-usb/list/?series=42875 > > > > > > > > The first 3 patches are already backported. Then there were a couple > > > > extra I had missed before. So the complete set would look like: > > > > > > > > d53701067f04 usb: dwc3: gadget: check if dep->frame_number is still valid > > > > 3451f6affaef usb: dwc3: gadget: remove unnecessary dev_info() > > > > 1517265228b4 usb: dwc3: trace: log ep commands in hex > > > > 25abad6a0584 usb: dwc3: gadget: return errors from __dwc3_gadget_start_isoc() > > > > fec9095bdef4e usb: dwc3: gadget: remove wait_end_transfer > > > > d4f1afe5e896c usb: dwc3: gadget: move requests to cancelled_list > > > > d5443bbf5fc8f usb: dwc3: gadget: introduce cancelled_list > > > > 7746a8dfb3f9c usb: dwc3: gadget: extract dwc3_gadget_ep_skip_trbs() > > > > c3acd59014148 usb: dwc3: gadget: use num_trbs when skipping TRBs on ->dequeue() > > > > 09fe1f8d7e2f4 usb: dwc3: gadget: track number of TRBs per request > > > > 1a22ec6435806 usb: dwc3: gadget: combine unaligned and zero flags > > > > > > > > Though perhaps only the stuff up through "move requests to > > > > cancelled_list" is the important stuff... Felipe might be able to say > > > > better. > > > > > > Can someone send me a correct list of exactly what patches to commit, to > > > what kernel tree(s), and in what order? Ideally you would have also > > > tested them yourself... > > > > > > As it is, this "random list of commits" doesn't make me feel good about > > > backporting. > > > > Ok here's my recommendation, in short form: cherry-pick > > 1dbcd8d42c02..fec9095bdef4 to 4.19. > > > > Long form rationale below: > > The series these fixes came from is this: > > https://patchwork.kernel.org/project/linux-usb/list/?series=42875 > > > > The first three are already in stable. I recommend picking the below > > commits, which I've listed in git log order, so the apply order would > > be bottom-up: > > fec9095bdef4e usb: dwc3: gadget: remove wait_end_transfer > > d4f1afe5e896c usb: dwc3: gadget: move requests to cancelled_list > > d5443bbf5fc8f usb: dwc3: gadget: introduce cancelled_list > > 7746a8dfb3f9c usb: dwc3: gadget: extract dwc3_gadget_ep_skip_trbs() > > c3acd59014148 usb: dwc3: gadget: use num_trbs when skipping TRBs on ->dequeue() > > 09fe1f8d7e2f4 usb: dwc3: gadget: track number of TRBs per request > > 1a22ec6435806 usb: dwc3: gadget: combine unaligned and zero flags > > This first patch here, breaks the build on 4.20 and 4.19 :( > > So I don't know how you tested this. > > Can you provide me a full patch series, properly backported, that > applies to 4.20.y and 4.19.y, so that I can get this in a tested format > that can be applied properly? Darn it. This worked 6 days ago. This commit came in and wrecked me: commit 25ad17d692ad54c3c33b2a31e5ce2a82e38de14e Author: Jack Pham <jackp@codeaurora.org> AuthorDate: Thu Jan 10 12:39:55 2019 -0800 Commit: Greg Kroah-Hartman <gregkh@linuxfoundation.org> CommitDate: Thu Jan 31 08:14:42 2019 +0100 usb: dwc3: gadget: Clear req->needs_extra_trb flag on cleanup commit bd6742249b9ca918565e4e3abaa06665e587f4b5 upstream. So then the directions for 4.19 would be: 1) revert 25ad17d692ad 2) cherry-pick d92021f66063..fec9095bdef4 3) cherry-pick bd6742249b9c (which was the reverted commit, that now applies without modification from upstream). For 4.20, this would be revert 5eaf9833f5be, then cherry-pick same as above. I've got trees where I've done this below: https://chromium.googlesource.com/chromiumos/third_party/kernel/+log/refs/sandbox/evgreen/stable-4.19.y-dwc3-gadget https://chromium.googlesource.com/chromiumos/third_party/kernel/+log/refs/sandbox/evgreen/stable-4.20.y-dwc3-gadget The testing I've done on these trees is to do make allmodconfig and ensure that they build cleanly. I was also able to test merging the 4.19 one into the ChromeOS tree and reboot while a gadget was connected (which fixes the problem I was seeing before). If you'd prefer I email out patches that do the same, I'm happy to do that too. -Evan ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Backporting dwc3 gadget fixes 2019-02-04 21:13 ` Evan Green @ 2019-02-11 13:41 ` Greg KH 0 siblings, 0 replies; 9+ messages in thread From: Greg KH @ 2019-02-11 13:41 UTC (permalink / raw) To: Evan Green Cc: He, Bo, Felipe Balbi, stable, Alan Stern, Sam Protsenko, Doug Anderson, Stephen Boyd, Matthias Kaehlcke On Mon, Feb 04, 2019 at 01:13:53PM -0800, Evan Green wrote: > On Mon, Feb 4, 2019 at 1:12 AM Greg KH <gregkh@linuxfoundation.org> wrote: > > > > On Tue, Jan 29, 2019 at 11:15:50AM -0800, Evan Green wrote: > > > On Tue, Jan 29, 2019 at 2:22 AM Greg KH <gregkh@linuxfoundation.org> wrote: > > > > > > > > On Wed, Jan 23, 2019 at 10:46:52AM -0800, Evan Green wrote: > > > > > Hi Felipe, > > > > > Well, I've only tried on the one device that has a dwc3 controller. > > > > > Given that the bug was "scheduling while atomic", the stack trace > > > > > always had dwc3_gadget_ep_dequeue doing the sleeping, and it only > > > > > happened when I had a gadget plugged in, I felt pretty solid that this > > > > > was the same bug. > > > > > > > > > > Also, Matthias pointed out I was looking at an older series when I was > > > > > figuring out which patches went together. Check my work, but the > > > > > series seems to be here: > > > > > https://patchwork.kernel.org/project/linux-usb/list/?series=42875 > > > > > > > > > > The first 3 patches are already backported. Then there were a couple > > > > > extra I had missed before. So the complete set would look like: > > > > > > > > > > d53701067f04 usb: dwc3: gadget: check if dep->frame_number is still valid > > > > > 3451f6affaef usb: dwc3: gadget: remove unnecessary dev_info() > > > > > 1517265228b4 usb: dwc3: trace: log ep commands in hex > > > > > 25abad6a0584 usb: dwc3: gadget: return errors from __dwc3_gadget_start_isoc() > > > > > fec9095bdef4e usb: dwc3: gadget: remove wait_end_transfer > > > > > d4f1afe5e896c usb: dwc3: gadget: move requests to cancelled_list > > > > > d5443bbf5fc8f usb: dwc3: gadget: introduce cancelled_list > > > > > 7746a8dfb3f9c usb: dwc3: gadget: extract dwc3_gadget_ep_skip_trbs() > > > > > c3acd59014148 usb: dwc3: gadget: use num_trbs when skipping TRBs on ->dequeue() > > > > > 09fe1f8d7e2f4 usb: dwc3: gadget: track number of TRBs per request > > > > > 1a22ec6435806 usb: dwc3: gadget: combine unaligned and zero flags > > > > > > > > > > Though perhaps only the stuff up through "move requests to > > > > > cancelled_list" is the important stuff... Felipe might be able to say > > > > > better. > > > > > > > > Can someone send me a correct list of exactly what patches to commit, to > > > > what kernel tree(s), and in what order? Ideally you would have also > > > > tested them yourself... > > > > > > > > As it is, this "random list of commits" doesn't make me feel good about > > > > backporting. > > > > > > Ok here's my recommendation, in short form: cherry-pick > > > 1dbcd8d42c02..fec9095bdef4 to 4.19. > > > > > > Long form rationale below: > > > The series these fixes came from is this: > > > https://patchwork.kernel.org/project/linux-usb/list/?series=42875 > > > > > > The first three are already in stable. I recommend picking the below > > > commits, which I've listed in git log order, so the apply order would > > > be bottom-up: > > > fec9095bdef4e usb: dwc3: gadget: remove wait_end_transfer > > > d4f1afe5e896c usb: dwc3: gadget: move requests to cancelled_list > > > d5443bbf5fc8f usb: dwc3: gadget: introduce cancelled_list > > > 7746a8dfb3f9c usb: dwc3: gadget: extract dwc3_gadget_ep_skip_trbs() > > > c3acd59014148 usb: dwc3: gadget: use num_trbs when skipping TRBs on ->dequeue() > > > 09fe1f8d7e2f4 usb: dwc3: gadget: track number of TRBs per request > > > 1a22ec6435806 usb: dwc3: gadget: combine unaligned and zero flags > > > > This first patch here, breaks the build on 4.20 and 4.19 :( > > > > So I don't know how you tested this. > > > > Can you provide me a full patch series, properly backported, that > > applies to 4.20.y and 4.19.y, so that I can get this in a tested format > > that can be applied properly? > > Darn it. This worked 6 days ago. This commit came in and wrecked me: > > commit 25ad17d692ad54c3c33b2a31e5ce2a82e38de14e > Author: Jack Pham <jackp@codeaurora.org> > AuthorDate: Thu Jan 10 12:39:55 2019 -0800 > Commit: Greg Kroah-Hartman <gregkh@linuxfoundation.org> > CommitDate: Thu Jan 31 08:14:42 2019 +0100 > > usb: dwc3: gadget: Clear req->needs_extra_trb flag on cleanup > > commit bd6742249b9ca918565e4e3abaa06665e587f4b5 upstream. > > So then the directions for 4.19 would be: > 1) revert 25ad17d692ad > 2) cherry-pick d92021f66063..fec9095bdef4 > 3) cherry-pick bd6742249b9c (which was the reverted commit, that now > applies without modification from upstream). > > For 4.20, this would be revert 5eaf9833f5be, then cherry-pick same as > above. I've got trees where I've done this below: > > https://chromium.googlesource.com/chromiumos/third_party/kernel/+log/refs/sandbox/evgreen/stable-4.19.y-dwc3-gadget > https://chromium.googlesource.com/chromiumos/third_party/kernel/+log/refs/sandbox/evgreen/stable-4.20.y-dwc3-gadget > > The testing I've done on these trees is to do make allmodconfig and > ensure that they build cleanly. I was also able to test merging the > 4.19 one into the ChromeOS tree and reboot while a gadget was > connected (which fixes the problem I was seeing before). > > If you'd prefer I email out patches that do the same, I'm happy to do that too. Please just email out the patches, that way I know they have been tested properly for the specific tree. thanks, greg k-h ^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2019-02-11 13:41 UTC | newest] Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2019-01-23 0:37 Backporting dwc3 gadget fixes Evan Green 2019-01-23 6:32 ` Felipe Balbi 2019-01-23 6:55 ` He, Bo 2019-01-23 18:46 ` Evan Green 2019-01-29 10:22 ` Greg KH 2019-01-29 19:15 ` Evan Green 2019-02-04 9:11 ` Greg KH 2019-02-04 21:13 ` Evan Green 2019-02-11 13:41 ` Greg KH
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).