linux-kernel - Re: 2.6.23-rc1-mm1 -- mostly fails to build

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <20070725225658.00e18aaa.akpm@linux-foundation.org>
Date:	Wed, 25 Jul 2007 22:56:58 -0700
From:	Andrew Morton <akpm@...ux-foundation.org>
To:	Andy Whitcroft <apw@...dowen.org>
Cc:	linux-kernel@...r.kernel.org, Steve Fox <drfickle@...ibm.com>,
	Mel Gorman <mel@....ul.ie>, Yinghai Lu <yinghai.lu@....com>
Subject: Re: 2.6.23-rc1-mm1 -- mostly fails to build

On Wed, 25 Jul 2007 23:41:46 +0100 Andy Whitcroft <apw@...dowen.org> wrote:

> On Wed, Jul 25, 2007 at 05:36:56PM +0100, Andy Whitcroft wrote:
> 
> > Will investigate the NUMA-Q explosion and report on that separatly.
> 
> Ok, I've been looking at the NUMA-Q boot panic below:
> 
> BUG: unable to handle kernel NULL pointer dereference at virtual address 00000000
>  printing eip:
> c111689f
> *pdpt = 0000000001387001
> *pde = 0000000000000000
> Oops: 0000 [#1]
> SMP
> Modules linked in:
> CPU:    0
> EIP:    0060:[<c111689f>]    Not tainted VLI
> EFLAGS: 00010286   (2.6.23-rc1-mm1-gc8131905-dirty #251)
> EIP is at pci_create_bus+0x11b/0x277
> eax: 00000000   ebx: c9352e00   ecx: c9073e94   edx: c9325400
> esi: c9325400   edi: c932559c   ebp: 00000002   esp: c9073e90
> ds: 007b   es: 007b   fs: 00d8  gs: 0000  ss: 0068
> Process swapper (pid: 1, ti=c9072000 task=c9070030 task.ti=c9072000)
> Stack: c12adc4f c9325400 00000000 00000002 00000000 00000000 00000000 c934c800
>        000000d6 00000000 c1116a09 00000000 c9073ed5 c11b178a 00000000 c934c940
>        00000000 02fffff4 c12bd8ac c934c800 c12bd8b4 c9325000 c1119825 c934c800
> Call Trace:
>  [<c1116a09>] pci_scan_bus_parented+0xe/0x21
>  [<c11b178a>] pci_fixup_i450nx+0xa7/0x101
>  [<c1119825>] pci_do_fixups+0x2d/0x38
>  [<c111665c>] pci_device_add+0x48/0x77
>  [<c11166a5>] pci_scan_single_device+0x1a/0x1f
>  [<c11166bf>] pci_scan_slot+0x15/0x47
>  [<c111670a>] pci_scan_child_bus+0x19/0x7c
>  [<c1116a14>] pci_scan_bus_parented+0x19/0x21
>  [<c11b259d>] pcibios_scan_root+0x75/0x7e
>  [<c1369ee3>] pci_numa_init+0x2c/0xe4
>  [<c1354b87>] kernel_init+0x0/0xa1
>  [<c1354a15>] do_initcalls+0x73/0x1a3
>  [<c109032c>] proc_register+0xa0/0xa7
>  [<c10905cd>] create_proc_entry+0x73/0x86
>  [<c103a5c9>] register_irq_proc+0x75/0x92
>  [<c1354b87>] kernel_init+0x0/0xa1
>  [<c1354be6>] kernel_init+0x5f/0xa1
>  [<c10031c3>] kernel_thread_helper+0x7/0x10
>  =======================
> Code: ff 8b 83 84 00 00 00 c7 04 24 4f dc 2a c1 89 44 24 04 e8 f8 42 f0 ff 83 7c 24 14 00 75 15 8b 93 84 00 00 00 85 d2 74 0b 8b 43 44 <8b> 00 89 82 50 01 00 00 c7 44 24 04 9a 04 00 00 8d bb 88 00 00
> EIP: [<c111689f>] pci_create_bus+0x11b/0x277 SS:ESP 0068:c9073e90
> Kernel panic - not syncing: Attempted to kill init!
> 
> This seems to have been caused by the introduction of the following
> code fragment into pci_create_bus:
> 
>         if (!parent)
>                 set_dev_node(b->bridge, pcibus_to_node(b));
> 
> This has come as part of the -mm patch below:
> 
>     try-parent-numa_node-at-first-before-using-default-v2.patch
> 
> This patch does not seem to be wrong in and of itself.  It does
> expose the fact that we are building busses with NULL sysdata.
> This has come up at least three times now.  Below is the patch
> proposed the last couple of times.  It is needed to allow any machine
> with i450nx quirk, plus for NUMA-Q systems.

All this could have happened due to my hamfisted repairing of yet another
reject storm, too.

> Andrew please could you add this to -mm again.
> 

ok..
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/