On Thu, Aug 29, 2024 at 01:08:53PM GMT, Michal Hocko wrote: > On Wed 28-08-24 18:58:43, Kent Overstreet wrote: > > On Wed, Aug 28, 2024 at 09:26:44PM GMT, Michal Hocko wrote: > > > On Wed 28-08-24 15:11:19, Kent Overstreet wrote: > [...] > > > > It was decided _years_ ago that PF_MEMALLOC flags were how this was > > > > going to be addressed. > > > > > > Nope! It has been decided that _some_ gfp flags are acceptable to be used > > > by scoped APIs. Most notably NOFS and NOIO are compatible with reclaim > > > modifiers and other flags so these are indeed safe to be used that way. > > > > Decided by who? > > Decides semantic of respective GFP flags and their compatibility with > others that could be nested in the scope. Well, that's a bit of commentary, at least. The question is which of those could properly apply to a section, not a callsite, and a PF_MEMALLOC_NOWAIT (similar to but not exactly the same as PF_MEMALLOC_NORECLAIM) would be at the top of that list since we already have a clear concept of sections where we're not allowed to sleep. And that tells us how to resolve GFP_NOFAIL with other conflicting PF_MEMALLOC flags: GFP_NOFAIL loses. It is a _bug_ if GFP_NOFAIL is accidentally used in a non sleepable context, and properly labelling those sections to the allocator would allow us to turn undefined behaviour into an error - _that_ would be turning kmalloc() into a safe interface. Ergo, if you're not absolutely sure that a GFP_NOFAIL use is safe according to call path and allocation size, you still need to be checking for failure - in the same way that you shouldn't be using BUG_ON() if you cannot prove that the condition won't occur in real wold usage. Given that, it's easy to see how to handle __GFP_RETRY_MAYFAIL and __GFP_NORETRY: if they're applied to a context, then the usage is saying "I need to attempt to run this section with some sort of latency bounds", and GFP_NOFAIL should lose - as well as emitting a warning. BTW, this is how you should be interpreting PF_MEMALLOC_NORECLAIM today: "I have strong latency bounds here, but not so strict that it needs to be strictly nonblocking".
