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 <plr.vincent@xxxxxxxxx>
Sent: Wednesday, August 1, 2018 11:04 PM
To: Felipe Balbi <felipe.balbi@xxxxxxxxxxxxxxx>
Cc: Alan Stern <stern@xxxxxxxxxxxxxxxxxxx>; Roger Quadros <rogerq@xxxxxx>; Lars-Peter Clausen <lars@xxxxxxxxxx>; Sam Protsenko <semen.protsenko@xxxxxxxxxx>; linux-usb@xxxxxxxxxxxxxxx; Praneeth Bajjuri <praneeth@xxxxxx>; He, Bo <bo.he@xxxxxxxxx>; Bai, Jie A <jie.a.bai@xxxxxxxxx>
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: <CD6925E8781EFD4D8E11882D20FC406D529834D2@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>
On Fri, 29 Jun 2018 09:32:43 +0300, Felipe Balbi <felipe.balbi@xxxxxxxxxxxxxxx> 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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
