Re: [RFC]: madvise(2) and mincore(2) in 2.3.26

Andi Kleen (ak@muc.de)
17 Nov 1999 01:56:32 +0100


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/