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=-5.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,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 6AB4EC49EA6 for ; Fri, 25 Jun 2021 03:38:30 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 5246C61408 for ; Fri, 25 Jun 2021 03:38:30 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233039AbhFYDkt (ORCPT ); Thu, 24 Jun 2021 23:40:49 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:52130 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232996AbhFYDks (ORCPT ); Thu, 24 Jun 2021 23:40:48 -0400 Received: from casper.infradead.org (casper.infradead.org [IPv6:2001:8b0:10b:1236::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id AF3EBC061574; Thu, 24 Jun 2021 20:38:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=0xEoyc03QRzDwm8N8irQEtu2n+8qponPR4uYVpebZvo=; b=gZZt4qXmWPsA24pLdMdyYC7tQX YBe7kptZTgUXk1lY37p1Qvtfr6Oj043pb/Pl2nY8Mt8Hzx/rTbH9z/X+eK3d+v/B0SGIsZeWfmLHs n5F4OX3xivYUQm0y8NPfRnD4wC7zAr5SfNad5PUJ1GJ+jnVRRjAama6HxuHe+xXY+Cl4fUVMO6fkW E3nT9uo1CdPU9aQ5G/765rkcT74N47pE0TxZ7/JbkUDk2MVKh9Kmobyxf1YKVldR1OZIbWMuo3uiP KAobc4EZ+IXIl8lHiaW3y1LJ9/ep9D0cfF+rVMFxyFTKt9DubgZ92zB6/wY4FwLSfgihDw+WIoCQW wR7ILcTA==; Received: from willy by casper.infradead.org with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1lwcfX-00HGr3-3b; Fri, 25 Jun 2021 03:38:16 +0000 Date: Fri, 25 Jun 2021 04:38:15 +0100 From: Matthew Wilcox To: "Martin K. Petersen" Cc: Linus Torvalds , Omar Sandoval , Al Viro , Dave Chinner , linux-fsdevel , linux-btrfs , Linux API , Kernel Team , Dave Chinner Subject: Re: [PATCH RESEND x3 v9 1/9] iov_iter: add copy_struct_from_iter() Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org On Thu, Jun 24, 2021 at 06:41:52PM -0400, Martin K. Petersen wrote: > > Linus, > > > I also worry that this "raw compressed data" thing isn't the only > > thing people will want to do. I could easily see some kind of > > "end-to-end CRC read/write" where the user passes in not just the > > data, but also checksums for it to validate it (maybe because you're > > doing a file copy and had the original checksums, but also maybe > > because user space simply has a known good copy and doesn't want > > errors re-introduced due to memory corruption). > > We already support passing CRCs down to be validated by the hardware for > both NVMe and SCSI. This currently only works from the block layer > down. When enabled, the checksums are generated by the block layer for > writes and the data is validated against the checksums sent by the > storage on reads. > > Over the years various attempts at adding support for passing the > checksum buffers in from userland have failed for exactly the reasons > outlined in this thread (Joel, Darrick, Bob). Would love to have a > generic way of passing this kind of information... Does it make any kind of sense to talk about doing this for buffered I/O, given that we can't generate them for (eg) mmaped files? Or does this only make sense to pass in for O_DIRECT accesses?