Re: [PATCH v1 10/36] mm: sanity-check maximum folio size in folio_set_order()
Lorenzo Stoakes <[email protected]> Fri, 29 Aug 2025 13:18:05 +0100
| 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 Fri, Aug 29, 2025 at 12:10:30PM +0200, David Hildenbrand wrote: > 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. Thanks! > > > > > > > > > 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. Ack, ok. I don't think vital for this series though! > > -- > Cheers > > David / dhildenb > Cheers, Lorenzo