Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
MIME-Version: 1.0
References: <cover.1635773880.git.dsterba@suse.com>
In-Reply-To: <cover.1635773880.git.dsterba@suse.com>
From:   Linus Torvalds <torvalds@linux-foundation.org>
Date:   Mon, 1 Nov 2021 13:03:25 -0700
Message-ID: <CAHk-=wjowO+mmVBoiWkCk6LeqVTYVBp0ruSUPN2z0_ObKisPYw@mail.gmail.com>
Subject: Re: [GIT PULL] Btrfs updates for 5.16
To:     David Sterba <dsterba@suse.com>, Qu Wenruo <wqu@suse.com>
Cc:     linux-btrfs <linux-btrfs@vger.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

On Mon, Nov 1, 2021 at 9:46 AM David Sterba <dsterba@suse.com> wrote:
>
> There's a merge conflict due to the last minute 5.15 changes (kmap
> reverts) and the conflict is not trivial.

You don't say.

I ended up just re-doing that resolution entirely, and as I did so, I
think I found a bug in the original revert that caused the conflict in
the first place.

And since that revert made it into 5.15, I felt like I had to fix that
bug first - and separately - so that the fix can be backported to
stable.

I then re-did my merge on top of that hopefully fixed state, and maybe
it's correct.

Or maybe I messed up entirely.

I did end up comparing it to your other branch too, but that was
equally as messy, apart from the "ok, I can mindlessly just take your
side".

And it was fairly different from what I had done in my merge
resolution, so who knows.

ANYWAY. What I'm trying to say is that you should look very very
carefully at commits

  2cf3f8133bda ("btrfs: fix lzo_decompress_bio() kmap leakage")
  037c50bfbeb3 ("Merge tag 'for-5.16-tag' of git://git.../linux")

because I marked that first one for stable, and the second is
obviously my entirely untested merge.

It makes sense to me, but apart from "it builds", I've not actually
tested any of it. This is all purely from looking at the code and
trying to figure out what the RightThing(tm) is.

Obviously the kmap thing tends to only be noticeable on 32-bit
platforms, and that lzo_decompress_bio() bug also needs just the
proper filesystem settings to trigger in the first place.

Again - please take a careful look. Both at my merge and at that
alleged kmap fix.

                          Linus