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.
If so, both sample of index could be performed without page lock.
Thanks,
-Jeff
>
>> + if (type == HOLE_OFF&& lastoff< endoff) {
>> + *offset = lastoff;
>> + found = true;
>> + }
>> + goto out;
>> + }
>> +
>> + lock_page(page);
>
> --Mark.
>
> _______________________________________________
> xfs mailing list
> xfs@xxxxxxxxxxx
> http://oss.sgi.com/mailman/listinfo/xfs
_______________________________________________
xfs mailing list
xfs@xxxxxxxxxxx
http://oss.sgi.com/mailman/listinfo/xfs
