All of lore.kernel.org
 help / color / mirror / Atom feed
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: Alexandre Belloni <alexandre.belloni@bootlin.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [PATCH] uio: ensure class is registered before devices
Date: Sat, 16 Jun 2018 09:14:30 +0200	[thread overview]
Message-ID: <20180616071430.GC30558@kroah.com> (raw)
In-Reply-To: <20180615155249.17607-1-alexandre.belloni@bootlin.com>

On Fri, Jun 15, 2018 at 05:52:49PM +0200, Alexandre Belloni wrote:
> When both uio and the uio drivers are built in the kernel, it is possible
> for a driver to register devices before the uio class is registered.
> 
> This may result in a NULL pointer dereference later on in
> get_device_parent() when accessing the class glue_dirs spinlock.
> 
> The trace looks like that:
> 
> Unable to handle kernel NULL pointer dereference at virtual address 00000140
> [...]
> Process swapper/0 (pid: 1, stack limit = 0xffff000008070000)
> Call trace:
> Exception stack(0xffff000008073810 to 0xffff000008073950)
> 3800:                                   0000000000000140 0000000000000001
> 3820: ffff800078f60000 ffffffffffffffff 0000000000000000 0000000000000000
> 3840: 0000000000000d39 07650764075f0774 0765076307690776 077207610770075f
> 3860: 07200774076e0765 0720072007200720 0720072007200720 0720072007200720
> 3880: 0720072007200720 ffffffffffffffff 0000000000000000 ffff0000089e88c0
> 38a0: 0000000000000010 ffff000008e0c000 ffff8000780990b0 ffff8000780f4ec0
> 38c0: ffff000008c41a48 ffff000008c41a30 ffff000008a59660 ffff000008c41a30
> 38e0: ffff000008a59660 ffff8000780f4c80 ffff000008c41000 ffff000008073950
> 3900: ffff0000084f3bb0 ffff000008073950 ffff0000089cc234 0000000040000045
> 3920: 00000000000005e7 ffff000008a59660 ffffffffffffffff 0000000000000000
> 3940: ffff000008073950 ffff0000089cc234
> [<ffff0000089cc234>] _raw_spin_lock+0x14/0x48
> [<ffff0000084f56bc>] device_add+0x154/0x6a0
> [<ffff0000084f5e48>] device_create_groups_vargs+0x120/0x128
> [<ffff0000084f5edc>] device_create+0x54/0x60
> [<ffff0000086e72c0>] __uio_register_device+0x120/0x4a8
> [<ffff000008528b7c>] jaguar2_pci_probe+0x2d4/0x558
> [<ffff0000083fc18c>] local_pci_probe+0x3c/0xb8
> [<ffff0000083fd81c>] pci_device_probe+0x11c/0x180
> [<ffff0000084f88bc>] driver_probe_device+0x22c/0x2d8
> [<ffff0000084f8a24>] __driver_attach+0xbc/0xc0
> [<ffff0000084f69fc>] bus_for_each_dev+0x4c/0x98
> [<ffff0000084f81b8>] driver_attach+0x20/0x28
> [<ffff0000084f7d08>] bus_add_driver+0x1b8/0x228
> [<ffff0000084f93c0>] driver_register+0x60/0xf8
> [<ffff0000083fb918>] __pci_register_driver+0x40/0x48
> 
> Return EPROBE_DEFER in that case so the driver can register the device
> later.
> 
> Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
> ---
> 
> Hi Greg,
> 
> I'm not sure using struct class::p to test for class registration is really
> something we should do but this allows to have a small patch.
> 
> The other solutions to fix this are:
>  - use a similar change but with a boolean to store whether the class has been
>    registered.
>  - or instead of EPROBE_DEFER, just register the class when the first uio
>    device is registered.
>  _ or stop allowing to compile uio as a module and use subsys_initcall instead
>  of module_init
> 
> What do you think?
> 
>  drivers/uio/uio.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/drivers/uio/uio.c b/drivers/uio/uio.c
> index e8f4ac9400ea..3fb84ab3dd99 100644
> --- a/drivers/uio/uio.c
> +++ b/drivers/uio/uio.c
> @@ -853,6 +853,9 @@ int __uio_register_device(struct module *owner,
>  	struct uio_device *idev;
>  	int ret = 0;
>  
> +	if (!uio_class.p)
> +		return -EPROBE_DEFER;

Ick, you are right, don't touch the .p field please.  We just need a "is
uio all initialized" flag for the class here that we should check
instead.

thanks,

greg k-h

      reply	other threads:[~2018-06-16  7:14 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-06-15 15:52 [PATCH] uio: ensure class is registered before devices Alexandre Belloni
2018-06-16  7:14 ` Greg Kroah-Hartman [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20180616071430.GC30558@kroah.com \
    --to=gregkh@linuxfoundation.org \
    --cc=alexandre.belloni@bootlin.com \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.