[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1291042737.30543.730.camel@gandalf.stny.rr.com>
Date: Mon, 29 Nov 2010 09:58:57 -0500
From: Steven Rostedt <rostedt@...dmis.org>
To: pavel@...linux.ru
Cc: LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] Repalce strncmp by memcmp
On Mon, 2010-11-29 at 05:09 +0300, Pavel Vasilyev wrote:
> This patch replace all strncmp(a, b, c) by memcmp(a, b, c).
But these are not the same. strncmp() will stop when a or b hit a null.
I'm not sure if memcmp() must do so, It may for some reason check
anything within the memory of a+c-1 or b+c-1. What happens if a or b are
right at the end of a vmalloc page, and is just a single character and
null?
x = vmalloc(32);
strcpy(x, "some 31 byte string + null");
call_func(x + 31);
in call_func we have:
call_func(char *a) {
strncmp(a, "this is some big string", 23);
With strncmp() when we hit a+1, it will stop comparing because a+1 is
null. With memcmp there's no such guarantee. We can then take a kernel
oops.
That will be a nice thing to try to debug.
Yes the above is contrived, but it demonstrates a possible problem with
this conversion.
-- Steve
>
> I test on x86_64 (AMD Opteron 285).
>
> #include <string.h>
> char *A = "0000";
> void test_memcmp(void) {
> memcmp(A, "TEST", 4);
> }
> void test_strn(void) {
> strncmp(A, "TEST", 4);
> }
> # gcc -c -O2 test.c
> # objdump -d test.o
> ...
>
> 0000000000000020 <test_strncmp>:
> 20: f3 c3 repz retq
> 22: 66 66 66 66 66 2e 0f data32 data32 data32 data32 nopw
> %cs:0x0(%rax,%rax,1)
> 29: 1f 84 00 00 00 00 00
>
> 0000000000000030 <test_memcmp>:
> 30: f3 c3 repz retq
>
> Wow, minus one commad :)
>
--
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/
Powered by blists - more mailing lists