From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: Logan Gunthorpe <logang@deltatee.com>
Cc: Bjorn Helgaas <helgaas@kernel.org>,
kernel test robot <fengguang.wu@intel.com>,
Linus Torvalds <torvalds@linux-foundation.org>, LKP <lkp@01.org>,
linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org,
linux-doc@vger.kernel.org, linux-pci@vger.kernel.org,
linux-kernel@vger.kernel.org, Bjorn Helgaas <bhelgaas@google.com>,
wfg@linux.intel.com, Alan Cox <alan@linux.intel.com>,
Arnd Bergmann <arnd@arndb.de>,
Linus Walleij <linus.walleij@linaro.org>,
David Airlie <airlied@linux.ie>,
David Herrmann <dh.herrmann@gmail.com>,
Daniel Vetter <daniel.vetter@ffwll.ch>
Subject: Re: [Merge tag 'pci-v4.12-changes' of git] 857f864014: BUG: unable to handle kernel NULL pointer dereference at 00000000000000a8
Date: Wed, 14 Jun 2017 07:00:49 +0200 [thread overview]
Message-ID: <20170614050049.GA11630@kroah.com> (raw)
In-Reply-To: <f848a5fb-096c-a025-cc3b-314cc3899f9e@deltatee.com>
On Tue, Jun 13, 2017 at 11:47:30AM -0600, Logan Gunthorpe wrote:
>
>
> On 13/06/17 10:35 AM, Greg Kroah-Hartman wrote:
> > For char devices, I doubt it, but we can't take the chance, which is why
> > you make it an option. Then, it's enabled for 'allmodconfig' builds,
> > which helps testers out.
>
> Well I took a look at this and it looks like a lot of work to modify all
> the drivers to support a possible dynamic allocation and I'm not really
> able to do all that right now.
No, don't modify any drivers, do this in the core chardev code.
> However, correct me if I'm missing something, but it looks fairly
> straightforward to extend the dynamic region above 256 in cases like
> this. There are already fixed major numbers above 255 and the
> infrastructure appears to support it. So what are your thoughts on the
> change below? I'd be happy to clean it up into a proper patch if you
> agree it's a workable option.
>
> Thanks,
>
> Logan
>
>
>
> diff --git a/fs/char_dev.c b/fs/char_dev.c
> index fb8507f521b2..539352425d95 100644
> --- a/fs/char_dev.c
> +++ b/fs/char_dev.c
> @@ -59,6 +59,29 @@ void chrdev_show(struct seq_file *f, off_t offset)
>
> #endif /* CONFIG_PROC_FS */
>
> +static int find_dynamic_major(void)
> +{
> + int i;
> + struct char_device_struct **cp;
> +
> + for (i = ARRAY_SIZE(chrdevs)-1; i > CHRDEV_MAJOR_DYN_END; i--) {
> + if (chrdevs[i] == NULL)
> + return i;
> + }
> +
> + for (i = CHRDEV_MAJOR_DYN_EXT_START;
> + i > CHRDEV_MAJOR_DYN_EXT_END; i--) {
> + for (cp = &chrdevs[major_to_index(i)]; *cp; cp = &(*cp)->next)
> + if ((*cp)->major == i)
> + break;
> +
> + if (*cp == NULL || (*cp)->major != i)
> + return i;
> + }
> +
> + return -EBUSY;
> +}
> +
> /*
> * Register a single major with a specified minor range.
> *
> @@ -84,22 +107,11 @@ __register_chrdev_region(unsigned int major,
> unsigned int baseminor,
>
> mutex_lock(&chrdevs_lock);
>
> - /* temporary */
> if (major == 0) {
> - for (i = ARRAY_SIZE(chrdevs)-1; i > 0; i--) {
> - if (chrdevs[i] == NULL)
> - break;
> - }
> -
> - if (i < CHRDEV_MAJOR_DYN_END)
> - pr_warn("CHRDEV \"%s\" major number %d goes below the dynamic
> allocation range\n",
> - name, i);
> -
> - if (i == 0) {
> - ret = -EBUSY;
> + ret = find_dynamic_major();
> + if (ret < 0)
> goto out;
> - }
> - major = i;
> + major = ret;
> }
>
> cd->major = major;
> diff --git a/include/linux/fs.h b/include/linux/fs.h
> index 249dad4e8d26..5780d69034ca 100644
> --- a/include/linux/fs.h
> +++ b/include/linux/fs.h
> @@ -2448,6 +2448,9 @@ static inline void bd_unlink_disk_holder(struct
> block_device *bdev,
> #define CHRDEV_MAJOR_HASH_SIZE 255
> /* Marks the bottom of the first segment of free char majors */
> #define CHRDEV_MAJOR_DYN_END 234
> +#define CHRDEV_MAJOR_DYN_EXT_START 511
> +#define CHRDEV_MAJOR_DYN_EXT_END 384
> +
> extern int alloc_chrdev_region(dev_t *, unsigned, unsigned, const char *);
> extern int register_chrdev_region(dev_t, unsigned, const char *);
> extern int __register_chrdev(unsigned int major, unsigned int baseminor,
>
>
>
> ----
>
> This results in char devices like this (another patch might be prudent
> to fix the ordering):
>
> Character devices:
> 510 ttySLM
> 1 mem
> 511 noz
> 4 /dev/vc/0
> 4 tty
> 4 ttyS
> 5 /dev/tty
> 5 /dev/console
> 5 /dev/ptmx
> 7 vcs
> 9 st
> 10 misc
> 13 input
> 21 sg
> 29 fb
> 43 ttyI
> 45 isdn
> 68 capi20
> 86 ch
> 90 mtd
> 99 ppdev
> 108 ppp
> 128 ptm
> 136 pts
> 152 aoechr
> 153 spi
> 161 ircomm
> 172 ttyMX
> 174 ttyMI
> 202 cpu/msr
> 203 cpu/cpuid
> 204 ttyJ
> 204 ttyMAX
> 206 osst
> 226 drm
> 235 ttyS
> 236 ttyRP
> 237 ttyARC
> 238 ttyPS
> 239 ttyIFX
> 494 rio_cm
> 240 ttySC
> 495 cros_ec
> 241 ipmidev
> 496 hidraw
> 242 rio_mport
> 497 ttySDIO
> 243 xz_dec_test
> 498 uio
> 244 bsg
> 499 firewire
> 245 pvfs2-req
> 500 nvme
> 246 watchdog
> 501 aac
> 247 iio
> 502 mei
> 248 ptp
> 503 phantom
> 249 pps
> 504 aux
> 250 dax
> 505 cmx
> 251 dimmctl
> 506 cmm
> 252 ndctl
> 507 ttySLP
> 253 tpm
> 508 ttyIPWp
> 254 gpiochip
> 509 ttySL
>
At quick glance, ooks good to me, care to clean it up and make it behind
a config option?
thanks,
greg k-h
next prev parent reply other threads:[~2017-06-14 5:00 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-06-04 12:33 [Merge tag 'pci-v4.12-changes' of git] 857f864014: BUG: unable to handle kernel NULL pointer dereference at 00000000000000a8 kernel test robot
[not found] ` <5933fe2d.V33ODGPU9noDVuyF%fengguang.wu-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
2017-06-06 17:55 ` Bjorn Helgaas
2017-06-06 19:02 ` Logan Gunthorpe
2017-06-12 20:08 ` Bjorn Helgaas
[not found] ` <20170612200852.GA28578-1RhO1Y9PlrlHTL0Zs8A6p5iNqAH0jzoTYJqu5kTmcBRl57MIdRCFDg@public.gmane.org>
2017-06-12 23:34 ` Logan Gunthorpe
2017-06-13 4:18 ` Greg Kroah-Hartman
2017-06-13 4:29 ` Logan Gunthorpe
2017-06-13 4:34 ` Greg Kroah-Hartman
2017-06-13 4:35 ` Greg Kroah-Hartman
2017-06-13 16:25 ` Logan Gunthorpe
2017-06-13 16:35 ` Greg Kroah-Hartman
2017-06-13 17:47 ` Logan Gunthorpe
2017-06-14 5:00 ` Greg Kroah-Hartman [this message]
2017-06-14 5:55 ` Logan Gunthorpe
2017-06-13 19:13 ` Sven-Haegar Koch
2017-06-14 5:01 ` Greg Kroah-Hartman
2017-06-14 9:59 ` Linus Walleij
2017-06-14 15:49 ` Logan Gunthorpe
2017-06-13 11:48 ` Alan Cox
2017-06-13 16:16 ` Logan Gunthorpe
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=20170614050049.GA11630@kroah.com \
--to=gregkh@linuxfoundation.org \
--cc=airlied@linux.ie \
--cc=alan@linux.intel.com \
--cc=arnd@arndb.de \
--cc=bhelgaas@google.com \
--cc=daniel.vetter@ffwll.ch \
--cc=devicetree@vger.kernel.org \
--cc=dh.herrmann@gmail.com \
--cc=fengguang.wu@intel.com \
--cc=helgaas@kernel.org \
--cc=linus.walleij@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=lkp@01.org \
--cc=logang@deltatee.com \
--cc=torvalds@linux-foundation.org \
--cc=wfg@linux.intel.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).