All of lore.kernel.org
 help / color / mirror / Atom feed
From: Miaohe Lin <linmiaohe@huawei.com>
To: Mike Kravetz <mike.kravetz@oracle.com>, <linux-mm@kvack.org>,
	<linux-kernel@vger.kernel.org>
Cc: Muchun Song <songmuchun@bytedance.com>,
	David Hildenbrand <david@redhat.com>,
	Sven Schnelle <svens@linux.ibm.com>,
	Michal Hocko <mhocko@suse.com>, Peter Xu <peterx@redhat.com>,
	Naoya Horiguchi <naoya.horiguchi@linux.dev>,
	"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>,
	James Houghton <jthoughton@google.com>,
	Mina Almasry <almasrymina@google.com>,
	Pasha Tatashin <pasha.tatashin@soleen.com>,
	Axel Rasmussen <axelrasmussen@google.com>,
	Ray Fucillo <Ray.Fucillo@intersystems.com>,
	Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [PATCH v2 6/9] hugetlb: add vma based lock for pmd sharing
Date: Sat, 24 Sep 2022 21:11:48 +0800	[thread overview]
Message-ID: <2b1b6d09-0188-23a3-6ac3-6e81446a10e4@huawei.com> (raw)
In-Reply-To: <20220914221810.95771-7-mike.kravetz@oracle.com>

On 2022/9/15 6:18, Mike Kravetz wrote:
> Allocate a new hugetlb_vma_lock structure and hang off vm_private_data
> for synchronization use by vmas that could be involved in pmd sharing.
> This data structure contains a rw semaphore that is the primary tool
> used for synchronization.
> 
> This new structure is ref counted, so that it can exist when NOT attached
> to a vma.  This is only helpful in resolving lock ordering issues where
> code may need to obtain the vma_lock while there are no guarantees the
> vma may go away.  By obtaining a ref on the structure, it can be
> guaranteed that at least the rw semaphore will not go away.
> 
> Only add infrastructure for the new lock here.  Actual use will be added
> in subsequent patches.
> 
> Signed-off-by: Mike Kravetz <mike.kravetz@oracle.com>

LGTM with some nits below. Thanks for your work, Mike.

Reviewed-by: Miaohe Lin <linmiaohe@huawei.com>

> -/* Reset counters to 0 and clear all HPAGE_RESV_* flags */
> -void reset_vma_resv_huge_pages(struct vm_area_struct *vma)
> +void hugetlb_dup_vma_private(struct vm_area_struct *vma)
>  {
>  	VM_BUG_ON_VMA(!is_vm_hugetlb_page(vma), vma);
> +	/*
> +	 * Clear vm_private_data
> +	 * - For MAP_PRIVATE mappings, this is the reserve map which does
> +	 *   not apply to children.  Faults generated by the children are
> +	 *   not guaranteed to succeed, even if read-only.
> +	 * - For shared mappings this is a per-vma semaphore that may be
> +	 *   allocated in a subsequent call to hugetlb_vm_op_open.
> +	 */
> +	vma->vm_private_data = (void *)0;
>  	if (!(vma->vm_flags & VM_MAYSHARE))
> -		vma->vm_private_data = (void *)0;
> +		return;

This if block can be deleted ? It doesn't do anything here.

>  }
>  
>  /*

<snip>

> +static void hugetlb_vma_lock_free(struct vm_area_struct *vma)
> +{
> +	/*
> +	 * Only present in sharable vmas.  See comment in
> +	 * __unmap_hugepage_range_final about how VM_SHARED could
> +	 * be set without VM_MAYSHARE.  As a result, we need to
> +	 * check if either is set in the free path.
> +	 */
> +	if (!vma || !(vma->vm_flags & (VM_MAYSHARE | VM_SHARED)))
> +		return;
> +
> +	if (vma->vm_private_data) {
> +		struct hugetlb_vma_lock *vma_lock = vma->vm_private_data;
> +
> +		/*
> +		 * vma_lock structure may or not be released, but it

may or not be released?

Thanks,
Miaohe Lin


  parent reply	other threads:[~2022-09-24 13:12 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-09-14 22:18 [PATCH v2 0/9] hugetlb: Use new vma lock for huge pmd sharing synchronization Mike Kravetz
2022-09-14 22:18 ` [PATCH v2 1/9] hugetlbfs: revert use i_mmap_rwsem to address page fault/truncate race Mike Kravetz
2022-09-14 22:18 ` [PATCH v2 2/9] hugetlbfs: revert use i_mmap_rwsem for more pmd sharing synchronization Mike Kravetz
2022-09-14 22:18 ` [PATCH v2 3/9] hugetlb: rename remove_huge_page to hugetlb_delete_from_page_cache Mike Kravetz
2022-09-14 22:18 ` [PATCH v2 4/9] hugetlb: create remove_inode_single_folio to remove single file folio Mike Kravetz
2022-09-24 12:36   ` Miaohe Lin
2022-09-14 22:18 ` [PATCH v2 5/9] hugetlb: rename vma_shareable() and refactor code Mike Kravetz
2022-09-14 22:18 ` [PATCH v2 6/9] hugetlb: add vma based lock for pmd sharing Mike Kravetz
2022-09-15 20:25   ` Mike Kravetz
2022-09-24 13:11   ` Miaohe Lin [this message]
2022-09-14 22:18 ` [PATCH v2 7/9] hugetlb: create hugetlb_unmap_file_folio to unmap single file folio Mike Kravetz
2022-09-14 22:18 ` [PATCH v2 8/9] hugetlb: use new vma_lock for pmd sharing synchronization Mike Kravetz
2022-09-29  6:08   ` Miaohe Lin
2022-10-01  0:00     ` Mike Kravetz
2022-10-08  2:29       ` Miaohe Lin
2022-09-14 22:18 ` [PATCH v2 9/9] hugetlb: clean up code checking for fault/truncation races Mike Kravetz
2022-09-19 23:32   ` Mike Kravetz
2022-09-29  6:25   ` Miaohe Lin

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=2b1b6d09-0188-23a3-6ac3-6e81446a10e4@huawei.com \
    --to=linmiaohe@huawei.com \
    --cc=Ray.Fucillo@intersystems.com \
    --cc=aarcange@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=almasrymina@google.com \
    --cc=aneesh.kumar@linux.vnet.ibm.com \
    --cc=axelrasmussen@google.com \
    --cc=dave@stgolabs.net \
    --cc=david@redhat.com \
    --cc=jthoughton@google.com \
    --cc=kirill.shutemov@linux.intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mhocko@suse.com \
    --cc=mike.kravetz@oracle.com \
    --cc=naoya.horiguchi@linux.dev \
    --cc=pasha.tatashin@soleen.com \
    --cc=peterx@redhat.com \
    --cc=prakash.sangappa@oracle.com \
    --cc=songmuchun@bytedance.com \
    --cc=svens@linux.ibm.com \
    /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.