Re: [PATCH v3 3/4] mm: BUG_ON to avoid NULL deference while __GFP_NOFAIL fails

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

 



On 19.08.24 15:19, Barry Song wrote:
On Tue, Aug 20, 2024 at 1:10 AM David Hildenbrand <david@xxxxxxxxxx> wrote:

On 19.08.24 15:05, Barry Song wrote:
On Tue, Aug 20, 2024 at 12:51 AM David Hildenbrand <david@xxxxxxxxxx> wrote:

On 19.08.24 14:49, Christoph Hellwig wrote:
On Mon, Aug 19, 2024 at 02:33:06PM +0200, David Hildenbrand wrote:
It should all be caught during testing either way. And if some OOT module
does something nasty, that's not our responsibility.

BUG_ON is not a way to write assertions into the code.

So you'd rather create exploits than crashing on a fundamental API
violation?  That's exactly what the series is trying to fix.

I'd rather have a sane API that doesn't even allow this level of
flexibility with NOFAIL.

yes, i have already sent a RFC enforcing direct_reclamation:
https://www.spinics.net/lists/linux-mm/msg394659.html

somehow, it is not ready yet. i think Christoph prefers scope
api rather than GFP_NOFAIL which definitely has
__GFP_DIRECT_RECLAIM set. I guess you know I have
at least  5 series running, so it will happen soon though.

That really sounds like the right thing to do, at least with the "direct
reclaim" problem ...



But probably I'm missing more details here why this all has to be so
complicated ;)

enforcing direct_reclamation is right and will work for a reasonable size.
but for this overflow size, even if we enforce direct_reclamation
in GFP_NOFAIL, we are still failing.

Right, someone requested something completely impossible. It's harder to
do something here that doesn't return NULL. Except WARN_ON_ONCE() and
loop for all infinity.

Returning NULL can introduce security vulnerabilities. While I’m not a hacker,
it’s hard to predict how they might exploit this. If we want to avoid using
BUG_ON, an alternative approach could be as follows:

while(gfp & __GFP_NOFAIL) some_cpu_relaxed_job;    ?

At least for the "allocate something impossible in size", retrying forever makes *some* sense (with a warning, of course). We would retry until it works for sizes that are possible.

For the other case, we should just make __GFP_NOFAIL imply whatever is currently a "must". Returning NULL here is indeed strange.

--
Cheers,

David / dhildenb





[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