From: Andy Whitcroft <apw@shadowen.org>
To: Greg KH <greg@kroah.com>, Martin Bligh <mbligh@google.com>
Cc: Andrew Morton <akpm@osdl.org>,
linux-kernel@vger.kernel.org, Matt Dobson <colpatch@us.ibm.com>,
Andy Whitcroft <apw@shadowen.org>
Subject: [PATCH] pci device sysdata may be null check in pcibus_to_node
Date: Tue, 20 Dec 2005 21:03:38 +0000 [thread overview]
Message-ID: <20051220210338.GA20681@shadowen.org> (raw)
In-Reply-To: 20051216231752.GA2731@kroah.com
pci device sysdata may be null, check in pcibus_to_node
We have been seeing panic's on NUMA systems in pci_call_probe() in
2.6.15-rc5-mm2 and -mm3. It seems that some changes have occured
to the meaning of the 'sysdata' for a device such that it is no
longer just an integer containing the node, it is now a structure
containing the node and other data. However, it seems that we do not
always initialise this sysdata before we probe the device.
Below are three examples from a boot with this checked for. It is
not clear to me whether it is reasonable to attempt to probe this
device without the bus sysdata being initialised. The attached
patch adds a safety check to pcibus_to_node() to avoid the panic,
this restores the 'call anytime' semantic for this function.
Someone who groks the bus initialisation better than I needs to look
this over and confirm whether its reasonable to have a null sysdata
or not.
Intel(R) PRO/1000 Network Driver - version 6.1.16-k2
Copyright (c) 1999-2005 Intel Corporation.
pci_call_probe: starting drv<c03d4be0> dev<dfd16800> id<c03d4734>
pci_call_probe: dev->bus<dfce6800>
pci_call_probe: dev->bus->sysdata<00000000>
pci_call_probe: node<-1>
e1000: eth0: e1000_probe: Intel(R) PRO/1000 Network Connection
pci_call_probe: starting drv<c03ef220> dev<dfd17400> id<c03eed00>
pci_call_probe: dev->bus<dfce6800>
pci_call_probe: dev->bus->sysdata<00000000>
pci_call_probe: node<-1>
Linux Tulip driver version 1.1.13 (December 15, 2004)
input: AT Translated Set 2 keyboard as /class/input/input0
tulip0: EEPROM default media type Autosense.
tulip0: Index #0 - Media 10baseT (#0) described by a
21140 non-MII (0) block.
tulip0: Index #1 - Media 100baseTx (#3) described by a
21140 non-MII (0) block.
tulip0: Index #2 - Media 10baseT-FDX (#4) described by a
21140 non-MII (0) block.
tulip0: Index #3 - Media 100baseTx-FDX (#5) described by a
21140 non-MII (0) block.
eth1: Digital DS21140 Tulip rev 33 at 0001fc00,
00:00:BC:0F:08:96, IRQ 28.
pci_call_probe: starting drv<c040a360> dev<dfd14400> id<c040a0fc>
pci_call_probe: dev->bus<dfce6600>
pci_call_probe: dev->bus->sysdata<dfffafa0>
pci_call_probe: node<0>
qla1280: QLA1040 found on PCI bus 0, dev 11
Signed-off-by: Andy Whitcroft <apw@shadowen.org>
---
topology.h | 2 +-
1 files changed, 1 insertion(+), 1 deletion(-)
diff -upN reference/include/asm-i386/topology.h current/include/asm-i386/topology.h
--- reference/include/asm-i386/topology.h
+++ current/include/asm-i386/topology.h
@@ -60,7 +60,7 @@ static inline int node_to_first_cpu(int
return first_cpu(mask);
}
-#define pcibus_to_node(bus) ((struct pci_sysdata *)((bus)->sysdata))->node
+#define pcibus_to_node(bus) (((bus)->sysdata)? ((struct pci_sysdata *)((bus)->sysdata))->node : -1)
#define pcibus_to_cpumask(bus) node_to_cpumask(pcibus_to_node(bus))
/* sched_domains SD_NODE_INIT for NUMAQ machines */
next prev parent reply other threads:[~2005-12-20 21:04 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-12-15 7:40 2.6.15-rc5-mm3 Andrew Morton
2005-12-15 9:48 ` 2.6.15-rc5-mm3 Andi Kleen
2005-12-15 15:36 ` 2.6.15-rc5-mm3 Andi Kleen
2005-12-15 14:30 ` 2.6.15-rc5-mm3 Alexander E. Patrakov
2005-12-16 12:50 ` 2.6.15-rc5-mm3 Lenar Lõhmus
2005-12-16 23:17 ` 2.6.15-rc5-mm3 Greg KH
2005-12-17 0:15 ` 2.6.15-rc5-mm3 J.A. Magallon
2005-12-17 1:42 ` 2.6.15-rc5-mm3 Greg KH
2005-12-20 21:03 ` Andy Whitcroft [this message]
2005-12-20 23:16 ` [PATCH] pci device sysdata may be null check in pcibus_to_node Andrew Morton
2005-12-22 21:06 ` [PATCH] pci device ensure sysdata initialised Andy Whitcroft
2005-12-22 23:18 ` Greg KH
2005-12-22 23:43 ` Andy Whitcroft
2005-12-22 23:51 ` Greg KH
2005-12-22 23:56 ` Andy Whitcroft
2005-12-18 8:16 ` 2.6.15-rc5-mm3 Grant Coady
2005-12-18 11:31 ` 2.6.15-rc5-mm3 Rafael J. Wysocki
2005-12-18 19:54 ` 2.6.15-rc5-mm3 Grant Coady
2005-12-22 17:48 ` 2.6.15-rc5-mm3 Greg KH
2005-12-23 1:05 ` 2.6.15-rc5-mm3 David Brownell
2005-12-21 23:14 ` 2.6.15-rc5-mm3 Jesper Juhl
2005-12-22 4:16 ` 2.6.15-rc5-mm3 Con Kolivas
2005-12-22 18:13 ` 2.6.15-rc5-mm3 Mattia Dongili
2005-12-29 23:46 ` 2.6.15-rc5-mm3 [BUG] smp_processor_id() in preemptible code Peter Williams
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=20051220210338.GA20681@shadowen.org \
--to=apw@shadowen.org \
--cc=akpm@osdl.org \
--cc=colpatch@us.ibm.com \
--cc=greg@kroah.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mbligh@google.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