Received: by 2002:ac0:a5a7:0:0:0:0:0 with SMTP id m36-v6csp1402948imm; Wed, 1 Aug 2018 15:32:49 -0700 (PDT) X-Google-Smtp-Source: AAOMgpfJ6Jni/kX84dK5PPDewRymnz8ZTyl2zTel8cSAJNvolGxqtf7ajJwmhD4PM9j9TlZobn6Q X-Received: by 2002:a62:9645:: with SMTP id c66-v6mr260632pfe.56.1533162769213; Wed, 01 Aug 2018 15:32:49 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1533162769; cv=none; d=google.com; s=arc-20160816; b=P39bc+soknidOqirYs3jr+0rJjyPfl4oY9RTEL8aHznw/IZnuTbvDh8hbFlaDBRx4Q YTkVPx3munv9IqzS6bWkrOpG62JgXmHkp7Cubhh6/r+JZhp3UvyZxBldptwEHIex2tz7 Zk/C9knn46JkAGi2HnYPbRKjEz8Dvywn6TsYFPtkfLjn7n3t086gZaEMPHfT9mAg1WTf elU+Y4u/yMQr/gYTU1YaNk7q7RpPhZCXtYzyBTf2Mn312ti+n0dycCh7pp5+GDe9vTHb X8q+mjTxUk2zEul/wODvIYcnjlSMRChzdyPFbXvxF48nSYRwEl3pAyC+A8aRil0gA2IC /hFQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :references:in-reply-to:mime-version:arc-authentication-results; bh=ipi9FgaPMPdEnADUWxz/Z1RZGmZr2jAxGO1i2MgYUOY=; b=WpAITA8ZpjU3FR4HzXHjYqL2LCPWyAzWEJZnqTx85E9oWAKAKGctwavdxtayfSFWUo 9NWFcDoxKqPYFFSV2m3Bfe8ElHC6730YAsZfdon/KgrMP0cBq31ljxSVyVK+u7lY1IJB UbpB97Ewy9aDGKjSCCo3tkJp6X+z7O+NgVmHCENzCdt1zP/aHoDrxtDn6/E1ANkZlRjV LsrWV6rSalYGHRY4Rp+Cv1FyOegO55W4xrNY781ofFN0PiuJ3qgnCJ3xa45uwK5tpCi7 XVBfxluXZ4tm08rWAGTHvy4I2hblvzZILC1ymwqziOMLYRpO4cccINCR3UqhxQ1B7dLl GmoA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id f3-v6si116913plo.410.2018.08.01.15.32.34; Wed, 01 Aug 2018 15:32:49 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1732009AbeHBATo (ORCPT + 99 others); Wed, 1 Aug 2018 20:19:44 -0400 Received: from mail-vk0-f53.google.com ([209.85.213.53]:44876 "EHLO mail-vk0-f53.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727002AbeHBATo (ORCPT ); Wed, 1 Aug 2018 20:19:44 -0400 Received: by mail-vk0-f53.google.com with SMTP id 125-v6so87049vke.11 for ; Wed, 01 Aug 2018 15:31:42 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ipi9FgaPMPdEnADUWxz/Z1RZGmZr2jAxGO1i2MgYUOY=; b=LnG6UUcw9lXeXkZGA8ST9hnzZaK8h+6yWr8NUSWnGWU44eOqC4bodTKNJHzAkF9VMa wIKj1yvbdOfZOs5rP4ntwvyD7YNWW01h4MFGMSA64LmEoCCk+on2KfmBW9d51cBrS7FE zKTLvp6fa3PLBBUze3YcUaavWEztiUYGSNllIK0uEzHvvaFE18ju61oWhqpacboI+5At PswOKxrY1pDRwHOjKFAhHdQAZzs+rz/pWglAVEUAvNH/YLnXP+dzwDmxfniGlZQ2YLKf +FHpOxrbQfHh63b1DhsvFJVPT4vwh0bxB+7HQFIb5I7C2XjXRp440GOv8X4DufAtJn3R 4HtQ== X-Gm-Message-State: AOUpUlGy1YcQ/UC9WbAvdYqY6HUOLt2PLPzxvXncixtB4vvif954kPp+ 9BYtNcuHBB4V193HxUsQqTnemiW/5rbZg0sK1LRnAg== X-Received: by 2002:a1f:cb83:: with SMTP id b125-v6mr173695vkg.68.1533162702163; Wed, 01 Aug 2018 15:31:42 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:ab0:49e9:0:0:0:0:0 with HTTP; Wed, 1 Aug 2018 15:31:41 -0700 (PDT) In-Reply-To: References: <6008699.T6Yd1fn3Dk@amdc3058> <1975707.vO8kdHz3oS@amdc3058> From: David Airlie Date: Thu, 2 Aug 2018 08:31:41 +1000 Message-ID: Subject: Re: Sleeping from invalid context in udlfb To: Mikulas Patocka Cc: Geert Uytterhoeven , Bartlomiej Zolnierkiewicz , Bernie Thompson , Ladislav Michl , DRI Development , Linux Fbdev development list , Greg KH , Jiri Slaby , Linux Kernel Mailing List Content-Type: multipart/alternative; boundary="0000000000003ee66f05726742e5" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --0000000000003ee66f05726742e5 Content-Type: text/plain; charset="UTF-8" I'm pretty sure udlkms handles this already. Dave. On Wed, Aug 1, 2018 at 11:34 PM, Mikulas Patocka wrote: > > > On Wed, 1 Aug 2018, Geert Uytterhoeven wrote: > > > Hi Mikulas, > > > > On Wed, Aug 1, 2018 at 12:59 PM Mikulas Patocka > wrote: > > > On Wed, 1 Aug 2018, Geert Uytterhoeven wrote: > > > > On Tue, Jul 31, 2018 at 5:23 PM Mikulas Patocka > wrote: > > > > > BTW when using the udlfb driver as a console, I've got this > warning. > > > > > vt_console_print takes a spinlock and then calls the framebuffer > driver > > > > > that sleeps. > > > > > > > > > > The question is - whose fault is this? Could the console code > somehow be > > > > > told to print characters without holding a spinlock? Or does it > mean that > > > > > 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 > > > > > #1: 00000000beacc951 ( (work_completion)(&(&dlfb-> > init_framebuffer_work)->work)){....} , at: process_one_work+0x17c/0x3a8 > > > > > #2: 00000000a402f826 ( registration_lock){....} , at: > register_framebuffer+0x28/0x2c0 [fb] > > > > > #3: 0000000021cbe902 ( console_lock){....} , at: > register_framebuffer+0x258/0x2c0 [fb] > > > > > #4: 0000000096d51735 ( console_owner){....} , at: > console_unlock+0x174/0x500 > > > > > #5: 00000000faa7f206 ( printing_lock){....} , at: > vt_console_print+0x60/0x3a0 > > > > > Preemption disabled at: [] > vt_console_print+0x60/0x3a0 > > > > > 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 > > > > > 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 > > > 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 > --0000000000003ee66f05726742e5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

I'm pretty sure udlkms handles thi= s already.

Dave.

On Wed, Aug 1, 2018 at 11:34 PM, Mi= kulas Patocka <mpatocka@redhat.com> wrote:


On Wed, 1 Aug 2018, Geert Uytterhoeven wrote:

> Hi Mikulas,
>
> On Wed, Aug 1, 2018 at 12:59 PM Mikulas Patocka <mpatocka@redhat.com> wrote:
> > On Wed, 1 Aug 2018, Geert Uytterhoeven wrote:
> > > On Tue, Jul 31, 2018 at 5:23 PM Mikulas Patocka <mpatocka@redhat.com> wrote:
> > > > BTW when using the udlfb driver as a console, I've = got this warning.
> > > > vt_console_print takes a spinlock and then calls the fr= amebuffer driver
> > > > that sleeps.
> > > >
> > > > The question is - whose fault is this? Could the consol= e code somehow be
> > > > told to print characters without holding a spinlock? Or= does it mean that
> > > > framebuffer drivers can't sleep?
> > > >
> > > > udlfb communicates through USB, so the sleeping is inev= itable.
> > > >
> > > > Mikulas
> > > >
> > > >
> > > > BUG: sleeping function called from invalid context at m= m/slab.h:421
> > > > in_atomic(): 1, irqs_disabled(): 0, pid: 430, name: kwo= rker/2:3
> > > > 6 locks held by kworker/2:3/430:
> > > >=C2=A0 #0: 000000001301127e ( (wq_completion)"event= s"){....} , at: process_one_work+0x17c/0x3a8
> > > >=C2=A0 #1: 00000000beacc951 ( (work_completion)(&(&a= mp;dlfb->init_framebuffer_work)->work)){....} , at: process= _one_work+0x17c/0x3a8
> > > >=C2=A0 #2: 00000000a402f826 ( registration_lock){....} ,= at: register_framebuffer+0x28/0x2c0 [fb]
> > > >=C2=A0 #3: 0000000021cbe902 ( console_lock){....} , at: = register_framebuffer+0x258/0x2c0 [fb]
> > > >=C2=A0 #4: 0000000096d51735 ( console_owner){....} , at:= console_unlock+0x174/0x500
> > > >=C2=A0 #5: 00000000faa7f206 ( printing_lock){....} , at:= vt_console_print+0x60/0x3a0
> > > > Preemption disabled at: [<ffffff8008403130>] vt_c= onsole_print+0x60/0x3a0
> > > > CPU: 2 PID: 430 Comm: kworker/2:3 Not tainted 4.17.10-d= ebug #3
> > > > Hardware name: Marvell Armada 8040 MacchiatoBin/Armada = 8040 MacchiatoBin, BIOS EDK II Jul 30 2018
> > > > Workqueue: events dlfb_init_framebuffer_work [udlfb] > > > > Call trace:
> > > >=C2=A0 dump_backtrace+0x0/0x150
> > > >=C2=A0 show_stack+0x14/0x20
> > > >=C2=A0 dump_stack+0x8c/0xac
> > > >=C2=A0 ___might_sleep+0x140/0x170
> > > >=C2=A0 __might_sleep+0x50/0x88
> > > >=C2=A0 __kmalloc+0x1b0/0x270
> > > >=C2=A0 xhci_urb_enqueue+0xa8/0x460 [xhci_hcd]
> > > >=C2=A0 usb_hcd_submit_urb+0xc0/0x998 [usbcore]
> > > >=C2=A0 usb_submit_urb+0x1e0/0x518 [usbcore]
> > > >=C2=A0 dlfb_submit_urb+0x38/0x98 [udlfb]
> > > >=C2=A0 dlfb_handle_damage.isra.4+0x1e0/0x210 [udlfb= ]
> > > >=C2=A0 dlfb_ops_imageblit+0x28/0x38 [udlfb]
> > > >=C2=A0 soft_cursor+0x15c/0x1d8 [fb]
> > > >=C2=A0 bit_cursor+0x324/0x510 [fb]
> > > >=C2=A0 fbcon_cursor+0x144/0x1a0 [fb]
> > > >=C2=A0 hide_cursor+0x38/0xa0
> > > >=C2=A0 vt_console_print+0x334/0x3a0
> > > >=C2=A0 console_unlock+0x274/0x500
> > > >=C2=A0 register_framebuffer+0x22c/0x2c0 [fb]
> > > >=C2=A0 dlfb_init_framebuffer_work+0x1ec/0x2fc [udlf= b]
> > > >=C2=A0 process_one_work+0x1e8/0x3a8
> > > >=C2=A0 worker_thread+0x44/0x418
> > > >=C2=A0 kthread+0x11c/0x120
> > > >=C2=A0 ret_from_fork+0x10/0x18
> > >
> > > This is sort of expected: you cannot do USB transfers from p= rintk().
> > >
> > > Gr{oetje,eeting}s,
> > >
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Geert
> >
> > So, should there be a framebuffer flag that prevents the console = from
> > binding to it?
> >
> > If I start the kernel with "console=3DttyS0,115200", it= doesn't try to bind
> > 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,
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0Geert

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

Mikulas

--0000000000003ee66f05726742e5--