mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Linus Torvalds <torvalds@linux-foundation.org>
To: Ingo Molnar <mingo@elte.hu>
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>,
	Greg Kroah-Hartman <gregkh@suse.de>,
	Yinghai Lu <yinghai@kernel.org>,
	Rusty Russell <rusty@rustcorp.com.au>, Tejun Heo <tj@kernel.org>,
	linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org,
	Thomas Gleixner <tglx@linutronix.de>,
	"H. Peter Anvin" <hpa@zytor.com>
Subject: Re: [crash] BUG: unable to handle kernel NULL pointer dereference at (null), last sysfs file: /sys/devices/pci0000:00/0000:00:01.0/local_cpus
Date: Fri, 18 Sep 2009 08:38:02 -0700 (PDT)	[thread overview]
Message-ID: <alpine.LFD.2.01.0909180755530.4950@localhost.localdomain> (raw)
In-Reply-To: <20090918075952.GA29026@elte.hu>



On Fri, 18 Sep 2009, Ingo Molnar wrote:
> 
> [  158.058140] warning: `dbus-daemon' uses 32-bit capabilities (legacy support in use)
> [  159.370562] BUG: unable to handle kernel NULL pointer dereference at (null)
> [  159.372694] IP: [<ffffffff8143b722>] bitmap_scnprintf+0x72/0xd0

Hmm. The code is

   a:	49 63 fc             	movslq %r12d,%rdi
   d:	0f 49 d3             	cmovns %ebx,%edx
  10:	c1 f8 1f             	sar    $0x1f,%eax
  13:	4c 01 ff             	add    %r15,%rdi
  16:	c1 e8 1a             	shr    $0x1a,%eax
  19:	c1 fa 06             	sar    $0x6,%edx
  1c:	41 c1 e8 02          	shr    $0x2,%r8d
  20:	8d 0c 03             	lea    (%rbx,%rax,1),%ecx
  23:	48 63 d2             	movslq %edx,%rdx
  26:	83 e1 3f             	and    $0x3f,%ecx
  29:	29 c1                	sub    %eax,%ecx
  2b:*	49 8b 44 d5 00       	mov    0x0(%r13,%rdx,8),%rax     <-- trapping instruction
  30:	48 c7 c2 8c 37 16 82 	mov    $0xffffffff8216378c,%rdx
  37:	48 d3 e8             	shr    %cl,%rax
  3a:	89 f1                	mov    %esi,%ecx
  3c:	44 89 f6             	mov    %r14d,%esi

and the obvious reason seems to be that 'maskp' is NULL (that faulting 
thing is the code for "val = (maskp[word] >> bit) & chunkmask;" with the 
actual fault being the access of "maskp[word]".

Now, the caller does

	mask = cpumask_of_pcibus(to_pci_dev(dev)->bus);

and then uses cpumask_scnprintf() that is just a wrapper that does

	bitmap_scnprintf(buf, len, cpumask_bits(srcp), nr_cpumask_bits);

So clearly we have "cpumask_of_pcibus()" being NULL (cpumask_bits() would 
not change it).

I assume this is the NUMA case? The non-NUMA case has just

	static inline const struct cpumask *cpumask_of_node(int node)
	{
	        return cpu_online_mask;
	}

so I don't think you can ever get NULL (if we have a NULL cpu_online_mask 
we have bigger problems). 

[ Side note: looking closer, I think our headers are buggy, and I _know_ 
  they are confusing. The above inline declaration of cpumask_of_node() 
  seems to be then later overridden in <asm-generic/topology.h> by a 
  #define! 

  And if I read that right, that will also override the debugging 
  versions that we declared if CONFIG_DEBUG_PER_CPU_MAPS is on. Ingo? 
  Rusty? Am I missing something?

  That said, those overrides should only happen for non-NUMA ]

The NUMA version of 'cpumask_of_node()' has all the debug code for show 
it's not returning NULL, but only when CONFIG_DEBUG_PER_CPU_MAPS is 
enabled. Otherwise it all seems to boil down to (through cpumask_of_pcibus 
and __pcibus_to_node):

	node_to_cpumask_map[bus->sysdata->node]

and it can fail either because "node" isn't initialized, or 
node_to_cpumask_map[] isn't.

Probably 'node' is still -1, and it gets the NULL by going off the array 
into la-la-land.

			Linus

  parent reply	other threads:[~2009-09-18 15:39 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-09-15 20:21 [git pull] first round of PCI updates for 2.6.32 Jesse Barnes
2009-09-16 14:55 ` Linus Torvalds
2009-09-16 15:20   ` Stephen Rothwell
2009-09-17 17:30 ` Ingo Molnar
2009-09-17 17:36   ` Jesse Barnes
2009-09-17 17:59     ` Ingo Molnar
2009-09-17 18:46       ` Jesse Barnes
2009-09-18  7:59         ` [crash] BUG: unable to handle kernel NULL pointer dereference at (null), last sysfs file: /sys/devices/pci0000:00/0000:00:01.0/local_cpus Ingo Molnar
2009-09-18  9:37           ` David Rientjes
2009-09-18 15:38           ` Linus Torvalds [this message]
2009-09-18 15:44             ` Jesse Barnes
2009-09-24  8:18             ` Rusty Russell
2009-09-24 12:18               ` [tip:x86/urgent] x86: Remove redundant non-NUMA topology functions tip-bot for Rusty Russell
2009-09-18 16:24           ` [crash] BUG: unable to handle kernel NULL pointer dereference at (null), last sysfs file: /sys/devices/pci0000:00/0000:00:01.0/local_cpus Yinghai Lu
2009-09-18 16:34             ` Jesse Barnes
2009-09-18 16:51             ` Linus Torvalds
2009-09-18 17:10               ` Jesse Barnes
2009-09-18 15:27       ` [git pull] first round of PCI updates for 2.6.32 Jesse Barnes
2009-09-18 15:52         ` Ingo Molnar
2009-09-18 16:17           ` Jesse Barnes
2009-09-17 17:45   ` Yinghai Lu
2009-09-17 18:31     ` Ingo Molnar

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=alpine.LFD.2.01.0909180755530.4950@localhost.localdomain \
    --to=torvalds@linux-foundation.org \
    --cc=gregkh@suse.de \
    --cc=hpa@zytor.com \
    --cc=jbarnes@virtuousgeek.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=rusty@rustcorp.com.au \
    --cc=tglx@linutronix.de \
    --cc=tj@kernel.org \
    --cc=yinghai@kernel.org \
    /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

Powered by JetHome