Re: [lkp] [gpio] 3c702e9987: kmsg.user_verbs:couldn't_register_device_number

[Greg KH]

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@xxxxxxxx> 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