Backporting dwc3 gadget fixes

From: Evan Green <evgreen@google.com>
To: stable@vger.kernel.org, Felipe Balbi <felipe.balbi@linux.intel.com>
Cc: Alan Stern <stern@rowland.harvard.edu>,
	Sam Protsenko <semen.protsenko@linaro.org>,
	bo.he@intel.com, Doug Anderson <dianders@chromium.org>,
	Stephen Boyd <swboyd@chromium.org>,
	Matthias Kaehlcke <mka@chromium.org>
Subject: Backporting dwc3 gadget fixes
Date: Tue, 22 Jan 2019 16:37:51 -0800	[thread overview]
Message-ID: <CAE=gft6yLB1=nO7dUP1LFdHExkV+HCtHZbxeQG847noxgqnxnA@mail.gmail.com> (raw)

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