Re: [PATCH bpf-next v6 0/6] bpf, mm: Introduce try_alloc_pages()

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, Jan 24, 2025 at 08:19:19AM -0800, Alexei Starovoitov wrote:
> I spotted this line:
> VM_BUG_ON_PAGE(compound && compound_order(page) != order, page);
> that line alone was a good enough reason to use __GFP_COMP,
> but since it's debug only I could only guess where the future lies.
> 
> Should it be something like:
> 
> if (WARN_ON(compound && compound_order(page) != order))
>  order = compound_order(page);
> 
> since proceeding with the wrong order is certain to crash.
> ?

It's hard to say.  We've got a discrepancy between "order at free call
site" and "order recorded in page".  We might, for example, have a
memory corruption which has overwritten the compound_order() stored in
the struct page, in which case the 'order' passed in is the correct one,
and "correcting" it to the corrupt one stored in struct page would be
the thing which caused the crash.

I'd leave it as VM_BUG_ON().




[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux