linux-kernel - Re: [PATCH 05/10] mm, util: Use dup

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CALF0-+WcXLR_akn8mL8u-QigHU9Bk5RotA3tbodZ8rhZsxpFLg@mail.gmail.com>
Date:	Tue, 25 Sep 2012 22:15:38 -0300
From:	Ezequiel Garcia <elezegarcia@...il.com>
To:	Andrew Morton <akpm@...ux-foundation.org>
Cc:	linux-kernel@...r.kernel.org, linux-mm@...ck.org,
	Pekka Enberg <penberg@...nel.org>
Subject: Re: [PATCH 05/10] mm, util: Use dup_user to duplicate user memory

Hi Andrew,

On Tue, Sep 25, 2012 at 6:29 PM, Andrew Morton
<akpm@...ux-foundation.org> wrote:
> On Sat,  8 Sep 2012 17:47:54 -0300
> Ezequiel Garcia <elezegarcia@...il.com> wrote:
>
>> Previously the strndup_user allocation was being done through memdup_user,
>> and the caller was wrongly traced as being strndup_user
>> (the correct trace must report the caller of strndup_user).
>>
>> This is a common problem: in order to get accurate callsite tracing,
>> a utils function can't allocate through another utils function,
>> but instead do the allocation himself (or inlined).
>>
>> Here we fix this by creating an always inlined dup_user() function to
>> performed the real allocation and to be used by memdup_user and strndup_user.
>
> This patch increases util.o's text size by 238 bytes.  A larger kernel
> with a worsened cache footprint.
>
> And we did this to get marginally improved tracing output?  This sounds
> like a bad tradeoff to me.
>

Mmm, that's bad tradeoff indeed.
It's certainly odd since the patch shouldn't increase the text size
*that* much.
Is it too much to ask that you send your kernel config and gcc version.

My compilation (x86 kernel in gcc 4.7.1) shows a kernel less bloated:

$ readelf -s util-dup-user.o | grep dup_user
   161: 00001c10   108 FUNC    GLOBAL DEFAULT    1 memdup_user
   169: 00001df0   159 FUNC    GLOBAL DEFAULT    1 strndup_user
$ readelf -s util.o | grep dup_user
   161: 00001c10   108 FUNC    GLOBAL DEFAULT    1 memdup_user
   169: 00001df0    98 FUNC    GLOBAL DEFAULT    1 strndup_user

$ size util.o
   text	   data	    bss	    dec	    hex	filename
  18319	   2077	      0	  20396	   4fac	util.o
$ size util-dup-user.o
   text	   data	    bss	    dec	    hex	filename
  18367	   2077	      0	  20444	   4fdc	util-dup-user.o

Am I doing anything wrong?
If you still feel this is unnecessary bloatness, perhaps I could think of
something depending on CONFIG_TRACING (though I know
we all hate those nasty ifdefs).

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