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/
This archive was generated by hypermail 2b29 : Mon Oct 23 2000 - 21:00:16 EST