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

[Barry Song <21cnbao@gmail.com>]

On Fri, Jul 19, 2024 at 8:40 PM Michal Hocko <mhocko@suse.com> wrote:
>
> 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?

I don't see why not, at least for GFP_NOFAIL, because its current
documentation strongly states that it will loop infinitely even if it can't
get memory. It never mentions the potential for a NULL return. Not
everyone is an MM expert, especially considering we have hundreds
of driver developers who are simply calling APIs. We shouldn't rely on
specialized MM knowledge to implement a driver.
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.

> --
> Michal Hocko
> SUSE Labs

Thanks
Barry