On Thu, 1 Mar 2012 22:15:51 +0100
Jan Kara [off-list ref] wrote:

On Thu 01-03-12 11:42:01, Andrew Morton wrote:

quoted

On Thu, 1 Mar 2012 12:04:04 +0100
Jan Kara [off-list ref] wrote:

quoted

quoted

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@kvack.org.  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@kvack.org"> email@kvack.org </a>