lkml.org 
[lkml]   [2000]   [Oct]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: 2.4.0-test10-pre3:Oops in mm/filemap.c:filemap_write_pa
Date
In article <200010192218.e9JMI1331218@flint.arm.linux.org.uk>,
Russell King <rmk@arm.linux.org.uk> wrote:
>Petr Vandrovec writes:
>> ... or from sys_exit() if you forget to unmap. Or from anywhere if
>> swapping code decides to swap such page. I'm trying to hunt it down
>> for more than month, but I have no idea what's wrong. In my case
>> way to trigger bug is:
>
>I actually think its as simple as:
>
>1. shared map a file
>2. close file
>3. unlink file
>4. unmap shared mapping
>
>In my case, I was running newaliases, and there wasn't any other
>processes using that mapping.

Hmm.. Looks like page->mapping was cleared by truncate_inode_pages()
when the inode was free'd, and there was still write-back activity on
one of the pages in question.

Looking at the problem, it appears that the unmap() will (correctly) do
a writepage() for each dirty page, and that will (again correctly) cause
NFS to do a delayed write-out with all the proper things (increment page
count because of the pending write etc). The inode hasn't been free'd
yet, because we're still using it.

But then when we _do_ release the inode, we end up doing
truncate_inode_pages() and through that we clear page->mapping, so the
pending write-out is SOL. I have this feeling that we probably should
NOT remove the mapping until the page count has gone down to zero.

The other alternative would be to flush the pending write-outs (or wait
for them synchronously - but that's just stupid and inefficient), which
would imply that we'd better add the "flush" operation to "struct
address_space_operations".

Can you get a full stack trace?

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

\
 
 \ /
  Last update: 2005-03-22 12:41    [W:1.092 / U:0.120 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site