Received: by 2002:a05:6a10:206:0:0:0:0 with SMTP id 6csp40224pxj; Wed, 16 Jun 2021 19:42:14 -0700 (PDT) X-Google-Smtp-Source: ABdhPJx23CyLwuG9WYM0FM7hSiVlmhgd+NWJXnTi+yPXiPpxC/7zxXouNKQs6ZZ4+4mXbn+VfElf X-Received: by 2002:a17:906:9516:: with SMTP id u22mr2646984ejx.442.1623897734463; Wed, 16 Jun 2021 19:42:14 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1623897734; cv=none; d=google.com; s=arc-20160816; b=lk330LC1IiEO9PeztWBZM1v4aQ5Uszlw1KUObJU6Na1jmfOC0MeBN2oZJCZw5//znz gV2+ne6cQuf0wJtpZ4ZaezfZ2obGb54xw5gih38sjfF3g6q5ofONZIaMAYhglrtveRiU TAC5i5TQR5v1KYgytDGR0gtX+7tV7oIasQd5kXIoEob9OM8dNkBZzJTLJSa1lWXEhvIB 5wMTbGYTPWUG/6N0agpdSZsW8GiV3UWYmgoh2D7nDfa7eueHiJgQIbp6QatKsN9kyl9C vsfso7wSE1wxvvsN/hpJ3xb5XYZWsrhNiFZSLMoXnHy728h/T/44taFLreYtQ9xVBTc7 Dz+g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=zcTgYpi1Wf0fLo/iEHgP7YtMF1cLshQvaBSIb7kzLA8=; b=xp/5AGSoN9J0SMYBKQvGe0//ZGkH9OnnmgwWaWEQc46cYqNqwJs43cII0uuufX4IyQ HUOUUXP4yC6NSL3B9NtRtq5EiN2xwqwvLUeRa+uN9J0gyzKrqUxFBLzK1awNlQ/9AzR9 ptMBNg/TwAPRD/tCmdyIHCOCQnrwLlTUQYuD5NlZ2KNe0ZL5mBdpxCttw8X7d1Gp/Tfx o50QwSFFnxOlrsNZn6gmSiH5XjMzwECD7Xb5bH8YFUP54m27DKoJ2lsnazhkE7FAxEoI BqB7b1qmEh9DDoEVWEMz24yOGww508o7XQinMW649s86guCEvF0FQDz1JVNFSKq5R39a v1Kg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=BRmNWSOS; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id bm24si3913115ejb.577.2021.06.16.19.41.52; Wed, 16 Jun 2021 19:42:14 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=BRmNWSOS; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234100AbhFQAbS (ORCPT + 99 others); Wed, 16 Jun 2021 20:31:18 -0400 Received: from mail.kernel.org ([198.145.29.99]:59186 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231322AbhFQAbR (ORCPT ); Wed, 16 Jun 2021 20:31:17 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id 1A65B613CD; Thu, 17 Jun 2021 00:29:11 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1623889751; bh=c6/UgIpgeNcNi4unNQ/ylhL9ijWKo/B8SV0ZczXTMVw=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=BRmNWSOSnu7pks8kP/2h7R/hduZJGEnYVXbHIBzoqFjbXkCm75pIt2cbP+1SQehE0 kkG4PLADA3FtZwuOJVbpx0Wf7Hi+ViRZ1cY6SA+E8i2X9Gi+YzIf4XBmpHnQ2nI48n FlbLRSJ10+tIsXy0GjF5Xe92FXqT3AGcey+2wRxcystoAF70ycYktBSJxWMRtdn3tJ rhPagjvHAWU5flKRgWkEy7lkuKYy66OWiaw48XcZYk8F9dXBnLJeofh8IkDa2I26FP YR2G9GS5H4kHWse9IaCsVEh2ar8xA3i1YcT27OLNB/eCss/P9Cfx2jL263dFXYpkAq 0L6PyFOTpuyPw== Date: Wed, 16 Jun 2021 17:29:09 -0700 From: Eric Biggers To: Satya Tangirala Cc: linux-block@vger.kernel.org, linux-kernel@vger.kernel.org, Jens Axboe Subject: Re: [PATCH v3 02/10] block: blk-crypto: introduce blk_crypto_bio_sectors_alignment() Message-ID: References: <20210604195900.2096121-1-satyat@google.com> <20210604195900.2096121-3-satyat@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210604195900.2096121-3-satyat@google.com> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Jun 04, 2021 at 07:58:52PM +0000, Satya Tangirala wrote: > The size of any bio must be aligned to the data unit size of the bio crypt > context (if it exists) of that bio. This must also be ensured whenever a > bio is split. Introduce blk_crypto_bio_sectors_alignment() that returns the > required alignment in sectors. The number of sectors passed to any call of > bio_split() must be aligned to blk_crypto_bio_sectors_alignment(). > > Signed-off-by: Satya Tangirala > --- > block/blk-crypto-internal.h | 20 ++++++++++++++++++++ > 1 file changed, 20 insertions(+) > > diff --git a/block/blk-crypto-internal.h b/block/blk-crypto-internal.h > index 0d36aae538d7..7f1535cc7e7c 100644 > --- a/block/blk-crypto-internal.h > +++ b/block/blk-crypto-internal.h > @@ -60,6 +60,21 @@ static inline bool blk_crypto_rq_is_encrypted(struct request *rq) > return rq->crypt_ctx; > } > > +/* > + * Returns the alignment requirement for the number of sectors in this bio based > + * on its bi_crypt_context. Any bios split from this bio must follow this > + * alignment requirement as well. Note that a bio must contain a whole number of > + * crypto data units (which is selected by the submitter of bio), since > + * encryption/decryption can only be performed on a complete crypto data unit. > + */ > +static inline unsigned int blk_crypto_bio_sectors_alignment(struct bio *bio) > +{ > + if (!bio_has_crypt_ctx(bio)) > + return 1; > + return bio->bi_crypt_context->bc_key->crypto_cfg.data_unit_size >> > + SECTOR_SHIFT; > +} > + > #else /* CONFIG_BLK_INLINE_ENCRYPTION */ > > static inline bool bio_crypt_rq_ctx_compatible(struct request *rq, > @@ -93,6 +108,11 @@ static inline bool blk_crypto_rq_is_encrypted(struct request *rq) > return false; > } > > +static inline unsigned int blk_crypto_bio_sectors_alignment(struct bio *bio) > +{ > + return 1; > +} > + > #endif /* CONFIG_BLK_INLINE_ENCRYPTION */ Looks fine, but I think we should rework the comment to be a bit easier to understand. Maybe: /* * Return the number of sectors to which the size of this bio (and any bios * split from it) must be aligned based on its encryption context. */ static inline unsigned int blk_crypto_bio_sectors_alignment(struct bio *bio) { if (!bio_has_crypt_ctx(bio)) return 1; /* * If the bio has an encryption context, its size must be aligned to its * crypto data unit size (which the submitter of the bio selected), as * encryption/decryption can only be done on complete crypto data units. */ return bio->bi_crypt_context->bc_key->crypto_cfg.data_unit_size >> SECTOR_SHIFT; }