On 08/21/12 13:25, Dave Chinner wrote:
> On Tue, Aug 21, 2012 at 12:54:52PM +0800, Jie Liu wrote:
>> On 08/20/12 23:31, Mark Tinguely wrote:
>>> On 08/13/12 08:07, Jeff Liu wrote:
>>>> helper routine to lookup data or hole offset from page cache for
>>>> unwritten extents.
>>>>
>>>> Signed-off-by: Jie Liu<jeff.liu@xxxxxxxxxx>
>>>>
>>>> ---
>>>> fs/xfs/xfs_file.c | 213
>>>> +++++++++++++++++++++++++++++++++++++++++++++++++++++
>>>> 1 files changed, 213 insertions(+), 0 deletions(-)
>>>> +STATIC bool
>>>> +xfs_find_get_desired_pgoff(
>>>> + struct inode *inode,
>>>> + struct xfs_bmbt_irec *map,
>>>> + unsigned int type,
>>>> + loff_t *offset)
>>>> +{
>>> ...
>>>
>>>> + for (i = 0; i< nr_pages; i++) {
>>>> + struct page *page = pvec.pages[i];
>>>> + loff_t b_offset;
>>>> +
>>>> + /*
>>>> + * Page index is out of range, searching done.
>>>> + * If the current offset is not reaches the end
>>>> + * of the specified search range, there should
>>>> + * be a hole between them.
>>>> + */
>>>> + if (page->index> end) {
>>> Shouldn't this sample of the index also be locked?
>> Thanks for the review. Yes, it should be locked in concert with the
>> sample of index below.
>>
>> However, as I have mentioned at v6,
>> http://oss.sgi.com/archives/xfs/2012-08/msg00028.html
>> I really don't understand why page->index will be changed as those pages
>> returned from pagevec_lookup() should
>> have refcount > 0. Hence, those pages can not be removed out of VM
>> cache upon memory reclaim IMHO.
> Ah, true, you are right. It's been a while since I looked at the
> reference count vs truncate vs page locks in detail, and I have
> always tended to err on the side of caution. I'd suggest you need to
> copy the comment from write_cache_pages() here to remind us why it
> is safe to do the check unlocked, otherwise in a couple of years
> time someone will be asking themselves why this is safe... :/
Thanks for your quick response and confirmation, I'll copy the comments so.
Thanks,
-Jeff
>
> Cheers,
>
> Dave.
_______________________________________________
xfs mailing list
xfs@xxxxxxxxxxx
http://oss.sgi.com/mailman/listinfo/xfs
