On Fri, 20 Apr 2007 18:39:43 -0700 (PDT) Christoph Lameter <[email protected]> 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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
