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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id D5995CDB483 for ; Sun, 15 Oct 2023 06:32:37 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230217AbjJOGch (ORCPT ); Sun, 15 Oct 2023 02:32:37 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57416 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229554AbjJOGcg (ORCPT ); Sun, 15 Oct 2023 02:32:36 -0400 Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D6551C5; Sat, 14 Oct 2023 23:32:35 -0700 (PDT) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 5D8B2C433C8; Sun, 15 Oct 2023 06:32:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1697351555; bh=d6xuGOzJZuwgxDsW1KDIXHD7c4zgZAlt19ISSXfUsRQ=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=afuskj+eSjn5goaasZk2ohUalSh4RQn/57gw9Cv0Bqz/+vhs/bKkx07a9xK3nXSPa II3s8NLkxL6A3bEdIh1S+Cw3+OmfUJ0M62Sv4frdXqOgFA03BYy3McrUKvJSGz2ewJ CVcE0/51ax3RCLAnoBLfWIohg3TfMDPswO5gsbHuFnGEGqoJL+sPaP1ULKVcmvlZMR YORsudrrSv3cBh4IHgONztOny2sYLNruxW5F8YqPTB1QkxyOyux609TOsHFtD8zOE2 S5opfDksetDsuSLUJxRn9YbSnSYLFQQWJsaN7fidVHZ9HyWBR5WMmM0Tt+pJQuNpP9 4wUucy4JAnheA== Date: Sat, 14 Oct 2023 23:32:33 -0700 From: Eric Biggers To: Josef Bacik Cc: linux-fscrypt@vger.kernel.org, linux-btrfs@vger.kernel.org Subject: Re: [PATCH v2 05/36] blk-crypto: add a process bio callback Message-ID: <20231015063233.GD10525@sol.localdomain> 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-btrfs@vger.kernel.org On Tue, Oct 10, 2023 at 04:40:20PM -0400, Josef Bacik wrote: > diff --git a/include/linux/blk-crypto-profile.h b/include/linux/blk-crypto-profile.h > index 90ab33cb5d0e..3c002e85631a 100644 > --- a/include/linux/blk-crypto-profile.h > +++ b/include/linux/blk-crypto-profile.h > @@ -100,6 +100,13 @@ struct blk_crypto_profile { > */ > struct device *dev; > > + /** > + * @process_bio_supported: Some things, like btrfs, require the > + * encrypted data for checksumming. Drivers set this to true if they can > + * handle the process_bio() callback. > + */ > + bool process_bio_supported; > + Is there any reason to think that real inline encryption hardware could support this? For the encryption case it seems impossible, since Linux never gets access to the ciphertext unless it reads it back from disk. So, given the dependency on blk-crypto-fallback, I'm wondering if we should just do something like 'profile == blk_crypto_fallback_profile' instead of having this bool in the struct blk_crypto_profile. - Eric