| Message ID | 20221021060340.7515-1-w@1wt.eu (mailing list archive) |
|---|---|
| State | Accepted |
| Commit | c80b5a0a22b673d5a02e64626a8dfc2f738be7d9 |
| Headers | show |
| Series | selftests/nolibc: add 7 tests for memcmp() | expand |
On Fri, Oct 21, 2022 at 08:03:40AM +0200, Willy Tarreau wrote: > This adds 7 combinations of input values for memcmp() using signed and > unsigned bytes, which will trigger on the original code before Rasmus' > fix. This is mostly aimed at helping backporters verify their work, and > showing how tests for corner cases can be added to the selftests suite. > > Before the fix it reports: > 12 memcmp_20_20 = 0 [OK] > 13 memcmp_20_60 = -64 [OK] > 14 memcmp_60_20 = 64 [OK] > 15 memcmp_20_e0 = 64 [FAIL] > 16 memcmp_e0_20 = -64 [FAIL] > 17 memcmp_80_e0 = -96 [OK] > 18 memcmp_e0_80 = 96 [OK] > > And after: > 12 memcmp_20_20 = 0 [OK] > 13 memcmp_20_60 = -64 [OK] > 14 memcmp_60_20 = 64 [OK] > 15 memcmp_20_e0 = -192 [OK] > 16 memcmp_e0_20 = 192 [OK] > 17 memcmp_80_e0 = -96 [OK] > 18 memcmp_e0_80 = 96 [OK] > > Cc: Rasmus Villemoes <linux@rasmusvillemoes.dk> > Signed-off-by: Willy Tarreau <w@1wt.eu> I have pulled both of these in, thank you! One thing, though... I had to do "make clean" in both tools/include/nolibc and tools/testing/selftests/nolibc to make those two "[FAIL]" indications go away. Does this mean that I am doing something wrong? It would be good to know before I send the pull request containing these, so that we can let Linus know of anything special he needs to do to ensure a valid test result. Thanx, Paul > --- > tools/testing/selftests/nolibc/nolibc-test.c | 7 +++++++ > 1 file changed, 7 insertions(+) > > diff --git a/tools/testing/selftests/nolibc/nolibc-test.c b/tools/testing/selftests/nolibc/nolibc-test.c > index 78bced95ac63..f14f5076fb6d 100644 > --- a/tools/testing/selftests/nolibc/nolibc-test.c > +++ b/tools/testing/selftests/nolibc/nolibc-test.c > @@ -565,6 +565,13 @@ int run_stdlib(int min, int max) > CASE_TEST(strchr_foobar_z); EXPECT_STRZR(1, strchr("foobar", 'z')); break; > CASE_TEST(strrchr_foobar_o); EXPECT_STREQ(1, strrchr("foobar", 'o'), "obar"); break; > CASE_TEST(strrchr_foobar_z); EXPECT_STRZR(1, strrchr("foobar", 'z')); break; > + CASE_TEST(memcmp_20_20); EXPECT_EQ(1, memcmp("aaa\x20", "aaa\x20", 4), 0); break; > + CASE_TEST(memcmp_20_60); EXPECT_LT(1, memcmp("aaa\x20", "aaa\x60", 4), 0); break; > + CASE_TEST(memcmp_60_20); EXPECT_GT(1, memcmp("aaa\x60", "aaa\x20", 4), 0); break; > + CASE_TEST(memcmp_20_e0); EXPECT_LT(1, memcmp("aaa\x20", "aaa\xe0", 4), 0); break; > + CASE_TEST(memcmp_e0_20); EXPECT_GT(1, memcmp("aaa\xe0", "aaa\x20", 4), 0); break; > + CASE_TEST(memcmp_80_e0); EXPECT_LT(1, memcmp("aaa\x80", "aaa\xe0", 4), 0); break; > + CASE_TEST(memcmp_e0_80); EXPECT_GT(1, memcmp("aaa\xe0", "aaa\x80", 4), 0); break; > case __LINE__: > return ret; /* must be last */ > /* note: do not set any defaults so as to permit holes above */ > -- > 2.17.5 >
On Fri, Oct 21, 2022 at 08:56:45AM -0700, Paul E. McKenney wrote: > On Fri, Oct 21, 2022 at 08:03:40AM +0200, Willy Tarreau wrote: > > This adds 7 combinations of input values for memcmp() using signed and > > unsigned bytes, which will trigger on the original code before Rasmus' > > fix. This is mostly aimed at helping backporters verify their work, and > > showing how tests for corner cases can be added to the selftests suite. > > > > Before the fix it reports: > > 12 memcmp_20_20 = 0 [OK] > > 13 memcmp_20_60 = -64 [OK] > > 14 memcmp_60_20 = 64 [OK] > > 15 memcmp_20_e0 = 64 [FAIL] > > 16 memcmp_e0_20 = -64 [FAIL] > > 17 memcmp_80_e0 = -96 [OK] > > 18 memcmp_e0_80 = 96 [OK] > > > > And after: > > 12 memcmp_20_20 = 0 [OK] > > 13 memcmp_20_60 = -64 [OK] > > 14 memcmp_60_20 = 64 [OK] > > 15 memcmp_20_e0 = -192 [OK] > > 16 memcmp_e0_20 = 192 [OK] > > 17 memcmp_80_e0 = -96 [OK] > > 18 memcmp_e0_80 = 96 [OK] > > > > Cc: Rasmus Villemoes <linux@rasmusvillemoes.dk> > > Signed-off-by: Willy Tarreau <w@1wt.eu> > > I have pulled both of these in, thank you! Thanks! > One thing, though... I had to do "make clean" in both tools/include/nolibc > and tools/testing/selftests/nolibc to make those two "[FAIL]" indications > go away. Does this mean that I am doing something wrong? No you didn't do anything wrong, it was the same for me and initially it was intentional, but probably it wasn't that good an idea. What happens is that we first prepare a pseudo-sysroot with kernel headers and nolibc headers, then we build the test based on this sysroot. Thus if any uapi header or nolibc header changes, nothing is detected. And I'm not much willing to always reinstall everything for every single test, nor to detect long dependency chains. Maybe I should think about adding another target to clean+test at the same time, or maybe make the current "nolibc-test" target do that and have a "retest" to only rebuild. But that needs to be thought about with the QEMU test as well (because most of the time for a quick test I don't build the kernel nor start QEMU, I just call the executable directly). Any ideas or suggestions are welcome, of course. We could consider that if we build a kernel and start QEMU, it's long enough to justify a systematic clean maybe ? > It would be good to know before I send the pull request containing these, > so that we can let Linus know of anything special he needs to do to > ensure a valid test result. I see. In the worst case, a preliminary "make clean" will do it. We just need to decide what's the best solution for everyone (i.e. not waste too much time between tests while not getting misleading results by accident). Thanks! Willy
On Fri, Oct 21, 2022 at 07:01:34PM +0200, Willy Tarreau wrote: > On Fri, Oct 21, 2022 at 08:56:45AM -0700, Paul E. McKenney wrote: > > On Fri, Oct 21, 2022 at 08:03:40AM +0200, Willy Tarreau wrote: > > > This adds 7 combinations of input values for memcmp() using signed and > > > unsigned bytes, which will trigger on the original code before Rasmus' > > > fix. This is mostly aimed at helping backporters verify their work, and > > > showing how tests for corner cases can be added to the selftests suite. > > > > > > Before the fix it reports: > > > 12 memcmp_20_20 = 0 [OK] > > > 13 memcmp_20_60 = -64 [OK] > > > 14 memcmp_60_20 = 64 [OK] > > > 15 memcmp_20_e0 = 64 [FAIL] > > > 16 memcmp_e0_20 = -64 [FAIL] > > > 17 memcmp_80_e0 = -96 [OK] > > > 18 memcmp_e0_80 = 96 [OK] > > > > > > And after: > > > 12 memcmp_20_20 = 0 [OK] > > > 13 memcmp_20_60 = -64 [OK] > > > 14 memcmp_60_20 = 64 [OK] > > > 15 memcmp_20_e0 = -192 [OK] > > > 16 memcmp_e0_20 = 192 [OK] > > > 17 memcmp_80_e0 = -96 [OK] > > > 18 memcmp_e0_80 = 96 [OK] > > > > > > Cc: Rasmus Villemoes <linux@rasmusvillemoes.dk> > > > Signed-off-by: Willy Tarreau <w@1wt.eu> > > > > I have pulled both of these in, thank you! > > Thanks! > > > One thing, though... I had to do "make clean" in both tools/include/nolibc > > and tools/testing/selftests/nolibc to make those two "[FAIL]" indications > > go away. Does this mean that I am doing something wrong? > > No you didn't do anything wrong, it was the same for me and initially it > was intentional, but probably it wasn't that good an idea. What happens > is that we first prepare a pseudo-sysroot with kernel headers and nolibc > headers, then we build the test based on this sysroot. Thus if any uapi > header or nolibc header changes, nothing is detected. And I'm not much > willing to always reinstall everything for every single test, nor to > detect long dependency chains. Maybe I should think about adding another > target to clean+test at the same time, or maybe make the current > "nolibc-test" target do that and have a "retest" to only rebuild. But > that needs to be thought about with the QEMU test as well (because most > of the time for a quick test I don't build the kernel nor start QEMU, I > just call the executable directly). > > Any ideas or suggestions are welcome, of course. We could consider that > if we build a kernel and start QEMU, it's long enough to justify a > systematic clean maybe ? > > > It would be good to know before I send the pull request containing these, > > so that we can let Linus know of anything special he needs to do to > > ensure a valid test result. > > I see. In the worst case, a preliminary "make clean" will do it. We just > need to decide what's the best solution for everyone (i.e. not waste too > much time between tests while not getting misleading results by accident). Maybe just document the careful/slow way, then people doing it more frequently can do it the clever/fast way. My guess is that the careful/slow is this: pushd tools/include/nolibc make clean make popd pushd tools/testing/selftests/nolibc make clean make -j32 run Or did I miss a turn in there somewhere? Thanx, Paul
On Fri, Oct 21, 2022 at 10:07:38AM -0700, Paul E. McKenney wrote: > > I see. In the worst case, a preliminary "make clean" will do it. We just > > need to decide what's the best solution for everyone (i.e. not waste too > > much time between tests while not getting misleading results by accident). > > Maybe just document the careful/slow way, then people doing it more > frequently can do it the clever/fast way. > > My guess is that the careful/slow is this: > > pushd tools/include/nolibc > make clean > make > popd > pushd tools/testing/selftests/nolibc > make clean > make -j32 run > > Or did I miss a turn in there somewhere? It's even easier, you don't even need the clean phase in include/nolibc. I'm doing this and it's sufficient: make -C tools/testing/selftests/nolibc clean make -C tools/testing/selftests/nolibc nolibc-test tools/testing/selftests/nolibc/nolibc-test Or for the test under QEMU, which involves a kernel build: make -C tools/testing/selftests/nolibc clean make -C tools/testing/selftests/nolibc -j $(nproc) run Where would you first look for such a hint ? Maybe the help output of the default "make" command could send as a hint that a clean is needed after patching nolibc and that could be sufficient ? I just want to make sure users don't waste their time trying to find what they could be doing wrong. Willy
On Fri, Oct 21, 2022 at 07:20:26PM +0200, Willy Tarreau wrote: > On Fri, Oct 21, 2022 at 10:07:38AM -0700, Paul E. McKenney wrote: > > > I see. In the worst case, a preliminary "make clean" will do it. We just > > > need to decide what's the best solution for everyone (i.e. not waste too > > > much time between tests while not getting misleading results by accident). > > > > Maybe just document the careful/slow way, then people doing it more > > frequently can do it the clever/fast way. > > > > My guess is that the careful/slow is this: > > > > pushd tools/include/nolibc > > make clean > > make > > popd > > pushd tools/testing/selftests/nolibc > > make clean > > make -j32 run > > > > Or did I miss a turn in there somewhere? > > It's even easier, you don't even need the clean phase in include/nolibc. > I'm doing this and it's sufficient: > > make -C tools/testing/selftests/nolibc clean > make -C tools/testing/selftests/nolibc nolibc-test > tools/testing/selftests/nolibc/nolibc-test > > Or for the test under QEMU, which involves a kernel build: > > make -C tools/testing/selftests/nolibc clean > make -C tools/testing/selftests/nolibc -j $(nproc) run > > Where would you first look for such a hint ? Maybe the help output of > the default "make" command could send as a hint that a clean is needed > after patching nolibc and that could be sufficient ? I just want to make > sure users don't waste their time trying to find what they could be doing > wrong. Maybe it suffices for the near term for me to put this information in the signed tag for the pull request? Another approach would be to remind about "make clean" in the case of a test failure. Or make test failure combined with a detected change trigger an automatic "make clean" and a retry. Or other schemes of increasing complexity and fragility. ;-) Other approaches? Thanx, Paul
On Fri, Oct 21, 2022 at 11:00:40AM -0700, Paul E. McKenney wrote: > > It's even easier, you don't even need the clean phase in include/nolibc. > > I'm doing this and it's sufficient: > > > > make -C tools/testing/selftests/nolibc clean > > make -C tools/testing/selftests/nolibc nolibc-test > > tools/testing/selftests/nolibc/nolibc-test > > > > Or for the test under QEMU, which involves a kernel build: > > > > make -C tools/testing/selftests/nolibc clean > > make -C tools/testing/selftests/nolibc -j $(nproc) run > > > > Where would you first look for such a hint ? Maybe the help output of > > the default "make" command could send as a hint that a clean is needed > > after patching nolibc and that could be sufficient ? I just want to make > > sure users don't waste their time trying to find what they could be doing > > wrong. > > Maybe it suffices for the near term for me to put this information in > the signed tag for the pull request? It can be sufficient for short term indeed, but it can be easy as well for me to mention it in the make output. > Another approach would be to remind about "make clean" in the case of > a test failure. Or make test failure combined with a detected change > trigger an automatic "make clean" and a retry. In fact failures are not the only case. For me it was the opposite. I applied Rasmus' fix, then I developed the test, verified that it worked, then reverted Rasmus' fix... to find that the test didn't catch the failure. I had a second look at the original patch and figured that the -192..+192 values were really not possible with a char so I concluded that a clean was needed. But leaving something in a claimed working state while it's not can be sufficiently misleading and make one waste significant time, because in such cases we rarely search why it works. > Or other schemes of increasing complexity and fragility. ;-) That's exactly what I'd like to avoid with such a lightweight component. If it takes more time to figure why something is going wrong than to write a test, we'll all give up. I think that a clean for QEMU is worth it because the kernel is rebuilt and its dependencies are quite robust, so that one would be a surprise. For other tests, probably leaving it explicit with a hint that it's needed should suffice. I'll recheck what conditions the installation of uapi headers because that's really what I don't want to see happening all the time. The rest is discrete, it's just a few files being copied, maybe it can be done every time. Will keep thinking about it and hopefully propose a patch to make the tests easier to use before we're too far in the 6.1 release. Thanks for keeping the conversation flowing, that helps me! Willy
On Sat, Oct 22, 2022 at 01:22:28PM +0200, Willy Tarreau wrote: > On Fri, Oct 21, 2022 at 11:00:40AM -0700, Paul E. McKenney wrote: > > > It's even easier, you don't even need the clean phase in include/nolibc. > > > I'm doing this and it's sufficient: > > > > > > make -C tools/testing/selftests/nolibc clean > > > make -C tools/testing/selftests/nolibc nolibc-test > > > tools/testing/selftests/nolibc/nolibc-test > > > > > > Or for the test under QEMU, which involves a kernel build: > > > > > > make -C tools/testing/selftests/nolibc clean > > > make -C tools/testing/selftests/nolibc -j $(nproc) run > > > > > > Where would you first look for such a hint ? Maybe the help output of > > > the default "make" command could send as a hint that a clean is needed > > > after patching nolibc and that could be sufficient ? I just want to make > > > sure users don't waste their time trying to find what they could be doing > > > wrong. > > > > Maybe it suffices for the near term for me to put this information in > > the signed tag for the pull request? > > It can be sufficient for short term indeed, but it can be easy as well > for me to mention it in the make output. Why not both? ;-) > > Another approach would be to remind about "make clean" in the case of > > a test failure. Or make test failure combined with a detected change > > trigger an automatic "make clean" and a retry. > > In fact failures are not the only case. For me it was the opposite. I > applied Rasmus' fix, then I developed the test, verified that it worked, > then reverted Rasmus' fix... to find that the test didn't catch the > failure. I had a second look at the original patch and figured that > the -192..+192 values were really not possible with a char so I > concluded that a clean was needed. But leaving something in a claimed > working state while it's not can be sufficiently misleading and make > one waste significant time, because in such cases we rarely search why > it works. Fair point! False negatives can be quite annoying as well. > > Or other schemes of increasing complexity and fragility. ;-) > > That's exactly what I'd like to avoid with such a lightweight component. > If it takes more time to figure why something is going wrong than to > write a test, we'll all give up. I think that a clean for QEMU is worth > it because the kernel is rebuilt and its dependencies are quite robust, > so that one would be a surprise. For other tests, probably leaving it > explicit with a hint that it's needed should suffice. I'll recheck what > conditions the installation of uapi headers because that's really what > I don't want to see happening all the time. The rest is discrete, it's > just a few files being copied, maybe it can be done every time. > > Will keep thinking about it and hopefully propose a patch to make the > tests easier to use before we're too far in the 6.1 release. Another possibility is to have a separate developers' and maintainers' option. Linus and I do "make whatever" for some value of "whatever" that builds from scratch, doing whatever cleaning that might be required. Developers use targets that are faster but have the possibility of false positives and false negatives. But maybe you have something better in mind. > Thanks for keeping the conversation flowing, that helps me! Looking forward to seeing what you come up with! Thanx, Paul
Hi Paul, On Mon, Oct 24, 2022 at 08:53:57AM -0700, Paul E. McKenney wrote: > > Will keep thinking about it and hopefully propose a patch to make the > > tests easier to use before we're too far in the 6.1 release. > > Another possibility is to have a separate developers' and maintainers' > option. Linus and I do "make whatever" for some value of "whatever" > that builds from scratch, doing whatever cleaning that might be required. > Developers use targets that are faster but have the possibility of false > positives and false negatives. > > But maybe you have something better in mind. > > > Thanks for keeping the conversation flowing, that helps me! > > Looking forward to seeing what you come up with! I could finally figure what was taking time in the installation process. Interestingly, it's "make headers", which is not redone without a "make clean" at the kernel level. The "make headers_install" only takes a few hundred milliseconds, so issuing a systematic "make clean" in the nolibc test dir only takes ~800ms here to perform a full rebuild, which is totally acceptable to me. Thus what I've done is to mark the sysroot target as .phony and start it with a removal of the current include dir so that we systematically rebuild it. Now there's no such risk of running a test against an earlier version anymore, and there are no "make clean" to worry about anymore either. That looks much better to me! And I could confirm that just issuing: $ time make -j8 -C tools/testing/selftests/nolibc run after reverting Rasmus' fix led me to this pretty quickly: ... Kernel: arch/x86/boot/bzImage is ready (#3) make[1]: Leaving directory '/k' 15 memcmp_20_e0 = 64 [FAIL] 16 memcmp_e0_20 = -64 [FAIL] See all results in /k/tools/testing/selftests/nolibc/run.out make: Leaving directory '/k/tools/testing/selftests/nolibc' real 0m14.538s user 0m27.828s sys 0m4.576s No more false positives nor false negatives anymore. I'm sending you the patch separately. Thanks for the discussion, the solution is way better now! Willy
On 26/10/2022 07.39, Willy Tarreau wrote: > > No more false positives nor false negatives anymore. I'm sending you > the patch separately. While you're at it, may I suggest also adding a few test cases where the buffers differ by 128, e.g. 0x0 v 0x80 and 0x40 v 0xc0.
On Wed, Oct 26, 2022 at 07:39:22AM +0200, Willy Tarreau wrote: > Hi Paul, > > On Mon, Oct 24, 2022 at 08:53:57AM -0700, Paul E. McKenney wrote: > > > Will keep thinking about it and hopefully propose a patch to make the > > > tests easier to use before we're too far in the 6.1 release. > > > > Another possibility is to have a separate developers' and maintainers' > > option. Linus and I do "make whatever" for some value of "whatever" > > that builds from scratch, doing whatever cleaning that might be required. > > Developers use targets that are faster but have the possibility of false > > positives and false negatives. > > > > But maybe you have something better in mind. > > > > > Thanks for keeping the conversation flowing, that helps me! > > > > Looking forward to seeing what you come up with! > > I could finally figure what was taking time in the installation process. > Interestingly, it's "make headers", which is not redone without a "make > clean" at the kernel level. The "make headers_install" only takes a few > hundred milliseconds, so issuing a systematic "make clean" in the nolibc > test dir only takes ~800ms here to perform a full rebuild, which is totally > acceptable to me. > > Thus what I've done is to mark the sysroot target as .phony and start it > with a removal of the current include dir so that we systematically rebuild > it. Now there's no such risk of running a test against an earlier version > anymore, and there are no "make clean" to worry about anymore either. > That looks much better to me! > > And I could confirm that just issuing: > > $ time make -j8 -C tools/testing/selftests/nolibc run > > after reverting Rasmus' fix led me to this pretty quickly: > > ... > Kernel: arch/x86/boot/bzImage is ready (#3) > make[1]: Leaving directory '/k' > 15 memcmp_20_e0 = 64 [FAIL] > 16 memcmp_e0_20 = -64 [FAIL] > See all results in /k/tools/testing/selftests/nolibc/run.out > make: Leaving directory '/k/tools/testing/selftests/nolibc' > > real 0m14.538s > user 0m27.828s > sys 0m4.576s > > No more false positives nor false negatives anymore. I'm sending you > the patch separately. > > Thanks for the discussion, the solution is way better now! Nice, looking forward to the patch! Thanx, Paul
On Wed, Oct 26, 2022 at 06:57:33AM -0700, Paul E. McKenney wrote: > On Wed, Oct 26, 2022 at 07:39:22AM +0200, Willy Tarreau wrote: > > Hi Paul, > > > > On Mon, Oct 24, 2022 at 08:53:57AM -0700, Paul E. McKenney wrote: > > > > Will keep thinking about it and hopefully propose a patch to make the > > > > tests easier to use before we're too far in the 6.1 release. > > > > > > Another possibility is to have a separate developers' and maintainers' > > > option. Linus and I do "make whatever" for some value of "whatever" > > > that builds from scratch, doing whatever cleaning that might be required. > > > Developers use targets that are faster but have the possibility of false > > > positives and false negatives. > > > > > > But maybe you have something better in mind. > > > > > > > Thanks for keeping the conversation flowing, that helps me! > > > > > > Looking forward to seeing what you come up with! > > > > I could finally figure what was taking time in the installation process. > > Interestingly, it's "make headers", which is not redone without a "make > > clean" at the kernel level. The "make headers_install" only takes a few > > hundred milliseconds, so issuing a systematic "make clean" in the nolibc > > test dir only takes ~800ms here to perform a full rebuild, which is totally > > acceptable to me. > > > > Thus what I've done is to mark the sysroot target as .phony and start it > > with a removal of the current include dir so that we systematically rebuild > > it. Now there's no such risk of running a test against an earlier version > > anymore, and there are no "make clean" to worry about anymore either. > > That looks much better to me! > > > > And I could confirm that just issuing: > > > > $ time make -j8 -C tools/testing/selftests/nolibc run > > > > after reverting Rasmus' fix led me to this pretty quickly: > > > > ... > > Kernel: arch/x86/boot/bzImage is ready (#3) > > make[1]: Leaving directory '/k' > > 15 memcmp_20_e0 = 64 [FAIL] > > 16 memcmp_e0_20 = -64 [FAIL] > > See all results in /k/tools/testing/selftests/nolibc/run.out > > make: Leaving directory '/k/tools/testing/selftests/nolibc' > > > > real 0m14.538s > > user 0m27.828s > > sys 0m4.576s > > > > No more false positives nor false negatives anymore. I'm sending you > > the patch separately. > > > > Thanks for the discussion, the solution is way better now! > > Nice, looking forward to the patch! In case you don't have it, it's this one: https://lore.kernel.org/all/20221026054508.19634-1-w@1wt.eu/ Do not hesitate to let me know if I should resend it. Thanks! Willy
On Wed, Oct 26, 2022 at 11:08:41AM +0200, Rasmus Villemoes wrote: > On 26/10/2022 07.39, Willy Tarreau wrote: > > > > No more false positives nor false negatives anymore. I'm sending you > > the patch separately. > > While you're at it, may I suggest also adding a few test cases where the > buffers differ by 128, e.g. 0x0 v 0x80 and 0x40 v 0xc0. I initially thought about it but changed my mind for +/- 0xc0 that covered the same cases in my opinion. Do you have a particular error case in mind that would be caught by this one that the other one does not catch ? I'm fine for proposing a respin of the patch to improve it if it brings some value, but I'm still failing to figure when that would be the case. Thanks, Willy
On 26/10/2022 21.52, Willy Tarreau wrote: > On Wed, Oct 26, 2022 at 11:08:41AM +0200, Rasmus Villemoes wrote: >> On 26/10/2022 07.39, Willy Tarreau wrote: >>> >>> No more false positives nor false negatives anymore. I'm sending you >>> the patch separately. >> >> While you're at it, may I suggest also adding a few test cases where the >> buffers differ by 128, e.g. 0x0 v 0x80 and 0x40 v 0xc0. > > I initially thought about it but changed my mind for +/- 0xc0 that > covered the same cases in my opinion. Do you have a particular error > case in mind that would be caught by this one that the other one does > not catch ? Not really, but in a sense the opposite: for the +/- 0xc0 case, both ways of comparison will give the wrong sign because -192 becomes +64 and vice versa. For +/- 0x80, one way of doing the comparison will "accidentally" produce the right answer, and I thought that might also be a little interesting. I'm fine for proposing a respin of the patch to improve > it if it brings some value, It's your call, you can respin, do an incremental patch, or just ignore me :) Rasmus
Hi Rasmus, On Thu, Oct 27, 2022 at 11:09:55AM +0200, Rasmus Villemoes wrote: > >> While you're at it, may I suggest also adding a few test cases where the > >> buffers differ by 128, e.g. 0x0 v 0x80 and 0x40 v 0xc0. > > > > I initially thought about it but changed my mind for +/- 0xc0 that > > covered the same cases in my opinion. Do you have a particular error > > case in mind that would be caught by this one that the other one does > > not catch ? > > Not really, but in a sense the opposite: for the +/- 0xc0 case, both > ways of comparison will give the wrong sign because -192 becomes +64 and > vice versa. For +/- 0x80, one way of doing the comparison will > "accidentally" produce the right answer, and I thought that might also > be a little interesting. OK, initially I thought you were trying to make the comparison return a match when there is none. I now see better what you mean there. > > I'm fine for proposing a respin of the patch to improve > > it if it brings some value, > > It's your call, you can respin, do an incremental patch, or just ignore > me :) I would like to propose you something. Till now I'm the only one having added tests to this file, and I'm still lacking feedback on the usability. I would very much appreciate it if you could try to add this test case yourself on top of existing ones (those present in Paul's rcu/next branch here: https://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git/ ). Then your criticism of what you would find unclear, unconvenient, poorly thought, unintuitive etc, and of course suggestions, would be welcome. That doesn't mean I'd have a quick solution of course but the more eyes there at the early stages, the better so that it becomes friendly to use for other contributors. If you don't want to, that's no big deal, but if you do I'll really appreciate it. Thank you, Willy
diff --git a/tools/testing/selftests/nolibc/nolibc-test.c b/tools/testing/selftests/nolibc/nolibc-test.c index 78bced95ac63..f14f5076fb6d 100644 --- a/tools/testing/selftests/nolibc/nolibc-test.c +++ b/tools/testing/selftests/nolibc/nolibc-test.c @@ -565,6 +565,13 @@ int run_stdlib(int min, int max) CASE_TEST(strchr_foobar_z); EXPECT_STRZR(1, strchr("foobar", 'z')); break; CASE_TEST(strrchr_foobar_o); EXPECT_STREQ(1, strrchr("foobar", 'o'), "obar"); break; CASE_TEST(strrchr_foobar_z); EXPECT_STRZR(1, strrchr("foobar", 'z')); break; + CASE_TEST(memcmp_20_20); EXPECT_EQ(1, memcmp("aaa\x20", "aaa\x20", 4), 0); break; + CASE_TEST(memcmp_20_60); EXPECT_LT(1, memcmp("aaa\x20", "aaa\x60", 4), 0); break; + CASE_TEST(memcmp_60_20); EXPECT_GT(1, memcmp("aaa\x60", "aaa\x20", 4), 0); break; + CASE_TEST(memcmp_20_e0); EXPECT_LT(1, memcmp("aaa\x20", "aaa\xe0", 4), 0); break; + CASE_TEST(memcmp_e0_20); EXPECT_GT(1, memcmp("aaa\xe0", "aaa\x20", 4), 0); break; + CASE_TEST(memcmp_80_e0); EXPECT_LT(1, memcmp("aaa\x80", "aaa\xe0", 4), 0); break; + CASE_TEST(memcmp_e0_80); EXPECT_GT(1, memcmp("aaa\xe0", "aaa\x80", 4), 0); break; case __LINE__: return ret; /* must be last */ /* note: do not set any defaults so as to permit holes above */
This adds 7 combinations of input values for memcmp() using signed and unsigned bytes, which will trigger on the original code before Rasmus' fix. This is mostly aimed at helping backporters verify their work, and showing how tests for corner cases can be added to the selftests suite. Before the fix it reports: 12 memcmp_20_20 = 0 [OK] 13 memcmp_20_60 = -64 [OK] 14 memcmp_60_20 = 64 [OK] 15 memcmp_20_e0 = 64 [FAIL] 16 memcmp_e0_20 = -64 [FAIL] 17 memcmp_80_e0 = -96 [OK] 18 memcmp_e0_80 = 96 [OK] And after: 12 memcmp_20_20 = 0 [OK] 13 memcmp_20_60 = -64 [OK] 14 memcmp_60_20 = 64 [OK] 15 memcmp_20_e0 = -192 [OK] 16 memcmp_e0_20 = 192 [OK] 17 memcmp_80_e0 = -96 [OK] 18 memcmp_e0_80 = 96 [OK] Cc: Rasmus Villemoes <linux@rasmusvillemoes.dk> Signed-off-by: Willy Tarreau <w@1wt.eu> --- tools/testing/selftests/nolibc/nolibc-test.c | 7 +++++++ 1 file changed, 7 insertions(+)