Re: [PATCH] nfs: Fix nfs_readpages() error path

From: Trond Myklebust
Date: Sun Oct 29 2006 - 14:11:45 EST


On Mon, 2006-10-30 at 00:56 +0900, OGAWA Hirofumi wrote:
> I've got the following oops.
>
> ------------[ cut here ]------------
> kernel BUG at /devel/linux/works/linux-2.6/mm/readahead.c:315!
> invalid opcode: 0000 [#1]
> SMP
>
> [...]
>
> EFLAGS: 00210283 (2.6.19-rc3 #3)
> EIP is at __do_page_cache_readahead+0x1a4/0x1b7
> eax: f260db64 ebx: f8f9aa18 ecx: 00000001 edx: f7710594
> esi: f6042b94 edi: f6042b84 ebp: f260db78 esp: f260db0c
> ds: 007b es: 007b ss: 0068
> Process emacs (pid: 3694, ti=f260d000 task=f670caa0 task.ti=f260d000)
> Stack: 00000001 000001ac f25dd88c 0000085e 0000001e 00000001 00001000 d7f4a48c
> d7f4a50c d7f4a50c 00001000 d7f4a50c f260db60 00200246 00000001 22222222
> 22222222 d7f4a50c d7f4a50c 00001000 d7f4a48c f260db68 c13cb9f8 c13cb9f8
> Call Trace:
> [<c0140a3a>] do_page_cache_readahead+0x43/0x4d
> [<c013ce9b>] filemap_nopage+0x14e/0x328
> [<c0145b8e>] __handle_mm_fault+0x146/0x7b6
> [<c01463cc>] get_user_pages+0x1ce/0x293
> [<c017f0a8>] elf_core_dump+0xa05/0xba5
> [<c015b8a7>] do_coredump+0x565/0x5d1
> [<c0123acb>] get_signal_to_deliver+0x701/0x758
> [<c010246b>] do_notify_resume+0x8b/0x6c4
> [<c0102ede>] work_notifysig+0x13/0x19
>
> The a_ops->readpages() is nfs_readpages(), and it seems to don't free
> pages list in error path. So, it hit the
> BUG_ON(!list_empty(&page_pool)) in __do_page_cache_readahead.

Wait. Why do we have this insane cleanup semantic anyway? I've just
grepped through the various readpages() methods out there. None of them
do anything more sophisticated than to call put_pages_list() in case of
error, and several of them get that wrong (including NFS, and CIFS).

Instead of the BUG_ON(), why can't we just stick a put_pages_list() into
__do_page_cache_readahead() and then get rid of all that duplicated
error handling in mpage_readpages(), nfs_readpages(), fuse_readpages(),
etc?

Cheers,
Trond
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/