linux-kernel - Re: BUG in mm/slab.c

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 for Android: free password hash cracker in your pocket

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

Message-Id: <20070517230455.ffed5138.akpm@linux-foundation.org>
Date:	Thu, 17 May 2007 23:04:55 -0700
From:	Andrew Morton <akpm@...ux-foundation.org>
To:	Jeff Garzik <jeff@...zik.org>
Cc:	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: BUG in mm/slab.c

On Fri, 18 May 2007 01:53:20 -0400 Jeff Garzik <jeff@...zik.org> wrote:

> Platform:  Fedora Core 6/x86-64 (lspci, kconfig, dmesg attached)
> 
> dmesg shows:
> > PCI: Using ACPI for IRQ routing
> > PCI: If a device doesn't work, try "pci=routeirq".  If it helps, post a report
> > BUG: at mm/slab.c:777 __find_general_cachep()
> > 
> > Call Trace:
> >  [<ffffffff802819b7>] __kmalloc+0xa7/0xe0
> >  [<ffffffff8021b7bd>] cache_k8_northbridges+0x9d/0x120
> >  [<ffffffff8053bb03>] gart_iommu_init+0x33/0x5b0
> >  [<ffffffff80228673>] __wake_up+0x43/0x70
> >  [<ffffffff803e01a0>] genl_rcv+0x0/0x70
> >  [<ffffffff803de768>] netlink_kernel_create+0x158/0x170
> >  [<ffffffff803dffd0>] genl_unlock+0x10/0x50
> >  [<ffffffff80535879>] pci_iommu_init+0x9/0x20
> >  [<ffffffff8052c6d4>] kernel_init+0x154/0x330
> >  [<ffffffff8020a958>] child_rip+0xa/0x12
> >  [<ffffffff803212ac>] acpi_ds_init_one_object+0x0/0x7c
> >  [<ffffffff8052c580>] kernel_init+0x0/0x330
> >  [<ffffffff8020a94e>] child_rip+0x0/0x12
> > 
> > PCI-GART: No AMD northbridge found.
> > hpet0: at MMIO 0xfed00000, IRQs 2, 8, 0
> > hpet0: 3 64-bit timers, 14318180 Hz
> 
> but the machine continues to work (I'm typing on it right now).  In 
> fact, I only noticed while checking on some SATA stuff :)

Yep, it's just a WARN_ON, no other effect.

I have a cure queued up:


From: Ben Collins <ben.collins@...ntu.com>

kmalloc for flush_words resulted in zero size allocation when no
k8_northbridges existed.  Short circuit the code path for this case.

Also remove uneeded zeroing of num_k8_northbridges just after checking if
it is zero.

Signed-off-by: Ben Collins <bcollins@...ntu.com>
Cc: Andi Kleen <ak@...e.de>
Cc: Dave Jones <davej@...emonkey.org.uk>
Signed-off-by: Andrew Morton <akpm@...ux-foundation.org>
---

 arch/x86_64/kernel/k8.c |    7 ++++++-
 1 files changed, 6 insertions(+), 1 deletion(-)

diff -puN arch/x86_64/kernel/k8.c~avoid-zero-size-allocation-in-cache_k8_northbridges arch/x86_64/kernel/k8.c
--- a/arch/x86_64/kernel/k8.c~avoid-zero-size-allocation-in-cache_k8_northbridges
+++ a/arch/x86_64/kernel/k8.c
@@ -39,10 +39,10 @@ int cache_k8_northbridges(void)
 {
 	int i;
 	struct pci_dev *dev;
+
 	if (num_k8_northbridges)
 		return 0;
 
-	num_k8_northbridges = 0;
 	dev = NULL;
 	while ((dev = next_k8_northbridge(dev)) != NULL)
 		num_k8_northbridges++;
@@ -52,6 +52,11 @@ int cache_k8_northbridges(void)
 	if (!k8_northbridges)
 		return -ENOMEM;
 
+	if (!num_k8_northbridges) {
+		k8_northbridges[0] = NULL;
+		return 0;
+	}
+
 	flush_words = kmalloc(num_k8_northbridges * sizeof(u32), GFP_KERNEL);
 	if (!flush_words) {
 		kfree(k8_northbridges);
_

-
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/