linux-kernel - Re: [lkp] [gpio] 3c702e9987: kmsg.user_verbs:couldn't_register_device

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Sun, 14 Feb 2016 18:42:11 +0100
From:	Linus Walleij <linus.walleij@...aro.org>
To:	Michael Welling <mwelling@...e.org>,
	Greg KH <gregkh@...uxfoundation.org>,
	Roland Dreier <rolandd@...co.com>
Cc:	kernel test robot <ying.huang@...ux.intel.com>, lkp@...org,
	LKML <linux-kernel@...r.kernel.org>,
	Arnd Bergmann <arnd@...db.de>,
	Markus Pargmann <mpa@...gutronix.de>,
	Johan Hovold <johan@...nel.org>
Subject: Re: [lkp] [gpio] 3c702e9987: kmsg.user_verbs:couldn't_register_device_number

Greg, heads-up on this... you'd know if this happened
before.

On Sun, Feb 14, 2016 at 9:06 AM, Michael Welling <mwelling@...e.org> wrote:
> On Sun, Feb 14, 2016 at 02:59:06PM +0800, kernel test robot wrote:
>> FYI, we noticed the below changes on
>>
>> https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio.git chardev
>> commit 3c702e9987e261042a07e43460a8148be254412e ("gpio: add a userspace chardev ABI for GPIOs")
>>
>>
>> [    1.951191] user_verbs: couldn't register device number
>
> Looks like user_verbs is using a static device node setup.
>
> enum {
>         IB_UVERBS_MAJOR       = 231,
>         IB_UVERBS_BASE_MINOR  = 192,
>         IB_UVERBS_MAX_DEVICES = 32
> };
>
> #define IB_UVERBS_BASE_DEV      MKDEV(IB_UVERBS_MAJOR, IB_UVERBS_BASE_MINOR)

That's annoying...
I notice that infiniband is using register_chrdev_region() at
module_init() time, counting on device major 231 to be free.

> Something tells me that a new GPIO chardev is taking this spot.

Yes. Please post the contents of /proc/devices on this system.

If you look in fs/char_dev.c this happens in
__register_chrdev_region() you can see that dynamic
character major numbers are assigned from 254 and
downwards in this way:

#define CHRDEV_MAJOR_HASH_SIZE       255
(...)
} *chrdevs[CHRDEV_MAJOR_HASH_SIZE];

        /* temporary */
        if (major == 0) {
                for (i = ARRAY_SIZE(chrdevs)-1; i > 0; i--) {
                        if (chrdevs[i] == NULL)
                                break;
                }

                if (i == 0) {
                        ret = -EBUSY;
                        goto out;
                }
                major = i;
        }

Whereas fixed device numbers are assigned sparsely
from low to high.

I suspect what happens is that in your system there are
already so many dynamically assigned character devices that
they go down and already collide with 232 and 233, you just
didn't notice until this make it hit 231 which incidentally
was in use.

So I would be very intersted in what misc stuff you have filling
out 232 thru 255, already knocking out other assigned
numbers...

I guess I *could* try to grab a static assignment in the low
range, say recycle character device 8, which is the first
unallocated from the bottom, but I'm afraid the device
core maintainers have worked to get devices to go more
dynamic and would be very unhappy about this.

Yours,
Linus Walleij