From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751556AbcBNRtt (ORCPT ); Sun, 14 Feb 2016 12:49:49 -0500 Received: from mail.linuxfoundation.org ([140.211.169.12]:42486 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751402AbcBNRts (ORCPT ); Sun, 14 Feb 2016 12:49:48 -0500 Date: Sun, 14 Feb 2016 09:49:47 -0800 From: Greg KH To: Linus Walleij Cc: Michael Welling , Roland Dreier , kernel test robot , lkp@01.org, LKML , Arnd Bergmann , Markus Pargmann , Johan Hovold Subject: Re: [lkp] [gpio] 3c702e9987: kmsg.user_verbs:couldn't_register_device_number Message-ID: <20160214174947.GA21558@kroah.com> References: <87ziv3n5fp.fsf@yhuang-dev.intel.com> <20160214080643.GA31304@qwerty.qwertyembedded> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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