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=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FSL_HELO_FAKE,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,USER_AGENT_SANE_1 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 4E06EC3F68F for ; Wed, 18 Dec 2019 22:27:31 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 1946B24650 for ; Wed, 18 Dec 2019 22:27:31 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1576708051; bh=o7ngMB3x98VTTgkfiZtHSRbzMlQgbTWT/i52kLguSiE=; h=Date:From:To:Cc:Subject:References:In-Reply-To:List-ID:From; b=181aD5kpZOy3iAryltDiaJrffqHgt/IStrEQtrIEdADLbE9leARslb+v7pR3rJdcX 8WRIHIrLSa6cZGbIKTS+bsCs78fHgARe2E4nTCaxqMxpnc4AOXyb/NIQUpzKwjnbIN NvU3+s7+NnhDmdjib2CbZQijUYv2HyXpVWGfpDf0= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726510AbfLRW13 (ORCPT ); Wed, 18 Dec 2019 17:27:29 -0500 Received: from mail.kernel.org ([198.145.29.99]:56350 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726387AbfLRW13 (ORCPT ); Wed, 18 Dec 2019 17:27:29 -0500 Received: from gmail.com (unknown [104.132.1.77]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 64E652082E; Wed, 18 Dec 2019 22:27:28 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1576708048; bh=o7ngMB3x98VTTgkfiZtHSRbzMlQgbTWT/i52kLguSiE=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=ejOCM73UI0+1N/sJ9nYSoNO/OfQJ03EACQbtWn4J87NE/6ll5ayLk55m3ox2OKeQC HgPzXi9FGNhpGKPYTE4Ui97/imrJbiNqO1xo4jwnZiZFvWSzvQk8iQwbysEQiFrczV X2v68LmTPcM7l+ZfsedbX9c3YpZ9ycitDC0wF0CU= Date: Wed, 18 Dec 2019 14:27:26 -0800 From: Eric Biggers To: "Martin K. Petersen" Cc: "Darrick J. Wong" , Satya Tangirala , linux-block@vger.kernel.org, linux-scsi@vger.kernel.org, linux-fscrypt@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-f2fs-devel@lists.sourceforge.net, Barani Muthukumaran , Kuohong Wang , Kim Boojin Subject: Re: [PATCH v6 2/9] block: Add encryption context to struct bio Message-ID: <20191218222726.GC47399@gmail.com> References: <20191218145136.172774-1-satyat@google.com> <20191218145136.172774-3-satyat@google.com> <20191218212116.GA7476@magnolia> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-fscrypt-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-fscrypt@vger.kernel.org On Wed, Dec 18, 2019 at 04:25:28PM -0500, Martin K. Petersen wrote: > > Darrick, > > >> +#ifdef CONFIG_BLK_INLINE_ENCRYPTION > >> + struct bio_crypt_ctx *bi_crypt_context; > >> +#endif > > > > This grows struct bio even if we aren't actively using bi_crypt_context, > > and I thought Jens told us to stop making it bigger. :) > > Yeah. Why not use the bio integrity plumbing? It was explicitly designed > to attach things to a bio and have them consumed by the device driver. > There's not really any such thing as "use the bio integrity plumbing". blk-integrity just does blk-integrity; it's not a plumbing layer that allows other features to be supported. Well, in theory we could refactor and rename all the hooks to "blk-extra" and make them delegate to either blk-integrity or blk-crypto, but I think that would be overkill. What we could do, though, is say that at most one of blk-crypto and blk-integrity can be used at once on a given bio, and put the bi_integrity and bi_crypt_context pointers in union. (That would require allocating a REQ_INLINECRYPT bit so that we can tell what the pointer points to.) - Eric