Adam Litke wrote on Wednesday, January 11, 2006 2:24 PM
> > here). The patch doesn't completely close the race (there is a much
> > smaller window without the zeroing though). The next patch should close
> > the race window completely.
>
> My only concern is if I am using the correct lock for the job here.
I don't think so.
> @@ -454,26 +455,31 @@ int hugetlb_no_page(struct mm_struct *mm
> * Use page lock to guard against racing truncation
> * before we get page_table_lock.
> */
> -retry:
> page = find_lock_page(mapping, idx);
> if (!page) {
> if (hugetlb_get_quota(mapping))
> goto out;
> +
> + if (shared)
> + spin_lock(&mapping->host->i_lock);
> +
> page = alloc_unzeroed_huge_page(vma, address);
> if (!page) {
> hugetlb_put_quota(mapping);
> + if (shared)
> + spin_unlock(&mapping->host->i_lock);
> goto out;
> }
What if two processes fault on the same page and races with find_lock_page(),
both find page not in the page cache. The process won the race proceed to
allocate last hugetlb page. While the other will exit with SIGBUS. In theory,
both processes should be OK.
- Ken
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
