Messages in this thread | | | Date | Mon, 28 Aug 2006 20:43:54 -0700 | From | Andrew Morton <> | Subject | Re: [PATCH 000 of 2] Invalidate_inode_pages2 changes. |
| |
On Tue, 29 Aug 2006 12:46:44 +1000 Neil Brown <neilb@suse.de> wrote:
> On Monday August 28, akpm@osdl.org wrote: > > On Tue, 29 Aug 2006 11:30:15 +1000 > > NeilBrown <neilb@suse.de> wrote: > > > > > I'm picking up on a conversation that was started in late March > > > this year, and which didn't get anywhere much. > > > See > > > http://lkml.org/lkml/2006/3/31/93 > > > and following. > > > > Nick's "possible lock_page fix for Andrea's nopage vs invalidate race?" > > patch (linux-mm) should fix this? > > > > If filemap_nopage() does lock_page(), invalidate_inode_pages2_range() is solid? > > UHmm.... yes. In that case we can remove lots of stuff from > invalidate_inode_pages2_range as we can be sure the page won't be > dirty or in writeback so invalidate_complete_page will be certain to > succeed.
I'm not sure we can remove much from invalidate_inode_pages2_range(). After lock_page() returns the page can be under writeback, so the wait_on_page_writeback() is appropriate. After the page has been unmapped from pagetables it could have been be redirtied.
Perhaps the while() loop is no longer necessary - nobody else will be mapping this locked page into pagetables.
> So if that goes ahead, these become moot. But until it does, these > would be nice to have :-)
I guess we need to repair Nick's broken wing.
> Also, the patch at > http://marc.theaimsgroup.com/?l=linux-mm&m=115443228617576&w=2 > appears not to set > + .vm_flags = VM_CAN_INVLD, > for nfs_fs_vm_operations, but maybe they are a later addition to > nfs...
I'm hoping all that stuff can go away. Instead, change do_page_fault to declare a new `struct page_fault_args' thing and pass that all the way up and down the pagefault path. Then, ->nopage implementations can simply set page_fault_args.i_locked_the_page, to be examined at higher levels.
page_fault_args can also be used to tell do_no_page() to rerun the fault, which would be needed if we want to stop holding down_read(mmap_sem) while doing synchronous disk reads.
It'd be a fairly big-but-simple patch though.
> Thinks: should I subscribe to linux-mm... only about 100 messages per > week.... maybe :-)
And no spam! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |