On Sat, 13 Oct 2007, Pekka Enberg wrote: > On 10/12/07, Hugh Dickins <hugh@xxxxxxxxxxx> wrote: > > But I keep suspecting that the answer might be the patch below (which > > rather follows what drivers/block/rd.c is doing). I'm especially > > worried that, rather than just AOP_WRITEPAGE_ACTIVATE being returned > > to userspace, bad enough in itself, you might be liable to hit that > > BUG_ON(page_mapped(page)). shmem_writepage does not expect to be > > called by anyone outside mm/vmscan.c, but unionfs can now get to it? > > Doesn't msync(2) get to it via mm/page-writeback.c:write_cache_pages() > without unionfs even? I believe not. Please do double-check my assertions, I've always found the _writepages paths rather twisty; but my belief (supported by the fact that we've not hit shmem_writepage's BUG_ON(page_mapped(page)) in five years) is that tmpfs/shmem opts out of all of that with its .capabilities = BDI_CAP_NO_ACCT_DIRTY | BDI_CAP_NO_WRITEBACK, in shmem_backing_dev_info, which avoids all those _writepages avenues (e.g. through bdi_cap_writeback_dirty tests), and write_cache_pages is just a subfunction of the _writepages. So, while I don't disagree with your patch to write_cache_pages (though it wasn't clear to me whether it should break from or continue the loop if it ever does meet an AOP_WRITEPAGE_ACTIVATE), I don't think that's really the root of the problem. Hugh - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
