linux-ext4 - Re: 2.6.23-rc9: Oops in cache_alloc

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

Message-ID: <470A3ADC.3000403@bull.net>
Date:	Mon, 08 Oct 2007 16:12:44 +0200
From:	Valerie Clement <valerie.clement@...l.net>
To:	cmm@...ibm.com
Cc:	ext4 development <linux-ext4@...r.kernel.org>,
	"Aneesh Kumar K.V" <aneesh.kumar@...ux.vnet.ibm.com>
Subject: Re: 2.6.23-rc9: Oops in cache_alloc_refill()  mm/slab.c

Mingming Cao wrote:
> kernel BUG at /home/clementv/src/linux-2.6.23-rc9/mm/slab.c:2923!
> invalid opcode: 0000 [1] SMP
> CPU 2
> Modules linked in: qla2xxx
> Pid: 4041, comm: ffsb Not tainted 2.6.23-rc9 #2
> RIP: 0010:[<ffffffff802758b6>]  [<ffffffff802758b6>] check_slabp+0xb5/0xc1
> RSP: 0018:ffff8100774bb958  EFLAGS: 00010096
> RAX: 0000000000000001 RBX: ffff81007e100100 RCX: 0000000000006d20
> RDX: 00000000ffffffff RSI: 0000000000000046 RDI: ffff81007e347280
> RBP: 00000000000000a8 R08: 0000000000000005 R09: ffffffff8060bb10
> R10: 00000000000ae468 R11: 0000000500000002 R12: 00000000000000a8
> R13: ffff81007e347280 R14: ffff81007e347280 R15: 0000000000000002
> FS:  0000000041802950(0063) GS:ffff81007e0c4728(0000) knlGS:0000000000000000
> CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
> CR2: 000000005f83d00c CR3: 0000000078149000 CR4: 00000000000006e0
> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
> Process ffsb (pid: 4041, threadinfo ffff8100774ba000, task ffff81007dbdc7a0)
> Stack:  000000000000000d 000000000000000e ffff81007e100100 ffff81007e342398
>   ffff81007e078488 ffffffff80277069 0000000000008050 ffff81007e347280
>   0000000000008050 0000000000000246 ffffffff80299539 fffffffffffff000
> Call Trace:
>   [<ffffffff80277069>] cache_alloc_refill+0xc8/0x23f
>   [<ffffffff80299539>] alloc_buffer_head+0x14/0x45
>   [<ffffffff802774cd>] kmem_cache_alloc+0x94/0xe9
>   [<ffffffff80299539>] alloc_buffer_head+0x14/0x45
>   [<ffffffff80299cf7>] alloc_page_buffers+0x38/0xd5
>   [<ffffffff80299da8>] create_empty_buffers+0x14/0x9b
>   [<ffffffff8029a875>] __block_prepare_write+0x7c/0x45b
>   [<ffffffff802f6e29>] ext4_get_block+0x0/0x139
>   [<ffffffff8029ac6e>] block_prepare_write+0x1a/0x25
>   [<ffffffff802f8340>] ext4_prepare_write+0xaf/0x175
>   [<ffffffff802576c2>] generic_file_buffered_write+0x288/0x631
>   [<ffffffff80257daa>] __generic_file_aio_write_nolock+0x33f/0x3a9
>   [<ffffffff8022b7d5>] enqueue_entity+0x17c/0x1a3
>   [<ffffffff80257e75>] generic_file_aio_write+0x61/0xc1
>   [<ffffffff8022c512>] __check_preempt_curr_fair+0x56/0x76
>   [<ffffffff802f4022>] ext4_file_write+0x16/0x91
>   [<ffffffff8027c4f4>] do_sync_write+0xc9/0x10c
>   [<ffffffff8027d50a>] file_move+0x1d/0x4c
>   [<ffffffff80245992>] autoremove_wake_function+0x0/0x2e
>   [<ffffffff8027b216>] do_filp_open+0x2a/0x38
>   [<ffffffff80275f7a>] poison_obj+0x26/0x30
>   [<ffffffff8027cc34>] vfs_write+0xad/0x136
>   [<ffffffff8027d171>] sys_write+0x45/0x6e
>   [<ffffffff8020b32e>] system_call+0x7e/0x83
> 
> 
> =============>
> 
> The stack track shows ext4_new_block(), is the problem repeatable? Does away without
> multiple block allocation patch?

The oops was not easily reproductible. I'd got it twice while testing 
the mballoc feature with the uninit_groups option but the running tests 
were different.
Since I made the change I sent friday to Aneesh (in the 
uninitialized-block-groups patch), I could not reproduce it.
Could the oops be related to this other problem I found ?

   Valérie
-
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html