Re: [PATCH v1 10/36] mm: sanity-check maximum folio size in folio_set_order()
David Hildenbrand <[email protected]>
| Newsgroups | com.zx2c4.lists.wireguard,dev.linux.lists.iommu,dev.linux.lists.virtualization,org.freedesktop.lists.dri-devel,org.freedesktop.lists.intel-gfx,org.infradead.lists.linux-arm-kernel,org.infradead.lists.linux-riscv,org.kernel.vger.io-uring,org.kernel.vger.kvm,org.kernel.vger.linux-crypto,org.kernel.vger.linux-ide,org.kernel.vger.linux-kernel,org.kernel.vger.linux-kselftest,org.kernel.vger.linux-mips,org.kernel.vger.linux-mmc,org.kernel.vger.linux-s390,org.kernel.vger.linux-scsi,org.kernel.vger.netdev,org.kvack.linux-mm |
|---|---|
| Message-ID | <[email protected]> |
On 28.08.25 17:00, Lorenzo Stoakes wrote: > On Thu, Aug 28, 2025 at 12:01:14AM +0200, David Hildenbrand wrote: >> 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(). > > NIT: with CONFIG_DEBUG_VM set :) Yes, will add that. > >> >> Reviewed-by: Zi Yan <[email protected]> >> Signed-off-by: David Hildenbrand <[email protected]> > > LGTM (apart from nit below), so: > > Reviewed-by: Lorenzo Stoakes <[email protected]> > >> --- >> mm/internal.h | 1 + >> 1 file changed, 1 insertion(+) >> >> diff --git a/mm/internal.h b/mm/internal.h >> index 45da9ff5694f6..9b0129531d004 100644 >> --- a/mm/internal.h >> +++ b/mm/internal.h >> @@ -755,6 +755,7 @@ static inline void folio_set_order(struct folio *folio, unsigned int order) >> { >> if (WARN_ON_ONCE(!order || !folio_test_large(folio))) >> return; >> + VM_WARN_ON_ONCE(order > MAX_FOLIO_ORDER); > > Given we have 'full-fat' WARN_ON*()'s above, maybe worth making this one too? The idea is that if you reach this point here, previous such checks I added failed. So this is the safety net, and for that VM_WARN_ON_ONCE() is sufficient. I think we should rather convert the WARN_ON_ONCE to VM_WARN_ON_ONCE() at some point, because no sane code should ever trigger that. -- Cheers David / dhildenb