On Fri, Jul 19, 2024 at 10:57 PM Michal Hocko <mhocko@xxxxxxxx> wrote: > > On Fri 19-07-24 21:58:51, Barry Song wrote: > > On Fri, Jul 19, 2024 at 9:45 PM Michal Hocko <mhocko@xxxxxxxx> wrote: > > > > > > On Fri 19-07-24 21:36:38, Barry Song wrote: > > > > And I believe that even most MM experts have no idea when GFP_NOFAIL > > > > will fail. This is so bad to keep it as is. > > > > > > GFP_NOFAIL doesn't fail in any supported scenarios. We are talking how > > > to deal with those that are unsupported. I am not sure how much helpful > > > it is to document all potential gfp combinations that make no-sense. > > > > Sorry, I don't see any point from what you are saying. You are simply claiming > > this is the fault of those calling "unsupported" APIs while lacking a valid way > > to stop this from happening. Bear in mind, Everything which is not forbidden > > is allowed. > > > > I don't think maintainers outside mm know what are supported and what > > are not supported. an "unsupported" scenario can find a way to come into > > mainline easily. > > Good luck documenting all of those in a comprehensible way and > maintaining the forward. I don't mean all unsupported GFP combinations should be documented. Other unsupported scenarios can reasonably return NULL, and the caller will check the return value. So, I don't see much value in documenting them all. But GFP_NOFAIL is absolutely *different*. Callers won't check the ret. BTW, we are really exposing potential exploits. Rather than an early stage BUG_ON(), is it reasonable to BUG_ON when we really return NULL for NOFAIL at the last moment? This will crash the system but it is still safer than exposing exploits. > -- > Michal Hocko > SUSE Labs Thanks Barry
