[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <f6aa6991-4c52-787c-a9c6-75f91e40548e@net4u.de>
Date: Wed, 26 Oct 2022 08:36:55 +0200
From: Ernst Herzberg <earny@...4u.de>
To: Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
linux-kernel@...r.kernel.org
Cc: stable@...r.kernel.org, torvalds@...ux-foundation.org,
akpm@...ux-foundation.org, linux@...ck-us.net, shuah@...nel.org,
patches@...nelci.org, lkft-triage@...ts.linaro.org, pavel@...x.de,
jonathanh@...dia.com, f.fainelli@...il.com,
sudipm.mukherjee@...il.com, srw@...dewatkins.net
Subject: Re: [PATCH 6.0 00/20] 6.0.4-rc1 review
Missed a patch?
Problematic patch in v6.0.3 :
> commit 3ea7c50339859394dd667184b5b16eee1ebb53bc
> Author: Josef Bacik <josef@...icpanda.com>
> Date: Mon Aug 8 16:10:26 2022 -0400
>
> btrfs: call __btrfs_remove_free_space_cache_locked on cache load failure
> [ Upstream commit 8a1ae2781dee9fc21ca82db682d37bea4bd074ad ]
> Now that lockdep is staying enabled through our entire CI runs I started
> seeing the following stack in generic/475
See:
https://lore.kernel.org/stable/Y1aeWdHd4%2FluzhAu@localhost.localdomain/
>
> Well I definitely fucked this patch up, because I should have used the _locked
> variant, but this was part of a series where I did the correct thing in the next
> patch
>
> btrfs: remove use btrfs_remove_free_space_cache instead of variant
>
> so this problem doesn't exist in linus. So either we need to pull that back
> into stable as well, or drop this patch from stable. I'm good either way, this
> was just to fix a lockdep splat so it's not really stable material, but I'll
> leave that decision up to y'all. Thanks,
>
> Josef
>
>
Powered by blists - more mailing lists