linux-kernel - Re: [PATCH] btrfs: Disable BTRFS on platforms having 256K pages

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:   Fri, 11 Jun 2021 16:56:31 +0000
From:   Chris Mason <clm@...com>
To:     "dsterba@...e.cz" <dsterba@...e.cz>
CC:     Christophe Leroy <christophe.leroy@...roup.eu>,
        Josef Bacik <josef@...icpanda.com>,
        David Sterba <dsterba@...e.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linuxppc-dev@...ts.ozlabs.org" <linuxppc-dev@...ts.ozlabs.org>,
        linux-btrfs <linux-btrfs@...r.kernel.org>,
        "linux-hexagon@...r.kernel.org" <linux-hexagon@...r.kernel.org>
Subject: Re: [PATCH] btrfs: Disable BTRFS on platforms having 256K pages


> On Jun 11, 2021, at 9:21 AM, David Sterba <dsterba@...e.cz> wrote:
> 
> On Fri, Jun 11, 2021 at 12:58:58PM +0000, Chris Mason wrote:
>>> On Jun 10, 2021, at 12:20 PM, David Sterba <dsterba@...e.cz> wrote:
>>> On Thu, Jun 10, 2021 at 04:50:09PM +0200, Christophe Leroy wrote:
>>>> Le 10/06/2021 à 15:54, Chris Mason a écrit :
>>>>>> On Jun 10, 2021, at 1:23 AM, Christophe Leroy <christophe.leroy@...roup.eu> wrote:
>>> And there's no such thing like "just bump BTRFS_MAX_COMPRESSED to 256K".
>>> The constant is part of on-disk format for lzo and otherwise changing it
>>> would impact performance so this would need proper evaluation.
>> 
>> Sorry, how is it baked into LZO?  It definitely will have performance implications, I agree there.
> 
> lzo_decompress_bio:
> 
> 309         /*
> 310          * Compressed data header check.
> 311          *
> 312          * The real compressed size can't exceed the maximum extent length, and
> 313          * all pages should be used (whole unused page with just the segment
> 314          * header is not possible).  If this happens it means the compressed
> 315          * extent is corrupted.
> 316          */
> 317         if (tot_len > min_t(size_t, BTRFS_MAX_COMPRESSED, srclen) ||
> 318             tot_len < srclen - PAGE_SIZE) {
> 319                 ret = -EUCLEAN;
> 320                 goto done;
> 321         }

Ah I see, so going back to an old LZO kernel will get upset.  Ok, fair enough.  So if we want to bump this for other reasons, we’ll need to make an LZO max size to maintain compatibility.

-chris