Skip to content

[PW_SID:994288] mm: remove nth_page() - #821

Closed
linux-riscv-bot wants to merge 35 commits into
workflow__riscv__fixesfrom
pw994288
Closed

[PW_SID:994288] mm: remove nth_page()#821
linux-riscv-bot wants to merge 35 commits into
workflow__riscv__fixesfrom
pw994288

Conversation

@linux-riscv-bot

@linux-riscv-bot linux-riscv-bot commented Aug 22, 2025

Copy link
Copy Markdown

PR for series 994288 applied to workflow__riscv__fixes

Name: mm: remove nth_page()
URL: https://patchwork.kernel.org/project/linux-riscv/list/?series=994288
Version: 1

David Hildenbrand added 30 commits August 22, 2025 03:35
David Hildenbrand Linux RISC-V bot
mm: stop making SPARSEMEM_VMEMMAP user-selectable
54bb1da 
In an ideal world, we wouldn't have to deal with SPARSEMEM without
SPARSEMEM_VMEMMAP, but in particular for 32bit SPARSEMEM_VMEMMAP is
considered too costly and consequently not supported.

However, if an architecture does support SPARSEMEM with
SPARSEMEM_VMEMMAP, let's forbid the user to disable VMEMMAP: just
like we already do for arm64, s390 and x86.

So if SPARSEMEM_VMEMMAP is supported, don't allow to use SPARSEMEM without
SPARSEMEM_VMEMMAP.

This implies that the option to not use SPARSEMEM_VMEMMAP will now be
gone for loongarch, powerpc, riscv and sparc. All architectures only
enable SPARSEMEM_VMEMMAP with 64bit support, so there should not really
be a big downside to using the VMEMMAP (quite the contrary).

This is a preparation for not supporting

(1) folio sizes that exceed a single memory section
(2) CMA allocations of non-contiguous page ranges

in SPARSEMEM without SPARSEMEM_VMEMMAP configs, whereby we
want to limit possible impact as much as possible (e.g., gigantic hugetlb
page allocations suddenly fails).

Cc: Huacai Chen <chenhuacai@kernel.org>
Cc: WANG Xuerui <kernel@xen0n.name>
Cc: Madhavan Srinivasan <maddy@linux.ibm.com>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Nicholas Piggin <npiggin@gmail.com>
Cc: Christophe Leroy <christophe.leroy@csgroup.eu>
Cc: Paul Walmsley <paul.walmsley@sifive.com>
Cc: Palmer Dabbelt <palmer@dabbelt.com>
Cc: Albert Ou <aou@eecs.berkeley.edu>
Cc: Alexandre Ghiti <alex@ghiti.fr>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Andreas Larsson <andreas@gaisler.com>
Signed-off-by: David Hildenbrand <david@redhat.com>
Acked-by: Zi Yan <ziy@nvidia.com>
Signed-off-by: Linux RISC-V bot <linux.riscv.bot@gmail.com>
David Hildenbrand Linux RISC-V bot
arm64: Kconfig: drop superfluous "select SPARSEMEM_VMEMMAP"
c4445b7 
Now handled by the core automatically once SPARSEMEM_VMEMMAP_ENABLE
is selected.

Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will@kernel.org>
Signed-off-by: David Hildenbrand <david@redhat.com>
Signed-off-by: Linux RISC-V bot <linux.riscv.bot@gmail.com>
David Hildenbrand Linux RISC-V bot
s390/Kconfig: drop superfluous "select SPARSEMEM_VMEMMAP"
81bfc53 
Now handled by the core automatically once SPARSEMEM_VMEMMAP_ENABLE
is selected.

Cc: Heiko Carstens <hca@linux.ibm.com>
Cc: Vasily Gorbik <gor@linux.ibm.com>
Cc: Alexander Gordeev <agordeev@linux.ibm.com>
Cc: Christian Borntraeger <borntraeger@linux.ibm.com>
Cc: Sven Schnelle <svens@linux.ibm.com>
Signed-off-by: David Hildenbrand <david@redhat.com>
Signed-off-by: Linux RISC-V bot <linux.riscv.bot@gmail.com>
David Hildenbrand Linux RISC-V bot
x86/Kconfig: drop superfluous "select SPARSEMEM_VMEMMAP"
b7144a2 
Now handled by the core automatically once SPARSEMEM_VMEMMAP_ENABLE
is selected.

Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Dave Hansen <dave.hansen@linux.intel.com>
Signed-off-by: David Hildenbrand <david@redhat.com>
Signed-off-by: Linux RISC-V bot <linux.riscv.bot@gmail.com>
David Hildenbrand Linux RISC-V bot
wireguard: selftests: remove CONFIG_SPARSEMEM_VMEMMAP=y from qemu ker…
b630b5c 
…nel config

It's no longer user-selectable (and the default was already "y"), so
let's just drop it.

Cc: "Jason A. Donenfeld" <Jason@zx2c4.com>
Cc: Shuah Khan <shuah@kernel.org>
Signed-off-by: David Hildenbrand <david@redhat.com>
Signed-off-by: Linux RISC-V bot <linux.riscv.bot@gmail.com>
David Hildenbrand Linux RISC-V bot
mm/page_alloc: reject unreasonable folio/compound page sizes in alloc…
a72b49f 
…_contig_range_noprof()

Let's reject them early, which in turn makes folio_alloc_gigantic() reject
them properly.

To avoid converting from order to nr_pages, let's just add MAX_FOLIO_ORDER
and calculate MAX_FOLIO_NR_PAGES based on that.

Signed-off-by: David Hildenbrand <david@redhat.com>
Signed-off-by: Linux RISC-V bot <linux.riscv.bot@gmail.com>
David Hildenbrand Linux RISC-V bot
mm/memremap: reject unreasonable folio/compound page sizes in memrema…
d524c87 
…p_pages()

Let's reject unreasonable folio sizes early, where we can still fail.
We'll add sanity checks to prepare_compound_head/prepare_compound_page
next.

Is there a way to configure a system such that unreasonable folio sizes
would be possible? It would already be rather questionable.

If so, we'd probably want to bail out earlier, where we can avoid a
WARN and just report a proper error message that indicates where
something went wrong such that we messed up.

Signed-off-by: David Hildenbrand <david@redhat.com>
Signed-off-by: Linux RISC-V bot <linux.riscv.bot@gmail.com>
David Hildenbrand Linux RISC-V bot
mm/hugetlb: check for unreasonable folio sizes when registering hstate
b1263dd 
Let's check that no hstate that corresponds to an unreasonable folio size
is registered by an architecture. If we were to succeed registering, we
could later try allocating an unsupported gigantic folio size.

Further, let's add a BUILD_BUG_ON() for checking that HUGETLB_PAGE_ORDER
is sane at build time. As HUGETLB_PAGE_ORDER is dynamic on powerpc, we have
to use a BUILD_BUG_ON_INVALID() to make it compile.

No existing kernel configuration should be able to trigger this check:
either SPARSEMEM without SPARSEMEM_VMEMMAP cannot be configured or
gigantic folios will not exceed a memory section (the case on sparse).

Signed-off-by: David Hildenbrand <david@redhat.com>
Signed-off-by: Linux RISC-V bot <linux.riscv.bot@gmail.com>
David Hildenbrand Linux RISC-V bot
mm/mm_init: make memmap_init_compound() look more like prep_compound_…
d17bbac 
…page()

Grepping for "prep_compound_page" leaves on clueless how devdax gets its
compound pages initialized.

Let's add a comment that might help finding this open-coded
prep_compound_page() initialization more easily.

Further, let's be less smart about the ordering of initialization and just
perform the prep_compound_head() call after all tail pages were
initialized: just like prep_compound_page() does.

No need for a lengthy comment then: again, just like prep_compound_page().

Note that prep_compound_head() already does initialize stuff in page[2]
through prep_compound_head() that successive tail page initialization
will overwrite: _deferred_list, and on 32bit _entire_mapcount and
_pincount. Very likely 32bit does not apply, and likely nobody ever ends
up testing whether the _deferred_list is empty.

So it shouldn't be a fix at this point, but certainly something to clean
up.

Signed-off-by: David Hildenbrand <david@redhat.com>
Signed-off-by: Linux RISC-V bot <linux.riscv.bot@gmail.com>
David Hildenbrand Linux RISC-V bot
mm/hugetlb: cleanup hugetlb_folio_init_tail_vmemmap()
b961663 
All pages were already initialized and set to PageReserved() with a
refcount of 1 by MM init code.

In fact, by using __init_single_page(), we will be setting the refcount to
1 just to freeze it again immediately afterwards.

So drop the __init_single_page() and use __ClearPageReserved() instead.
Adjust the comments to highlight that we are dealing with an open-coded
prep_compound_page() variant.

Further, as we can now safely iterate over all pages in a folio, let's
avoid the page-pfn dance and just iterate the pages directly.

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>
Signed-off-by: Linux RISC-V bot <linux.riscv.bot@gmail.com>
David Hildenbrand Linux RISC-V bot
mm: sanity-check maximum folio size in folio_set_order()
60edbab 
Let's sanity-check in folio_set_order() whether we would be trying to
create a folio with an order that would make it exceed MAX_FOLIO_ORDER.

This will enable the check whenever a folio/compound page is initialized
through prepare_compound_head() / prepare_compound_page().

Signed-off-by: David Hildenbrand <david@redhat.com>
Signed-off-by: Linux RISC-V bot <linux.riscv.bot@gmail.com>
David Hildenbrand Linux RISC-V bot
mm: limit folio/compound page sizes in problematic kernel configs
1eb66d6 
Let's limit the maximum folio size in problematic kernel config where
the memmap is allocated per memory section (SPARSEMEM without
SPARSEMEM_VMEMMAP) to a single memory section.

Currently, only a single architectures supports ARCH_HAS_GIGANTIC_PAGE
but not SPARSEMEM_VMEMMAP: sh.

Fortunately, the biggest hugetlb size sh supports is 64 MiB
(HUGETLB_PAGE_SIZE_64MB) and the section size is at least 64 MiB
(SECTION_SIZE_BITS == 26), so their use case is not degraded.

As folios and memory sections are naturally aligned to their order-2 size
in memory, consequently a single folio can no longer span multiple memory
sections on these problematic kernel configs.

nth_page() is no longer required when operating within a single compound
page / folio.

Signed-off-by: David Hildenbrand <david@redhat.com>
Signed-off-by: Linux RISC-V bot <linux.riscv.bot@gmail.com>
David Hildenbrand Linux RISC-V bot
mm: simplify folio_page() and folio_page_idx()
15d6dde 
Now that a single folio/compound page can no longer span memory sections
in problematic kernel configurations, we can stop using nth_page().

While at it, turn both macros into static inline functions and add
kernel doc for folio_page_idx().

Signed-off-by: David Hildenbrand <david@redhat.com>
Signed-off-by: Linux RISC-V bot <linux.riscv.bot@gmail.com>
David Hildenbrand Linux RISC-V bot
mm/mm/percpu-km: drop nth_page() usage within single allocation
6f47b5b 
We're allocating a higher-order page from the buddy. For these pages
(that are guaranteed to not exceed a single memory section) there is no
need to use nth_page().

Signed-off-by: David Hildenbrand <david@redhat.com>
Signed-off-by: Linux RISC-V bot <linux.riscv.bot@gmail.com>
David Hildenbrand Linux RISC-V bot
fs: hugetlbfs: remove nth_page() usage within folio in adjust_range_h…
d2ee790 
…wpoison()

The nth_page() is not really required anymore, so let's remove it.
While at it, cleanup and simplify the code a bit.

Signed-off-by: David Hildenbrand <david@redhat.com>
Signed-off-by: Linux RISC-V bot <linux.riscv.bot@gmail.com>
David Hildenbrand Linux RISC-V bot
mm/pagewalk: drop nth_page() usage within folio in folio_walk_start()
15008ee 
It's no longer required to use nth_page() within a folio, so let's just
drop the nth_page() in folio_walk_start().

Signed-off-by: David Hildenbrand <david@redhat.com>
Signed-off-by: Linux RISC-V bot <linux.riscv.bot@gmail.com>
David Hildenbrand Linux RISC-V bot
mm/gup: drop nth_page() usage within folio when recording subpages
bb4a02d 
nth_page() is no longer required when iterating over pages within a
single folio, so let's just drop it when recording subpages.

Signed-off-by: David Hildenbrand <david@redhat.com>
Signed-off-by: Linux RISC-V bot <linux.riscv.bot@gmail.com>
David Hildenbrand Linux RISC-V bot
io_uring/zcrx: remove "struct io_copy_cache" and one nth_page() usage
86b6e33 
We always provide a single dst page, it's unclear why the io_copy_cache
complexity is required.

So let's simplify and get rid of "struct io_copy_cache", simply working on
the single page.

... which immediately allows us for dropping one "nth_page" usage,
because it's really just a single page.

Cc: Jens Axboe <axboe@kernel.dk>
Signed-off-by: David Hildenbrand <david@redhat.com>
Signed-off-by: Linux RISC-V bot <linux.riscv.bot@gmail.com>
David Hildenbrand Linux RISC-V bot
io_uring/zcrx: remove nth_page() usage within folio
4fe1759 
Within a folio/compound page, nth_page() is no longer required.
Given that we call folio_test_partial_kmap()+kmap_local_page(), the code
would already be problematic if the src_pages would span multiple folios.

So let's just assume that all src pages belong to a single
folio/compound page and can be iterated ordinarily.

Cc: Jens Axboe <axboe@kernel.dk>
Signed-off-by: David Hildenbrand <david@redhat.com>
Signed-off-by: Linux RISC-V bot <linux.riscv.bot@gmail.com>
David Hildenbrand Linux RISC-V bot
mips: mm: convert __flush_dcache_pages() to __flush_dcache_folio_pages()
340eab8 
Let's make it clearer that we are operating within a single folio by
providing both the folio and the page.

This implies that for flush_dcache_folio() we'll now avoid one more
page->folio lookup, and that we can safely drop the "nth_page" usage.

Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
Signed-off-by: David Hildenbrand <david@redhat.com>
Signed-off-by: Linux RISC-V bot <linux.riscv.bot@gmail.com>
David Hildenbrand Linux RISC-V bot
mm/cma: refuse handing out non-contiguous page ranges
3664eb8 
Let's disallow handing out PFN ranges with non-contiguous pages, so we
can remove the nth-page usage in __cma_alloc(), and so any callers don't
have to worry about that either when wanting to blindly iterate pages.

This is really only a problem in configs with SPARSEMEM but without
SPARSEMEM_VMEMMAP, and only when we would cross memory sections in some
cases.

Will this cause harm? Probably not, because it's mostly 32bit that does
not support SPARSEMEM_VMEMMAP. If this ever becomes a problem we could
look into allocating the memmap for the memory sections spanned by a
single CMA region in one go from memblock.

Signed-off-by: David Hildenbrand <david@redhat.com>
Signed-off-by: Linux RISC-V bot <linux.riscv.bot@gmail.com>
David Hildenbrand Linux RISC-V bot
dma-remap: drop nth_page() in dma_common_contiguous_remap()
57fa0ab 
dma_common_contiguous_remap() is used to remap an "allocated contiguous
region". Within a single allocation, there is no need to use nth_page()
anymore.

Neither the buddy, nor hugetlb, nor CMA will hand out problematic page
ranges.

Cc: Marek Szyprowski <m.szyprowski@samsung.com>
Cc: Robin Murphy <robin.murphy@arm.com>
Signed-off-by: David Hildenbrand <david@redhat.com>
Signed-off-by: Linux RISC-V bot <linux.riscv.bot@gmail.com>
David Hildenbrand Linux RISC-V bot
scatterlist: disallow non-contigous page ranges in a single SG entry
e0eb43d 
The expectation is that there is currently no user that would pass in
non-contigous page ranges: no allocator, not even VMA, will hand these
out.

The only problematic part would be if someone would provide a range
obtained directly from memblock, or manually merge problematic ranges.
If we find such cases, we should fix them to create separate
SG entries.

Let's check in sg_set_page() that this is really the case. No need to
check in sg_set_folio(), as pages in a folio are guaranteed to be
contiguous.

We can now drop the nth_page() usage in sg_page_iter_page().

Signed-off-by: David Hildenbrand <david@redhat.com>
Signed-off-by: Linux RISC-V bot <linux.riscv.bot@gmail.com>
David Hildenbrand Linux RISC-V bot
ata: libata-eh: drop nth_page() usage within SG entry
04fb34d 
It's no longer required to use nth_page() when iterating pages within a
single SG entry, so let's drop the nth_page() usage.

Cc: Damien Le Moal <dlemoal@kernel.org>
Cc: Niklas Cassel <cassel@kernel.org>
Signed-off-by: David Hildenbrand <david@redhat.com>
Signed-off-by: Linux RISC-V bot <linux.riscv.bot@gmail.com>
David Hildenbrand Linux RISC-V bot
drm/i915/gem: drop nth_page() usage within SG entry
383fc75 
It's no longer required to use nth_page() when iterating pages within a
single SG entry, so let's drop the nth_page() usage.

Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Tvrtko Ursulin <tursulin@ursulin.net>
Cc: David Airlie <airlied@gmail.com>
Cc: Simona Vetter <simona@ffwll.ch>
Signed-off-by: David Hildenbrand <david@redhat.com>
Signed-off-by: Linux RISC-V bot <linux.riscv.bot@gmail.com>
David Hildenbrand Linux RISC-V bot
mspro_block: drop nth_page() usage within SG entry
e6bdc45 
It's no longer required to use nth_page() when iterating pages within a
single SG entry, so let's drop the nth_page() usage.

Cc: Maxim Levitsky <maximlevitsky@gmail.com>
Cc: Alex Dubov <oakad@yahoo.com>
Cc: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: David Hildenbrand <david@redhat.com>
Signed-off-by: Linux RISC-V bot <linux.riscv.bot@gmail.com>
David Hildenbrand Linux RISC-V bot
memstick: drop nth_page() usage within SG entry
f121955 
It's no longer required to use nth_page() when iterating pages within a
single SG entry, so let's drop the nth_page() usage.

Cc: Maxim Levitsky <maximlevitsky@gmail.com>
Cc: Alex Dubov <oakad@yahoo.com>
Cc: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: David Hildenbrand <david@redhat.com>
Signed-off-by: Linux RISC-V bot <linux.riscv.bot@gmail.com>
David Hildenbrand Linux RISC-V bot
mmc: drop nth_page() usage within SG entry
1715023 
It's no longer required to use nth_page() when iterating pages within a
single SG entry, so let's drop the nth_page() usage.

Cc: Alex Dubov <oakad@yahoo.com>
Cc: Ulf Hansson <ulf.hansson@linaro.org>
Cc: Jesper Nilsson <jesper.nilsson@axis.com>
Cc: Lars Persson <lars.persson@axis.com>
Signed-off-by: David Hildenbrand <david@redhat.com>
Signed-off-by: Linux RISC-V bot <linux.riscv.bot@gmail.com>
David Hildenbrand Linux RISC-V bot
scsi: core: drop nth_page() usage within SG entry
1795475 
It's no longer required to use nth_page() when iterating pages within a
single SG entry, so let's drop the nth_page() usage.

Cc: "James E.J. Bottomley" <James.Bottomley@HansenPartnership.com>
Cc: "Martin K. Petersen" <martin.petersen@oracle.com>
Cc: Doug Gilbert <dgilbert@interlog.com>
Signed-off-by: David Hildenbrand <david@redhat.com>
Signed-off-by: Linux RISC-V bot <linux.riscv.bot@gmail.com>
David Hildenbrand Linux RISC-V bot
vfio/pci: drop nth_page() usage within SG entry
f39a574 
It's no longer required to use nth_page() when iterating pages within a
single SG entry, so let's drop the nth_page() usage.

Cc: Brett Creeley <brett.creeley@amd.com>
Cc: Jason Gunthorpe <jgg@ziepe.ca>
Cc: Yishai Hadas <yishaih@nvidia.com>
Cc: Shameer Kolothum <shameerali.kolothum.thodi@huawei.com>
Cc: Kevin Tian <kevin.tian@intel.com>
Cc: Alex Williamson <alex.williamson@redhat.com>
Signed-off-by: David Hildenbrand <david@redhat.com>
Signed-off-by: Linux RISC-V bot <linux.riscv.bot@gmail.com>
@linux-riscv-bot

linux-riscv-bot commented Aug 23, 2025

Copy link
Copy Markdown
Author

Patch 33: "[RFC,33/35] kfence: drop nth_page() usage"
kdoc
Desc: Detects for kdoc errors
Duration: 0.87 seconds
Result: PASS

@linux-riscv-bot

linux-riscv-bot commented Aug 23, 2025

Copy link
Copy Markdown
Author

Patch 33: "[RFC,33/35] kfence: drop nth_page() usage"
module-param
Desc: Detect module_param changes
Duration: 0.27 seconds
Result: PASS

@linux-riscv-bot

linux-riscv-bot commented Aug 23, 2025

Copy link
Copy Markdown
Author

Patch 33: "[RFC,33/35] kfence: drop nth_page() usage"
verify-fixes
Desc: Verifies that the Fixes: tags exist
Duration: 0.23 seconds
Result: PASS

@linux-riscv-bot

linux-riscv-bot commented Aug 23, 2025

Copy link
Copy Markdown
Author

Patch 33: "[RFC,33/35] kfence: drop nth_page() usage"
verify-signedoff
Desc: Verifies that Signed-off-by: tags are correct
Duration: 0.32 seconds
Result: PASS

@linux-riscv-bot

linux-riscv-bot commented Aug 23, 2025

Copy link
Copy Markdown
Author

Patch 34: "[RFC,34/35] block: update comment of "struct bio_vec" regarding nth_page()"
build-rv32-defconfig
Desc: Builds riscv32 defconfig
Duration: 111.33 seconds
Result: PASS

@linux-riscv-bot

linux-riscv-bot commented Aug 23, 2025

Copy link
Copy Markdown
Author

Patch 34: "[RFC,34/35] block: update comment of "struct bio_vec" regarding nth_page()"
build-rv64-clang-allmodconfig
Desc: Builds riscv64 allmodconfig with Clang, and checks for errors and added warnings
Duration: 1936.79 seconds
Result: PASS

@linux-riscv-bot

linux-riscv-bot commented Aug 23, 2025

Copy link
Copy Markdown
Author

Patch 34: "[RFC,34/35] block: update comment of "struct bio_vec" regarding nth_page()"
build-rv64-gcc-allmodconfig
Desc: Builds riscv64 allmodconfig with GCC, and checks for errors and added warnings
Duration: 2604.29 seconds
Result: PASS

@linux-riscv-bot

linux-riscv-bot commented Aug 23, 2025

Copy link
Copy Markdown
Author

Patch 34: "[RFC,34/35] block: update comment of "struct bio_vec" regarding nth_page()"
build-rv64-nommu-k210-defconfig
Desc: Builds riscv64 defconfig with NOMMU for K210
Duration: 22.61 seconds
Result: PASS

@linux-riscv-bot

linux-riscv-bot commented Aug 23, 2025

Copy link
Copy Markdown
Author

Patch 34: "[RFC,34/35] block: update comment of "struct bio_vec" regarding nth_page()"
build-rv64-nommu-k210-virt
Desc: Builds riscv64 defconfig with NOMMU for the virt platform
Duration: 23.67 seconds
Result: PASS

@linux-riscv-bot

linux-riscv-bot commented Aug 23, 2025

Copy link
Copy Markdown
Author

Patch 34: "[RFC,34/35] block: update comment of "struct bio_vec" regarding nth_page()"
checkpatch
Desc: Runs checkpatch.pl on the patch
Duration: 0.74 seconds
Result: PASS

@linux-riscv-bot

linux-riscv-bot commented Aug 23, 2025

Copy link
Copy Markdown
Author

Patch 34: "[RFC,34/35] block: update comment of "struct bio_vec" regarding nth_page()"
dtb-warn-rv64
Desc: Checks for Device Tree warnings/errors
Duration: 79.05 seconds
Result: PASS

@linux-riscv-bot

linux-riscv-bot commented Aug 23, 2025

Copy link
Copy Markdown
Author

Patch 34: "[RFC,34/35] block: update comment of "struct bio_vec" regarding nth_page()"
header-inline
Desc: Detects static functions without inline keyword in header files
Duration: 0.23 seconds
Result: PASS

@linux-riscv-bot

linux-riscv-bot commented Aug 23, 2025

Copy link
Copy Markdown
Author

Patch 34: "[RFC,34/35] block: update comment of "struct bio_vec" regarding nth_page()"
kdoc
Desc: Detects for kdoc errors
Duration: 0.87 seconds
Result: PASS

@linux-riscv-bot

linux-riscv-bot commented Aug 23, 2025

Copy link
Copy Markdown
Author

Patch 34: "[RFC,34/35] block: update comment of "struct bio_vec" regarding nth_page()"
module-param
Desc: Detect module_param changes
Duration: 0.25 seconds
Result: PASS

@linux-riscv-bot

linux-riscv-bot commented Aug 23, 2025

Copy link
Copy Markdown
Author

Patch 34: "[RFC,34/35] block: update comment of "struct bio_vec" regarding nth_page()"
verify-fixes
Desc: Verifies that the Fixes: tags exist
Duration: 0.21 seconds
Result: PASS

@linux-riscv-bot

linux-riscv-bot commented Aug 23, 2025

Copy link
Copy Markdown
Author

Patch 34: "[RFC,34/35] block: update comment of "struct bio_vec" regarding nth_page()"
verify-signedoff
Desc: Verifies that Signed-off-by: tags are correct
Duration: 0.33 seconds
Result: PASS

@linux-riscv-bot

linux-riscv-bot commented Aug 23, 2025

Copy link
Copy Markdown
Author

Patch 35: "[RFC,35/35] mm: remove nth_page()"
build-rv32-defconfig
Desc: Builds riscv32 defconfig
Duration: 110.43 seconds
Result: PASS

@linux-riscv-bot

linux-riscv-bot commented Aug 23, 2025

Copy link
Copy Markdown
Author

Patch 35: "[RFC,35/35] mm: remove nth_page()"
build-rv64-clang-allmodconfig
Desc: Builds riscv64 allmodconfig with Clang, and checks for errors and added warnings
Duration: 2058.32 seconds
Result: PASS

@linux-riscv-bot

linux-riscv-bot commented Aug 23, 2025

Copy link
Copy Markdown
Author

Patch 35: "[RFC,35/35] mm: remove nth_page()"
build-rv64-gcc-allmodconfig
Desc: Builds riscv64 allmodconfig with GCC, and checks for errors and added warnings
Duration: 2707.48 seconds
Result: PASS

@linux-riscv-bot

linux-riscv-bot commented Aug 23, 2025

Copy link
Copy Markdown
Author

Patch 35: "[RFC,35/35] mm: remove nth_page()"
build-rv64-nommu-k210-defconfig
Desc: Builds riscv64 defconfig with NOMMU for K210
Duration: 21.87 seconds
Result: PASS

@linux-riscv-bot

linux-riscv-bot commented Aug 23, 2025

Copy link
Copy Markdown
Author

Patch 35: "[RFC,35/35] mm: remove nth_page()"
build-rv64-nommu-k210-virt
Desc: Builds riscv64 defconfig with NOMMU for the virt platform
Duration: 23.17 seconds
Result: PASS

@linux-riscv-bot

linux-riscv-bot commented Aug 23, 2025

Copy link
Copy Markdown
Author

Patch 35: "[RFC,35/35] mm: remove nth_page()"
checkpatch
Desc: Runs checkpatch.pl on the patch
Duration: 0.90 seconds
Result: PASS

@linux-riscv-bot

linux-riscv-bot commented Aug 23, 2025

Copy link
Copy Markdown
Author

Patch 35: "[RFC,35/35] mm: remove nth_page()"
dtb-warn-rv64
Desc: Checks for Device Tree warnings/errors
Duration: 80.21 seconds
Result: PASS

@linux-riscv-bot

linux-riscv-bot commented Aug 23, 2025

Copy link
Copy Markdown
Author

Patch 35: "[RFC,35/35] mm: remove nth_page()"
header-inline
Desc: Detects static functions without inline keyword in header files
Duration: 0.22 seconds
Result: PASS

@linux-riscv-bot

linux-riscv-bot commented Aug 23, 2025

Copy link
Copy Markdown
Author

Patch 35: "[RFC,35/35] mm: remove nth_page()"
kdoc
Desc: Detects for kdoc errors
Duration: 0.92 seconds
Result: PASS

@linux-riscv-bot

linux-riscv-bot commented Aug 23, 2025

Copy link
Copy Markdown
Author

Patch 35: "[RFC,35/35] mm: remove nth_page()"
module-param
Desc: Detect module_param changes
Duration: 0.26 seconds
Result: PASS

@linux-riscv-bot

linux-riscv-bot commented Aug 23, 2025

Copy link
Copy Markdown
Author

Patch 35: "[RFC,35/35] mm: remove nth_page()"
verify-fixes
Desc: Verifies that the Fixes: tags exist
Duration: 0.21 seconds
Result: PASS

@linux-riscv-bot

linux-riscv-bot commented Aug 23, 2025

Copy link
Copy Markdown
Author

Patch 35: "[RFC,35/35] mm: remove nth_page()"
verify-signedoff
Desc: Verifies that Signed-off-by: tags are correct
Duration: 0.32 seconds
Result: PASS

@linux-riscv-bot
linux-riscv-bot deleted the pw994288 branch August 29, 2025 01:02
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

1 participant

@linux-riscv-bot