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; ? > > -- > Cheers, > > David / dhildenb >
