linux-kernel - kernel BUGs when removing largish files with the SLOB allocator

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-next>] [day] [month] [year] [list]

Message-ID: <6d6a94c50609032356t47950e40lbf77f15136e67bc5@mail.gmail.com>
Date:	Mon, 4 Sep 2006 14:56:33 +0800
From:	Aubrey <aubreylee@...il.com>
To:	linux-kernel@...r.kernel.org
Cc:	mpm@...enic.com, dhowells@...hat.com, davidm@...pgear.com,
	gerg@...pgear.com
Subject: kernel BUGs when removing largish files with the SLOB allocator

Hi all,

I'm working on the nommu blackfin uclinux(2.6.16) platform and  get a
kernel BUG! at mm/nommu.c:124 when removing largish file with the SLOB
allocator.

root:~> df -k
Filesystem           1k-blocks      Used Available Use% Mounted on
/dev/mtdblock3            3008      1264      1744  42% /
root:~> cp /bin/busybox /busy
root:~> df -k
Filesystem           1k-blocks      Used Available Use% Mounted on
/dev/mtdblock3            3008      1532      1476  51% /
root:~> ls -l /bin/busybox /busy
-rwxr-xr-x    1 0        0          423904 /bin/busybox
-rwxr-xr-x    1 0        0          423904 /busy
root:~> md5sum /bin/busybox
7db253a2259ab71bc854c9e5dac544d6  /bin/busybox
root:~> md5sum /busy
7db253a2259ab71bc854c9e5dac544d6  /busy
root:~> rm /busy
kernel BUG at mm/nommu.c:124!
Kernel panic - not syncing: BUG!

Bug comes from  mm/nommu.c:
=======================================
        if (!objp || !((page = virt_to_page(objp))) ||
           (unsigned long)objp >= memory_end)
                return 0;

        if (PageSlab(page))
                return ksize(objp);

        BUG_ON(page->index < 0);
124:    BUG_ON(page->index >= MAX_ORDER);
=======================================

This seems that the SLOB allocator doesn't set the SLAB page flag
while nommu.c seem to be written for SLAB only.

On my side the following patch seems to work around the issue
============================================================
--- nommu.c     2006-06-26 14:49:28.000000000 +0800
+++ nommu.c.new 2006-06-26 14:47:20.000000000 +0800
@@ -18,7 +18,9 @@
 #include <linux/file.h>
 #include <linux/highmem.h>
 #include <linux/pagemap.h>
-#include <linux/slab.h>
+#ifdef CONFIG_SLAB
+# include <linux/slab.h>
+#endif
 #include <linux/vmalloc.h>
 #include <linux/ptrace.h>
 #include <linux/blkdev.h>
@@ -117,7 +119,9 @@
        if (!objp || !((page = virt_to_page(objp))) || (unsigned
long)objp >= memory_end)
                return 0;

+#ifdef CONFIG_SLAB
        if (PageSlab(page))
+#endif
                return ksize(objp);

        BUG_ON(page->index < 0);
============================================================

Is there any solution/patch to fix the issue?

Any suggestions are really appreciated.

Thanks,
-Aubrey

-- 
VGER BF report: U 0.498985
-
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/