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

2016-02-14 Thread Michael Welling 
On Sun, Feb 14, 2016 at 03:49:54PM -0800, Greg KH wrote:
> On Sun, Feb 14, 2016 at 01:51:20PM -0600, Michael Welling wrote:
> > On Sun, Feb 14, 2016 at 11:05:15AM -0800, Greg KH wrote:
> > > On Sun, Feb 14, 2016 at 06:56:20PM +0100, Linus Walleij wrote:
> > > > On Sun, Feb 14, 2016 at 6:49 PM, Greg KH  
> > > > wrote:
> > > > > 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  
> > > > >> 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?
> > > > 
> > > > I mean it's annoying that they collide. (Because of the details I
> > > > write below, it's fine it's using the assigned number.
> > > > 
> > > > > Why not just ask for a new reserved one?  We could give you 261 and
> > > > > everything should be fine, right?
> > > > 
> > > > Sure I can post a patch for that, but it just mitigates the problem.
> > > > 
> > > > The report point to the serious problem that on this system
> > > > some dynamic allocations have already stolen major device
> > > > numbers 232 thru 255, and 232 and 233 are also assigned.
> > > > 
> > > > What do you think about a patch that makes fs/char_dev.c
> > > > emit a warning when it starts assigning dynamic numbers
> > > > 233 and below?
> > > 
> > > That's fine with me.  I also think maybe we should look into just
> > > switching all char major/minor allocation to be dynamic, starting at the
> > > bottom and moving up.  I think the only tools that might have an issue
> > > with that is the raw device controller, but maybe that has been fixed up
> > > in userspace, I haven't looked at that in many years.
> > >
> > 
> > Is there any reason for the CHRDEV_MAJOR_HASH_SIZE being 255?
> > If we increase the size to say 511 will it break userspace?
> 
> No, that's an internal thing, but I don't see what that has to do with
> this...
> 
> > In the future I see a robot building a kernel with more that 255 devices and
> > having to deal with this kind of collision again.
> 
> We handle major numbers larger than 255 already...
> 
> > The handling of large major assignment baffles me.
> 
> It's tricky, messy, and something you don't want to touch, seriously...
>

Doh... I see now that each entry in the table is a list.

But then the dynamic allocation only looks for a NULL entry in the table.
So the limitation appears to be 255 dynamically allocated devices so still
has something to do with this.

Another simpler alternate to going completely dynamic is allocate dynamically
starting at an offset outside of the fixed range and just increment the major
on a first come first serve basis.

I guess that the current number would have to be stored somewhere.

Does this make sense or am I still not understanding how this works?

> good luck,
> 
> greg k-h

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

2016-02-14 Thread Michael Welling 
On Sun, Feb 14, 2016 at 03:49:54PM -0800, Greg KH wrote:
> On Sun, Feb 14, 2016 at 01:51:20PM -0600, Michael Welling wrote:
> > On Sun, Feb 14, 2016 at 11:05:15AM -0800, Greg KH wrote:
> > > On Sun, Feb 14, 2016 at 06:56:20PM +0100, Linus Walleij wrote:
> > > > On Sun, Feb 14, 2016 at 6:49 PM, Greg KH  
> > > > wrote:
> > > > > 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  
> > > > >> 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?
> > > > 
> > > > I mean it's annoying that they collide. (Because of the details I
> > > > write below, it's fine it's using the assigned number.
> > > > 
> > > > > Why not just ask for a new reserved one?  We could give you 261 and
> > > > > everything should be fine, right?
> > > > 
> > > > Sure I can post a patch for that, but it just mitigates the problem.
> > > > 
> > > > The report point to the serious problem that on this system
> > > > some dynamic allocations have already stolen major device
> > > > numbers 232 thru 255, and 232 and 233 are also assigned.
> > > > 
> > > > What do you think about a patch that makes fs/char_dev.c
> > > > emit a warning when it starts assigning dynamic numbers
> > > > 233 and below?
> > > 
> > > That's fine with me.  I also think maybe we should look into just
> > > switching all char major/minor allocation to be dynamic, starting at the
> > > bottom and moving up.  I think the only tools that might have an issue
> > > with that is the raw device controller, but maybe that has been fixed up
> > > in userspace, I haven't looked at that in many years.
> > >
> > 
> > Is there any reason for the CHRDEV_MAJOR_HASH_SIZE being 255?
> > If we increase the size to say 511 will it break userspace?
> 
> No, that's an internal thing, but I don't see what that has to do with
> this...
> 
> > In the future I see a robot building a kernel with more that 255 devices and
> > having to deal with this kind of collision again.
> 
> We handle major numbers larger than 255 already...
> 
> > The handling of large major assignment baffles me.
> 
> It's tricky, messy, and something you don't want to touch, seriously...
>

Doh... I see now that each entry in the table is a list.

But then the dynamic allocation only looks for a NULL entry in the table.
So the limitation appears to be 255 dynamically allocated devices so still
has something to do with this.

Another simpler alternate to going completely dynamic is allocate dynamically
starting at an offset outside of the fixed range and just increment the major
on a first come first serve basis.

I guess that the current number would have to be stored somewhere.

Does this make sense or am I still not understanding how this works?

> good luck,
> 
> greg k-h

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

2016-02-14 Thread Greg KH 
On Sun, Feb 14, 2016 at 01:51:20PM -0600, Michael Welling wrote:
> On Sun, Feb 14, 2016 at 11:05:15AM -0800, Greg KH wrote:
> > On Sun, Feb 14, 2016 at 06:56:20PM +0100, Linus Walleij wrote:
> > > On Sun, Feb 14, 2016 at 6:49 PM, Greg KH  
> > > wrote:
> > > > 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  
> > > >> 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?
> > > 
> > > I mean it's annoying that they collide. (Because of the details I
> > > write below, it's fine it's using the assigned number.
> > > 
> > > > Why not just ask for a new reserved one?  We could give you 261 and
> > > > everything should be fine, right?
> > > 
> > > Sure I can post a patch for that, but it just mitigates the problem.
> > > 
> > > The report point to the serious problem that on this system
> > > some dynamic allocations have already stolen major device
> > > numbers 232 thru 255, and 232 and 233 are also assigned.
> > > 
> > > What do you think about a patch that makes fs/char_dev.c
> > > emit a warning when it starts assigning dynamic numbers
> > > 233 and below?
> > 
> > That's fine with me.  I also think maybe we should look into just
> > switching all char major/minor allocation to be dynamic, starting at the
> > bottom and moving up.  I think the only tools that might have an issue
> > with that is the raw device controller, but maybe that has been fixed up
> > in userspace, I haven't looked at that in many years.
> >
> 
> Is there any reason for the CHRDEV_MAJOR_HASH_SIZE being 255?
> If we increase the size to say 511 will it break userspace?

No, that's an internal thing, but I don't see what that has to do with
this...

> In the future I see a robot building a kernel with more that 255 devices and
> having to deal with this kind of collision again.

We handle major numbers larger than 255 already...

> The handling of large major assignment baffles me.

It's tricky, messy, and something you don't want to touch, seriously...

good luck,

greg k-h

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

2016-02-14 Thread Greg KH 
On Sun, Feb 14, 2016 at 01:51:20PM -0600, Michael Welling wrote:
> On Sun, Feb 14, 2016 at 11:05:15AM -0800, Greg KH wrote:
> > On Sun, Feb 14, 2016 at 06:56:20PM +0100, Linus Walleij wrote:
> > > On Sun, Feb 14, 2016 at 6:49 PM, Greg KH  
> > > wrote:
> > > > 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  
> > > >> 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?
> > > 
> > > I mean it's annoying that they collide. (Because of the details I
> > > write below, it's fine it's using the assigned number.
> > > 
> > > > Why not just ask for a new reserved one?  We could give you 261 and
> > > > everything should be fine, right?
> > > 
> > > Sure I can post a patch for that, but it just mitigates the problem.
> > > 
> > > The report point to the serious problem that on this system
> > > some dynamic allocations have already stolen major device
> > > numbers 232 thru 255, and 232 and 233 are also assigned.
> > > 
> > > What do you think about a patch that makes fs/char_dev.c
> > > emit a warning when it starts assigning dynamic numbers
> > > 233 and below?
> > 
> > That's fine with me.  I also think maybe we should look into just
> > switching all char major/minor allocation to be dynamic, starting at the
> > bottom and moving up.  I think the only tools that might have an issue
> > with that is the raw device controller, but maybe that has been fixed up
> > in userspace, I haven't looked at that in many years.
> >
> 
> Is there any reason for the CHRDEV_MAJOR_HASH_SIZE being 255?
> If we increase the size to say 511 will it break userspace?

No, that's an internal thing, but I don't see what that has to do with
this...

> In the future I see a robot building a kernel with more that 255 devices and
> having to deal with this kind of collision again.

We handle major numbers larger than 255 already...

> The handling of large major assignment baffles me.

It's tricky, messy, and something you don't want to touch, seriously...

good luck,

greg k-h

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

2016-02-14 Thread Michael Welling 
On Sun, Feb 14, 2016 at 11:05:15AM -0800, Greg KH wrote:
> On Sun, Feb 14, 2016 at 06:56:20PM +0100, Linus Walleij wrote:
> > On Sun, Feb 14, 2016 at 6:49 PM, Greg KH  wrote:
> > > 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  
> > >> 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?
> > 
> > I mean it's annoying that they collide. (Because of the details I
> > write below, it's fine it's using the assigned number.
> > 
> > > Why not just ask for a new reserved one?  We could give you 261 and
> > > everything should be fine, right?
> > 
> > Sure I can post a patch for that, but it just mitigates the problem.
> > 
> > The report point to the serious problem that on this system
> > some dynamic allocations have already stolen major device
> > numbers 232 thru 255, and 232 and 233 are also assigned.
> > 
> > What do you think about a patch that makes fs/char_dev.c
> > emit a warning when it starts assigning dynamic numbers
> > 233 and below?
> 
> That's fine with me.  I also think maybe we should look into just
> switching all char major/minor allocation to be dynamic, starting at the
> bottom and moving up.  I think the only tools that might have an issue
> with that is the raw device controller, but maybe that has been fixed up
> in userspace, I haven't looked at that in many years.
>

Is there any reason for the CHRDEV_MAJOR_HASH_SIZE being 255?
If we increase the size to say 511 will it break userspace?

In the future I see a robot building a kernel with more that 255 devices and
having to deal with this kind of collision again.

The handling of large major assignment baffles me.
The major numbers outside of the size of the table are just wrapping around to
the beginning again. This is inherently going to cause collisions.

static inline int major_to_index(unsigned major)
{
return major % CHRDEV_MAJOR_HASH_SIZE;
}

> I thought I had an old patch around somewhere that did that, will go
> look for it this week and see what breaks with it enabled...
> 
> thanks,
> 
> greg k-h

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

2016-02-14 Thread Greg KH 
On Sun, Feb 14, 2016 at 06:56:20PM +0100, Linus Walleij wrote:
> On Sun, Feb 14, 2016 at 6:49 PM, Greg KH  wrote:
> > 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  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?
> 
> I mean it's annoying that they collide. (Because of the details I
> write below, it's fine it's using the assigned number.
> 
> > Why not just ask for a new reserved one?  We could give you 261 and
> > everything should be fine, right?
> 
> Sure I can post a patch for that, but it just mitigates the problem.
> 
> The report point to the serious problem that on this system
> some dynamic allocations have already stolen major device
> numbers 232 thru 255, and 232 and 233 are also assigned.
> 
> What do you think about a patch that makes fs/char_dev.c
> emit a warning when it starts assigning dynamic numbers
> 233 and below?

That's fine with me.  I also think maybe we should look into just
switching all char major/minor allocation to be dynamic, starting at the
bottom and moving up.  I think the only tools that might have an issue
with that is the raw device controller, but maybe that has been fixed up
in userspace, I haven't looked at that in many years.

I thought I had an old patch around somewhere that did that, will go
look for it this week and see what breaks with it enabled...

thanks,

greg k-h

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

2016-02-14 Thread Linus Walleij 
On Sun, Feb 14, 2016 at 6:49 PM, Greg KH  wrote:
> 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  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?

I mean it's annoying that they collide. (Because of the details I
write below, it's fine it's using the assigned number.

> Why not just ask for a new reserved one?  We could give you 261 and
> everything should be fine, right?

Sure I can post a patch for that, but it just mitigates the problem.

The report point to the serious problem that on this system
some dynamic allocations have already stolen major device
numbers 232 thru 255, and 232 and 233 are also assigned.

What do you think about a patch that makes fs/char_dev.c
emit a warning when it starts assigning dynamic numbers
233 and below?

Yours,
Linus Walleij

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

2016-02-14 Thread 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  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

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

2016-02-14 Thread Linus Walleij 
On Sun, Feb 14, 2016 at 9:06 AM, Michael Welling  wrote:

> 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)
>
> Something tells me that a new GPIO chardev is taking this spot.

I don't think so, since gpio is reserving it as a core_initcall() it
gets a high chardev major. It's likely the device that used to
be device 232 stealing the fingerprint sensor slot that got
pushed down and is now stealing device 231 infiniband.

Maybe I should make a patch making fs/char_dev.c emit a warning
or fail when it goes below 234... it doesn't currently. It just steals
more numbers. It's a serious archtectural issue if it persists.

Yours,
Linus Walleij

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

2016-02-14 Thread Linus Walleij 
Greg, heads-up on this... you'd know if this happened
before.

On Sun, Feb 14, 2016 at 9:06 AM, Michael Welling  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

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

2016-02-14 Thread Michael Welling 
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)

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

It looks like the device is documented to be using the range:
https://www.kernel.org/doc/Documentation/devices.txt

Could you run cat /proc/devices?

> [1.952527] ucm: couldn't register device number
> 
> 
> Thanks,
> Ying Huang

> #
> # Automatically generated file; DO NOT EDIT.
> # Linux/x86_64 4.5.0-rc1 Kernel Configuration
> #
> CONFIG_64BIT=y
> CONFIG_X86_64=y
> CONFIG_X86=y
> CONFIG_INSTRUCTION_DECODER=y
> CONFIG_PERF_EVENTS_INTEL_UNCORE=y
> CONFIG_OUTPUT_FORMAT="elf64-x86-64"
> CONFIG_ARCH_DEFCONFIG="arch/x86/configs/x86_64_defconfig"
> CONFIG_LOCKDEP_SUPPORT=y
> CONFIG_STACKTRACE_SUPPORT=y
> CONFIG_MMU=y
> CONFIG_ARCH_MMAP_RND_BITS_MIN=28
> CONFIG_ARCH_MMAP_RND_BITS_MAX=32
> CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MIN=8
> CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MAX=16
> CONFIG_NEED_DMA_MAP_STATE=y
> CONFIG_NEED_SG_DMA_LENGTH=y
> CONFIG_GENERIC_ISA_DMA=y
> CONFIG_GENERIC_BUG=y
> CONFIG_GENERIC_BUG_RELATIVE_POINTERS=y
> CONFIG_GENERIC_HWEIGHT=y
> CONFIG_ARCH_MAY_HAVE_PC_FDC=y
> CONFIG_RWSEM_XCHGADD_ALGORITHM=y
> CONFIG_GENERIC_CALIBRATE_DELAY=y
> CONFIG_ARCH_HAS_CPU_RELAX=y
> CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y
> CONFIG_HAVE_SETUP_PER_CPU_AREA=y
> CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y
> CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y
> CONFIG_ARCH_HIBERNATION_POSSIBLE=y
> CONFIG_ARCH_SUSPEND_POSSIBLE=y
> CONFIG_ARCH_WANT_HUGE_PMD_SHARE=y
> CONFIG_ARCH_WANT_GENERAL_HUGETLB=y
> CONFIG_ZONE_DMA32=y
> CONFIG_AUDIT_ARCH=y
> CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y
> CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y
> CONFIG_X86_64_SMP=y
> CONFIG_ARCH_HWEIGHT_CFLAGS="-fcall-saved-rdi -fcall-saved-rsi 
> -fcall-saved-rdx -fcall-saved-rcx -fcall-saved-r8 -fcall-saved-r9 
> -fcall-saved-r10 -fcall-saved-r11"
> CONFIG_ARCH_SUPPORTS_UPROBES=y
> CONFIG_FIX_EARLYCON_MEM=y
> CONFIG_PGTABLE_LEVELS=4
> CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
> CONFIG_IRQ_WORK=y
> CONFIG_BUILDTIME_EXTABLE_SORT=y
> 
> #
> # General setup
> #
> CONFIG_INIT_ENV_ARG_LIMIT=32
> CONFIG_CROSS_COMPILE=""
> # CONFIG_COMPILE_TEST is not set
> CONFIG_LOCALVERSION=""
> CONFIG_LOCALVERSION_AUTO=y
> CONFIG_HAVE_KERNEL_GZIP=y
> CONFIG_HAVE_KERNEL_BZIP2=y
> CONFIG_HAVE_KERNEL_LZMA=y
> CONFIG_HAVE_KERNEL_XZ=y
> CONFIG_HAVE_KERNEL_LZO=y
> CONFIG_HAVE_KERNEL_LZ4=y
> CONFIG_KERNEL_GZIP=y
> # CONFIG_KERNEL_BZIP2 is not set
> # CONFIG_KERNEL_LZMA is not set
> # CONFIG_KERNEL_XZ is not set
> # CONFIG_KERNEL_LZO is not set
> # CONFIG_KERNEL_LZ4 is not set
> CONFIG_DEFAULT_HOSTNAME="(none)"
> CONFIG_SWAP=y
> CONFIG_SYSVIPC=y
> CONFIG_SYSVIPC_SYSCTL=y
> CONFIG_POSIX_MQUEUE=y
> CONFIG_POSIX_MQUEUE_SYSCTL=y
> CONFIG_CROSS_MEMORY_ATTACH=y
> CONFIG_FHANDLE=y
> # CONFIG_USELIB is not set
> # CONFIG_AUDIT is not set
> CONFIG_HAVE_ARCH_AUDITSYSCALL=y
> 
> #
> # IRQ subsystem
> #
> CONFIG_GENERIC_IRQ_PROBE=y
> CONFIG_GENERIC_IRQ_SHOW=y
> CONFIG_GENERIC_PENDING_IRQ=y
> CONFIG_GENERIC_IRQ_CHIP=y
> CONFIG_IRQ_DOMAIN=y
> CONFIG_IRQ_DOMAIN_HIERARCHY=y
> CONFIG_GENERIC_MSI_IRQ=y
> CONFIG_GENERIC_MSI_IRQ_DOMAIN=y
> CONFIG_IRQ_DOMAIN_DEBUG=y
> CONFIG_IRQ_FORCED_THREADING=y
> CONFIG_SPARSE_IRQ=y
> CONFIG_CLOCKSOURCE_WATCHDOG=y
> CONFIG_ARCH_CLOCKSOURCE_DATA=y
> CONFIG_CLOCKSOURCE_VALIDATE_LAST_CYCLE=y
> CONFIG_GENERIC_TIME_VSYSCALL=y
> CONFIG_GENERIC_CLOCKEVENTS=y
> CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y
> CONFIG_GENERIC_CLOCKEVENTS_MIN_ADJUST=y
> CONFIG_GENERIC_CMOS_UPDATE=y
> 
> #
> # Timers subsystem
> #
> CONFIG_HZ_PERIODIC=y
> # CONFIG_NO_HZ_IDLE is not set
> # CONFIG_NO_HZ_FULL is not set
> CONFIG_NO_HZ=y
> # CONFIG_HIGH_RES_TIMERS is not set
> 
> #
> # CPU/Task time and stats accounting
> #
> # CONFIG_TICK_CPU_ACCOUNTING is not set
> # CONFIG_VIRT_CPU_ACCOUNTING_GEN is not set
> CONFIG_IRQ_TIME_ACCOUNTING=y
> # CONFIG_BSD_PROCESS_ACCT is not set
> # CONFIG_TASKSTATS is not set
> 
> #
> # RCU Subsystem
> #
> CONFIG_TREE_RCU=y
> # CONFIG_RCU_EXPERT is not set
> CONFIG_SRCU=y
> # CONFIG_TASKS_RCU is not set
> CONFIG_RCU_STALL_COMMON=y
> # CONFIG_TREE_RCU_TRACE is not set
> # CONFIG_RCU_EXPEDITE_BOOT is not set
> CONFIG_BUILD_BIN2C=y
> CONFIG_IKCONFIG=y
> # CONFIG_IKCONFIG_PROC is not set
> CONFIG_LOG_BUF_SHIFT=17
> CONFIG_LOG_CPU_MAX_BUF_SHIFT=12
> CONFIG_HAVE_UNSTABLE_SCHED_CLOCK=y
> CONFIG_ARCH_SUPPORTS_NUMA_BALANCING=y
> CONFIG_ARCH_WANT_BATCHED_UNMAP_TLB_FLUSH=y
> CONFIG_ARCH_SUPPORTS_INT128=y
> #

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

2016-02-14 Thread Greg KH 
On Sun, Feb 14, 2016 at 06:56:20PM +0100, Linus Walleij wrote:
> On Sun, Feb 14, 2016 at 6:49 PM, Greg KH  wrote:
> > 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  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?
> 
> I mean it's annoying that they collide. (Because of the details I
> write below, it's fine it's using the assigned number.
> 
> > Why not just ask for a new reserved one?  We could give you 261 and
> > everything should be fine, right?
> 
> Sure I can post a patch for that, but it just mitigates the problem.
> 
> The report point to the serious problem that on this system
> some dynamic allocations have already stolen major device
> numbers 232 thru 255, and 232 and 233 are also assigned.
> 
> What do you think about a patch that makes fs/char_dev.c
> emit a warning when it starts assigning dynamic numbers
> 233 and below?

That's fine with me.  I also think maybe we should look into just
switching all char major/minor allocation to be dynamic, starting at the
bottom and moving up.  I think the only tools that might have an issue
with that is the raw device controller, but maybe that has been fixed up
in userspace, I haven't looked at that in many years.

I thought I had an old patch around somewhere that did that, will go
look for it this week and see what breaks with it enabled...

thanks,

greg k-h

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

2016-02-14 Thread Michael Welling 
On Sun, Feb 14, 2016 at 11:05:15AM -0800, Greg KH wrote:
> On Sun, Feb 14, 2016 at 06:56:20PM +0100, Linus Walleij wrote:
> > On Sun, Feb 14, 2016 at 6:49 PM, Greg KH  wrote:
> > > 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  
> > >> 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?
> > 
> > I mean it's annoying that they collide. (Because of the details I
> > write below, it's fine it's using the assigned number.
> > 
> > > Why not just ask for a new reserved one?  We could give you 261 and
> > > everything should be fine, right?
> > 
> > Sure I can post a patch for that, but it just mitigates the problem.
> > 
> > The report point to the serious problem that on this system
> > some dynamic allocations have already stolen major device
> > numbers 232 thru 255, and 232 and 233 are also assigned.
> > 
> > What do you think about a patch that makes fs/char_dev.c
> > emit a warning when it starts assigning dynamic numbers
> > 233 and below?
> 
> That's fine with me.  I also think maybe we should look into just
> switching all char major/minor allocation to be dynamic, starting at the
> bottom and moving up.  I think the only tools that might have an issue
> with that is the raw device controller, but maybe that has been fixed up
> in userspace, I haven't looked at that in many years.
>

Is there any reason for the CHRDEV_MAJOR_HASH_SIZE being 255?
If we increase the size to say 511 will it break userspace?

In the future I see a robot building a kernel with more that 255 devices and
having to deal with this kind of collision again.

The handling of large major assignment baffles me.
The major numbers outside of the size of the table are just wrapping around to
the beginning again. This is inherently going to cause collisions.

static inline int major_to_index(unsigned major)
{
return major % CHRDEV_MAJOR_HASH_SIZE;
}

> I thought I had an old patch around somewhere that did that, will go
> look for it this week and see what breaks with it enabled...
> 
> thanks,
> 
> greg k-h

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

2016-02-14 Thread Linus Walleij 
On Sun, Feb 14, 2016 at 6:49 PM, Greg KH  wrote:
> 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  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?

I mean it's annoying that they collide. (Because of the details I
write below, it's fine it's using the assigned number.

> Why not just ask for a new reserved one?  We could give you 261 and
> everything should be fine, right?

Sure I can post a patch for that, but it just mitigates the problem.

The report point to the serious problem that on this system
some dynamic allocations have already stolen major device
numbers 232 thru 255, and 232 and 233 are also assigned.

What do you think about a patch that makes fs/char_dev.c
emit a warning when it starts assigning dynamic numbers
233 and below?

Yours,
Linus Walleij

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

2016-02-14 Thread Linus Walleij 
Greg, heads-up on this... you'd know if this happened
before.

On Sun, Feb 14, 2016 at 9:06 AM, Michael Welling  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

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

2016-02-14 Thread 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  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

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

2016-02-14 Thread Linus Walleij 
On Sun, Feb 14, 2016 at 9:06 AM, Michael Welling  wrote:

> 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)
>
> Something tells me that a new GPIO chardev is taking this spot.

I don't think so, since gpio is reserving it as a core_initcall() it
gets a high chardev major. It's likely the device that used to
be device 232 stealing the fingerprint sensor slot that got
pushed down and is now stealing device 231 infiniband.

Maybe I should make a patch making fs/char_dev.c emit a warning
or fail when it goes below 234... it doesn't currently. It just steals
more numbers. It's a serious archtectural issue if it persists.

Yours,
Linus Walleij

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

2016-02-14 Thread Michael Welling 
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)

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

It looks like the device is documented to be using the range:
https://www.kernel.org/doc/Documentation/devices.txt

Could you run cat /proc/devices?

> [1.952527] ucm: couldn't register device number
> 
> 
> Thanks,
> Ying Huang

> #
> # Automatically generated file; DO NOT EDIT.
> # Linux/x86_64 4.5.0-rc1 Kernel Configuration
> #
> CONFIG_64BIT=y
> CONFIG_X86_64=y
> CONFIG_X86=y
> CONFIG_INSTRUCTION_DECODER=y
> CONFIG_PERF_EVENTS_INTEL_UNCORE=y
> CONFIG_OUTPUT_FORMAT="elf64-x86-64"
> CONFIG_ARCH_DEFCONFIG="arch/x86/configs/x86_64_defconfig"
> CONFIG_LOCKDEP_SUPPORT=y
> CONFIG_STACKTRACE_SUPPORT=y
> CONFIG_MMU=y
> CONFIG_ARCH_MMAP_RND_BITS_MIN=28
> CONFIG_ARCH_MMAP_RND_BITS_MAX=32
> CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MIN=8
> CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MAX=16
> CONFIG_NEED_DMA_MAP_STATE=y
> CONFIG_NEED_SG_DMA_LENGTH=y
> CONFIG_GENERIC_ISA_DMA=y
> CONFIG_GENERIC_BUG=y
> CONFIG_GENERIC_BUG_RELATIVE_POINTERS=y
> CONFIG_GENERIC_HWEIGHT=y
> CONFIG_ARCH_MAY_HAVE_PC_FDC=y
> CONFIG_RWSEM_XCHGADD_ALGORITHM=y
> CONFIG_GENERIC_CALIBRATE_DELAY=y
> CONFIG_ARCH_HAS_CPU_RELAX=y
> CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y
> CONFIG_HAVE_SETUP_PER_CPU_AREA=y
> CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y
> CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y
> CONFIG_ARCH_HIBERNATION_POSSIBLE=y
> CONFIG_ARCH_SUSPEND_POSSIBLE=y
> CONFIG_ARCH_WANT_HUGE_PMD_SHARE=y
> CONFIG_ARCH_WANT_GENERAL_HUGETLB=y
> CONFIG_ZONE_DMA32=y
> CONFIG_AUDIT_ARCH=y
> CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y
> CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y
> CONFIG_X86_64_SMP=y
> CONFIG_ARCH_HWEIGHT_CFLAGS="-fcall-saved-rdi -fcall-saved-rsi 
> -fcall-saved-rdx -fcall-saved-rcx -fcall-saved-r8 -fcall-saved-r9 
> -fcall-saved-r10 -fcall-saved-r11"
> CONFIG_ARCH_SUPPORTS_UPROBES=y
> CONFIG_FIX_EARLYCON_MEM=y
> CONFIG_PGTABLE_LEVELS=4
> CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
> CONFIG_IRQ_WORK=y
> CONFIG_BUILDTIME_EXTABLE_SORT=y
> 
> #
> # General setup
> #
> CONFIG_INIT_ENV_ARG_LIMIT=32
> CONFIG_CROSS_COMPILE=""
> # CONFIG_COMPILE_TEST is not set
> CONFIG_LOCALVERSION=""
> CONFIG_LOCALVERSION_AUTO=y
> CONFIG_HAVE_KERNEL_GZIP=y
> CONFIG_HAVE_KERNEL_BZIP2=y
> CONFIG_HAVE_KERNEL_LZMA=y
> CONFIG_HAVE_KERNEL_XZ=y
> CONFIG_HAVE_KERNEL_LZO=y
> CONFIG_HAVE_KERNEL_LZ4=y
> CONFIG_KERNEL_GZIP=y
> # CONFIG_KERNEL_BZIP2 is not set
> # CONFIG_KERNEL_LZMA is not set
> # CONFIG_KERNEL_XZ is not set
> # CONFIG_KERNEL_LZO is not set
> # CONFIG_KERNEL_LZ4 is not set
> CONFIG_DEFAULT_HOSTNAME="(none)"
> CONFIG_SWAP=y
> CONFIG_SYSVIPC=y
> CONFIG_SYSVIPC_SYSCTL=y
> CONFIG_POSIX_MQUEUE=y
> CONFIG_POSIX_MQUEUE_SYSCTL=y
> CONFIG_CROSS_MEMORY_ATTACH=y
> CONFIG_FHANDLE=y
> # CONFIG_USELIB is not set
> # CONFIG_AUDIT is not set
> CONFIG_HAVE_ARCH_AUDITSYSCALL=y
> 
> #
> # IRQ subsystem
> #
> CONFIG_GENERIC_IRQ_PROBE=y
> CONFIG_GENERIC_IRQ_SHOW=y
> CONFIG_GENERIC_PENDING_IRQ=y
> CONFIG_GENERIC_IRQ_CHIP=y
> CONFIG_IRQ_DOMAIN=y
> CONFIG_IRQ_DOMAIN_HIERARCHY=y
> CONFIG_GENERIC_MSI_IRQ=y
> CONFIG_GENERIC_MSI_IRQ_DOMAIN=y
> CONFIG_IRQ_DOMAIN_DEBUG=y
> CONFIG_IRQ_FORCED_THREADING=y
> CONFIG_SPARSE_IRQ=y
> CONFIG_CLOCKSOURCE_WATCHDOG=y
> CONFIG_ARCH_CLOCKSOURCE_DATA=y
> CONFIG_CLOCKSOURCE_VALIDATE_LAST_CYCLE=y
> CONFIG_GENERIC_TIME_VSYSCALL=y
> CONFIG_GENERIC_CLOCKEVENTS=y
> CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y
> CONFIG_GENERIC_CLOCKEVENTS_MIN_ADJUST=y
> CONFIG_GENERIC_CMOS_UPDATE=y
> 
> #
> # Timers subsystem
> #
> CONFIG_HZ_PERIODIC=y
> # CONFIG_NO_HZ_IDLE is not set
> # CONFIG_NO_HZ_FULL is not set
> CONFIG_NO_HZ=y
> # CONFIG_HIGH_RES_TIMERS is not set
> 
> #
> # CPU/Task time and stats accounting
> #
> # CONFIG_TICK_CPU_ACCOUNTING is not set
> # CONFIG_VIRT_CPU_ACCOUNTING_GEN is not set
> CONFIG_IRQ_TIME_ACCOUNTING=y
> # CONFIG_BSD_PROCESS_ACCT is not set
> # CONFIG_TASKSTATS is not set
> 
> #
> # RCU Subsystem
> #
> CONFIG_TREE_RCU=y
> # CONFIG_RCU_EXPERT is not set
> CONFIG_SRCU=y
> # CONFIG_TASKS_RCU is not set
> CONFIG_RCU_STALL_COMMON=y
> # CONFIG_TREE_RCU_TRACE is not set
> # CONFIG_RCU_EXPEDITE_BOOT is not set
> CONFIG_BUILD_BIN2C=y
> CONFIG_IKCONFIG=y
> # CONFIG_IKCONFIG_PROC is not set
> CONFIG_LOG_BUF_SHIFT=17
> CONFIG_LOG_CPU_MAX_BUF_SHIFT=12
> CONFIG_HAVE_UNSTABLE_SCHED_CLOCK=y
> CONFIG_ARCH_SUPPORTS_NUMA_BALANCING=y
> CONFIG_ARCH_WANT_BATCHED_UNMAP_TLB_FLUSH=y
> CONFIG_ARCH_SUPPORTS_INT128=y
> #