Re: [PATCH RFC] mm: warn potential return NULL for kmalloc_array and kvmalloc_array with __GFP_NOFAIL

[Michal Hocko <mhocko@suse.com>]

On Fri 19-07-24 20:28:41, Barry Song wrote:
> On Fri, Jul 19, 2024 at 8:01 PM Michal Hocko <mhocko@suse.com> wrote:
> >
> > On Fri 19-07-24 19:51:06, Barry Song wrote:
> > > On Fri, Jul 19, 2024 at 7:42 PM Michal Hocko <mhocko@suse.com> wrote:
> > [...]
> > > > It cannot reclaim itself and it cannot sleep to wait for the memory so
> > > > NOFAIL semantic is simply impossible. We have put a warning in place to
> > >
> > > this is still "right" behaviour to retry infinitely at least according
> > > to the doc of
> > > __GFP_NOFAIL.
> >
> > I do not agree that implementing busy loop in the kernel is the right
> > practice!
> >
> > > I assume getting new memory by many retries is still
> > > possibly some other processes might be reclaiming or freeing memory
> > > then providing free memory to this one being stuck.
> >
> > No, I strongly disagree we should even pretend this is a supported
> > allocation strategy. NAK to any attempt to legalize it in some form.
> 
> fare enough.
> I am not trying to legitimize it, just explaining what the documentation says.
> If it is illegal, we should clearly and firmly state that it is
> illegal, rather than
> pretending it is legal and returning NULL. This is also wrong.

Patches to docuementation are always welcome of course. Please keep in
mind that our internal interfaces (something that is not directly
exported to the userspace) are not really defensive against users. We do
expect some level of reasonable expectations from users. Think about it.
GFP_NOWAIT| __GFP_NOFAIL or GDP_ATOMIC|__GFP_NOFAIL is simply impossible
with a finite amount of memory. Isn't it? You are literally saying that
the request _must not_ fail yet it shouldn't resp. cannot wait for any
memory to reclaim if it is not ready for use!

With our gfp flag interface we have quite some combinations of flags
that we do not support. Do we want to document all of them?
-- 
Michal Hocko
SUSE Labs