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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu 18-07-24 20:43:53, Barry Song wrote:
> On Thu, Jul 18, 2024 at 8:32 PM Michal Hocko <mhocko@xxxxxxxx> wrote:
> >
> > On Thu 18-07-24 20:18:02, Barry Song wrote:
> > > So the purpose is making sure the semantics - NOFAIL means no failure
> > > and we don't need to check ret.  If we can't really succeed, it should throw
> > > a BUG to stop any potential exploits.
> >
> > This would require to panic consistently on failure in all allocator
> > path that can bail out. E.g. page allocator on GFP_NOWAIT|GFP_NOFAIL
> > req. not sure how many more.
> 
> Right, this GFP_NOFAIL issue seems quite messy. However, at least vmalloc
> will retry by itself, even if alloc_pages might have failed with
> GFP_NOWAIT | GFP_NOFAIL.
> 
> But isn't that the definition of __GFP_NOFAIL?
> 
>  * %__GFP_NOFAIL: The VM implementation _must_ retry infinitely: the caller
>  * cannot handle allocation failures. The allocation could block
>  * indefinitely but will never return with failure. Testing for
>  * failure is pointless."
> 
> So I believe any code that doesn't retry and ends up returning NULL should be
> fixed.

Yes, those shouldn't really fail. NOWAIT|NOFAIL was something that
should never happen and I really hope it doesn't. Others should really
retry but it's been some time since I've checked the last time.

These overflow checks were added without any acks by MM people...
-- 
Michal Hocko
SUSE Labs




[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux