Date:	Sun, 22 Apr 2007 23:08:41 -0700
From:	Andrew Morton <akpm@...ux-foundation.org>
To:	Christoph Lameter <clameter@....com>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: slab allocators: Remove SLAB_DEBUG_INITIAL flag

On Fri, 20 Apr 2007 18:39:43 -0700 (PDT) Christoph Lameter <clameter@....com> wrote:

> I have never seen a use of SLAB_DEBUG_INITIAL. It is only supported by SLAB.
> 
> I think its purpose was to have a callback after an object has been freed
> to verify that the state is the constructor state again? The callback is
> performed before each freeing of an object.
> 
> I would think that it is much easier to check the object state manually
> before the free. That also places the check near the code object
> manipulation of the object.
> 
> Also the SLAB_DEBUG_INITIAL callback is only performed if the kernel was 
> compiled with SLAB debugging on. If there would be code in a constructor 
> handling SLAB_DEBUG_INITIAL then it would have to be conditional on 
> SLAB_DEBUG otherwise it would just be dead code. But there is no such code 
> in the kernel. I think SLUB_DEBUG_INITIAL is too problematic to make real 
> use of, difficult to understand and there are easier ways to accomplish 
> the same effect (i.e. add debug code before kfree).
> 
> There is a related flag SLAB_CTOR_VERIFY that is frequently checked
> to be clear in fs inode caches. Remove the pointless checks 
> (they would even be pointless without removeal of SLAB_DEBUG_INITIAL) 
> from the fs constructors.
> 
> This is the last slab flag that SLUB did not support. Remove the check
> for unimplemented flags from SLUB.

This patch causes a use-uninitialised crash in the locks code.



VFS: Mounted root (ext3 filesystem) readonly.
Freeing unused kernel memory: 316k freed
Write protecting the kernel read-only data: 961k
BUG: unable to handle kernel paging request at virtual address 5a5a5a66
 printing eip:
c0188f40
*pde = 00000000
Oops: 0000 [#1]
SMP 
Modules linked in:
CPU:    0
EIP:    0060:[<c0188f40>]    Not tainted VLI
EFLAGS: 00010206   (2.6.21-rc7-mm1 #17)
EIP is at locks_release_private+0x10/0x40
eax: 5a5a5a5a   ebx: c336f7cc   ecx: 00000000   edx: c336f850
esi: c336f850   edi: c336f850   ebp: c242fe40   esp: c242fe38
ds: 007b   es: 007b   fs: 00d8  gs: 0033  ss: 0068
Process init (pid: 1, ti=c242e000 task=c242d550 task.ti=c242e000)
Stack: c336f850 c336f7cc c242fe50 c0189026 00000000 c3cfee2c c242fed0 c018a2fe 
       ffffffff c336f84c c242fe80 c0175b37 00000000 c3cfed24 c336f850 c242fe80 
       c01759f1 01003180 c336f7cc c336f748 00000000 000000d0 00000000 c013d825 
Call Trace:
 [<c0103e6a>] show_trace_log_lvl+0x1a/0x30
 [<c0103f29>] show_stack_log_lvl+0xa9/0xd0
 [<c0104139>] show_registers+0x1e9/0x2f0
 [<c0104355>] die+0x115/0x250
 [<c0116679>] do_page_fault+0x2d9/0x610
 [<c03e07b1>] error_code+0x79/0x80
 [<c0189026>] locks_copy_lock+0x16/0x50
 [<c018a2fe>] __posix_lock_file_conf+0x24e/0x530
 [<c018a613>] posix_lock_file+0x13/0x20
 [<c018bd49>] fcntl_setlk+0x129/0x260
 [<c0186a0a>] do_fcntl+0x2a/0x2a0
 [<c0186cbc>] sys_fcntl64+0x3c/0x80
 [<c0102dde>] sysenter_past_esp+0x5f/0x99
 =======================
Code: 4b fe ff ff 8d b4 26 00 00 00 00 8b 45 f0 e8 68 fd ff ff e9 4b ff ff ff 90 90 90 55 89 e5 53 89 c3 83 ec 04 8b 40 60 85 c0 74 12 <8b> 50 0c 85 d2 74 04 89 d8 ff d2 c7 43 60 00 00 00 00 8b 43 64 
EIP: [<c0188f40>] locks_release_private+0x10/0x40 SS:ESP 0068:c242fe38
Kernel panic - not syncing: Attempted to kill init!
-
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/

Powered by blists - more mailing lists