Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752165AbdFMEf3 (ORCPT ); Tue, 13 Jun 2017 00:35:29 -0400 Received: from mail.linuxfoundation.org ([140.211.169.12]:60376 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751871AbdFMEf1 (ORCPT ); Tue, 13 Jun 2017 00:35:27 -0400 Date: Tue, 13 Jun 2017 06:35:18 +0200 From: Greg Kroah-Hartman To: Logan Gunthorpe Cc: Bjorn Helgaas , kernel test robot , Linus Torvalds , LKP , 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 , wfg@linux.intel.com, Alan Cox , Arnd Bergmann , Linus Walleij , David Airlie , David Herrmann , Daniel Vetter Subject: Re: [Merge tag 'pci-v4.12-changes' of git] 857f864014: BUG: unable to handle kernel NULL pointer dereference at 00000000000000a8 Message-ID: <20170613043518.GA14621@kroah.com> References: <5933fe2d.V33ODGPU9noDVuyF%fengguang.wu@intel.com> <20170606175552.GA12672@bhelgaas-glaptop.roam.corp.google.com> <20170612200852.GA28578@bhelgaas-glaptop.roam.corp.google.com> <61e11e67-6c1b-ef1e-5fb8-a7c9efb17666@deltatee.com> <20170613041842.GA13308@kroah.com> <20170613043416.GB14217@kroah.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170613043416.GB14217@kroah.com> User-Agent: Mutt/1.8.3 (2017-05-23) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1125 Lines: 26 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