lkml.org 
[lkml]   [1999]   [Nov]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [RFC]: madvise(2) and mincore(2) in 2.3.26
From
Date
cel@monkey.org (Chuck Lever) writes:

Hallo Chuck,

> + */
> +static long madvise_dontneed(struct vm_area_struct * vma,
> + unsigned long start, unsigned long end)
> +{
> + struct inode * inode = vma->vm_file->f_dentry->d_inode;
> + struct page * page, **hash;
> +
> + start = ((start - vma->vm_start) >> PAGE_CACHE_SHIFT) + vma->vm_pgoff;
> + end = ((end - vma->vm_start) >> PAGE_CACHE_SHIFT) + vma->vm_pgoff;
> +
> + while (start < end) {
> + hash = page_hash(&inode->i_data, start);
> +
> + spin_lock(&pagecache_lock);
> + page = __find_page_nolock(&inode->i_data, start,
> + *hash);
> + if (page)
> + clear_bit(PG_referenced, &page->flags);
> + spin_unlock(&pagecache_lock);


What happens when some other thread/process has set the referenced bit?
shrink_mmap() could throw the data way.
I think you need at least check for shared pages here, and make it a nop
for this case.

Also is mincore really useful? Either you have the memory locked and
then then you know that it is in core, or you haven't, then everything
is possible. I cannot imagine a useful application for it.

The rest looks very nice.

-Andi

--
This is like TV. I don't like TV.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:55    [from the cache]
©2003-2014 Jasper Spaans. Advertise on this site