[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20160214174947.GA21558@kroah.com>
Date: Sun, 14 Feb 2016 09:49:47 -0800
From: Greg KH <gregkh@...uxfoundation.org>
To: Linus Walleij <linus.walleij@...aro.org>
Cc: Michael Welling <mwelling@...e.org>,
Roland Dreier <rolandd@...co.com>,
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
On Sun, Feb 14, 2016 at 06:42:11PM +0100, Linus Walleij wrote:
> 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.
That device major is assigned to Infiniband, why shouldn't it be doing
this?
>
> > 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.
Why not just ask for a new reserved one? We could give you 261 and
everything should be fine, right?
thanks,
greg k-h
Powered by blists - more mailing lists