Re: Checking page_count(page) in invalidate_complete_page

Nick Piggin
2006-09-25T23:21:37Z

Chuck Lever wrote:

> Nick Piggin wrote:
>
>> Andrew Morton wrote:
>> Also, you can't guarantee anything much about its refcount even then
>> (because it could be on a private reclaim list or pagevec somewhere).
>>
>>> We could retry the invalidation a few times, but that stinks.
>>>
>>> I think invalidate_inode_pages2() is sufficiently different from (ie:
>>> stronger than) invalidate_inode_pages() to justify the addition of a
>>> new
>>> invalidate_complete_page2(), which skips the page refcount check.
>>>
>>
>> Yes, I think that would be possible using the lock_page in do_no_page
>> trick.
>> That would also enable you to invalidate pages that have direct IO going
>> into them, and other weird and wonderful get_user_pages happenings.
>>
>> I haven't thrown away those patches, and I am looking for a
>> justification
>> for them because they make the code look nicer ;)
>>
>> For 2.6.18.stable, Andrew's idea of checking the return value and retry
>> might be the only option.
>
>
> I think allowing callers of invalidate_inode_pages2() to get the
> previous behavior is reasonable here. There are only 2 of them: v9fs
> and the NFS client.

That still reintroduces the page fault race, but if the dumb
check'n'retry is
no good then it may be OK for 2.6.18.stable, considering the page fault race
is much less common than the reclaim one. Not sure, not my call.

Upstream, it should be fixed properly without re-introducing bugs along the
way.

--

Send instant messages to your online friends http://au.messenger.yahoo.com