From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 22BA3C352A8 for ; Thu, 26 Sep 2019 12:18:23 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id E8DA5207FF for ; Thu, 26 Sep 2019 12:18:22 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b="COZ7Z/I6" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726275AbfIZMSV (ORCPT ); Thu, 26 Sep 2019 08:18:21 -0400 Received: from new4-smtp.messagingengine.com ([66.111.4.230]:33037 "EHLO new4-smtp.messagingengine.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725768AbfIZMSV (ORCPT ); Thu, 26 Sep 2019 08:18:21 -0400 Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailnew.nyi.internal (Postfix) with ESMTP id 5D3012F12; Thu, 26 Sep 2019 08:18:20 -0400 (EDT) Received: from imap37 ([10.202.2.87]) by compute3.internal (MEProxy); Thu, 26 Sep 2019 08:18:20 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=TF2e2v 5QJWANq2RvA+l4zDSrT7f1zxrbP1wF6DFeYtk=; b=COZ7Z/I6Ef2JAcktyDpH1t fr6D5NZkAOJUOLF0SGltqlpNJX9DU06wPkTMsVjm1d6bEWTCS9mG5zCqEQxCe7I9 BBLG13s6cvcu3jCb13mdtr+BjtxsubwtiC7UJhIIaCgwHhBW7s5bH1vr3mcXIswT 6BzHiKqaWo8cJip2TD46PETshG3/wCRgoPr0VR6rQwop8UddmV8d2AkL+IaxSd/Z qsA3kz4tM3ev0ilBWmzDyytZjhj5/slzUSDbFfgqM9R8PZfraY3R14edkYN/hvQJ XvVa2UExj6XdVyXxmrnhz4yeCGzCKo+22/z/j/a8BZmjB3uFxvDvMgAp53Vb1Xsg == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrfeeggdehtdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefofgggkfgjfhffhffvufgtsehttdertderredtnecuhfhrohhmpedfveholhhi nhcuhggrlhhtvghrshdfuceofigrlhhtvghrshesvhgvrhgsuhhmrdhorhhgqeenucfrrg hrrghmpehmrghilhhfrhhomhepfigrlhhtvghrshesvhgvrhgsuhhmrdhorhhgnecuvehl uhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 6954C684005E; Thu, 26 Sep 2019 08:18:19 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.7-305-g4111847-fmstable-20190924v1 Mime-Version: 1.0 Message-Id: <4e6e03c1-b2f4-4841-99af-cbb75f33c14d@www.fastmail.com> In-Reply-To: References: <230a76e65372a8fb3ec62ce167d9322e5e342810.1568875700.git.osandov@fb.com> <20190924171513.GA39872@vader> <20190924193513.GA45540@vader> <20190925071129.GB804@dread.disaster.area> <60c48ac5-b215-44e1-a628-6145d84a4ce3@www.fastmail.com> Date: Thu, 26 Sep 2019 08:17:12 -0400 From: "Colin Walters" To: "Chris Mason" Cc: "Dave Chinner" , "Jann Horn" , "Omar Sandoval" , "Aleksa Sarai" , "Jens Axboe" , linux-fsdevel , "linux-btrfs@vger.kernel.org" , "Linux API" , "Kernel Team" , "Andy Lutomirski" Subject: Re: [RFC PATCH 2/3] add RWF_ENCODED for writing compressed data Content-Type: text/plain Sender: linux-fsdevel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org On Wed, Sep 25, 2019, at 10:56 AM, Chris Mason wrote: > The data is verified while being decompressed, but that's a fairly large > fuzzing surface (all of zstd, zlib, and lzo). A lot of people will > correctly argue that we already have that fuzzing surface today, but I'd > rather not make a really easy way to stuff arbitrary bytes through the > kernel decompression code until all the projects involved sign off. Right. So maybe have this start of as a BTRFS ioctl and require privileges? I assume that's sufficient for what Omar wants. (Are there actually any other popular Linux filesystems that do transparent compression anyways?)