From: Mike Kravetz <mike.kravetz@oracle.com>
To: Matthew Wilcox <willy@infradead.org>, Waiman Long <longman@redhat.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
linux-kernel@vger.kernel.org, linux-mm@kvack.org,
Davidlohr Bueso <dave@stgolabs.net>,
Peter Zijlstra <peterz@infradead.org>,
Ingo Molnar <mingo@redhat.com>, Will Deacon <will.deacon@arm.com>
Subject: Re: [PATCH] hugetlbfs: Take read_lock on i_mmap for PMD sharing
Date: Thu, 7 Nov 2019 13:49:55 -0800 [thread overview]
Message-ID: <ed46ef09-7766-eb80-a4ad-4c72d8dba188@oracle.com> (raw)
In-Reply-To: <20191107195441.GF11823@bombadil.infradead.org>
On 11/7/19 11:54 AM, Matthew Wilcox wrote:
> Are there other current users of the write lock that could use a read lock?
> At first blush, it would seem that unmap_ref_private() also only needs
> a read lock on the i_mmap tree. I don't think hugetlb_change_protection()
> needs the write lock either. Nor retract_page_tables().
I believe that the semaphore still needs to be held in write mode while
calling huge_pmd_unshare (as is done in the call sites above). Why?
There is this check for sharing in huge_pmd_unshare,
if (page_count(virt_to_page(ptep)) == 1)
return 0; // implies no sharing
Note that huge_pmd_share now increments the page count with the semaphore
held just in read mode. It is OK to do increments in parallel without
synchronization. However, we don't want anyone else changing the count
while that check in huge_pmd_unshare is happening. Hence, the need for
taking the semaphore in write mode.
--
Mike Kravetz
next prev parent reply other threads:[~2019-11-07 21:50 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-11-07 19:06 [PATCH] hugetlbfs: Take read_lock on i_mmap for PMD sharing Waiman Long
2019-11-07 19:13 ` Waiman Long
2019-11-07 19:15 ` Waiman Long
2019-11-07 19:31 ` Mike Kravetz
2019-11-07 19:42 ` Matthew Wilcox
2019-11-07 21:06 ` Waiman Long
2019-11-07 19:54 ` Matthew Wilcox
2019-11-07 21:27 ` Waiman Long
2019-11-07 21:49 ` Mike Kravetz [this message]
2019-11-07 21:56 ` Mike Kravetz
2019-11-08 2:04 ` Davidlohr Bueso
2019-11-08 3:22 ` Andrew Morton
2019-11-08 19:10 ` Mike Kravetz
2019-11-09 1:47 ` Mike Kravetz
2019-11-12 17:27 ` Waiman Long
2019-11-12 23:11 ` Mike Kravetz
2019-11-13 2:55 ` Waiman Long
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=ed46ef09-7766-eb80-a4ad-4c72d8dba188@oracle.com \
--to=mike.kravetz@oracle.com \
--cc=akpm@linux-foundation.org \
--cc=dave@stgolabs.net \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=longman@redhat.com \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=will.deacon@arm.com \
--cc=willy@infradead.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).