Message ID | 20221026054508.19634-1-w@1wt.eu |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a5d:6687:0:0:0:0:0 with SMTP id l7csp76448wru; Tue, 25 Oct 2022 23:00:12 -0700 (PDT) X-Google-Smtp-Source: AMsMyM4F61+vt8GVeLhQ3y0+zKtAcqZ2TiMIM1wViK/O63f8KinrVxeoWn059sLeqhFwnYKaWedi X-Received: by 2002:a17:902:da92:b0:17f:9148:9b8c with SMTP id j18-20020a170902da9200b0017f91489b8cmr42854696plx.117.1666764012337; Tue, 25 Oct 2022 23:00:12 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1666764012; cv=none; d=google.com; s=arc-20160816; b=woYymu1G63wCYNiXjWb+CRJC/65c4PF5zVuR8dgZTKjoAzt8OOfAjNdDsC8EdD16Jc P3T3IkFB8e9IQ6bmup2F3NCupr74jCsvqoHqCCFrjPygDdP2o/8GY0fg5+1tDHocmIHq H245wpLnDTNeCGEWfoTtjr0ZYB1B60c/1bUN5w1Il/NsTU7mBVYpgD8neGCQt1M6Wwn3 6c4HZb+3+s3GEWLx1uhEdif9pgHbPwcE/nUN9o21JbBayGapBVZ/ddWP84JYdIbY8wc/ i5IfU5hrgjI1ru8oARz0eSqfWlH0gzit3YYdyomkOCmBt699rb3CA4vSaJ2tBZq9ongT 8iKg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:message-id:date:subject:cc:to:from; bh=1yQEY2H6UQk1F9b0QI0uA1C+vcYE++nxK/A2P1fnR2g=; b=cDRpwR8zO4pe9IaCdj87gImxs/jM6ue2l9dpOi/R8Rl4lEkuvaFMm31WK6MXJNmMFY U8uDDvx/QernlHEnk4h/12iPZ4RReQZJUl0mfSA+e5itjy7DWWCDG92YxO/AYqQtuAYN Ubz4lCTnjlI3vw5GfF9pv7PlvInBbwCAHfUt4c89ijXPTNzWR4TocLNBd+tmsyAWCm4j r23fgAnVlz00RDZEUOIM9Ta9LVBi5YdNpGsC7bjm6VC6wJYTlPo+YIpbNviR24evB4U0 ftQsrsCAbvhofA7TWb4ehV0r863MYmESemy1zgsJTno5zpB9Cqxy1NhiqiaYAjhoYmnu w06w== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id t16-20020a632250000000b0046edccffb8dsi6207563pgm.535.2022.10.25.22.59.59; Tue, 25 Oct 2022 23:00:12 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232504AbiJZFqH (ORCPT <rfc822;pwkd43@gmail.com> + 99 others); Wed, 26 Oct 2022 01:46:07 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:35918 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229551AbiJZFqF (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Wed, 26 Oct 2022 01:46:05 -0400 Received: from 1wt.eu (wtarreau.pck.nerim.net [62.212.114.60]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 79A7229C8C; Tue, 25 Oct 2022 22:46:03 -0700 (PDT) Received: (from willy@localhost) by pcw.home.local (8.15.2/8.15.2/Submit) id 29Q5jtWm019680; Wed, 26 Oct 2022 07:45:55 +0200 From: Willy Tarreau <w@1wt.eu> To: "Paul E. McKenney" <paulmck@kernel.org> Cc: linux-kselftest@vger.kernel.org, linux-kernel@vger.kernel.org, Willy Tarreau <w@1wt.eu> Subject: [PATCH] selftests/nolibc: always rebuild the sysroot when running a test Date: Wed, 26 Oct 2022 07:45:08 +0200 Message-Id: <20221026054508.19634-1-w@1wt.eu> X-Mailer: git-send-email 2.17.5 X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,SPF_HELO_PASS, SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1747728740689859300?= X-GMAIL-MSGID: =?utf-8?q?1747728740689859300?= |
Series |
selftests/nolibc: always rebuild the sysroot when running a test
|
|
Commit Message
Willy Tarreau
Oct. 26, 2022, 5:45 a.m. UTC
Paul and myself got trapped a few times by not seeing the effects of
applying a patch to the nolibc source code until a "make clean" was
issued in the nolibc directory. It's particularly annoying when trying
to confirm that a proposed patch really solves a problem (or that
reverting it reintroduces the problem).
The reason for the sysroot not being rebuilt was that it can be quite
slow. But in fact it's only slow after a "make clean" issued at the
kernel's topdir, because it's the main "make headers" that can take a
tens of seconds; as long as "usr/include" still contains headers, the
"headers_install" phase is only a quick "rsync", and rebuilding the
whole nolibc sysroot takes a bit less than one second, which is perfectly
acceptable for a test, even more once the time lost caused by misleading
results if factored in.
This patch marks the sysroot target as phony and starts by clearing
the previous sysroot for the current architecture before reinstalling
it. Thanks to this, applying a patch to nolibc makes the effect
immediately visible to "make nolibc-test":
$ time make -j -C tools/testing/selftests/nolibc nolibc-test
make: Entering directory '/k/tools/testing/selftests/nolibc'
MKDIR sysroot/x86/include
make[1]: Entering directory '/k/tools/include/nolibc'
make[2]: Entering directory '/k'
make[2]: Leaving directory '/k'
make[2]: Entering directory '/k'
INSTALL /k/tools/testing/selftests/nolibc/sysroot/sysroot/include
make[2]: Leaving directory '/k'
make[1]: Leaving directory '/k/tools/include/nolibc'
CC nolibc-test
make: Leaving directory '/k/tools/testing/selftests/nolibc'
real 0m0.869s
user 0m0.716s
sys 0m0.149s
Cc: "Paul E. McKenney" <paulmck@kernel.org>
Link: https://lore.kernel.org/all/20221021155645.GK5600@paulmck-ThinkPad-P17-Gen-1/
Signed-off-by: Willy Tarreau <w@1wt.eu>
---
tools/testing/selftests/nolibc/Makefile | 3 +++
1 file changed, 3 insertions(+)
Comments
On Wed, Oct 26, 2022 at 07:45:08AM +0200, Willy Tarreau wrote: > Paul and myself got trapped a few times by not seeing the effects of > applying a patch to the nolibc source code until a "make clean" was > issued in the nolibc directory. It's particularly annoying when trying > to confirm that a proposed patch really solves a problem (or that > reverting it reintroduces the problem). > > The reason for the sysroot not being rebuilt was that it can be quite > slow. But in fact it's only slow after a "make clean" issued at the > kernel's topdir, because it's the main "make headers" that can take a > tens of seconds; as long as "usr/include" still contains headers, the > "headers_install" phase is only a quick "rsync", and rebuilding the > whole nolibc sysroot takes a bit less than one second, which is perfectly > acceptable for a test, even more once the time lost caused by misleading > results if factored in. > > This patch marks the sysroot target as phony and starts by clearing > the previous sysroot for the current architecture before reinstalling > it. Thanks to this, applying a patch to nolibc makes the effect > immediately visible to "make nolibc-test": > > $ time make -j -C tools/testing/selftests/nolibc nolibc-test > make: Entering directory '/k/tools/testing/selftests/nolibc' > MKDIR sysroot/x86/include > make[1]: Entering directory '/k/tools/include/nolibc' > make[2]: Entering directory '/k' > make[2]: Leaving directory '/k' > make[2]: Entering directory '/k' > INSTALL /k/tools/testing/selftests/nolibc/sysroot/sysroot/include > make[2]: Leaving directory '/k' > make[1]: Leaving directory '/k/tools/include/nolibc' > CC nolibc-test > make: Leaving directory '/k/tools/testing/selftests/nolibc' > > real 0m0.869s > user 0m0.716s > sys 0m0.149s > > Cc: "Paul E. McKenney" <paulmck@kernel.org> > Link: https://lore.kernel.org/all/20221021155645.GK5600@paulmck-ThinkPad-P17-Gen-1/ > Signed-off-by: Willy Tarreau <w@1wt.eu> Works like a champ with reverting and unreverting c9388e0c1c6c ("tools/nolibc/string: Fix memcmp() implementation"), thank you!!! I have queued this. I expect to push this into the next merge window, thus avoiding the need to document the need for "make clean" in my pull request. ;-) Thanx, Paul > --- > tools/testing/selftests/nolibc/Makefile | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/tools/testing/selftests/nolibc/Makefile b/tools/testing/selftests/nolibc/Makefile > index 69ea659caca9..22f1e1d73fa8 100644 > --- a/tools/testing/selftests/nolibc/Makefile > +++ b/tools/testing/selftests/nolibc/Makefile > @@ -95,6 +95,7 @@ all: run > sysroot: sysroot/$(ARCH)/include > > sysroot/$(ARCH)/include: > + $(Q)rm -rf sysroot/$(ARCH) sysroot/sysroot > $(QUIET_MKDIR)mkdir -p sysroot > $(Q)$(MAKE) -C ../../../include/nolibc ARCH=$(ARCH) OUTPUT=$(CURDIR)/sysroot/ headers_standalone > $(Q)mv sysroot/sysroot sysroot/$(ARCH) > @@ -133,3 +134,5 @@ clean: > $(Q)rm -rf initramfs > $(call QUIET_CLEAN, run.out) > $(Q)rm -rf run.out > + > +.PHONY: sysroot/$(ARCH)/include > -- > 2.35.3 >
On Wed, Oct 26, 2022 at 09:48:25AM -0700, Paul E. McKenney wrote: > On Wed, Oct 26, 2022 at 07:45:08AM +0200, Willy Tarreau wrote: > Works like a champ with reverting and unreverting c9388e0c1c6c > ("tools/nolibc/string: Fix memcmp() implementation"), thank you!!! Thanks for the feedback, and glad it suits your needs as well. I hope that it will progressively encourage a few of us to enhance it with more tests. > I have queued this. I expect to push this into the next merge window, > thus avoiding the need to document the need for "make clean" in my > pull request. ;-) Stupid question, is it really worth postponing it, considering that we've just introduced this series right now ? I mean, if the current usage is confusing, it's probably better to propose the fix before 6.1-final ? It's not a new feature here but rather a fix for a recently introduced one, thus I think it could be part of the next fix series. Rest assured I don't want to put a mess into your patch workflow, just asking :-) Thanks! Willy
On Wed, Oct 26, 2022 at 09:59:02PM +0200, Willy Tarreau wrote: > On Wed, Oct 26, 2022 at 09:48:25AM -0700, Paul E. McKenney wrote: > > On Wed, Oct 26, 2022 at 07:45:08AM +0200, Willy Tarreau wrote: > > Works like a champ with reverting and unreverting c9388e0c1c6c > > ("tools/nolibc/string: Fix memcmp() implementation"), thank you!!! > > Thanks for the feedback, and glad it suits your needs as well. I > hope that it will progressively encourage a few of us to enhance > it with more tests. Here is hoping! ;-) > > I have queued this. I expect to push this into the next merge window, > > thus avoiding the need to document the need for "make clean" in my > > pull request. ;-) > > Stupid question, is it really worth postponing it, considering that > we've just introduced this series right now ? I mean, if the current > usage is confusing, it's probably better to propose the fix before > 6.1-final ? It's not a new feature here but rather a fix for a recently > introduced one, thus I think it could be part of the next fix series. > Rest assured I don't want to put a mess into your patch workflow, just > asking :-) You lost me here. My intent is to push these nolicb patches into the upcoming v6.2 merge window: 2318a710bffbd tools/nolibc: Fix missing strlen() definition and infinite loop with gcc-12 6937b8de8f1c3 tools/nolibc/string: Fix memcmp() implementation e1bbfe393c900 selftests/nolibc: Add 7 tests for memcmp() 3f2c1c45a3a9a selftests/nolibc: Always rebuild the sysroot when running a test I didn't see the problem until I queued the third patch (e1bbfe393c900), and it is still in -rcu, not in v6.1. What am I missing here? Thanx, Paul
On Wed, Oct 26, 2022 at 01:41:38PM -0700, Paul E. McKenney wrote: > > > I have queued this. I expect to push this into the next merge window, > > > thus avoiding the need to document the need for "make clean" in my > > > pull request. ;-) > > > > Stupid question, is it really worth postponing it, considering that > > we've just introduced this series right now ? I mean, if the current > > usage is confusing, it's probably better to propose the fix before > > 6.1-final ? It's not a new feature here but rather a fix for a recently > > introduced one, thus I think it could be part of the next fix series. > > Rest assured I don't want to put a mess into your patch workflow, just > > asking :-) > > You lost me here. Ah sorry! > My intent is to push these nolicb patches into the upcoming v6.2 > merge window: > > 2318a710bffbd tools/nolibc: Fix missing strlen() definition and infinite loop with gcc-12 > 6937b8de8f1c3 tools/nolibc/string: Fix memcmp() implementation > e1bbfe393c900 selftests/nolibc: Add 7 tests for memcmp() > 3f2c1c45a3a9a selftests/nolibc: Always rebuild the sysroot when running a test > > I didn't see the problem until I queued the third patch (e1bbfe393c900), > and it is still in -rcu, not in v6.1. > > What am I missing here? I thought that since some of them are fixes, they would be pushed during 6.1-rc so that we don't release 6.1 with known defects. For example Rasmus' fix for memcmp() or the strlen() fix would IMHO make sense for this release since we're aware of the bugs and we have the fixes. The 3rd one is indeed an addition and in no way a fix and it can easily wait for 6.2. The 4th one is more of a usability fix but I agree that for this last one it's debatable, I was mostly seeing this as a possiility to avoid causing needless confusion. Hoping this clarifies my initial question. Thanks, Willy
On Thu, Oct 27, 2022 at 04:34:56AM +0200, Willy Tarreau wrote: > On Wed, Oct 26, 2022 at 01:41:38PM -0700, Paul E. McKenney wrote: > > > > I have queued this. I expect to push this into the next merge window, > > > > thus avoiding the need to document the need for "make clean" in my > > > > pull request. ;-) > > > > > > Stupid question, is it really worth postponing it, considering that > > > we've just introduced this series right now ? I mean, if the current > > > usage is confusing, it's probably better to propose the fix before > > > 6.1-final ? It's not a new feature here but rather a fix for a recently > > > introduced one, thus I think it could be part of the next fix series. > > > Rest assured I don't want to put a mess into your patch workflow, just > > > asking :-) > > > > You lost me here. > > Ah sorry! > > > My intent is to push these nolicb patches into the upcoming v6.2 > > merge window: > > > > 2318a710bffbd tools/nolibc: Fix missing strlen() definition and infinite loop with gcc-12 > > 6937b8de8f1c3 tools/nolibc/string: Fix memcmp() implementation > > e1bbfe393c900 selftests/nolibc: Add 7 tests for memcmp() > > 3f2c1c45a3a9a selftests/nolibc: Always rebuild the sysroot when running a test > > > > I didn't see the problem until I queued the third patch (e1bbfe393c900), > > and it is still in -rcu, not in v6.1. > > > > What am I missing here? > > I thought that since some of them are fixes, they would be pushed during > 6.1-rc so that we don't release 6.1 with known defects. For example Rasmus' > fix for memcmp() or the strlen() fix would IMHO make sense for this > release since we're aware of the bugs and we have the fixes. The 3rd one > is indeed an addition and in no way a fix and it can easily wait for 6.2. > The 4th one is more of a usability fix but I agree that for this last one > it's debatable, I was mostly seeing this as a possiility to avoid causing > needless confusion. > > Hoping this clarifies my initial question. Very much so, thank you! I was not considering the bug fixed by the first two patches to be serious, my mistake, apologies for my misclassification. Given that background, I would rebase these two, test them, and send off a pull request, probably early next week. 2318a710bffbd tools/nolibc: Fix missing strlen() definition and infinite loop with gcc-12 6937b8de8f1c3 tools/nolibc/string: Fix memcmp() implementation I would push the other two commits into the upcoming merge window. Or might the discussion between you and Rasmus result in changes to either of those first two commits? If so, I should of course wait for that discussion to resolve. Thanx, Paul
On Thu, Oct 27, 2022 at 10:04:53AM -0700, Paul E. McKenney wrote: > > > My intent is to push these nolicb patches into the upcoming v6.2 > > > merge window: > > > > > > 2318a710bffbd tools/nolibc: Fix missing strlen() definition and infinite loop with gcc-12 > > > 6937b8de8f1c3 tools/nolibc/string: Fix memcmp() implementation > > > e1bbfe393c900 selftests/nolibc: Add 7 tests for memcmp() > > > 3f2c1c45a3a9a selftests/nolibc: Always rebuild the sysroot when running a test > > > > > > I didn't see the problem until I queued the third patch (e1bbfe393c900), > > > and it is still in -rcu, not in v6.1. > > > > > > What am I missing here? > > > > I thought that since some of them are fixes, they would be pushed during > > 6.1-rc so that we don't release 6.1 with known defects. For example Rasmus' > > fix for memcmp() or the strlen() fix would IMHO make sense for this > > release since we're aware of the bugs and we have the fixes. The 3rd one > > is indeed an addition and in no way a fix and it can easily wait for 6.2. > > The 4th one is more of a usability fix but I agree that for this last one > > it's debatable, I was mostly seeing this as a possiility to avoid causing > > needless confusion. > > > > Hoping this clarifies my initial question. > > Very much so, thank you! > > I was not considering the bug fixed by the first two patches to be > serious, my mistake, apologies for my misclassification. No worries, I wasn't probably clear upfront about the purpose. > Given that background, I would rebase these two, test them, and send > off a pull request, probably early next week. > > 2318a710bffbd tools/nolibc: Fix missing strlen() definition and infinite loop with gcc-12 > 6937b8de8f1c3 tools/nolibc/string: Fix memcmp() implementation Perfect, thank you! > I would push the other two commits into the upcoming merge window. OK! > Or might the discussion between you and Rasmus result in changes to > either of those first two commits? If so, I should of course wait for > that discussion to resolve. We'll see, but in any case it would just be a minor detail, but I'll give you a quick response so that you don't have to deal with multiple versions of the patch, we all know that it's painful. Thanks! Willy
On Thu, Oct 27, 2022 at 07:13:08PM +0200, Willy Tarreau wrote: > On Thu, Oct 27, 2022 at 10:04:53AM -0700, Paul E. McKenney wrote: > > > > My intent is to push these nolicb patches into the upcoming v6.2 > > > > merge window: > > > > > > > > 2318a710bffbd tools/nolibc: Fix missing strlen() definition and infinite loop with gcc-12 > > > > 6937b8de8f1c3 tools/nolibc/string: Fix memcmp() implementation > > > > e1bbfe393c900 selftests/nolibc: Add 7 tests for memcmp() > > > > 3f2c1c45a3a9a selftests/nolibc: Always rebuild the sysroot when running a test > > > > > > > > I didn't see the problem until I queued the third patch (e1bbfe393c900), > > > > and it is still in -rcu, not in v6.1. > > > > > > > > What am I missing here? > > > > > > I thought that since some of them are fixes, they would be pushed during > > > 6.1-rc so that we don't release 6.1 with known defects. For example Rasmus' > > > fix for memcmp() or the strlen() fix would IMHO make sense for this > > > release since we're aware of the bugs and we have the fixes. The 3rd one > > > is indeed an addition and in no way a fix and it can easily wait for 6.2. > > > The 4th one is more of a usability fix but I agree that for this last one > > > it's debatable, I was mostly seeing this as a possiility to avoid causing > > > needless confusion. > > > > > > Hoping this clarifies my initial question. > > > > Very much so, thank you! > > > > I was not considering the bug fixed by the first two patches to be > > serious, my mistake, apologies for my misclassification. > > No worries, I wasn't probably clear upfront about the purpose. > > > Given that background, I would rebase these two, test them, and send > > off a pull request, probably early next week. > > > > 2318a710bffbd tools/nolibc: Fix missing strlen() definition and infinite loop with gcc-12 > > 6937b8de8f1c3 tools/nolibc/string: Fix memcmp() implementation > > Perfect, thank you! > > > I would push the other two commits into the upcoming merge window. > > OK! > > > Or might the discussion between you and Rasmus result in changes to > > either of those first two commits? If so, I should of course wait for > > that discussion to resolve. > > We'll see, but in any case it would just be a minor detail, but I'll > give you a quick response so that you don't have to deal with multiple > versions of the patch, we all know that it's painful. If I don't hear otherwise from you by the end of tomorrow (Friday), Pacific Time, I will rebase those two patches in preparation for sending a pull request for the regression. I will of course run the pull-message text past you before sending the pull request. Thanx, Paul
Hi Paul, On Thu, Oct 27, 2022 at 11:26:29AM -0700, Paul E. McKenney wrote: > > We'll see, but in any case it would just be a minor detail, but I'll > > give you a quick response so that you don't have to deal with multiple > > versions of the patch, we all know that it's painful. > > If I don't hear otherwise from you by the end of tomorrow (Friday), > Pacific Time, I will rebase those two patches in preparation for sending > a pull request for the regression. I will of course run the pull-message > text past you before sending the pull request. No news on this front, so feel free to pick what you already have. Thank you! Willy
On Fri, Oct 28, 2022 at 09:34:05PM +0200, Willy Tarreau wrote: > Hi Paul, > > On Thu, Oct 27, 2022 at 11:26:29AM -0700, Paul E. McKenney wrote: > > > We'll see, but in any case it would just be a minor detail, but I'll > > > give you a quick response so that you don't have to deal with multiple > > > versions of the patch, we all know that it's painful. > > > > If I don't hear otherwise from you by the end of tomorrow (Friday), > > Pacific Time, I will rebase those two patches in preparation for sending > > a pull request for the regression. I will of course run the pull-message > > text past you before sending the pull request. > > No news on this front, so feel free to pick what you already have. Very good, thank you! I currently expect to send something like the pull request shown below early next week. Thoughts? Thanx, Paul ------------------------------------------------------------------------ Hello, Linus, This pull request fixes a couple of nolibc string-function bugs noted by kernel test robot, Rasmus Villemoes, Willy Tarreau. The following changes since commit 9abf2313adc1ca1b6180c508c25f22f9395cc780: Linux 6.1-rc1 (2022-10-16 15:36:24 -0700) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git tags/nolibc-urgent.2022.10.28a for you to fetch changes up to b3f4f51ea68a495f8a5956064c33dce711a2df91: tools/nolibc/string: Fix memcmp() implementation (2022-10-28 15:07:02 -0700) ---------------------------------------------------------------- Urgent nolibc pull request for v6.1 This pull request contains a couple of commits that fix string-function bugs introduced by: 96980b833a21 ("tools/nolibc/string: do not use __builtin_strlen() at -O0") 66b6f755ad45 ("rcutorture: Import a copy of nolibc") These appeared in v5.19 and v5.0, respectively, but it would be good to get these fixes in sooner rather than later. Commits providing the corresponding tests are in -rcu and I expect to submit them into the upcoming v6.2 merge window. ---------------------------------------------------------------- Rasmus Villemoes (1): tools/nolibc/string: Fix memcmp() implementation Willy Tarreau (1): tools/nolibc: Fix missing strlen() definition and infinite loop with gcc-12 tools/include/nolibc/string.h | 17 ++++++++++------- 1 file changed, 10 insertions(+), 7 deletions(-)
On Fri, Oct 28, 2022 at 03:22:14PM -0700, Paul E. McKenney wrote: > I currently expect to send something like the pull request shown > below early next week. > > Thoughts? That's perfect, thank you Paul! Willy
diff --git a/tools/testing/selftests/nolibc/Makefile b/tools/testing/selftests/nolibc/Makefile index 69ea659caca9..22f1e1d73fa8 100644 --- a/tools/testing/selftests/nolibc/Makefile +++ b/tools/testing/selftests/nolibc/Makefile @@ -95,6 +95,7 @@ all: run sysroot: sysroot/$(ARCH)/include sysroot/$(ARCH)/include: + $(Q)rm -rf sysroot/$(ARCH) sysroot/sysroot $(QUIET_MKDIR)mkdir -p sysroot $(Q)$(MAKE) -C ../../../include/nolibc ARCH=$(ARCH) OUTPUT=$(CURDIR)/sysroot/ headers_standalone $(Q)mv sysroot/sysroot sysroot/$(ARCH) @@ -133,3 +134,5 @@ clean: $(Q)rm -rf initramfs $(call QUIET_CLEAN, run.out) $(Q)rm -rf run.out + +.PHONY: sysroot/$(ARCH)/include