From: Mike Kravetz <mike.kravetz@oracle.com>
To: "Kirill A. Shutemov" <kirill@shutemov.name>
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org,
Michal Hocko <mhocko@kernel.org>, Hugh Dickins <hughd@google.com>,
Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>,
"Aneesh Kumar K . V" <aneesh.kumar@linux.vnet.ibm.com>,
Andrea Arcangeli <aarcange@redhat.com>,
"Kirill A . Shutemov" <kirill.shutemov@linux.intel.com>,
Davidlohr Bueso <dave@stgolabs.net>,
Prakash Sangappa <prakash.sangappa@oracle.com>,
Andrew Morton <akpm@linux-foundation.org>,
stable@vger.kernel.org
Subject: Re: [PATCH v2 2/2] hugetlbfs: Use i_mmap_rwsem to fix page fault/truncate race
Date: Fri, 21 Dec 2018 10:28:25 -0800 [thread overview]
Message-ID: <849f5202-2200-265f-7769-8363053e8373@oracle.com> (raw)
In-Reply-To: <20181221102824.5v36l6l5t2zthpgr@kshutemo-mobl1>
On 12/21/18 2:28 AM, Kirill A. Shutemov wrote:
> On Tue, Dec 18, 2018 at 02:35:57PM -0800, Mike Kravetz wrote:
>> Instead of writing the required complicated code for this rare
>> occurrence, just eliminate the race. i_mmap_rwsem is now held in read
>> mode for the duration of page fault processing. Hold i_mmap_rwsem
>> longer in truncation and hold punch code to cover the call to
>> remove_inode_hugepages.
>
> One of remove_inode_hugepages() callers is noticeably missing --
> hugetlbfs_evict_inode(). Why?
>
> It at least deserves a comment on why the lock rule doesn't apply to it.
In the case of hugetlbfs_evict_inode, the vfs layer guarantees there are
no more users of the inode/file. Therefore, it is safe to call without
holding the mutex. But, I did add this comment to remove_inode_hugepages.
* Callers of this routine must hold the i_mmap_rwsem in write mode to prevent
* races with page faults.
So, I violated the rule that I documented. Thanks for catching.
I will update the comments to note this excpetion to the rule. Another
option is to simply take the semaphore and still note why it is technically
not needed. Since there are no users there will be no contention of the
semaphore and the overhead should be negligible.
--
Mike Kravetz
next prev parent reply other threads:[~2018-12-21 18:28 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-12-18 22:35 [PATCH v2 0/2] hugetlbfs: use i_mmap_rwsem for better synchronization Mike Kravetz
2018-12-18 22:35 ` [PATCH v2 1/2] hugetlbfs: use i_mmap_rwsem for more pmd sharing synchronization Mike Kravetz
2018-12-19 1:24 ` Sasha Levin
2018-12-21 10:05 ` Kirill A. Shutemov
2018-12-21 18:20 ` Mike Kravetz
2018-12-18 22:35 ` [PATCH v2 2/2] hugetlbfs: Use i_mmap_rwsem to fix page fault/truncate race Mike Kravetz
2018-12-19 1:24 ` Sasha Levin
2018-12-21 10:28 ` Kirill A. Shutemov
2018-12-21 18:28 ` Mike Kravetz [this message]
2018-12-21 20:21 ` Kirill A. Shutemov
2018-12-21 22:17 ` Mike Kravetz
2018-12-22 22:14 ` Kirill A. Shutemov
2018-12-20 21:06 ` [PATCH v2 0/2] hugetlbfs: use i_mmap_rwsem for better synchronization Andrew Morton
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=849f5202-2200-265f-7769-8363053e8373@oracle.com \
--to=mike.kravetz@oracle.com \
--cc=aarcange@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=aneesh.kumar@linux.vnet.ibm.com \
--cc=dave@stgolabs.net \
--cc=hughd@google.com \
--cc=kirill.shutemov@linux.intel.com \
--cc=kirill@shutemov.name \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@kernel.org \
--cc=n-horiguchi@ah.jp.nec.com \
--cc=prakash.sangappa@oracle.com \
--cc=stable@vger.kernel.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