On Thu 29-08-24 07:55:08, Kent Overstreet wrote: > 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. Unfortunately a lack of __GFP_DIRECT_RECLAIM means both no reclaim and no sleeping allowed for historical reasons. GFP_NOWAIT is both used from atomic contexts and as an optimistic allocation attempt with a heavier fallback allocation strategy. If you want NORECLAIM semantic then this would need to be represented by different means than __GFP_DIRECT_RECLAIM alone. > 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. If your definition of safe includes an oops or worse silent failure then yes. Not really safe interface in my book though. E.g. (just randomly looking at GFP_NOFAIL users) btree_paths_realloc doesn't check the return value and if it happened to be called from such a scope it would have blown up. That code is safe without the scope though. There are many other callsites which do not have failure paths. -- Michal Hocko SUSE Labs
