[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <3721.1190618652@turing-police.cc.vt.edu>
Date: Mon, 24 Sep 2007 03:24:12 -0400
From: Valdis.Kletnieks@...edu
To: Jan Engelhardt <jengelh@...putergmbh.de>
Cc: Alexey Dobriyan <adobriyan@...il.com>, akpm@...l.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH] Uninline kcalloc()
On Mon, 24 Sep 2007 08:22:31 +0200, Jan Engelhardt said:
>
> On Sep 24 2007 01:35, Valdis.Kletnieks@...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 - if you do this, then
> >the "calling function" gets listed as "kcalloc()" rather than the much more
> >useful "function that called kcalloc()" (which is what you care about).
> >
> >(I remember going around and around multiple times getting those stupid
> >inlines set up right, so that feature actually did something useful, otherwise
> >kcalloc and kzalloc didn't report where they were called from).
>
> Since 'inline' is only a hint , should not it be __always_inline,
> so that __builtin_return_address() always works?
At the time I was trying to fix that, saying "inline" actually forced it
to be so. Probably need to go re-check that, since there's been about
forty-leven different "tweak the semantics of inline" since then....
Content of type "application/pgp-signature" skipped
Powered by blists - more mailing lists