Thread (19 messages) flat view 19 messages, 6 authors, 2018-12-31

Re: Sleeping from invalid context in udlfb

From: David Airlie <airlied@redhat.com>
Date: 2018-08-01 22:31:43
Also in: dri-devel

I'm pretty sure udlkms handles this already.

Dave.

On Wed, Aug 1, 2018 at 11:34 PM, Mikulas Patocka [off-list ref]
wrote:

On Wed, 1 Aug 2018, Geert Uytterhoeven wrote:
quoted
Hi Mikulas,

On Wed, Aug 1, 2018 at 12:59 PM Mikulas Patocka [off-list ref]
wrote:
quoted
quoted
On Wed, 1 Aug 2018, Geert Uytterhoeven wrote:
quoted
On Tue, Jul 31, 2018 at 5:23 PM Mikulas Patocka [off-list ref]
wrote:
quoted
quoted
quoted
quoted
BTW when using the udlfb driver as a console, I've got this
warning.
quoted
quoted
quoted
quoted
vt_console_print takes a spinlock and then calls the framebuffer
driver
quoted
quoted
quoted
quoted
that sleeps.

The question is - whose fault is this? Could the console code
somehow be
quoted
quoted
quoted
quoted
told to print characters without holding a spinlock? Or does it
mean that
quoted
quoted
quoted
quoted
framebuffer drivers can't sleep?

udlfb communicates through USB, so the sleeping is inevitable.

Mikulas


BUG: sleeping function called from invalid context at mm/slab.h:421
in_atomic(): 1, irqs_disabled(): 0, pid: 430, name: kworker/2:3
6 locks held by kworker/2:3/430:
 #0: 000000001301127e ( (wq_completion)"events"){....} , at:
process_one_work+0x17c/0x3a8
quoted
quoted
quoted
quoted
 #1: 00000000beacc951 ( (work_completion)(&(&dlfb->
init_framebuffer_work)->work)){....} , at: process_one_work+0x17c/0x3a8
quoted
quoted
quoted
quoted
 #2: 00000000a402f826 ( registration_lock){....} , at:
register_framebuffer+0x28/0x2c0 [fb]
quoted
quoted
quoted
quoted
 #3: 0000000021cbe902 ( console_lock){....} , at:
register_framebuffer+0x258/0x2c0 [fb]
quoted
quoted
quoted
quoted
 #4: 0000000096d51735 ( console_owner){....} , at:
console_unlock+0x174/0x500
quoted
quoted
quoted
quoted
 #5: 00000000faa7f206 ( printing_lock){....} , at:
vt_console_print+0x60/0x3a0
quoted
quoted
quoted
quoted
Preemption disabled at: [<ffffff8008403130>]
vt_console_print+0x60/0x3a0
quoted
quoted
quoted
quoted
CPU: 2 PID: 430 Comm: kworker/2:3 Not tainted 4.17.10-debug #3
Hardware name: Marvell Armada 8040 MacchiatoBin/Armada 8040
MacchiatoBin, BIOS EDK II Jul 30 2018
quoted
quoted
quoted
quoted
Workqueue: events dlfb_init_framebuffer_work [udlfb]
Call trace:
 dump_backtrace+0x0/0x150
 show_stack+0x14/0x20
 dump_stack+0x8c/0xac
 ___might_sleep+0x140/0x170
 __might_sleep+0x50/0x88
 __kmalloc+0x1b0/0x270
 xhci_urb_enqueue+0xa8/0x460 [xhci_hcd]
 usb_hcd_submit_urb+0xc0/0x998 [usbcore]
 usb_submit_urb+0x1e0/0x518 [usbcore]
 dlfb_submit_urb+0x38/0x98 [udlfb]
 dlfb_handle_damage.isra.4+0x1e0/0x210 [udlfb]
 dlfb_ops_imageblit+0x28/0x38 [udlfb]
 soft_cursor+0x15c/0x1d8 [fb]
 bit_cursor+0x324/0x510 [fb]
 fbcon_cursor+0x144/0x1a0 [fb]
 hide_cursor+0x38/0xa0
 vt_console_print+0x334/0x3a0
 console_unlock+0x274/0x500
 register_framebuffer+0x22c/0x2c0 [fb]
 dlfb_init_framebuffer_work+0x1ec/0x2fc [udlfb]
 process_one_work+0x1e8/0x3a8
 worker_thread+0x44/0x418
 kthread+0x11c/0x120
 ret_from_fork+0x10/0x18
This is sort of expected: you cannot do USB transfers from printk().

Gr{oetje,eeting}s,

                        Geert
So, should there be a framebuffer flag that prevents the console from
binding to it?

If I start the kernel with "console=ttyS0,115200", it doesn't try to
bind
quoted
quoted
to the udlfb driver, but if I start it without this flag, it does and
crashes :-(
Your frame buffer driver should offload tasks that may sleep to e.g. a
workqueue.

Gr{oetje,eeting}s,

                        Geert
I can try to do this - but - taking a spinlock and copying 8MB framebuffer
would damage scheduling latency even for PCI framebuffer drivers.

Mikulas
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help