On Thu, 1 Mar 2012 22:15:51 +0100 Jan Kara <jack@xxxxxxx> wrote: > On Thu 01-03-12 11:42:01, Andrew Morton wrote: > > On Thu, 1 Mar 2012 12:04:04 +0100 > > Jan Kara <jack@xxxxxxx> wrote: > > > > > > iirc, the way I "grabbed" the page was to actually lock it, with > > > > [try_]_lock_page(). And unlock it again way over within the writeback > > > > thread. I forget why I did it this way, rather than get_page() or > > > > whatever. Locking the page is a good way of preventing anyone else > > > > from futzing with it. It also pins the inode, which perhaps meant that > > > > with careful management, I could avoid the igrab()/iput() horrors > > > > discussed above. > > > > > > I think using get_page() might be a good way to go. > > > > get_page() doesn't pin the inode - truncate() will still detach it > > from the address_space(). > Yes, I know. And exactly because of that I'd like to use it. Flusher > thread would lock the page from the work item, check whether it is still > attached to the inode and if yes, it will proceed. Otherwise it will just > discard the work item because we know the page has already been written out > by someone else or truncated. That would work OK. The vmscanning process won't know that its writeback effort failed, but it's hard to see how that could cause a problem. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/ Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>