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 14:53, Christoph Hellwig wrote:
On Mon, Aug 19, 2024 at 02:51:06PM +0200, David Hildenbrand 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.

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

Well, the only way to do that is to remove (__)GFP_NOFAIL and require
either explicit _nofail variants without a way to pass gfp flags, or
endless loops in the callers.  I suggested the first one earlier, but
no one liked it due to the API complexity and overhead.  And I've not
heard anyone arguing for the latter yet.

Right, and and "allocate more than even possible" case is extremely ugly.


One other way might be a compile time check that requires any GPF
flag that contains (__)GFP_NOFAIL to be a compile time constants.
This is true for many but not all callers currently.

Right.

--
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