linux-kernel - Re: [PATCH AUTOSEL 4.20 072/117] btrfs: alloc_chunk: fix more DUP stripe size handling

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 for Android: free password hash cracker in your pocket

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

Message-ID: <20190123174146.GV2900@twin.jikos.cz>
Date:   Wed, 23 Jan 2019 18:41:47 +0100
From:   David Sterba <dsterba@...e.cz>
To:     Hans van Kranenburg <Hans.van.Kranenburg@...dix.com>
Cc:     Sasha Levin <sashal@...nel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "stable@...r.kernel.org" <stable@...r.kernel.org>,
        David Sterba <dsterba@...e.com>,
        "linux-btrfs@...r.kernel.org" <linux-btrfs@...r.kernel.org>
Subject: Re: [PATCH AUTOSEL 4.20 072/117] btrfs: alloc_chunk: fix more DUP
 stripe size handling

On Wed, Jan 23, 2019 at 03:54:00PM +0000, Hans van Kranenburg wrote:
> On 1/23/19 3:37 PM, Sasha Levin wrote:
> > On Tue, Jan 08, 2019 at 11:52:02PM +0000, Hans van Kranenburg wrote:
> >> Hi Sasha,
> >>
> >> On 1/8/19 8:25 PM, Sasha Levin wrote:
> >>> From: Hans van Kranenburg <hans.van.kranenburg@...dix.com>
> >>>
> >>> [ Upstream commit baf92114c7e6dd6124aa3d506e4bc4b694da3bc3 ]
> >>>
> >>> Commit 92e222df7b "btrfs: alloc_chunk: fix DUP stripe size handling"
> >>> fixed calculating the stripe_size for a new DUP chunk.
> >>
> >> That one also ended up as:
> >>
> >> 4.14-stable
> >> 0136bd7238b2cb8238426af4183ed0b02165c3f9
> >>
> >> 4.9-stable
> >> 8890bae03f4dba1c2292e5445682b556af4e8f1b
> >>
> >> 4.4-stable
> >> 97c3e46ef53748278286fc09dcc30b138d6677c4
> >>
> >> 3.16.57-rc1
> >> f68f46284a199f6837c1d5b94a6ae979a2cc463c
> >>
> >> While hitting the failure condition without adding "crafting" steps to
> >> make it exactly match the scenario is unlikely, it might be good if we
> >> just go all the way back with this regression fix?
> > 
> > What do you mean with "all the way back"?
> 
> Oh, apologies for not using unambigious phrasing.
> 
> I mean, it seems the autoselection only found 92e222df7b in places where
> it's actually called 92e222df7b, and not where it was cherry-picked.
> 
> So, for my own understanding: If I have to do something like this ever
> again, then should I have added it like this inside baf92114c?
> 
> Fixes: 92e222df7b ("btrfs: alloc_chunk: fix DUP stripe size handling")
> Fixes: 0136bd7238 ("btrfs: alloc_chunk: fix DUP stripe size handling")
> Fixes: 8890bae03f ("btrfs: alloc_chunk: fix DUP stripe size handling")
> Fixes: 97c3e46ef5 ("btrfs: alloc_chunk: fix DUP stripe size handling")
> Fixes: f68f46284a ("btrfs: alloc_chunk: fix DUP stripe size handling")

The Fixes: tag should always refer to a commit id in Linus' tree, the
stable tree backports use that for common reference so the individual
commit ids of stable trees are not relevant.