All of lore.kernel.org
 help / color / mirror / Atom feed
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: Sven-Haegar Koch <haegar@sdinet.de>
Cc: Logan Gunthorpe <logang@deltatee.com>,
	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:01:12 +0200	[thread overview]
Message-ID: <20170614050112.GB11630@kroah.com> (raw)
In-Reply-To: <alpine.DEB.2.20.1706132106410.11042@aurora.sdinet.de>

On Tue, Jun 13, 2017 at 09:13:32PM +0200, Sven-Haegar Koch wrote:
> On Tue, 13 Jun 2017, Greg Kroah-Hartman wrote:
> 
> > On Tue, Jun 13, 2017 at 10:25:40AM -0600, Logan Gunthorpe wrote:
> > > 
> > > On 12/06/17 10:35 PM, Greg Kroah-Hartman wrote:
> > > > Or better yet, just turn all char major allocations into dynamic, which
> > > > would be really good for test systems.  I thought someone proposed
> > > > patches for that a long time ago, but I can't find them anymore.  That
> > > > would be the simplest solution here.
> > > 
> > > Would people not complain about that? I would not be surprised if some
> > > crazy application is using hard coded major numbers in userspace. So
> > > such a change could potentially break userspace...
> > 
> > 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.
> 
> At least for /dev/null, /dev/zero, and perhaps /dev/tty it would 
> definitely break things if the major+minor number is not static. I have 
> multiple chroot environments having only some minimal needed static 
> /dev subdir, with naturally no daemons or filesystem creating those 
> on-demand. For the main /dev I use whatever the system sets up, so 
> devtmpfs with udev.

No, it wouldn't be required, it would be an option for those people
using devtmpfs.

thanks,

greg k-h

WARNING: multiple messages have this Message-ID (diff)
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: lkp@lists.01.org
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:01:12 +0200	[thread overview]
Message-ID: <20170614050112.GB11630@kroah.com> (raw)
In-Reply-To: <alpine.DEB.2.20.1706132106410.11042@aurora.sdinet.de>

[-- Attachment #1: Type: text/plain, Size: 1444 bytes --]

On Tue, Jun 13, 2017 at 09:13:32PM +0200, Sven-Haegar Koch wrote:
> On Tue, 13 Jun 2017, Greg Kroah-Hartman wrote:
> 
> > On Tue, Jun 13, 2017 at 10:25:40AM -0600, Logan Gunthorpe wrote:
> > > 
> > > On 12/06/17 10:35 PM, Greg Kroah-Hartman wrote:
> > > > Or better yet, just turn all char major allocations into dynamic, which
> > > > would be really good for test systems.  I thought someone proposed
> > > > patches for that a long time ago, but I can't find them anymore.  That
> > > > would be the simplest solution here.
> > > 
> > > Would people not complain about that? I would not be surprised if some
> > > crazy application is using hard coded major numbers in userspace. So
> > > such a change could potentially break userspace...
> > 
> > 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.
> 
> At least for /dev/null, /dev/zero, and perhaps /dev/tty it would 
> definitely break things if the major+minor number is not static. I have 
> multiple chroot environments having only some minimal needed static 
> /dev subdir, with naturally no daemons or filesystem creating those 
> on-demand. For the main /dev I use whatever the system sets up, so 
> devtmpfs with udev.

No, it wouldn't be required, it would be an option for those people
using devtmpfs.

thanks,

greg k-h

WARNING: multiple messages have this Message-ID (diff)
From: gregkh@linuxfoundation.org (Greg Kroah-Hartman)
To: linux-arm-kernel@lists.infradead.org
Subject: [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:01:12 +0200	[thread overview]
Message-ID: <20170614050112.GB11630@kroah.com> (raw)
In-Reply-To: <alpine.DEB.2.20.1706132106410.11042@aurora.sdinet.de>

On Tue, Jun 13, 2017 at 09:13:32PM +0200, Sven-Haegar Koch wrote:
> On Tue, 13 Jun 2017, Greg Kroah-Hartman wrote:
> 
> > On Tue, Jun 13, 2017 at 10:25:40AM -0600, Logan Gunthorpe wrote:
> > > 
> > > On 12/06/17 10:35 PM, Greg Kroah-Hartman wrote:
> > > > Or better yet, just turn all char major allocations into dynamic, which
> > > > would be really good for test systems.  I thought someone proposed
> > > > patches for that a long time ago, but I can't find them anymore.  That
> > > > would be the simplest solution here.
> > > 
> > > Would people not complain about that? I would not be surprised if some
> > > crazy application is using hard coded major numbers in userspace. So
> > > such a change could potentially break userspace...
> > 
> > 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.
> 
> At least for /dev/null, /dev/zero, and perhaps /dev/tty it would 
> definitely break things if the major+minor number is not static. I have 
> multiple chroot environments having only some minimal needed static 
> /dev subdir, with naturally no daemons or filesystem creating those 
> on-demand. For the main /dev I use whatever the system sets up, so 
> devtmpfs with udev.

No, it wouldn't be required, it would be an option for those people
using devtmpfs.

thanks,

greg k-h

  reply	other threads:[~2017-06-14  5:01 UTC|newest]

Thread overview: 51+ 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
2017-06-04 12:33 ` kernel test robot
2017-06-04 12:33 ` kernel test robot
2017-06-06 17:55 ` Bjorn Helgaas
2017-06-06 17:55   ` Bjorn Helgaas
2017-06-06 17:55   ` Bjorn Helgaas
2017-06-06 19:02   ` Logan Gunthorpe
2017-06-12 20:08     ` Bjorn Helgaas
2017-06-12 20:08       ` Bjorn Helgaas
2017-06-12 23:34       ` Logan Gunthorpe
2017-06-12 23:34         ` Logan Gunthorpe
2017-06-13  4:18         ` Greg Kroah-Hartman
2017-06-13  4:18           ` Greg Kroah-Hartman
2017-06-13  4:18           ` Greg Kroah-Hartman
2017-06-13  4:29           ` Logan Gunthorpe
2017-06-13  4:29             ` Logan Gunthorpe
2017-06-13  4:34             ` Greg Kroah-Hartman
2017-06-13  4:34               ` Greg Kroah-Hartman
2017-06-13  4:34               ` Greg Kroah-Hartman
2017-06-13  4:35               ` Greg Kroah-Hartman
2017-06-13  4:35                 ` Greg Kroah-Hartman
2017-06-13  4:35                 ` Greg Kroah-Hartman
2017-06-13 16:25                 ` Logan Gunthorpe
2017-06-13 16:25                   ` Logan Gunthorpe
2017-06-13 16:35                   ` Greg Kroah-Hartman
2017-06-13 16:35                     ` Greg Kroah-Hartman
2017-06-13 16:35                     ` Greg Kroah-Hartman
2017-06-13 17:47                     ` Logan Gunthorpe
2017-06-13 17:47                       ` Logan Gunthorpe
2017-06-14  5:00                       ` Greg Kroah-Hartman
2017-06-14  5:00                         ` Greg Kroah-Hartman
2017-06-14  5:00                         ` Greg Kroah-Hartman
2017-06-14  5:55                         ` Logan Gunthorpe
2017-06-14  5:55                           ` Logan Gunthorpe
2017-06-13 19:13                     ` Sven-Haegar Koch
2017-06-13 19:13                       ` Sven-Haegar Koch
2017-06-13 19:13                       ` Sven-Haegar Koch
2017-06-13 19:13                       ` Sven-Haegar Koch
2017-06-14  5:01                       ` Greg Kroah-Hartman [this message]
2017-06-14  5:01                         ` Greg Kroah-Hartman
2017-06-14  5:01                         ` Greg Kroah-Hartman
2017-06-14  9:59               ` Linus Walleij
2017-06-14  9:59                 ` Linus Walleij
2017-06-14  9:59                 ` Linus Walleij
2017-06-14 15:49                 ` Logan Gunthorpe
2017-06-14 15:49                   ` Logan Gunthorpe
2017-06-13 11:48         ` Alan Cox
2017-06-13 11:48           ` Alan Cox
2017-06-13 11:48           ` Alan Cox
2017-06-13 16:16           ` Logan Gunthorpe
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=20170614050112.GB11630@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=haegar@sdinet.de \
    --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 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.