linux-kernel - Re: nolibc changes since 6.6-rc1 for linux-next

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <ZSPr6IonkLryUb0s@1wt.eu>
Date:   Mon, 9 Oct 2023 14:02:48 +0200
From:   Willy Tarreau <w@....eu>
To:     Thomas Weißschuh <linux@...ssschuh.net>
Cc:     "Paul E. McKenney" <paulmck@...nel.org>,
        Shuah Khan <skhan@...uxfoundation.org>,
        Shuah Khan <shuah@...nel.org>, linux-kernel@...r.kernel.org
Subject: Re: nolibc changes since 6.6-rc1 for linux-next

On Mon, Oct 09, 2023 at 01:25:58PM +0200, Thomas Weißschuh wrote:
> On 2023-10-08 09:27:43-0700, Paul E. McKenney wrote:
> 
> > [..]
> 
> > The other approach involves rebasing the "nolibc/next" stack
> > on top of the "nolibc/fixes" stack.  Please see the -rcu branch
> > nolibc-rebase.2023.10.08a to see how that would look.  Note that the
> > rebase process detected and eliminated the duplicate commits.
> > In this case, I actually used "git cherry-pick":
> > 
> > 	git checkout -b nolibc-rebase.2023.10.08a nolibc/fixes
> > 	git cherry-pick v6.6-rc1..nolibc/next
> > 	git cherry-pick skip # After complaint about first duplicate
> > 	git cherry-pick --continue
> > 	git cherry-pick skip # After complaint about second duplicate
> > 	git cherry-pick --continue
> > 	git diff nolibc-merge.2023.10.08a # Verify no differences
> > 
> > You could just as easily do this:
> > 
> > 	git branch nolibc-rebase.2023.10.08a nolibc/next
> > 	git rebase --onto nolibc/next v6.6-rc1 nolibc-rebase.2023.10.08a
> > 
> > There would be the same complaints about duplicate commits and
> > similar response (it prompts you with your alternatives).
> > 
> > And then I send the fixes portion of the branch to Linus after a few
> > days of exposure to -next testing, and the full branch for the upcoming
> > merge window.
> > 
> > Test results for nolibc-rebase.2023.10.08a:
> > "make run": 160 test(s): 158 passed,   2 skipped,   0 failed => status: warning
> > "make run-user": 160 test(s): 158 passed,   2 skipped,   0 failed => status: warning
> > 
> > This approach has its strenghts and weaknesses.
> > 
> > 1.	It avoids all the weaknesses called out for merging.
> > 
> > 2.	It can require more testing when moving yet another commit
> > 	down into urgent-fixes portion of the branch.
> > 
> > 3.	Many people are much less comfortable rebasing and mass
> > 	cherry-picking than they are with merging.
> > 
> > Again, I am happy to do this either way (especially since I now have
> > both ways set up in -rcu), but felt the need to call out the strengths
> > and weaknesses of each approach.  Your guys' choice.
> 
> Your proposed aproach sounds great, thanks for all your patience.
> 
> I implemented it now at
> https://git.kernel.org/pub/scm/linux/kernel/git/nolibc/linux-nolibc.git/
> 
> Please pull the changes in this repository since the v6.6-rc1 tag.
> 
> The branch 'fixes' up to and including
> 5579b93524ab2d360e2250bdd12ba32635a4300b for the v6.6 cycle.
> 
> The branch 'next' up to and including
> d423dcd4ac21041618ab83455c09440d76dbc099 for linux-next.
> 
> The branch 'next', based upon 'fixes', was tested as follows:
> 
> i386:          160 test(s): 160 passed,   0 skipped,   0 failed => status: success
> x86_64:        160 test(s): 160 passed,   0 skipped,   0 failed => status: success
> arm64:         160 test(s): 160 passed,   0 skipped,   0 failed => status: success
> arm:           160 test(s): 160 passed,   0 skipped,   0 failed => status: success
> mips:          160 test(s): 159 passed,   1 skipped,   0 failed => status: warning
> ppc:           160 test(s): 160 passed,   0 skipped,   0 failed => status: success
> ppc64:         160 test(s): 160 passed,   0 skipped,   0 failed => status: success
> ppc64le:       160 test(s): 160 passed,   0 skipped,   0 failed => status: success
> riscv:         160 test(s): 160 passed,   0 skipped,   0 failed => status: success
> s390:          160 test(s): 159 passed,   1 skipped,   0 failed => status: warning
> loongarch:     160 test(s): 159 passed,   1 skipped,   0 failed => status: warning
> 
> > While in the area, would the following (absolutely not urgent or even
> > particularly important) patch be a good idea?  This gets rid of a line
> > of noise from "git status" after running the tests.
> > 
> > 							Thanx, Paul
> > 
> > ------------------------------------------------------------------------
> > 
> > diff --git a/tools/testing/selftests/nolibc/.gitignore b/tools/testing/selftests/nolibc/.gitignore
> > index 52f613cdad54..3487da96e12e 100644
> > --- a/tools/testing/selftests/nolibc/.gitignore
> > +++ b/tools/testing/selftests/nolibc/.gitignore
> > @@ -3,3 +3,4 @@
> >  /nolibc-test
> >  /run.out
> >  /sysroot/
> > +/initramfs.cpio
> 
> Thanks, I folded this into commit
> fdaa5901424c ("selftests/nolibc: don't embed initramfs into kernel image"),
> where it belongs.

Nice work, thanks very much Thomas!
Willy