lkml.org 
[lkml]   [2004]   [Dec]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH][2/2] fix unchecked returns from kmalloc() (in mm/slab.c)
    On Tue, 7 Dec 2004, Jens Axboe wrote:

    > On Tue, Dec 07 2004, Jesper Juhl wrote:
    > > On Tue, 7 Dec 2004, Jens Axboe wrote:
    > >
    > > > On Tue, Dec 07 2004, Jesper Juhl wrote:
    > > > >
    > > > > Problem reported by Katrina Tsipenyuk and the Fortify Software engineering
    > > > > team in thread with subject "PROBLEM: unchecked returns from kmalloc() in
    > > > > linux-2.6.10-rc2".
    > > > >
    > > > > Unfortunately I'm not very familliar with the code in question, and since
    > > > > I didn't find a really good way to deal with a failing kmalloc() here I
    > > > > settled for second best which is to add a BUG_ON() in case kmalloc fails.
    > > > > This will at least crash in a sane way at the point the problem occoures
    > > > > rather than getting strange problems at a (possibly) later time. If
    > > > > someone who's familliar with how this code works has a better solution
    > > > > then please step forward :) but in the mean time I think this is at least
    > > > > a slight improvement over the current situation.
    > > > >
    > > > > Patch has been compile tested and boot tested and didn't blow up
    > > > > instantly, but please review before applying.
    > > > >
    > > > >
    > > > > Signed-off-by: Jesper Juhl <juhl-lkml@dif.dk>
    > > > >
    > > > > diff -up linux-2.6.10-rc3-bk2-orig/mm/slab.c linux-2.6.10-rc3-bk2/mm/slab.c
    > > > > --- linux-2.6.10-rc3-bk2-orig/mm/slab.c 2004-12-06 22:24:56.000000000 +0100
    > > > > +++ linux-2.6.10-rc3-bk2/mm/slab.c 2004-12-07 21:27:20.000000000 +0100
    > > > > @@ -804,6 +804,7 @@ void __init kmem_cache_init(void)
    > > > > void * ptr;
    > > > >
    > > > > ptr = kmalloc(sizeof(struct arraycache_init), GFP_KERNEL);
    > > > > + BUG_ON(ptr == NULL); /* FIXME: Can a failed kmalloc be handled better? */
    > > > > local_irq_disable();
    > > > > BUG_ON(ac_data(&cache_cache) != &initarray_cache.cache);
    > > > > memcpy(ptr, ac_data(&cache_cache), sizeof(struct arraycache_init));
    > > >
    > > > This is pointless, as a NULL deref on memcpy will give you the exact
    > > > same info.
    > > >
    > > Hmm, now why didn't I think of that. Thanks Jens.
    > > I guess I'm not up to the task of fixing this one. I'll try looking
    > > harder, but I don't think I can do better in this case.
    >
    > See my next mail, I'm not so sure there's anything worth fixing. If
    > there was no fear of it being misused, perhaps GFP_PANIC would be a
    > proper way to flag that this really should not fail.
    >
    Ok, I'll just leave this alone now. Implementing GFP_PANIC is waaaay out
    of my league at the moment. Could be fun to try just for the hell of it,
    but I have a feeling it's beyond me... maybe I'll take a stab at it during
    the weekend if for no other reason than to learn a bit about how memory
    allocation actually works in the kernel (a mostly dark spot atm) :)
    ...


    --
    Jesper Juhl

    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2005-03-22 14:08    [W:0.026 / U:0.032 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site