All of lore.kernel.org
 help / color / mirror / Atom feed
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: Tue, 13 Jun 2017 06:35:18 +0200	[thread overview]
Message-ID: <20170613043518.GA14621@kroah.com> (raw)
In-Reply-To: <20170613043416.GB14217@kroah.com>

On Tue, Jun 13, 2017 at 06:34:16AM +0200, Greg Kroah-Hartman wrote:
> On Mon, Jun 12, 2017 at 10:29:20PM -0600, Logan Gunthorpe wrote:
> > 
> > 
> > On 12/06/17 10:18 PM, Greg Kroah-Hartman wrote:
> > > What test causes so many major numbers to be allocated?  Is this
> > > in-kernel test code?  Do you really have a system that requires so many
> > > different drivers that all want a dynamic char major?
> > 
> > This is a 0day kernel robot test. I'm not sure the motivations of its
> > design but it seems to be similar to an allyesconfig. So all/most
> > modules are compiled in and allocating their char device regions on boot
> > of a qemu instance.
> 
> Ah, that makes sense.  Well, someone can always work on expanding the
> range of dynamic char major numbers if they are running out of them on a
> real system, I'll gladly take patches for that :)

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.

thnaks,

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: Tue, 13 Jun 2017 06:35:18 +0200	[thread overview]
Message-ID: <20170613043518.GA14621@kroah.com> (raw)
In-Reply-To: <20170613043416.GB14217@kroah.com>

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

On Tue, Jun 13, 2017 at 06:34:16AM +0200, Greg Kroah-Hartman wrote:
> On Mon, Jun 12, 2017 at 10:29:20PM -0600, Logan Gunthorpe wrote:
> > 
> > 
> > On 12/06/17 10:18 PM, Greg Kroah-Hartman wrote:
> > > What test causes so many major numbers to be allocated?  Is this
> > > in-kernel test code?  Do you really have a system that requires so many
> > > different drivers that all want a dynamic char major?
> > 
> > This is a 0day kernel robot test. I'm not sure the motivations of its
> > design but it seems to be similar to an allyesconfig. So all/most
> > modules are compiled in and allocating their char device regions on boot
> > of a qemu instance.
> 
> Ah, that makes sense.  Well, someone can always work on expanding the
> range of dynamic char major numbers if they are running out of them on a
> real system, I'll gladly take patches for that :)

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.

thnaks,

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: Tue, 13 Jun 2017 06:35:18 +0200	[thread overview]
Message-ID: <20170613043518.GA14621@kroah.com> (raw)
In-Reply-To: <20170613043416.GB14217@kroah.com>

On Tue, Jun 13, 2017 at 06:34:16AM +0200, Greg Kroah-Hartman wrote:
> On Mon, Jun 12, 2017 at 10:29:20PM -0600, Logan Gunthorpe wrote:
> > 
> > 
> > On 12/06/17 10:18 PM, Greg Kroah-Hartman wrote:
> > > What test causes so many major numbers to be allocated?  Is this
> > > in-kernel test code?  Do you really have a system that requires so many
> > > different drivers that all want a dynamic char major?
> > 
> > This is a 0day kernel robot test. I'm not sure the motivations of its
> > design but it seems to be similar to an allyesconfig. So all/most
> > modules are compiled in and allocating their char device regions on boot
> > of a qemu instance.
> 
> Ah, that makes sense.  Well, someone can always work on expanding the
> range of dynamic char major numbers if they are running out of them on a
> real system, I'll gladly take patches for that :)

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.

thnaks,

greg k-h

  reply	other threads:[~2017-06-13  4:35 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 [this message]
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
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=20170613043518.GA14621@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 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.