Messages in this thread | | | Subject | Re: [PATCH] Uninline kcalloc() | From | Valdis.Kletnieks@vt ... | Date | Mon, 24 Sep 2007 03:55:20 -0400 |
| |
On Mon, 24 Sep 2007 11:44:35 +0400, Alexey Dobriyan said: > On 9/24/07, Valdis.Kletnieks@vt.edu <Valdis.Kletnieks@vt.edu> wrote: > > On Sun, 23 Sep 2007 00:03:49 +0400, Alexey Dobriyan said: > > > > > -static inline void *kcalloc(size_t n, size_t size, gfp_t flags) > > > -{ > > > - if (n != 0 && size > ULONG_MAX / n) > > > - return NULL; > > > - return __kmalloc(n * size, flags | __GFP_ZERO); > > > -} > > > +void *kcalloc(size_t n, size_t size, gfp_t flags); > > > > NAK. > > > > This busticates some pretty subtle code in mm/slab.c that uses > > uses __builtin_return_address() for debugging > > Interesting. Here is output from kernel with patch applied and leak > plugged into proc_dointvec() (I checked twice): > > $ grep kcalloc /proc/slab_allocators
Right. That was the whole *point* of the patch to inline kcalloc - otherwise you ended up with zillions of entries for kcalloc that didn't tell you where they came from.
> $ grep proc_dointvec /proc/slab_allocators > size-64: 19 proc_dointvec+0x48/0xa0
A lot more useful, no? ;) <confoozled> I'm failing to see where proc_dointvec() ends up calling kcalloc? So I'm not sure what that's [unhandled content-type:application/pgp-signature] | |