lkml.org 
[lkml]   [2018]   [Dec]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH RFC] mm: vmalloc: do not allow kzalloc to fail
On Fri, Dec 21, 2018 at 01:58:39PM -0800, David Rientjes wrote:
> On Thu, 20 Dec 2018, Nicholas Mc Guire wrote:
>
> > diff --git a/mm/vmalloc.c b/mm/vmalloc.c
> > index 871e41c..1c118d7 100644
> > --- a/mm/vmalloc.c
> > +++ b/mm/vmalloc.c
> > @@ -1258,7 +1258,7 @@ void __init vmalloc_init(void)
> >
> > /* Import existing vmlist entries. */
> > for (tmp = vmlist; tmp; tmp = tmp->next) {
> > - va = kzalloc(sizeof(struct vmap_area), GFP_NOWAIT);
> > + va = kzalloc(sizeof(*va), GFP_NOWAIT | __GFP_NOFAIL);
> > va->flags = VM_VM_AREA;
> > va->va_start = (unsigned long)tmp->addr;
> > va->va_end = va->va_start + tmp->size;
>
> Hi Nicholas,
>
> You're right that this looks wrong because there's no guarantee that va is
> actually non-NULL. __GFP_NOFAIL won't help in init, unfortunately, since
> we're not giving the page allocator a chance to reclaim so this would
> likely just end up looping forever instead of crashing with a NULL pointer
> dereference, which would actually be the better result.
>
tried tracing the __GFP_NOFAIL path and had concluded that it would
end in out_of_memory() -> panic("System is deadlocked on memory\n");
which also should point cleanly to the cause - but I´m actually not
that sure if that trace was correct in all cases.

> You could do
>
> BUG_ON(!va);
>
> to make it obvious why we crashed, however. It makes it obvious that the
> crash is intentional rather than some error in the kernel code.

makes sense - that atleast makes it imediately clear from the code
that there is no way out from here.

thx!
hofrat

\
 
 \ /
  Last update: 2018-12-22 18:00    [W:0.132 / U:0.168 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site