Your patch fix the issue BUG: scheduling while atomic:
BUG: scheduling while atomic: SettingsProvide/3433/0x00000104
Preemption disabled at:
[<ffffffff81e00053>] __do_softirq+0x53/0x31b
CPU: 1 PID: 3433 Comm: SettingsProvide Tainted: P U
ilt-2e5dc0ac-g3f662bf-dirty #8
Call Trace:
<IRQ>
dump_stack+0x70/0x9e
__schedule_bug+0x7f/0xd0
__schedule+0x61d/0x860
schedule+0x36/0x90
dwc3_gadget_ep_dequeue+0x27a/0x2e0 [dwc3]
usb_ep_dequeue+0x23/0x90
ffs_aio_cancel+0x4c/0x70
kiocb_cancel+0x40/0x50
free_ioctx_users+0x6e/0x100
percpu_ref_switch_to_atomic_rcu+0x159/0x160
rcu_process_callbacks+0x1a7/0x520
__do_softirq+0x11a/0x31b
irq_exit+0xb5/0xc0
smp_apic_timer_interrupt+0x7c/0x160
the BUG is introduced form the patch:
commit: cf3113d89
usb: dwc3: gadget: properly increment dequeue pointer on ep_dequeue
the commit: cf3113d89 call the below function maybe in softirq context:
wait_event_lock_irq(dep->wait_end_transfer,
!(dep->flags &
DWC3_EP_END_TRANSFER_PENDING),
dwc->lock);
-----Original Message-----
From: Vincent Pelletier <[email protected]>
Sent: Wednesday, August 1, 2018 11:04 PM
To: Felipe Balbi <[email protected]>
Cc: Alan Stern <[email protected]>; Roger Quadros <[email protected]>;
Lars-Peter Clausen <[email protected]>; Sam Protsenko
<[email protected]>; [email protected]; Praneeth Bajjuri
<[email protected]>; He, Bo <[email protected]>; Bai, Jie A <[email protected]>
Subject: Re: usb: gadget: ffs: Fix BUG when userland exits with submitted AIO
transfers
Hello,
Bo He, CC'ed, found a regression introduced in my patch, discussed in this
thread, and submitted a patch:
Subject: [PATCH] fix panic at pwq_activate_delayed_work.
Date: Wed, 1 Aug 2018 10:14:38 +0000
Message-ID:
<cd6925e8781efd4d8e11882d20fc406d52983...@shsmsx104.ccr.corp.intel.com>
On Fri, 29 Jun 2018 09:32:43 +0300, Felipe Balbi <[email protected]>
wrote:
> Hmm, that's what I remember, but we don't have that documented and
> dwc3 has a sleep in its dequeue, which I need to remove for other
> reasons anyway.
Given the above comment from Felipe, I expected my patch would be dropped in
favour of making dwc3 not sleep in dequeue, as it seems to be the actual root
cause.
Should my patch be reverted ? It adds complexity which, I believe, becomes
superfluous if dequeue does not sleep anywhere.
Or maybe non-sleeping dequeue is not there yet, and a solution right now (later
revertable) is better, in which case my change would be worth fixing ?
--
Vincent Pelletier
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
