From: David Hildenbrand <david@redhat.com>
To: Mike Rapoport <rppt@kernel.org>
Cc: linux-kernel@vger.kernel.org,
Alexander Potapenko <glider@google.com>,
Andrew Morton <akpm@linux-foundation.org>,
Brendan Jackman <jackmanb@google.com>,
Christoph Lameter <cl@gentwo.org>,
Dennis Zhou <dennis@kernel.org>,
Dmitry Vyukov <dvyukov@google.com>,
dri-devel@lists.freedesktop.org, intel-gfx@lists.freedesktop.org,
iommu@lists.linux.dev, io-uring@vger.kernel.org,
Jason Gunthorpe <jgg@nvidia.com>, Jens Axboe <axboe@kernel.dk>,
Johannes Weiner <hannes@cmpxchg.org>,
John Hubbard <jhubbard@nvidia.com>,
kasan-dev@googlegroups.com, kvm@vger.kernel.org,
"Liam R. Howlett" <Liam.Howlett@oracle.com>,
Linus Torvalds <torvalds@linux-foundation.org>,
linux-arm-kernel@axis.com, linux-arm-kernel@lists.infradead.org,
linux-crypto@vger.kernel.org, linux-ide@vger.kernel.org,
linux-kselftest@vger.kernel.org, linux-mips@vger.kernel.org,
linux-mmc@vger.kernel.org, linux-mm@kvack.org,
linux-riscv@lists.infradead.org, linux-s390@vger.kernel.org,
linux-scsi@vger.kernel.org,
Lorenzo Stoakes <lorenzo.stoakes@oracle.com>,
Marco Elver <elver@google.com>,
Marek Szyprowski <m.szyprowski@samsung.com>,
Michal Hocko <mhocko@suse.com>,
Muchun Song <muchun.song@linux.dev>,
netdev@vger.kernel.org, Oscar Salvador <osalvador@suse.de>,
Peter Xu <peterx@redhat.com>, Robin Murphy <robin.murphy@arm.com>,
Suren Baghdasaryan <surenb@google.com>, Tejun Heo <tj@kernel.org>,
virtualization@lists.linux.dev, Vlastimil Babka <vbabka@suse.cz>,
wireguard@lists.zx2c4.com, x86@kernel.org,
Zi Yan <ziy@nvidia.com>
Subject: Re: [PATCH v1 13/36] mm/hugetlb: cleanup hugetlb_folio_init_tail_vmemmap()
Date: Thu, 28 Aug 2025 09:44:27 +0200 [thread overview]
Message-ID: <377449bd-3c06-4a09-8647-e41354e64b30@redhat.com> (raw)
In-Reply-To: <aLADXP89cp6hAq0q@kernel.org>
On 28.08.25 09:21, Mike Rapoport wrote:
> On Thu, Aug 28, 2025 at 12:01:17AM +0200, David Hildenbrand wrote:
>> We can now safely iterate over all pages in a folio, so no need for the
>> pfn_to_page().
>>
>> Also, as we already force the refcount in __init_single_page() to 1,
>> we can just set the refcount to 0 and avoid page_ref_freeze() +
>> VM_BUG_ON. Likely, in the future, we would just want to tell
>> __init_single_page() to which value to initialize the refcount.
>>
>> Further, adjust the comments to highlight that we are dealing with an
>> open-coded prep_compound_page() variant, and add another comment explaining
>> why we really need the __init_single_page() only on the tail pages.
>>
>> Note that the current code was likely problematic, but we never ran into
>> it: prep_compound_tail() would have been called with an offset that might
>> exceed a memory section, and prep_compound_tail() would have simply
>> added that offset to the page pointer -- which would not have done the
>> right thing on sparsemem without vmemmap.
>>
>> Signed-off-by: David Hildenbrand <david@redhat.com>
>> ---
>> mm/hugetlb.c | 20 ++++++++++++--------
>> 1 file changed, 12 insertions(+), 8 deletions(-)
>>
>> diff --git a/mm/hugetlb.c b/mm/hugetlb.c
>> index 4a97e4f14c0dc..1f42186a85ea4 100644
>> --- a/mm/hugetlb.c
>> +++ b/mm/hugetlb.c
>> @@ -3237,17 +3237,18 @@ static void __init hugetlb_folio_init_tail_vmemmap(struct folio *folio,
>> {
>> enum zone_type zone = zone_idx(folio_zone(folio));
>> int nid = folio_nid(folio);
>> + struct page *page = folio_page(folio, start_page_number);
>> unsigned long head_pfn = folio_pfn(folio);
>> unsigned long pfn, end_pfn = head_pfn + end_page_number;
>> - int ret;
>> -
>> - for (pfn = head_pfn + start_page_number; pfn < end_pfn; pfn++) {
>> - struct page *page = pfn_to_page(pfn);
>>
>> + /*
>> + * We mark all tail pages with memblock_reserved_mark_noinit(),
>> + * so these pages are completely uninitialized.
>
> ^ not? ;-)
Can you elaborate?
--
Cheers
David / dhildenb
WARNING: multiple messages have this Message-ID (diff)
From: David Hildenbrand <david@redhat.com>
To: Mike Rapoport <rppt@kernel.org>
Cc: linux-kernel@vger.kernel.org,
Alexander Potapenko <glider@google.com>,
Andrew Morton <akpm@linux-foundation.org>,
Brendan Jackman <jackmanb@google.com>,
Christoph Lameter <cl@gentwo.org>,
Dennis Zhou <dennis@kernel.org>,
Dmitry Vyukov <dvyukov@google.com>,
dri-devel@lists.freedesktop.org, intel-gfx@lists.freedesktop.org,
iommu@lists.linux.dev, io-uring@vger.kernel.org,
Jason Gunthorpe <jgg@nvidia.com>, Jens Axboe <axboe@kernel.dk>,
Johannes Weiner <hannes@cmpxchg.org>,
John Hubbard <jhubbard@nvidia.com>,
kasan-dev@googlegroups.com, kvm@vger.kernel.org,
"Liam R. Howlett" <Liam.Howlett@oracle.com>,
Linus Torvalds <torvalds@linux-foundation.org>,
linux-arm-kernel@axis.com, linux-arm-kernel@lists.infradead.org,
linux-crypto@vger.kernel.org, linux-ide@vger.kernel.org,
linux-kselftest@vger.kernel.org, linux-mips@vger.kernel.org,
linux-mmc@vger.kernel.org, linux-mm@kvack.org,
linux-riscv@lists.infradead.org, linux-s390@vger.kernel.org,
linux-scsi@vger.kernel.org,
Lorenzo Stoakes <lorenzo.stoakes@oracle.com>,
Marco Elver <elver@google.com>,
Marek Szyprowski <m.szyprowski@samsung.com>,
Michal Hocko <mhocko@suse.com>,
Muchun Song <muchun.song@linux.dev>,
netdev@vger.kernel.org, Oscar Salvador <osalvador@suse.de>,
Peter Xu <peterx@redhat.com>, Robin Murphy <robin.murphy@arm.com>,
Suren Baghdasaryan <surenb@google.com>, Tejun Heo <tj@kernel.org>,
virtualization@lists.linux.dev, Vlastimil Babka <vbabka@suse.cz>,
wireguard@lists.zx2c4.com, x86@kernel.org,
Zi Yan <ziy@nvidia.com>
Subject: Re: [PATCH v1 13/36] mm/hugetlb: cleanup hugetlb_folio_init_tail_vmemmap()
Date: Thu, 28 Aug 2025 09:44:27 +0200 [thread overview]
Message-ID: <377449bd-3c06-4a09-8647-e41354e64b30@redhat.com> (raw)
In-Reply-To: <aLADXP89cp6hAq0q@kernel.org>
On 28.08.25 09:21, Mike Rapoport wrote:
> On Thu, Aug 28, 2025 at 12:01:17AM +0200, David Hildenbrand wrote:
>> We can now safely iterate over all pages in a folio, so no need for the
>> pfn_to_page().
>>
>> Also, as we already force the refcount in __init_single_page() to 1,
>> we can just set the refcount to 0 and avoid page_ref_freeze() +
>> VM_BUG_ON. Likely, in the future, we would just want to tell
>> __init_single_page() to which value to initialize the refcount.
>>
>> Further, adjust the comments to highlight that we are dealing with an
>> open-coded prep_compound_page() variant, and add another comment explaining
>> why we really need the __init_single_page() only on the tail pages.
>>
>> Note that the current code was likely problematic, but we never ran into
>> it: prep_compound_tail() would have been called with an offset that might
>> exceed a memory section, and prep_compound_tail() would have simply
>> added that offset to the page pointer -- which would not have done the
>> right thing on sparsemem without vmemmap.
>>
>> Signed-off-by: David Hildenbrand <david@redhat.com>
>> ---
>> mm/hugetlb.c | 20 ++++++++++++--------
>> 1 file changed, 12 insertions(+), 8 deletions(-)
>>
>> diff --git a/mm/hugetlb.c b/mm/hugetlb.c
>> index 4a97e4f14c0dc..1f42186a85ea4 100644
>> --- a/mm/hugetlb.c
>> +++ b/mm/hugetlb.c
>> @@ -3237,17 +3237,18 @@ static void __init hugetlb_folio_init_tail_vmemmap(struct folio *folio,
>> {
>> enum zone_type zone = zone_idx(folio_zone(folio));
>> int nid = folio_nid(folio);
>> + struct page *page = folio_page(folio, start_page_number);
>> unsigned long head_pfn = folio_pfn(folio);
>> unsigned long pfn, end_pfn = head_pfn + end_page_number;
>> - int ret;
>> -
>> - for (pfn = head_pfn + start_page_number; pfn < end_pfn; pfn++) {
>> - struct page *page = pfn_to_page(pfn);
>>
>> + /*
>> + * We mark all tail pages with memblock_reserved_mark_noinit(),
>> + * so these pages are completely uninitialized.
>
> ^ not? ;-)
Can you elaborate?
--
Cheers
David / dhildenb
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
next prev parent reply other threads:[~2025-08-28 7:44 UTC|newest]
Thread overview: 288+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-08-27 22:01 [PATCH v1 00/36] mm: remove nth_page() David Hildenbrand
2025-08-27 22:01 ` David Hildenbrand
2025-08-27 22:01 ` [PATCH v1 01/36] mm: stop making SPARSEMEM_VMEMMAP user-selectable David Hildenbrand
2025-08-27 22:01 ` David Hildenbrand
2025-08-28 7:18 ` Wei Yang
2025-08-28 7:18 ` Wei Yang
2025-08-28 14:11 ` Lorenzo Stoakes
2025-08-28 14:11 ` Lorenzo Stoakes
2025-08-29 0:26 ` Liam R. Howlett
2025-08-29 0:26 ` Liam R. Howlett
2025-08-27 22:01 ` [PATCH v1 02/36] arm64: Kconfig: drop superfluous "select SPARSEMEM_VMEMMAP" David Hildenbrand
2025-08-27 22:01 ` David Hildenbrand
2025-08-28 10:43 ` Catalin Marinas
2025-08-28 10:43 ` Catalin Marinas
2025-08-28 14:12 ` Lorenzo Stoakes
2025-08-28 14:12 ` Lorenzo Stoakes
2025-08-29 0:27 ` Liam R. Howlett
2025-08-29 0:27 ` Liam R. Howlett
2025-08-27 22:01 ` [PATCH v1 03/36] s390/Kconfig: " David Hildenbrand
2025-08-27 22:01 ` David Hildenbrand
2025-08-28 14:12 ` Lorenzo Stoakes
2025-08-28 14:12 ` Lorenzo Stoakes
2025-08-29 0:28 ` Liam R. Howlett
2025-08-29 0:28 ` Liam R. Howlett
2025-08-27 22:01 ` [PATCH v1 04/36] x86/Kconfig: " David Hildenbrand
2025-08-27 22:01 ` David Hildenbrand
2025-08-27 22:52 ` Dave Hansen
2025-08-27 22:52 ` Dave Hansen
2025-08-28 14:25 ` Lorenzo Stoakes
2025-08-28 14:25 ` Lorenzo Stoakes
2025-08-29 0:28 ` Liam R. Howlett
2025-08-29 0:28 ` Liam R. Howlett
2025-08-27 22:01 ` [PATCH v1 05/36] wireguard: selftests: remove CONFIG_SPARSEMEM_VMEMMAP=y from qemu kernel config David Hildenbrand
2025-08-27 22:01 ` David Hildenbrand
2025-08-28 14:26 ` Lorenzo Stoakes
2025-08-28 14:26 ` Lorenzo Stoakes
2025-08-29 0:29 ` Liam R. Howlett
2025-08-29 0:29 ` Liam R. Howlett
2025-08-27 22:01 ` [PATCH v1 06/36] mm/page_alloc: reject unreasonable folio/compound page sizes in alloc_contig_range_noprof() David Hildenbrand
2025-08-27 22:01 ` David Hildenbrand
2025-08-28 7:31 ` Wei Yang
2025-08-28 7:31 ` Wei Yang
2025-08-28 14:37 ` Lorenzo Stoakes
2025-08-28 14:37 ` Lorenzo Stoakes
2025-08-29 10:06 ` David Hildenbrand
2025-08-29 10:06 ` David Hildenbrand
2025-08-29 12:31 ` Lorenzo Stoakes
2025-08-29 12:31 ` Lorenzo Stoakes
2025-08-29 13:09 ` David Hildenbrand
2025-08-29 13:09 ` David Hildenbrand
2025-08-29 0:33 ` Liam R. Howlett
2025-08-29 0:33 ` Liam R. Howlett
2025-08-29 9:58 ` David Hildenbrand
2025-08-29 9:58 ` David Hildenbrand
2025-08-27 22:01 ` [PATCH v1 07/36] mm/memremap: reject unreasonable folio/compound page sizes in memremap_pages() David Hildenbrand
2025-08-27 22:01 ` David Hildenbrand
2025-08-28 14:39 ` Lorenzo Stoakes
2025-08-28 14:39 ` Lorenzo Stoakes
2025-08-29 0:34 ` Liam R. Howlett
2025-08-29 0:34 ` Liam R. Howlett
2025-08-27 22:01 ` [PATCH v1 08/36] mm/hugetlb: check for unreasonable folio sizes when registering hstate David Hildenbrand
2025-08-27 22:01 ` David Hildenbrand
2025-08-28 1:04 ` Zi Yan
2025-08-28 1:04 ` Zi Yan
2025-08-28 14:45 ` Lorenzo Stoakes
2025-08-28 14:45 ` Lorenzo Stoakes
2025-08-29 10:07 ` David Hildenbrand
2025-08-29 10:07 ` David Hildenbrand
2025-08-29 12:18 ` Lorenzo Stoakes
2025-08-29 12:18 ` Lorenzo Stoakes
2025-08-29 0:35 ` Liam R. Howlett
2025-08-29 0:35 ` Liam R. Howlett
2025-08-27 22:01 ` [PATCH v1 09/36] mm/mm_init: make memmap_init_compound() look more like prep_compound_page() David Hildenbrand
2025-08-27 22:01 ` David Hildenbrand
2025-08-28 7:35 ` Wei Yang
2025-08-28 7:35 ` Wei Yang
2025-08-28 14:54 ` Lorenzo Stoakes
2025-08-28 14:54 ` Lorenzo Stoakes
2025-08-29 0:37 ` Liam R. Howlett
2025-08-29 0:37 ` Liam R. Howlett
2025-08-27 22:01 ` [PATCH v1 10/36] mm: sanity-check maximum folio size in folio_set_order() David Hildenbrand
2025-08-27 22:01 ` David Hildenbrand
2025-08-28 7:35 ` Wei Yang
2025-08-28 7:35 ` Wei Yang
2025-08-28 15:00 ` Lorenzo Stoakes
2025-08-28 15:00 ` Lorenzo Stoakes
2025-08-29 10:10 ` David Hildenbrand
2025-08-29 10:10 ` David Hildenbrand
2025-08-29 12:18 ` Lorenzo Stoakes
2025-08-29 12:18 ` Lorenzo Stoakes
2025-08-29 14:24 ` Liam R. Howlett
2025-08-29 14:24 ` Liam R. Howlett
2025-08-27 22:01 ` [PATCH v1 11/36] mm: limit folio/compound page sizes in problematic kernel configs David Hildenbrand
2025-08-27 22:01 ` David Hildenbrand
2025-08-28 7:37 ` Wei Yang
2025-08-28 7:37 ` Wei Yang
2025-08-28 15:10 ` Lorenzo Stoakes
2025-08-28 15:10 ` Lorenzo Stoakes
2025-08-29 11:57 ` David Hildenbrand
2025-08-29 11:57 ` David Hildenbrand
2025-08-29 12:01 ` Lorenzo Stoakes
2025-08-29 12:01 ` Lorenzo Stoakes
2025-08-29 14:27 ` Liam R. Howlett
2025-08-29 14:27 ` Liam R. Howlett
2025-08-27 22:01 ` [PATCH v1 12/36] mm: simplify folio_page() and folio_page_idx() David Hildenbrand
2025-08-27 22:01 ` David Hildenbrand
2025-08-28 7:43 ` Wei Yang
2025-08-28 7:43 ` Wei Yang
2025-08-28 7:46 ` David Hildenbrand
2025-08-28 7:46 ` David Hildenbrand
2025-08-28 8:18 ` Wei Yang
2025-08-28 8:18 ` Wei Yang
2025-08-28 15:24 ` Lorenzo Stoakes
2025-08-28 15:24 ` Lorenzo Stoakes
2025-08-29 14:41 ` Liam R. Howlett
2025-08-29 14:41 ` Liam R. Howlett
2025-08-27 22:01 ` [PATCH v1 13/36] mm/hugetlb: cleanup hugetlb_folio_init_tail_vmemmap() David Hildenbrand
2025-08-27 22:01 ` David Hildenbrand
2025-08-28 7:21 ` Mike Rapoport
2025-08-28 7:21 ` Mike Rapoport
2025-08-28 7:44 ` David Hildenbrand [this message]
2025-08-28 7:44 ` David Hildenbrand
2025-08-28 8:06 ` Mike Rapoport
2025-08-28 8:06 ` Mike Rapoport
2025-08-28 8:18 ` David Hildenbrand
2025-08-28 8:18 ` David Hildenbrand
2025-08-28 8:37 ` Mike Rapoport
2025-08-28 8:37 ` Mike Rapoport
2025-08-29 12:00 ` David Hildenbrand
2025-08-29 12:00 ` David Hildenbrand
2025-08-28 15:37 ` Lorenzo Stoakes
2025-08-28 15:37 ` Lorenzo Stoakes
2025-08-29 11:59 ` David Hildenbrand
2025-08-29 11:59 ` David Hildenbrand
2025-08-29 12:02 ` Lorenzo Stoakes
2025-08-29 12:02 ` Lorenzo Stoakes
2025-08-29 14:57 ` Liam R. Howlett
2025-08-29 14:57 ` Liam R. Howlett
2025-08-27 22:01 ` [PATCH v1 14/36] mm/mm/percpu-km: drop nth_page() usage within single allocation David Hildenbrand
2025-08-27 22:01 ` David Hildenbrand
2025-08-28 15:43 ` Lorenzo Stoakes
2025-08-28 15:43 ` Lorenzo Stoakes
2025-08-29 14:59 ` Liam R. Howlett
2025-08-29 14:59 ` Liam R. Howlett
2025-08-27 22:01 ` [PATCH v1 15/36] fs: hugetlbfs: remove nth_page() usage within folio in adjust_range_hwpoison() David Hildenbrand
2025-08-27 22:01 ` David Hildenbrand
2025-08-28 1:14 ` [PATCH v1 15/36] " Zi Yan
2025-08-28 1:14 ` Zi Yan
2025-08-28 15:45 ` [PATCH v1 15/36] fs: " Lorenzo Stoakes
2025-08-28 15:45 ` Lorenzo Stoakes
2025-08-29 12:02 ` David Hildenbrand
2025-08-29 12:02 ` David Hildenbrand
2025-08-29 12:09 ` Lorenzo Stoakes
2025-08-29 12:09 ` Lorenzo Stoakes
2025-08-27 22:01 ` [PATCH v1 16/36] fs: hugetlbfs: cleanup " David Hildenbrand
2025-08-27 22:01 ` David Hildenbrand
2025-08-28 1:18 ` [PATCH v1 16/36] " Zi Yan
2025-08-28 1:18 ` Zi Yan
2025-08-28 16:20 ` [PATCH v1 16/36] fs: " Lorenzo Stoakes
2025-08-28 16:20 ` Lorenzo Stoakes
2025-08-29 13:22 ` David Hildenbrand
2025-08-29 13:22 ` David Hildenbrand
2025-08-27 22:01 ` [PATCH v1 17/36] mm/pagewalk: drop nth_page() usage within folio in folio_walk_start() David Hildenbrand
2025-08-27 22:01 ` David Hildenbrand
2025-08-28 16:21 ` Lorenzo Stoakes
2025-08-28 16:21 ` Lorenzo Stoakes
2025-08-29 15:11 ` Liam R. Howlett
2025-08-29 15:11 ` Liam R. Howlett
2025-08-27 22:01 ` [PATCH v1 18/36] mm/gup: drop nth_page() usage within folio when recording subpages David Hildenbrand
2025-08-27 22:01 ` David Hildenbrand
2025-08-28 16:37 ` Lorenzo Stoakes
2025-08-28 16:37 ` Lorenzo Stoakes
2025-08-29 13:41 ` David Hildenbrand
2025-08-29 13:41 ` David Hildenbrand
2025-08-29 15:19 ` Lorenzo Stoakes
2025-08-29 15:19 ` Lorenzo Stoakes
2025-09-01 11:35 ` David Hildenbrand
2025-09-01 11:35 ` David Hildenbrand
2025-08-27 22:01 ` [PATCH v1 19/36] io_uring/zcrx: remove nth_page() usage within folio David Hildenbrand
2025-08-27 22:01 ` David Hildenbrand
2025-08-28 16:48 ` Lorenzo Stoakes
2025-08-28 16:48 ` Lorenzo Stoakes
2025-08-27 22:01 ` [PATCH v1 20/36] mips: mm: convert __flush_dcache_pages() to __flush_dcache_folio_pages() David Hildenbrand
2025-08-27 22:01 ` David Hildenbrand
2025-08-28 16:57 ` Lorenzo Stoakes
2025-08-28 16:57 ` Lorenzo Stoakes
2025-08-28 20:51 ` David Hildenbrand
2025-08-28 20:51 ` David Hildenbrand
2025-08-29 12:51 ` Lorenzo Stoakes
2025-08-29 12:51 ` Lorenzo Stoakes
2025-08-29 13:44 ` David Hildenbrand
2025-08-29 13:44 ` David Hildenbrand
2025-08-29 14:45 ` Lorenzo Stoakes
2025-08-29 14:45 ` Lorenzo Stoakes
2025-08-27 22:01 ` [PATCH v1 21/36] mm/cma: refuse handing out non-contiguous page ranges David Hildenbrand
2025-08-27 22:01 ` David Hildenbrand
2025-08-28 17:28 ` Lorenzo Stoakes
2025-08-28 17:28 ` Lorenzo Stoakes
2025-08-29 14:34 ` David Hildenbrand
2025-08-29 14:34 ` David Hildenbrand
2025-08-29 14:44 ` Lorenzo Stoakes
2025-08-29 14:44 ` Lorenzo Stoakes
2025-08-27 22:01 ` [PATCH v1 22/36] dma-remap: drop nth_page() in dma_common_contiguous_remap() David Hildenbrand
2025-08-27 22:01 ` David Hildenbrand
2025-08-28 17:29 ` Lorenzo Stoakes
2025-08-28 17:29 ` Lorenzo Stoakes
2025-08-27 22:01 ` [PATCH v1 23/36] scatterlist: disallow non-contigous page ranges in a single SG entry David Hildenbrand
2025-08-27 22:01 ` David Hildenbrand
2025-08-28 17:53 ` Lorenzo Stoakes
2025-08-28 17:53 ` Lorenzo Stoakes
2025-08-27 22:01 ` [PATCH v1 24/36] ata: libata-eh: drop nth_page() usage within " David Hildenbrand
2025-08-27 22:01 ` David Hildenbrand
2025-08-28 4:24 ` Damien Le Moal
2025-08-28 4:24 ` Damien Le Moal
2025-08-28 17:53 ` Lorenzo Stoakes
2025-08-28 17:53 ` Lorenzo Stoakes
2025-08-29 0:22 ` Damien Le Moal
2025-08-29 0:22 ` Damien Le Moal
2025-08-29 14:37 ` David Hildenbrand
2025-08-29 14:37 ` David Hildenbrand
2025-08-27 22:01 ` [PATCH v1 25/36] drm/i915/gem: " David Hildenbrand
2025-08-27 22:01 ` David Hildenbrand
2025-08-28 17:55 ` Lorenzo Stoakes
2025-08-28 17:55 ` Lorenzo Stoakes
2025-08-27 22:01 ` [PATCH v1 26/36] mspro_block: " David Hildenbrand
2025-08-27 22:01 ` David Hildenbrand
2025-08-28 17:56 ` Lorenzo Stoakes
2025-08-28 17:56 ` Lorenzo Stoakes
2025-08-27 22:01 ` [PATCH v1 27/36] memstick: " David Hildenbrand
2025-08-27 22:01 ` David Hildenbrand
2025-08-28 17:57 ` Lorenzo Stoakes
2025-08-28 17:57 ` Lorenzo Stoakes
2025-08-27 22:01 ` [PATCH v1 28/36] mmc: " David Hildenbrand
2025-08-27 22:01 ` David Hildenbrand
2025-08-28 17:59 ` Lorenzo Stoakes
2025-08-28 17:59 ` Lorenzo Stoakes
2025-08-27 22:01 ` [PATCH v1 29/36] scsi: scsi_lib: " David Hildenbrand
2025-08-27 22:01 ` David Hildenbrand
2025-08-28 18:00 ` Lorenzo Stoakes
2025-08-28 18:00 ` Lorenzo Stoakes
2025-08-31 1:03 ` Martin K. Petersen
2025-08-31 1:03 ` Martin K. Petersen
2025-08-27 22:01 ` [PATCH v1 30/36] scsi: sg: " David Hildenbrand
2025-08-27 22:01 ` David Hildenbrand
2025-08-28 18:00 ` Lorenzo Stoakes
2025-08-28 18:00 ` Lorenzo Stoakes
2025-08-31 1:04 ` Martin K. Petersen
2025-08-31 1:04 ` Martin K. Petersen
2025-08-27 22:01 ` [PATCH v1 31/36] vfio/pci: " David Hildenbrand
2025-08-27 22:01 ` David Hildenbrand
2025-08-28 18:01 ` Lorenzo Stoakes
2025-08-28 18:01 ` Lorenzo Stoakes
2025-08-28 18:52 ` Alex Williamson
2025-08-28 18:52 ` Alex Williamson
2025-08-28 20:15 ` Brett Creeley
2025-08-28 20:15 ` Brett Creeley
2025-08-27 22:01 ` [PATCH v1 32/36] crypto: remove " David Hildenbrand
2025-08-27 22:01 ` David Hildenbrand
2025-08-28 18:02 ` Lorenzo Stoakes
2025-08-28 18:02 ` Lorenzo Stoakes
2025-08-30 8:50 ` Herbert Xu
2025-08-30 8:50 ` Herbert Xu
2025-08-27 22:01 ` [PATCH v1 33/36] mm/gup: drop nth_page() usage in unpin_user_page_range_dirty_lock() David Hildenbrand
2025-08-27 22:01 ` David Hildenbrand
2025-08-28 18:09 ` Lorenzo Stoakes
2025-08-28 18:09 ` Lorenzo Stoakes
2025-08-29 14:41 ` David Hildenbrand
2025-08-29 14:41 ` David Hildenbrand
2025-08-27 22:01 ` [PATCH v1 34/36] kfence: drop nth_page() usage David Hildenbrand
2025-08-27 22:01 ` David Hildenbrand
2025-08-28 8:43 ` Marco Elver
2025-08-28 8:43 ` Marco Elver
2025-08-28 18:19 ` Lorenzo Stoakes
2025-08-28 18:19 ` Lorenzo Stoakes
2025-08-27 22:01 ` [PATCH v1 35/36] block: update comment of "struct bio_vec" regarding nth_page() David Hildenbrand
2025-08-27 22:01 ` David Hildenbrand
2025-08-28 18:19 ` Lorenzo Stoakes
2025-08-28 18:19 ` Lorenzo Stoakes
2025-08-27 22:01 ` [PATCH v1 36/36] mm: remove nth_page() David Hildenbrand
2025-08-27 22:01 ` David Hildenbrand
2025-08-28 18:25 ` Lorenzo Stoakes
2025-08-28 18:25 ` Lorenzo Stoakes
2025-08-29 14:42 ` David Hildenbrand
2025-08-29 14:42 ` David Hildenbrand
2025-08-28 14:34 ` ✓ i915.CI.BAT: success for series starting with [v1,01/36] mm: stop making SPARSEMEM_VMEMMAP user-selectable Patchwork
2025-08-28 19:55 ` ✗ i915.CI.Full: failure for mm: remove nth_page() Patchwork
2025-08-29 15:28 ` ✗ Fi.CI.BUILD: failure for mm: remove nth_page() (rev3) Patchwork
2025-09-01 12:43 ` ✗ Fi.CI.BUILD: failure for mm: remove nth_page() (rev4) Patchwork
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=377449bd-3c06-4a09-8647-e41354e64b30@redhat.com \
--to=david@redhat.com \
--cc=Liam.Howlett@oracle.com \
--cc=akpm@linux-foundation.org \
--cc=axboe@kernel.dk \
--cc=cl@gentwo.org \
--cc=dennis@kernel.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=dvyukov@google.com \
--cc=elver@google.com \
--cc=glider@google.com \
--cc=hannes@cmpxchg.org \
--cc=intel-gfx@lists.freedesktop.org \
--cc=io-uring@vger.kernel.org \
--cc=iommu@lists.linux.dev \
--cc=jackmanb@google.com \
--cc=jgg@nvidia.com \
--cc=jhubbard@nvidia.com \
--cc=kasan-dev@googlegroups.com \
--cc=kvm@vger.kernel.org \
--cc=linux-arm-kernel@axis.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-crypto@vger.kernel.org \
--cc=linux-ide@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=linux-mips@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-mmc@vger.kernel.org \
--cc=linux-riscv@lists.infradead.org \
--cc=linux-s390@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=lorenzo.stoakes@oracle.com \
--cc=m.szyprowski@samsung.com \
--cc=mhocko@suse.com \
--cc=muchun.song@linux.dev \
--cc=netdev@vger.kernel.org \
--cc=osalvador@suse.de \
--cc=peterx@redhat.com \
--cc=robin.murphy@arm.com \
--cc=rppt@kernel.org \
--cc=surenb@google.com \
--cc=tj@kernel.org \
--cc=torvalds@linux-foundation.org \
--cc=vbabka@suse.cz \
--cc=virtualization@lists.linux.dev \
--cc=wireguard@lists.zx2c4.com \
--cc=x86@kernel.org \
--cc=ziy@nvidia.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.