All of lore.kernel.org
 help / color / mirror / Atom feed
From: Gerald Schaefer <gerald.schaefer@linux.ibm.com>
To: Hugh Dickins <hughd@google.com>
Cc: Matthew Wilcox <willy@infradead.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Mike Kravetz <mike.kravetz@oracle.com>,
	Mike Rapoport <rppt@kernel.org>,
	"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
	David Hildenbrand <david@redhat.com>,
	Suren Baghdasaryan <surenb@google.com>,
	Qi Zheng <zhengqi.arch@bytedance.com>,
	Yang Shi <shy828301@gmail.com>,
	Mel Gorman <mgorman@techsingularity.net>,
	Peter Xu <peterx@redhat.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Will Deacon <will@kernel.org>, Yu Zhao <yuzhao@google.com>,
	Alistair Popple <apopple@nvidia.com>,
	Ralph Campbell <rcampbell@nvidia.com>,
	Ira Weiny <ira.weiny@intel.com>,
	Steven Price <steven.price@arm.com>,
	SeongJae Park <sj@kernel.org>,
	Naoya Horiguchi <naoya.horiguchi@nec.com>,
	Christophe Leroy <christophe.leroy@csgroup.eu>,
	Zack Rusin <zackr@vmware.com>, Jason Gunthorpe <jgg@ziepe.ca>,
	Axel Rasmussen <axelrasmussen@google.com>,
	Anshuman Khandual <anshuman.khandual@arm.com>,
	Pasha Tatashin <pasha.tatashin@soleen.com>,
	Miaohe Lin <linmiaohe@huawei.com>,
	Minchan Kim <minchan@kernel.org>,
	Christoph Hellwig <hch@infradead.org>, Song Liu <song@kernel.org>,
	Thomas Hellstrom <thomas.hellstrom@linux.intel.com>,
	Russell King <linux@armlinux.org.uk>,
	"David S. Miller" <davem@davemloft.net>,
	Michael Ellerman <mpe@ellerman.id.au>,
	"Aneesh Kumar K.V" <aneesh.kumar@linux.ibm.com>,
	Heiko Carstens <hca@linux.ibm.com>,
	Christian Borntraeger <borntraeger@linux.ibm.com>,
	Claudio Imbrenda <imbrenda@linux.ibm.com>,
	Alexander Gordeev <agordeev@linux.ibm.com>,
	Jann Horn <jannh@google.com>,
	linux-arm-kernel@lists.infradead.org, sparclinux@vger.kernel.org,
	linuxppc-dev@lists.ozlabs.org, linux-s390@vger.kernel.org,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org,
	Vasily Gorbik <gor@linux.ibm.com>
Subject: Re: [PATCH 05/12] powerpc: add pte_free_defer() for pgtables sharing page
Date: Thu, 1 Jun 2023 15:57:51 +0200	[thread overview]
Message-ID: <20230601155751.7c949ca4@thinkpad-T15> (raw)
In-Reply-To: <a8df11d-55ae-64bc-edcb-d383a7a941ea@google.com>

On Mon, 29 May 2023 07:36:40 -0700 (PDT)
Hugh Dickins <hughd@google.com> wrote:

> On Mon, 29 May 2023, Matthew Wilcox wrote:
> > On Sun, May 28, 2023 at 11:20:21PM -0700, Hugh Dickins wrote:  
> > > +void pte_free_defer(struct mm_struct *mm, pgtable_t pgtable)
> > > +{
> > > +	struct page *page;
> > > +
> > > +	page = virt_to_page(pgtable);
> > > +	call_rcu(&page->rcu_head, pte_free_now);
> > > +}  
> > 
> > This can't be safe (on ppc).  IIRC you might have up to 16x4k page
> > tables sharing one 64kB page.  So if you have two page tables from the
> > same page being defer-freed simultaneously, you'll reuse the rcu_head
> > and I cannot imagine things go well from that point.  
> 
> Oh yes, of course, thanks for catching that so quickly.
> So my s390 and sparc implementations will be equally broken.
> 
> > 
> > I have no idea how to solve this problem.  
> 
> I do: I'll have to go back to the more complicated implementation we
> actually ran with on powerpc - I was thinking those complications just
> related to deposit/withdraw matters, forgetting the one-rcu_head issue.
> 
> It uses large (0x10000) increments of the page refcount, avoiding
> call_rcu() when already active.
> 
> It's not a complication I had wanted to explain or test for now,
> but we shall have to.  Should apply equally well to sparc, but s390
> more of a problem, since s390 already has its own refcount cleverness.

Yes, we have 2 pagetables in one 4K page, which could result in same
rcu_head reuse. It might be possible to use the cleverness from our
page_table_free() function, e.g. to only do the call_rcu() once, for
the case where both 2K pagetable fragments become unused, similar to
how we decide when to actually call __free_page().

However, it might be much worse, and page->rcu_head from a pagetable
page cannot be used at all for s390, because we also use page->lru
to keep our list of free 2K pagetable fragments. I always get confused
by struct page unions, so not completely sure, but it seems to me that
page->rcu_head would overlay with page->lru, right?

WARNING: multiple messages have this Message-ID (diff)
From: Gerald Schaefer <gerald.schaefer@linux.ibm.com>
To: Hugh Dickins <hughd@google.com>
Cc: Miaohe Lin <linmiaohe@huawei.com>,
	David Hildenbrand <david@redhat.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Yang Shi <shy828301@gmail.com>, Peter Xu <peterx@redhat.com>,
	Song Liu <song@kernel.org>,
	sparclinux@vger.kernel.org,
	Alexander Gordeev <agordeev@linux.ibm.com>,
	Claudio Imbrenda <imbrenda@linux.ibm.com>,
	Will Deacon <will@kernel.org>,
	linux-s390@vger.kernel.org, Yu Zhao <yuzhao@google.com>,
	Ira Weiny <ira.weiny@intel.com>,
	Alistair Popple <apopple@nvidia.com>,
	Russell King <linux@armlinux.org.uk>,
	Matthew Wilcox <willy@infradead.org>,
	Steven Price <steven.price@arm.com>,
	Christoph Hellwig <hch@infradead.org>,
	Jason Gunthorpe <jgg@ziepe.ca>,
	"Aneesh Kumar K.V" <aneesh.kumar@linux.ibm.com>,
	Axel Rasmussen <axelrasmussen@google.com>,
	Christian Borntraeger <borntraeger@linux.ibm.com>,
	Thomas Hellstrom <thomas.hellstrom@linux.intel.com>,
	Ralph Campbell <rcampbell@nvidia.com>,
	Pasha Tatashin <pasha.tatashin@soleen.com>,
	Vasily Gorbik <gor@linux.ibm.com>,
	Anshuman Khandual <a nshuman.khandual@arm.com>,
	Heiko Carstens <hca@linux.ibm.com>,
	Qi Zheng <zhengqi.arch@bytedance.com>,
	Suren Baghdasaryan <surenb@google.com>,
	linux-arm-kernel@lists.infradead.org,
	SeongJae Park <sj@kernel.org>, Jann Horn <jannh@google.com>,
	linux-mm@kvack.org, linuxppc-dev@lists.ozlabs.org,
	"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
	Naoya Horiguchi <naoya.horiguchi@nec.com>,
	linux-kernel@vger.kernel.org, Minchan Kim <minchan@kernel.org>,
	Mike Rapoport <rppt@kernel.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Mel Gorman <mgorman@techsingularity.net>,
	"David S. Miller" <davem@davemloft.net>,
	Zack Rusin <zackr@vmware.com>,
	Mike Kravetz <mike.kravetz@oracle.com>
Subject: Re: [PATCH 05/12] powerpc: add pte_free_defer() for pgtables sharing page
Date: Thu, 1 Jun 2023 15:57:51 +0200	[thread overview]
Message-ID: <20230601155751.7c949ca4@thinkpad-T15> (raw)
In-Reply-To: <a8df11d-55ae-64bc-edcb-d383a7a941ea@google.com>

On Mon, 29 May 2023 07:36:40 -0700 (PDT)
Hugh Dickins <hughd@google.com> wrote:

> On Mon, 29 May 2023, Matthew Wilcox wrote:
> > On Sun, May 28, 2023 at 11:20:21PM -0700, Hugh Dickins wrote:  
> > > +void pte_free_defer(struct mm_struct *mm, pgtable_t pgtable)
> > > +{
> > > +	struct page *page;
> > > +
> > > +	page = virt_to_page(pgtable);
> > > +	call_rcu(&page->rcu_head, pte_free_now);
> > > +}  
> > 
> > This can't be safe (on ppc).  IIRC you might have up to 16x4k page
> > tables sharing one 64kB page.  So if you have two page tables from the
> > same page being defer-freed simultaneously, you'll reuse the rcu_head
> > and I cannot imagine things go well from that point.  
> 
> Oh yes, of course, thanks for catching that so quickly.
> So my s390 and sparc implementations will be equally broken.
> 
> > 
> > I have no idea how to solve this problem.  
> 
> I do: I'll have to go back to the more complicated implementation we
> actually ran with on powerpc - I was thinking those complications just
> related to deposit/withdraw matters, forgetting the one-rcu_head issue.
> 
> It uses large (0x10000) increments of the page refcount, avoiding
> call_rcu() when already active.
> 
> It's not a complication I had wanted to explain or test for now,
> but we shall have to.  Should apply equally well to sparc, but s390
> more of a problem, since s390 already has its own refcount cleverness.

Yes, we have 2 pagetables in one 4K page, which could result in same
rcu_head reuse. It might be possible to use the cleverness from our
page_table_free() function, e.g. to only do the call_rcu() once, for
the case where both 2K pagetable fragments become unused, similar to
how we decide when to actually call __free_page().

However, it might be much worse, and page->rcu_head from a pagetable
page cannot be used at all for s390, because we also use page->lru
to keep our list of free 2K pagetable fragments. I always get confused
by struct page unions, so not completely sure, but it seems to me that
page->rcu_head would overlay with page->lru, right?

WARNING: multiple messages have this Message-ID (diff)
From: Gerald Schaefer <gerald.schaefer@linux.ibm.com>
To: Hugh Dickins <hughd@google.com>
Cc: Matthew Wilcox <willy@infradead.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Mike Kravetz <mike.kravetz@oracle.com>,
	Mike Rapoport <rppt@kernel.org>,
	"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
	David Hildenbrand <david@redhat.com>,
	Suren Baghdasaryan <surenb@google.com>,
	Qi Zheng <zhengqi.arch@bytedance.com>,
	Yang Shi <shy828301@gmail.com>,
	Mel Gorman <mgorman@techsingularity.net>,
	Peter Xu <peterx@redhat.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Will Deacon <will@kernel.org>, Yu Zhao <yuzhao@google.com>,
	Alistair Popple <apopple@nvidia.com>,
	Ralph Campbell <rcampbell@nvidia.com>,
	Ira Weiny <ira.weiny@intel.com>,
	Steven Price <steven.price@arm.com>,
	SeongJae Park <sj@kernel.org>,
	Naoya Horiguchi <naoya.horiguchi@nec.com>,
	Christophe Leroy <christophe.leroy@csgroup.eu>,
	Zack Rusin <zackr@vmware.com>, Jason Gunthorpe <jgg@ziepe.ca>,
	Axel Rasmussen <axelrasmussen@google.com>,
	Anshuman Khandual <anshuman.khandual@arm.com>,
	Pasha Tatashin <pasha.tatashin@soleen.com>,
	Miaohe Lin <linmiaohe@huawei.com>,
	Minchan Kim <minchan@kernel.org>,
	Christoph Hellwig <hch@infradead.org>, Song Liu <song@kernel.org>,
	Thomas Hellstrom <thomas.hellstrom@linux.intel.com>,
	Russell King <linux@armlinux.org.uk>,
	"David S. Miller" <davem@davemloft.net>,
	Michael Ellerman <mpe@ellerman.id.au>,
	"Aneesh Kumar K.V" <aneesh.kumar@linux.ibm.com>,
	Heiko Carstens <hca@linux.ibm.com>,
	Christian Borntraeger <borntraeger@linux.ibm.com>,
	Claudio Imbrenda <imbrenda@linux.ibm.com>,
	Alexander Gordeev <agordeev@linux.ibm.com>,
	Jann Horn <jannh@google.com>,
	linux-arm-kernel@lists.infradead.org, sparclinux@vger.kernel.org,
	linuxppc-dev@lists.ozlabs.org, linux-s390@vger.kernel.org,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org,
	Vasily Gorbik <gor@linux.ibm.com>
Subject: Re: [PATCH 05/12] powerpc: add pte_free_defer() for pgtables sharing page
Date: Thu, 1 Jun 2023 15:57:51 +0200	[thread overview]
Message-ID: <20230601155751.7c949ca4@thinkpad-T15> (raw)
In-Reply-To: <a8df11d-55ae-64bc-edcb-d383a7a941ea@google.com>

On Mon, 29 May 2023 07:36:40 -0700 (PDT)
Hugh Dickins <hughd@google.com> wrote:

> On Mon, 29 May 2023, Matthew Wilcox wrote:
> > On Sun, May 28, 2023 at 11:20:21PM -0700, Hugh Dickins wrote:  
> > > +void pte_free_defer(struct mm_struct *mm, pgtable_t pgtable)
> > > +{
> > > +	struct page *page;
> > > +
> > > +	page = virt_to_page(pgtable);
> > > +	call_rcu(&page->rcu_head, pte_free_now);
> > > +}  
> > 
> > This can't be safe (on ppc).  IIRC you might have up to 16x4k page
> > tables sharing one 64kB page.  So if you have two page tables from the
> > same page being defer-freed simultaneously, you'll reuse the rcu_head
> > and I cannot imagine things go well from that point.  
> 
> Oh yes, of course, thanks for catching that so quickly.
> So my s390 and sparc implementations will be equally broken.
> 
> > 
> > I have no idea how to solve this problem.  
> 
> I do: I'll have to go back to the more complicated implementation we
> actually ran with on powerpc - I was thinking those complications just
> related to deposit/withdraw matters, forgetting the one-rcu_head issue.
> 
> It uses large (0x10000) increments of the page refcount, avoiding
> call_rcu() when already active.
> 
> It's not a complication I had wanted to explain or test for now,
> but we shall have to.  Should apply equally well to sparc, but s390
> more of a problem, since s390 already has its own refcount cleverness.

Yes, we have 2 pagetables in one 4K page, which could result in same
rcu_head reuse. It might be possible to use the cleverness from our
page_table_free() function, e.g. to only do the call_rcu() once, for
the case where both 2K pagetable fragments become unused, similar to
how we decide when to actually call __free_page().

However, it might be much worse, and page->rcu_head from a pagetable
page cannot be used at all for s390, because we also use page->lru
to keep our list of free 2K pagetable fragments. I always get confused
by struct page unions, so not completely sure, but it seems to me that
page->rcu_head would overlay with page->lru, right?

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2023-06-01 13:59 UTC|newest]

Thread overview: 158+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-05-29  6:11 [PATCH 00/12] mm: free retracted page table by RCU Hugh Dickins
2023-05-29  6:11 ` Hugh Dickins
2023-05-29  6:11 ` Hugh Dickins
2023-05-29  6:14 ` [PATCH 01/12] mm/pgtable: add rcu_read_lock() and rcu_read_unlock()s Hugh Dickins
2023-05-29  6:14   ` Hugh Dickins
2023-05-29  6:14   ` Hugh Dickins
2023-05-31 17:06   ` Jann Horn
2023-05-31 17:06     ` Jann Horn
2023-05-31 17:06     ` Jann Horn
2023-06-02  2:50     ` Hugh Dickins
2023-06-02  2:50       ` Hugh Dickins
2023-06-02  2:50       ` Hugh Dickins
2023-06-02 14:21       ` Jann Horn
2023-06-02 14:21         ` Jann Horn
2023-06-02 14:21         ` Jann Horn
2023-05-29  6:16 ` [PATCH 02/12] mm/pgtable: add PAE safety to __pte_offset_map() Hugh Dickins
2023-05-29  6:16   ` Hugh Dickins
2023-05-29  6:16   ` Hugh Dickins
2023-05-29 13:56   ` Matthew Wilcox
2023-05-29 13:56     ` Matthew Wilcox
2023-05-29 13:56     ` Matthew Wilcox
     [not found]   ` <ZHeg3oRljRn6wlLX@ziepe.ca>
2023-06-02  5:35     ` Hugh Dickins
2023-06-02  5:35       ` Hugh Dickins
2023-06-02  5:35       ` Hugh Dickins
2023-05-29  6:17 ` [PATCH 03/12] arm: adjust_pte() use pte_offset_map_nolock() Hugh Dickins
2023-05-29  6:17   ` Hugh Dickins
2023-05-29  6:17   ` Hugh Dickins
2023-05-29  6:18 ` [PATCH 04/12] powerpc: assert_pte_locked() " Hugh Dickins
2023-05-29  6:18   ` Hugh Dickins
2023-05-29  6:18   ` Hugh Dickins
2023-05-29  6:20 ` [PATCH 05/12] powerpc: add pte_free_defer() for pgtables sharing page Hugh Dickins
2023-05-29  6:20   ` Hugh Dickins
2023-05-29  6:20   ` Hugh Dickins
2023-05-29 14:02   ` Matthew Wilcox
2023-05-29 14:02     ` Matthew Wilcox
2023-05-29 14:02     ` Matthew Wilcox
2023-05-29 14:36     ` Hugh Dickins
2023-05-29 14:36       ` Hugh Dickins
2023-05-29 14:36       ` Hugh Dickins
2023-06-01 13:57       ` Gerald Schaefer [this message]
2023-06-01 13:57         ` Gerald Schaefer
2023-06-01 13:57         ` Gerald Schaefer
2023-06-02  6:38         ` Hugh Dickins
2023-06-02  6:38           ` Hugh Dickins
2023-06-02 14:20     ` Jason Gunthorpe
2023-06-02 14:20       ` Jason Gunthorpe
2023-06-02 14:20       ` Jason Gunthorpe
2023-06-06  3:40       ` Hugh Dickins
2023-06-06  3:40         ` Hugh Dickins
2023-06-06  3:40         ` Hugh Dickins
2023-06-06 18:23         ` Jason Gunthorpe
2023-06-06 18:23           ` Jason Gunthorpe
2023-06-06 18:23           ` Jason Gunthorpe
2023-06-06 19:03           ` Peter Xu
2023-06-06 19:03             ` Peter Xu
2023-06-06 19:03             ` Peter Xu
2023-06-06 19:08             ` Jason Gunthorpe
2023-06-06 19:08               ` Jason Gunthorpe
2023-06-06 19:08               ` Jason Gunthorpe
2023-06-07  3:49               ` Hugh Dickins
2023-06-07  3:49                 ` Hugh Dickins
2023-06-07  3:49                 ` Hugh Dickins
2023-05-29  6:21 ` [PATCH 06/12] sparc: " Hugh Dickins
2023-05-29  6:21   ` Hugh Dickins
2023-05-29  6:21   ` Hugh Dickins
2023-06-06  3:46   ` Hugh Dickins
2023-06-06  3:46     ` Hugh Dickins
2023-06-06  3:46     ` Hugh Dickins
2023-05-29  6:22 ` [PATCH 07/12] s390: add pte_free_defer(), with use of mmdrop_async() Hugh Dickins
2023-05-29  6:22   ` Hugh Dickins
2023-05-29  6:22   ` Hugh Dickins
2023-06-06  5:11   ` Hugh Dickins
2023-06-06  5:11     ` Hugh Dickins
2023-06-06  5:11     ` Hugh Dickins
2023-06-06 18:39     ` Jason Gunthorpe
2023-06-06 18:39       ` Jason Gunthorpe
2023-06-06 18:39       ` Jason Gunthorpe
2023-06-08  2:46       ` Hugh Dickins
2023-06-08  2:46         ` Hugh Dickins
2023-06-08  2:46         ` Hugh Dickins
2023-06-06 19:40     ` Gerald Schaefer
2023-06-06 19:40       ` Gerald Schaefer
2023-06-06 19:40       ` Gerald Schaefer
2023-06-08  3:35       ` Hugh Dickins
2023-06-08  3:35         ` Hugh Dickins
2023-06-08  3:35         ` Hugh Dickins
2023-06-08 13:58         ` Jason Gunthorpe
2023-06-08 13:58           ` Jason Gunthorpe
2023-06-08 13:58           ` Jason Gunthorpe
2023-06-08 15:47         ` Gerald Schaefer
2023-06-08 15:47           ` Gerald Schaefer
2023-06-08 15:47           ` Gerald Schaefer
2023-06-13  6:34           ` Hugh Dickins
2023-06-14 13:30             ` Gerald Schaefer
2023-06-14 21:59               ` Hugh Dickins
2023-06-15 12:11                 ` Gerald Schaefer
2023-06-15 20:06                   ` Hugh Dickins
2023-06-16  8:38                     ` Gerald Schaefer
2023-06-15 12:34                 ` Jason Gunthorpe
2023-06-15 21:09                   ` Hugh Dickins
2023-06-16 12:35                     ` Jason Gunthorpe
2023-05-29  6:23 ` [PATCH 08/12] mm/pgtable: add pte_free_defer() for pgtable as page Hugh Dickins
2023-05-29  6:23   ` Hugh Dickins
2023-05-29  6:23   ` Hugh Dickins
2023-06-01 13:31   ` Jann Horn
2023-06-01 13:31     ` Jann Horn
2023-06-01 13:31     ` Jann Horn
     [not found]   ` <ZHekpAKJ05cr/GLl@ziepe.ca>
2023-06-02  6:03     ` Hugh Dickins
2023-06-02  6:03       ` Hugh Dickins
2023-06-02  6:03       ` Hugh Dickins
2023-06-02 12:15       ` Jason Gunthorpe
2023-06-02 12:15         ` Jason Gunthorpe
2023-06-02 12:15         ` Jason Gunthorpe
2023-05-29  6:25 ` [PATCH 09/12] mm/khugepaged: retract_page_tables() without mmap or vma lock Hugh Dickins
2023-05-29  6:25   ` Hugh Dickins
2023-05-29  6:25   ` Hugh Dickins
2023-05-29 23:26   ` Peter Xu
2023-05-29 23:26     ` Peter Xu
2023-05-29 23:26     ` Peter Xu
2023-05-31  0:38     ` Hugh Dickins
2023-05-31  0:38       ` Hugh Dickins
2023-05-31  0:38       ` Hugh Dickins
2023-05-31 15:34   ` Jann Horn
2023-05-31 15:34     ` Jann Horn
2023-05-31 15:34     ` Jann Horn
     [not found]     ` <ZHe0A079X9B8jWlH@x1n>
2023-05-31 22:18       ` Jann Horn
2023-05-31 22:18         ` Jann Horn
2023-05-31 22:18         ` Jann Horn
2023-06-01 14:06         ` Jason Gunthorpe
2023-06-01 14:06           ` Jason Gunthorpe
2023-06-01 14:06           ` Jason Gunthorpe
2023-06-06  6:18     ` Hugh Dickins
2023-06-06  6:18       ` Hugh Dickins
2023-06-06  6:18       ` Hugh Dickins
2023-05-29  6:26 ` [PATCH 10/12] mm/khugepaged: collapse_pte_mapped_thp() with mmap_read_lock() Hugh Dickins
2023-05-29  6:26   ` Hugh Dickins
2023-05-29  6:26   ` Hugh Dickins
2023-05-31 17:25   ` Jann Horn
2023-05-31 17:25     ` Jann Horn
2023-06-02  5:11     ` Hugh Dickins
2023-06-02  5:11       ` Hugh Dickins
2023-06-02  5:11       ` Hugh Dickins
2023-05-29  6:28 ` [PATCH 11/12] mm/khugepaged: delete khugepaged_collapse_pte_mapped_thps() Hugh Dickins
2023-05-29  6:28   ` Hugh Dickins
2023-05-29  6:28   ` Hugh Dickins
2023-05-29  6:30 ` [PATCH 12/12] mm: delete mmap_write_trylock() and vma_try_start_write() Hugh Dickins
2023-05-29  6:30   ` Hugh Dickins
2023-05-29  6:30   ` Hugh Dickins
2023-05-31 17:59 ` [PATCH 00/12] mm: free retracted page table by RCU Jann Horn
2023-06-02  4:37   ` Hugh Dickins
2023-06-02  4:37     ` Hugh Dickins
2023-06-02  4:37     ` Hugh Dickins
2023-06-02 15:26     ` Jann Horn
2023-06-02 15:26       ` Jann Horn
2023-06-02 15:26       ` Jann Horn
2023-06-06  6:28       ` Hugh Dickins
2023-06-06  6:28         ` Hugh Dickins
2023-06-06  6:28         ` Hugh Dickins

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=20230601155751.7c949ca4@thinkpad-T15 \
    --to=gerald.schaefer@linux.ibm.com \
    --cc=agordeev@linux.ibm.com \
    --cc=akpm@linux-foundation.org \
    --cc=aneesh.kumar@linux.ibm.com \
    --cc=anshuman.khandual@arm.com \
    --cc=apopple@nvidia.com \
    --cc=axelrasmussen@google.com \
    --cc=borntraeger@linux.ibm.com \
    --cc=christophe.leroy@csgroup.eu \
    --cc=davem@davemloft.net \
    --cc=david@redhat.com \
    --cc=gor@linux.ibm.com \
    --cc=hca@linux.ibm.com \
    --cc=hch@infradead.org \
    --cc=hughd@google.com \
    --cc=imbrenda@linux.ibm.com \
    --cc=ira.weiny@intel.com \
    --cc=jannh@google.com \
    --cc=jgg@ziepe.ca \
    --cc=kirill.shutemov@linux.intel.com \
    --cc=linmiaohe@huawei.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linux-s390@vger.kernel.org \
    --cc=linux@armlinux.org.uk \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=mgorman@techsingularity.net \
    --cc=mike.kravetz@oracle.com \
    --cc=minchan@kernel.org \
    --cc=mpe@ellerman.id.au \
    --cc=naoya.horiguchi@nec.com \
    --cc=pasha.tatashin@soleen.com \
    --cc=peterx@redhat.com \
    --cc=peterz@infradead.org \
    --cc=rcampbell@nvidia.com \
    --cc=rppt@kernel.org \
    --cc=shy828301@gmail.com \
    --cc=sj@kernel.org \
    --cc=song@kernel.org \
    --cc=sparclinux@vger.kernel.org \
    --cc=steven.price@arm.com \
    --cc=surenb@google.com \
    --cc=thomas.hellstrom@linux.intel.com \
    --cc=will@kernel.org \
    --cc=willy@infradead.org \
    --cc=yuzhao@google.com \
    --cc=zackr@vmware.com \
    --cc=zhengqi.arch@bytedance.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.