From: ebiederm@xmission.com (Eric W. Biederman)
To: Aristeu Rozanski <aris@redhat.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
linux-kernel@vger.kernel.org,
"Serge E. Hallyn" <serge@hallyn.com>
Subject: Re: [PATCH v2] userns: improve uid/gid map collision detection
Date: Fri, 25 Jan 2013 18:31:37 -0800 [thread overview]
Message-ID: <871ud8hdyu.fsf@xmission.com> (raw)
In-Reply-To: <20130125140317.GS17632@redhat.com> (Aristeu Rozanski's message of "Fri, 25 Jan 2013 09:03:18 -0500")
Aristeu Rozanski <aris@redhat.com> writes:
> On Thu, Jan 24, 2013 at 04:46:12PM -0800, Andrew Morton wrote:
>> eek, a macro! Macros are always bad.
>>
>> This one is bad because
>>
>> a) it's a macro
>>
>> b) it evaluates its args multiple times and hence will cause nasty
>> bugs if called with expressions-with-side-effects.
>>
>> c) it evaluates its args multiple times and if called with
>> non-trivial expressions the compiler might not be able to CSE those
>> expressions, leading to code bloat.
>>
>> Add lo, this patch:
>>
>> --- a/kernel/user_namespace.c~userns-improve-uid-gid-map-collision-detection-fix
>> +++ a/kernel/user_namespace.c
>> @@ -521,7 +521,11 @@ struct seq_operations proc_projid_seq_op
>>
>> static DEFINE_MUTEX(id_map_mutex);
>>
>> -#define in_range(b,first,len) ((b)>=(first)&&(b)<(first)+(len))
>> +static bool in_range(u32 b, u32 first, u32 len)
>> +{
>> + return b >= first && b < first + len;
>> +}
>> +
>> static inline int extent_collision(struct uid_gid_map *new_map,
>> struct uid_gid_extent *extent)
>> {
>>
>> reduces the user_namespace.o text from 4822 bytes to 4727 with
>> gcc-4.4.4. This is a remarkably large difference.
>
> thanks Andrew
>
> (I see Eric already answered about the config option)
Aritsteu after looking at both my version and yours I am going with
mine. While my code is a little wordier I have half the number of
comparisons your code does, and I took the time to kill the variable
introducing a function to test for range collisions makes unnecessary.
On Andrews size metric my version seems noticably smaller as well.
size $PWD-build/kernel/user_namespace.o
text data bss dec hex filename
4376 144 0 4520 11a8 /home/eric/projects/linux/linux-userns-devel-build/kernel/user_namespace.o
Short of something unexpected I plan to push all my code to linux-next
sometime tomorrow.
Eric
next prev parent reply other threads:[~2013-01-26 2:31 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-01-23 16:02 [PATCH] userns: improve uid/gid map collision detection Aristeu Rozanski
2013-01-24 4:44 ` Serge E. Hallyn
2013-01-24 15:28 ` [PATCH v2] " Aristeu Rozanski
2013-01-25 0:46 ` Andrew Morton
2013-01-25 2:00 ` Eric W. Biederman
2013-01-25 14:03 ` Aristeu Rozanski
2013-01-26 2:31 ` Eric W. Biederman [this message]
2013-01-28 14:25 ` Aristeu Rozanski
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=871ud8hdyu.fsf@xmission.com \
--to=ebiederm@xmission.com \
--cc=akpm@linux-foundation.org \
--cc=aris@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=serge@hallyn.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.