From: Greg KH <gregkh@linuxfoundation.org>
To: lkp@lists.01.org
Subject: Re: [gpio] 3c702e9987: kmsg.user_verbs:couldn't_register_device_number
Date: Sun, 14 Feb 2016 09:49:47 -0800 [thread overview]
Message-ID: <20160214174947.GA21558@kroah.com> (raw)
In-Reply-To: <CACRpkdYo4xAU0VDTopmg3r=yo9fzqeBHii0v2kvkmARPL349Og@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2897 bytes --]
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
WARNING: multiple messages have this Message-ID (diff)
From: Greg KH <gregkh@linuxfoundation.org>
To: Linus Walleij <linus.walleij@linaro.org>
Cc: Michael Welling <mwelling@ieee.org>,
Roland Dreier <rolandd@cisco.com>,
kernel test robot <ying.huang@linux.intel.com>,
lkp@01.org, LKML <linux-kernel@vger.kernel.org>,
Arnd Bergmann <arnd@arndb.de>,
Markus Pargmann <mpa@pengutronix.de>,
Johan Hovold <johan@kernel.org>
Subject: Re: [lkp] [gpio] 3c702e9987: kmsg.user_verbs:couldn't_register_device_number
Date: Sun, 14 Feb 2016 09:49:47 -0800 [thread overview]
Message-ID: <20160214174947.GA21558@kroah.com> (raw)
In-Reply-To: <CACRpkdYo4xAU0VDTopmg3r=yo9fzqeBHii0v2kvkmARPL349Og@mail.gmail.com>
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
next prev parent reply other threads:[~2016-02-14 17:49 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-02-14 6:59 [gpio] 3c702e9987: kmsg.user_verbs:couldn't_register_device_number kernel test robot
2016-02-14 6:59 ` [lkp] " kernel test robot
2016-02-14 8:06 ` Michael Welling
2016-02-14 8:06 ` [lkp] " Michael Welling
2016-02-14 17:42 ` Linus Walleij
2016-02-14 17:42 ` [lkp] " Linus Walleij
2016-02-14 17:49 ` Greg KH [this message]
2016-02-14 17:49 ` Greg KH
2016-02-14 17:56 ` Linus Walleij
2016-02-14 17:56 ` [lkp] " Linus Walleij
2016-02-14 19:05 ` Greg KH
2016-02-14 19:05 ` [lkp] " Greg KH
2016-02-14 19:51 ` Michael Welling
2016-02-14 19:51 ` [lkp] " Michael Welling
2016-02-14 23:49 ` Greg KH
2016-02-14 23:49 ` [lkp] " Greg KH
2016-02-15 4:21 ` Michael Welling
2016-02-15 4:21 ` [lkp] " Michael Welling
2016-02-14 17:48 ` Linus Walleij
2016-02-14 17:48 ` [lkp] " Linus Walleij
2016-02-15 2:39 ` Huang, Ying
2016-02-15 2:39 ` [LKP] [lkp] " Huang, Ying
2016-02-15 9:36 ` Linus Walleij
2016-02-15 9:36 ` [LKP] [lkp] " Linus Walleij
2016-02-23 6:35 ` Huang, Ying
2016-02-23 6:35 ` [LKP] [lkp] " Huang, Ying
2016-02-23 21:50 ` Michael Welling
2016-02-23 21:50 ` [LKP] [lkp] " Michael Welling
2016-02-24 16:01 ` Linus Walleij
2016-02-24 16:01 ` [LKP] [lkp] " Linus Walleij
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20160214174947.GA21558@kroah.com \
--to=gregkh@linuxfoundation.org \
--cc=lkp@lists.01.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.