linux-kernel - Re: [musl] Re: [GIT PULL] asm-generic changes for 5.19

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: <CAK8P3a2JgrW5a7_udCUWen-gOnJgVeRV2oAd-uq4VSuYkFUqNQ@mail.gmail.com>
Date:   Tue, 31 May 2022 10:09:26 +0200
From:   Arnd Bergmann <arnd@...nel.org>
To:     Huacai Chen <chenhuacai@...nel.org>
Cc:     musl@...ts.openwall.com, WANG Xuerui <kernel@...0n.name>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        linux-arch <linux-arch@...r.kernel.org>,
        GNU C Library <libc-alpha@...rceware.org>,
        Yoshinori Sato <ysato@...rs.sourceforge.jp>,
        Peter Zijlstra <peterz@...radead.org>,
        Marc Zyngier <maz@...nel.org>,
        Masahiro Yamada <masahiroy@...nel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Jiaxun Yang <jiaxun.yang@...goat.com>,
        ACPI Devel Maling List <linux-acpi@...r.kernel.org>,
        Jianmin Lv <lvjianmin@...ngson.cn>,
        linux-pci <linux-pci@...r.kernel.org>,
        Ard Biesheuvel <ardb@...nel.org>,
        Huacai Chen <chenhuacai@...ngson.cn>
Subject: Re: [musl] Re: [GIT PULL] asm-generic changes for 5.19

On Tue, May 31, 2022 at 9:50 AM Huacai Chen <chenhuacai@...nel.org> wrote:
> On Mon, May 30, 2022 at 11:56 PM Arnd Bergmann <arnd@...nel.org> wrote:
> > On Mon, May 30, 2022 at 5:00 PM WANG Xuerui <kernel@...0n.name> wrote:
> > > Now I see
> > > the loongarch-next HEAD is already rebased on top of what I believe to
> > > be the current main branch, however I vaguely remember that it's not
> > > good to base one's patches on top of "some random commit", so I wonder
> > > whether the current branch state is appropriate for a PR?
> >
> > You are correct, a pull request should always be based on an -rc, orat least
> > have the minimum set of dependencies. The branch was previously
> > based on top of the spinlock implementation, which is still the best
> > place to start here.
> I have a difficult problem to select the base. Take swiotlb_init() as
> an example: If I select 5.18-rc1, I should use swiotlb_init(1); if I
> select Linus' latest tree, I should use swiotlb_init(true,
> SWIOTLB_VERBOSE). However, if I select 5.18-rc1, linux-next will have
> a build error because the code there expect swiotlb_init(true,
> SWIOTLB_VERBOSE).

Ok, I see. This is the kind of thing we normally prevent by having everything
in linux-next for a few weeks before the merge window. How many issues
like this are you aware of? If it's just the swiotlb, you could try merging
the swiotlb branch that is in mainline now on top of the spinlock branch,
and still get a minimum set of dependencies. If there are many more,
then basing on top of the current mainline is probably less intrusive after
all.

       Arnd