From: Alex Tomas Subject: Re: delayed allocatiou result in Oops Date: Fri, 15 Jun 2007 09:14:20 +0400 Message-ID: <4672202C.4080304@clusterfs.com> References: <20070614072352.GA6517@localhost.sw.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: linux-ext4@vger.kernel.org To: Dmitriy Monakhov Return-path: Received: from mail.chehov.net ([80.71.245.247]:51472 "EHLO mail.rialcom.ru" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750946AbXFOFOd (ORCPT ); Fri, 15 Jun 2007 01:14:33 -0400 In-Reply-To: <20070614072352.GA6517@localhost.sw.ru> Sender: linux-ext4-owner@vger.kernel.org List-Id: linux-ext4.vger.kernel.org looks like an error in error handling path (notice -28 (ENOSPC) before) thanks for the report, Alex Dmitriy Monakhov wrote: > ) > > Simple test failed on ext4 when delayed allocation was used. > #mkfs.ext3 -b4096 /dev/vzvg/test2 > #mount -text4dev /dev/vzvg/test2 /mnt/test -odelalloc > #fsstress -d /mnt/test/ -l100 -n100000 -p20 -f dwrite=0 > > > EXT4-fs: writeback error = -28 > ...... > EXT4-fs: writeback error = -28 > Unable to handle kernel NULL pointer dereference at 0000000000000000 RIP: > [] block_read_full_page+0xab/0x25f > PGD 44c1067 PUD 44fd067 PMD 0 > Oops: 0000 [2] SMP > CPU 0 > Modules linked in: ext4dev jbd2 > Pid: 4833, comm: fsstress Not tainted 2.6.22-rc4-mm2 #9 > RIP: 0010:[] [] block_read_full_page+0xab/0x25f > RSP: 0018:ffff810004df9a58 EFLAGS: 00010203 > RAX: 0000000000001000 RBX: ffff8100cf4256f8 RCX: 000000000000000c > > RDX: 0000000000000001 RSI: 000000000000000c RDI: ffff8100cf4256f8 > RBP: 0000000000000000 R08: ffff810004df9be8 R09: ffff810004df9c58 > R10: 8888888888888888 R11: 8888888888888888 R12: 0000000000000052 > R13: 0000000000001000 R14: 0000000000000000 R15: 00000000000000d3 > FS: 00002adfe3f7d6f0(0000) GS:ffffffff80730000(0000) knlGS:0000000000000000 > CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b > CR2: 0000000000000000 CR3: 0000000004362000 CR4: 00000000000006e0 > DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 > DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 > Process fsstress (pid: 4833, threadinfo ffff810004df8000, task ffff810004c867a0) > Stack: ffffffff880180f2 ffff8100054a23f0 0000000000000000 0000000000000000 > ffff810005dcbb80 ffff81000549bf00 0000000000000000 ffff810005def8b0 > ffffffff88029e60 ffffffff8025b2be ffff8100054da540 ffff8100cf496fb0 > Call Trace: > [] :ext4dev:ext4_get_block+0x0/0x109 > [] find_get_page+0x21/0x51 > [] do_mpage_readpage+0x45f/0x480 > [] :ext4dev:ext4_get_block+0x0/0x109 > [] :jbd2:jbd2_journal_dirty_metadata+0x197/0x1be > [] bit_waitqueue+0x1c/0x99 > [] mpage_readpage+0x4e/0x67 > [] :ext4dev:ext4_get_block+0x0/0x109 > [] do_lookup+0x63/0x1ae > [] file_read_actor+0x8d/0xf6 > [] find_get_page+0x21/0x51 > [] do_generic_mapping_read+0x23c/0x3da > [] file_read_actor+0x0/0xf6 > [] generic_file_aio_read+0x119/0x156 > [] do_sync_read+0xc9/0x10c > > [] cp_new_stat+0xe5/0xfd > [] autoremove_wake_function+0x0/0x2e > [] vfs_read+0xaa/0x132 > [] sys_read+0x45/0x6e > [] system_call+0x7e/0x83 > Code: 8b 45 00 a8 01 0f 85 e6 00 00 00 8b 45 00 a8 20 0f 85 c9 00 > > > I've digged this a litle bit with folowig results: > > int block_read_full_page(struct page *page, get_block_t *get_block) > { > ... > 1914: if (!page_has_buffers(page)) <<< page_has_buffers(page) == true > create_empty_buffers(page, blocksize, 0); > head = page_buffers(page); <<<< page_buffers(page) == NULL > << <<< page->flags == 100000000000821 > <<< PagePrivate(page) == 1, (page)->private == NULL > <<< So we have private page without buffers, it is WRONG. > > iblock = (sector_t)page->index << (PAGE_CACHE_SHIFT - inode->i_blkbits); > lblock = (i_size_read(inode)+blocksize-1) >> inode->i_blkbits; > bh = head; > nr = 0; > i = 0; > > do { > if (buffer_uptodate(bh)) << Null pointer deref here result in oops > ....... > } > > - > To unsubscribe from this list: send the line "unsubscribe linux-ext4" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html