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: <CAK8P3a3QQY3EqcdpogDR0TzPg61=y24aCYRpWWZGLe15GGPvdA@mail.gmail.com>
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ