Re: [RFC][PATCH] utsname: completely overwrite prior information

[Vegard Nossum]

On Sat, Sep 13, 2008 at 12:11 AM, Andrew Morton
<akpm@xxxxxxxxxxxxxxxxxxxx> wrote:
> fair enuf.  Did you check allthe other fields in 'struct new_utsname'?

As far as I can tell, only nodename (hostname) and domainname may be
changed by userspace.

>
>> index 038a7bc..78b4515 100644
>> --- a/kernel/sys.c
>> +++ b/kernel/sys.c
>> @@ -1352,7 +1352,8 @@ asmlinkage long sys_sethostname(char __user *name, int len)
>>       errno = -EFAULT;
>>       if (!copy_from_user(tmp, name, len)) {
>>               memcpy(utsname()->nodename, tmp, len);
>> -             utsname()->nodename[len] = 0;
>> +             memset(utsname()->nodename + len, 0,
>> +                     sizeof(utsname()->nodename) - len);
>
> We could do the memset before the memcpy.  It's more work, but less
> text.  Whatever.

Whatever :-)

> While we're there, the code generation in there is a bit sloppy.  How's
> this look?
>
>
> From: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
>
> utsname() is quite expensive to calculate.  Cache it in a local.
>
>          text    data     bss     dec     hex filename
> before:  11136     720      16   11872    2e60 kernel/sys.o
> after:   11096     720      16   11832    2e38 kernel/sys.o
>
> Cc: Vegard Nossum <vegard.nossum@xxxxxxxxx>
> Cc: "Eric W. Biederman" <ebiederm@xxxxxxxxxxxx>
> Cc: "Serge E. Hallyn" <serue@xxxxxxxxxx>
> Signed-off-by: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>

I agree with this change. FWIW: Acked-by: Vegard Nossum
<vegard.nossum@xxxxxxxxx>

There seems to be a few more places throughout the kernel which
needlessly call utsname() more than once. I will keep it in mind.

Thanks,


Vegard

-- 
"The animistic metaphor of the bug that maliciously sneaked in while
the programmer was not looking is intellectually dishonest as it
disguises that the error is the programmer's own creation."
	-- E. W. Dijkstra, EWD1036
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/