Messages in this thread | | | From | (Linus Torvalds) | Subject | Re: 2.4.0-test10-pre3:Oops in mm/filemap.c:filemap_write_pa | Date | 19 Oct 2000 16:26:11 -0700 |
| |
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/
| |