linux-kernel - Re: [PATCH] btrfs: avoid link error with CONFIG_NO_AUTO

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]

Date:   Mon, 5 Nov 2018 22:27:03 +0100
From:   Arnd Bergmann <arnd@...db.de>
To:     dsterba@...e.cz, Arnd Bergmann <arnd@...db.de>,
        Qu Wenruo <wqu@...e.de>, Chris Mason <clm@...com>,
        David Sterba <DSterba@...e.com>,
        Josef Bacik <josef@...icpanda.com>,
        Gu Jinxiang <gujx@...fujitsu.com>,
        Changbin Du <changbin.du@...il.com>,
        Misono Tomohiro <misono.tomohiro@...fujitsu.com>,
        Anand Jain <anand.jain@...cle.com>,
        Nikolay Borisov <nborisov@...e.com>,
        linux-btrfs@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] btrfs: avoid link error with CONFIG_NO_AUTO_INLINE

On 11/5/18, David Sterba <dsterba@...e.cz> wrote:
> On Sun, Nov 04, 2018 at 11:32:03PM +0100, Arnd Bergmann wrote:
>> >> Cc: Changbin Du <changbin.du@...il.com>
>> >> Fixes: 943b8435c3bd ("kernel hacking: add a config option to disable
>> >> compiler auto-inlining")
>> >
>> > I can't find it in the mainline kernel, is the commit hash correct?
>> > If not merged, we should still has a chance to further polish that
>> > patch.
>>
>> It's in linux-next.
>
> I can't find it in current linux-next either, the final reference in
> Fixes: must refer to a commit in Linus' tree.

Ah, right, it got rebased. The commit ID in today's linux-next
is 917fad29febd. Most trees in linux-next don't rebase so this
would not be an issue, but you are right that this one clearly
did, so the line is wrong here.

The commit is now delayed until 4.21 I assume.

> You can take this fix with the patch that introduces the config option
> (ack for that) in case merging through the btrfs tree would be too late
> for it (ie. no common base for the git trees containg the new code and
> fix).
>
> Or I can take it through btrfs tree in 4.20-rc cycle. In both cases the
> Fixes: does not need to be there.

Please take it through the btrfs tree. Let me know if you need me
to extend the changelog to explain that situation better.

      Arnd