From: 'David Gibson' <david@gibson.dropbear.id.au>
To: "Chen, Kenneth W" <kenneth.w.chen@intel.com>, g@ozlabs.org
Cc: Andrew Morton <akpm@osdl.org>,
'Christoph Lameter' <christoph@schroedinger.engr.sgi.com>,
Hugh Dickins <hugh@veritas.com>,
bill.irwin@oracle.com, Adam Litke <agl@us.ibm.com>,
linux-mm@kvack.org
Subject: Re: [RFC] reduce hugetlb_instantiation_mutex usage
Date: Tue, 31 Oct 2006 14:17:04 +1100 [thread overview]
Message-ID: <20061031031703.GA7220@localhost.localdomain> (raw)
In-Reply-To: <000001c6fc97$ecd8cbd0$ff0da8c0@amr.corp.intel.com>
On Mon, Oct 30, 2006 at 06:54:46PM -0800, Chen, Kenneth W wrote:
> David Gibson wrote on Thursday, October 26, 2006 9:06 PM
> > > Alternatively, we could put the page into pagecache whether or not the
> > > mapping is MAP_SHARED. Then pull it out again prior to unlocking it if
> > > it's MAP_PRIVATE. So we're using pagecache just as a way for the
> > > concurrent faulter to locate the page.
> >
> > Hrm.. interesting if we can make it work. I'd be worried about cases
> > with concurrent PRIVATE and SHARED pages on the same file offset.
>
> I got side tracked on to the radix-tree stuff. The comments in
> hugetlb_no_page() make me wonder whether we have a race issue on
> private mapping:
>
> /*
> * Use page lock to guard against racing truncation
> * before we get page_table_lock.
> */
>
> Private mapping won't use radix tree during instantiation. What protects
> racy truncate against fault in that scenario? Don't we have a bug here?
Not at present, because the hugetlb_instantiation_mutex protects both
fault paths. But with Andrew's patch as it stands, yes. As I said in
a previous email. The libhugetlbfs testsuite now has a testcase for
the MAP_PRIVATE as well as the MAP_SHARED version of the race.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2006-10-31 3:17 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-10-26 22:17 [RFC] reduce hugetlb_instantiation_mutex usage Chen, Kenneth W
2006-10-26 22:44 ` Andrew Morton
2006-10-26 23:31 ` 'David Gibson'
2006-10-27 0:04 ` Andrew Morton
2006-10-27 3:11 ` 'David Gibson'
2006-10-27 3:35 ` Andrew Morton
2006-10-27 4:06 ` 'David Gibson'
2006-10-31 2:54 ` Chen, Kenneth W
2006-10-31 3:17 ` 'David Gibson' [this message]
2006-10-31 5:15 ` Chen, Kenneth W
2006-10-31 11:05 ` 'David Gibson'
2006-10-31 12:48 ` Hugh Dickins
2006-11-01 6:18 ` Nick Piggin
2006-11-01 10:17 ` Chen, Kenneth W
2006-11-02 3:06 ` Nick Piggin
2006-11-02 2:29 ` 'David Gibson'
2006-10-27 1:47 ` 'David Gibson'
2006-10-30 20:55 ` Adam Litke
2006-10-26 23:47 ` 'David Gibson'
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=20061031031703.GA7220@localhost.localdomain \
--to=david@gibson.dropbear.id.au \
--cc=agl@us.ibm.com \
--cc=akpm@osdl.org \
--cc=bill.irwin@oracle.com \
--cc=christoph@schroedinger.engr.sgi.com \
--cc=g@ozlabs.org \
--cc=hugh@veritas.com \
--cc=kenneth.w.chen@intel.com \
--cc=linux-mm@kvack.org \
/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.