From: Peter Zijlstra <peterz@infradead.org>
To: Mel Gorman <mel@csn.ul.ie>
Cc: r6144 <rainy6144@gmail.com>,
linux-kernel@vger.kernel.org, Darren Hart <dvhltc@us.ibm.com>,
tglx <tglx@linutronix.de>, Andrea Arcangeli <aarcange@redhat.com>,
Lee Schermerhorn <lee.schermerhorn@hp.com>
Subject: Re: Process-shared futexes on hugepages puts the kernel in an infinite loop in 2.6.32.11; is this fixed now?
Date: Mon, 19 Apr 2010 13:52:36 +0200 [thread overview]
Message-ID: <1271677956.1674.922.camel@laptop> (raw)
In-Reply-To: <20100419114300.GT19264@csn.ul.ie>
On Mon, 2010-04-19 at 12:43 +0100, Mel Gorman wrote:
> > Right, so I had a quick chat with Mel, and it appears MAP_PRIVATE
> > hugetlb pages don't have their page->mapping set.
> >
> > I guess something like the below might work, but I'd really rather not
> > add hugetlb knowledge to futex.c. Does anybody else have a better idea?
> > Maybe create something similar to an anon_vma for hugetlb pages?
> >
>
> anon_vma for hugetlb pages sounds overkill, what would it gain? In this
> context, futex only appears to distinguish between whether the
> references are private or shared.
>
> Looking at the hugetlbfs code, I can't see a place where it actually cares
> about the mapping as such. It's used to find shared pages in the page cache
> (but not in the LRU) that are backed by the hugetlbfs file. For hugetlbfs
> though, the mapping is mostly kept in page->private for reservation accounting
> purposes.
>
> I can't think of other parts of the VM that touch the mapping if the
> page is managed by hugetlbfs so the following patch should also work but
> without futex having hugetlbfs-awareness. What do you think? Maybe for
> safety, it would be better to make the mapping some obvious poison bytes
> or'd with PAGE_MAPPING_ANON so an oops will be more obvious?
Yes, this seems perfectly adequate to me, that poison idea might be
worthwhile too :-)
Acked-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
> diff --git a/mm/hugetlb.c b/mm/hugetlb.c
> index 6034dc9..57a5faa 100644
> --- a/mm/hugetlb.c
> +++ b/mm/hugetlb.c
> @@ -546,6 +546,7 @@ static void free_huge_page(struct page *page)
>
> mapping = (struct address_space *) page_private(page);
> set_page_private(page, 0);
> + page->mapping = NULL;
> BUG_ON(page_count(page));
> INIT_LIST_HEAD(&page->lru);
>
> @@ -2447,8 +2448,10 @@ retry:
> spin_lock(&inode->i_lock);
> inode->i_blocks += blocks_per_huge_page(h);
> spin_unlock(&inode->i_lock);
> - } else
> + } else {
> lock_page(page);
> + page->mapping = (struct address_space *)PAGE_MAPPING_ANON;
> + }
> }
>
> /*
next prev parent reply other threads:[~2010-04-19 11:52 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-04-16 15:45 Process-shared futexes on hugepages puts the kernel in an infinite loop in 2.6.32.11; is this fixed now? r6144
2010-04-16 20:27 ` Peter Zijlstra
2010-04-19 11:43 ` Mel Gorman
2010-04-19 11:52 ` Peter Zijlstra [this message]
2010-04-19 15:32 ` Mel Gorman
2010-04-19 15:45 ` Peter Zijlstra
2010-04-19 16:11 ` Andrea Arcangeli
2010-04-19 16:18 ` Peter Zijlstra
2010-04-19 16:32 ` Andrea Arcangeli
2010-04-19 16:34 ` Mel Gorman
2010-04-19 15:48 ` Andrea Arcangeli
2010-04-19 16:04 ` Darren Hart
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1271677956.1674.922.camel@laptop \
--to=peterz@infradead.org \
--cc=aarcange@redhat.com \
--cc=dvhltc@us.ibm.com \
--cc=lee.schermerhorn@hp.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mel@csn.ul.ie \
--cc=rainy6144@gmail.com \
--cc=tglx@linutronix.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.