linux-kernel - Re: [GIT PULL] Kbuild updates for v5.4-rc1

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: <20190917181636.7sngz5lrldx34rth@willie-the-truck>
Date:   Tue, 17 Sep 2019 19:16:37 +0100
From:   Will Deacon <will@...nel.org>
To:     Jessica Yu <jeyu@...nel.org>
Cc:     Masahiro Yamada <yamada.masahiro@...ionext.com>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Matthias Maennich <maennich@...gle.com>,
        gregkh@...uxfoundation.org,
        Linux Kbuild mailing list <linux-kbuild@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [GIT PULL] Kbuild updates for v5.4-rc1

Hi Jessica,

On Tue, Sep 17, 2019 at 08:01:36PM +0200, Jessica Yu wrote:
> Yikes, I did not catch Stephen Rothwell's email about pausing the
> linux-next releases from Sept 5 until Sept 30
> (https://lore.kernel.org/linux-next/20190904233443.3f73c46b@canb.auug.org.au/).
> 
> The modules-next namespace patches have been in since last Tuesday,
> and my original plan was for them to catch at least a week of
> linux-next time before sending the pull request. :-/ But that did not
> happen due to the above.
> 
> So Linus, in light of the above realization, I'd say at this time - I
> will still formally send a pull request with the merge conflicts
> resolved with either solution #2 or #3, but merge at your own
> discretion, it's fine to delay to the following release if you're
> uncomfortable.

FWIW, when I've run into unexpected merge conflicts with other trees in the
past, I've found that it's usually sufficient just to include the resolution
as an inline diff in the pull request, rather than try to munge the tree
with merges or rebases.  Linus is pretty good at figuring it out, and with a
resolution to compare with, the damage is limited. The downside of the merge
is that it's fiddly to extract the changes and see what's actually being
pulled.

Also, it's not like the kbuild stuff has been in -next for ages, so this
would've been a late and messy conflict regardless.

Will