linux-kernel - Re: [PATCH 5/9] btrfs: zstd: Switch to the zstd-1.4.6 API

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:   Wed, 16 Sep 2020 10:43:04 -0400
From:   "Chris Mason" <clm@...com>
To:     Christoph Hellwig <hch@...radead.org>
CC:     Nick Terrell <nickrterrell@...il.com>,
        Herbert Xu <herbert@...dor.apana.org.au>,
        <linux-crypto@...r.kernel.org>, <linux-btrfs@...r.kernel.org>,
        <squashfs-devel@...ts.sourceforge.net>,
        <linux-f2fs-devel@...ts.sourceforge.net>,
        <linux-kernel@...r.kernel.org>, Kernel Team <Kernel-team@...com>,
        Nick Terrell <terrelln@...com>, Petr Malat <oss@...at.biz>,
        Johannes Weiner <jweiner@...com>,
        Niket Agarwal <niketa@...com>, Yann Collet <cyan@...com>
Subject: Re: [PATCH 5/9] btrfs: zstd: Switch to the zstd-1.4.6 API

On 16 Sep 2020, at 10:30, Christoph Hellwig wrote:

> On Wed, Sep 16, 2020 at 10:20:52AM -0400, Chris Mason wrote:
>> It???s not completely clear what you???re asking for here.  If the 
>> API
>> matches what???s in zstd-1.4.6, that seems like a reasonable way to 
>> label
>> it.  That???s what the upstream is for this code.
>>
>> I???m also not sure why we???re taking extra time to shit on the zstd
>> userspace package.  Can we please be constructive or at least 
>> actionable?
>
> Because it really doesn't matter that these crappy APIs he is
> introducing match anything, especially not something done as horribly
> as the zstd API.  We'll need to do this properly, and claiming
> compliance to some version of this lousy API is completely irrelevant
> for the kernel.

If the underlying goal is to closely follow the upstream of another 
project, we’re much better off using those APIs as provided.

Otherwise we just end up with drift and kernel-specific bugs that are 
harder to debug.  To the extent those APIs make us contort the kernel 
code, I’m sure Nick is interested in improving things in both places.

There are probably 1000 constructive ways to have that conversation.  
Please choose one of those instead of being an asshole.

-chris