lkml.org 
[lkml]   [2016]   [Feb]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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@ieee.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

\
 
 \ /
  Last update: 2016-02-14 19:21    [W:0.182 / U:0.424 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site