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 D7B05C001DC for ; Fri, 14 Jul 2023 18:14:23 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236300AbjGNSOW (ORCPT ); Fri, 14 Jul 2023 14:14:22 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33748 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236374AbjGNSOV (ORCPT ); Fri, 14 Jul 2023 14:14:21 -0400 Received: from mail-oo1-xc36.google.com (mail-oo1-xc36.google.com [IPv6:2607:f8b0:4864:20::c36]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C32EE35AC for ; Fri, 14 Jul 2023 11:14:00 -0700 (PDT) Received: by mail-oo1-xc36.google.com with SMTP id 006d021491bc7-5636426c1b3so1475305eaf.1 for ; Fri, 14 Jul 2023 11:14:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=toxicpanda-com.20221208.gappssmtp.com; s=20221208; t=1689358440; x=1691950440; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=8Hdu2InbnZf8zZ43qw4QAyACx5oSj6HL3+2N5nCu1wA=; b=k3G2PzEy0/TjadwEMX4AISCCZcZQ26hJGHqqTdhWP7o17GXWX60iEiAq99DYuBR14C qLpTkN2xqp3MrUrtxBdPHfe3vCs2IbX/vLi+5FdDHAAsIAhteZZ1oZVi2EMQZnctgBUB gjZdsAP6OD2zBJgFCTNH+nf2ecimoImwHDLOA+dD9bXppkiaDP2lSmcIrAEm8iSwciIz YWVTIhPXFDAZYsDrjRLk+bjsO/S2jhQ2+vHBnjw0O3wb26TNjf9b5LR+OErGbh3TEdaM c/+ZedXbRL+zAyosKgGJXRPTsPXIBAOHTase1AGfi+w4xJ7dzpPk1+fuVVvO+7IPW76M F+ng== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1689358440; x=1691950440; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=8Hdu2InbnZf8zZ43qw4QAyACx5oSj6HL3+2N5nCu1wA=; b=DWT556fWNNpvczsyNKcKwjbo7+orj+LsArBvoYY7/637IeRMTIqrvKUWFuZUhyVKRH WWjdjLniXN8X8dbDqCLmWjk3gdijAgt/1Tt+NcCGaDpoOsN6UKIGMnIeL9OkYbYyL8U7 sQnqQTAfMno3ivALUzdZ1CbajsmJHsaJdu3miA/HyBZdeSLWI3AJOFIiX6gzOZBiwPng ZRbDoa+5+VoLsi0PsvB5gTWaZCeIvoluyD6fTD5LM/tYtXk7MkkYpKtDyAhMEiBKaEaA WDrUQpaKXqQes491c0cglJB2/V4ir4Wf/zm4R6bA/D66r48NWdiI/rYM1mZSZUGwt8gE w9+A== X-Gm-Message-State: ABy/qLZNwGdw+5VAf2o96C52CWsjirEkBdsWUTWfMIj96RGuThYVTDYW ElFyqQmoREzXBfiAbEkjEyo/aQ== X-Google-Smtp-Source: APBJJlEA7P5OZ5d0XThiykbhJWzpmPzDC6Os0oNNzxwe6eb3uYbg+psf3TwtC4jP41q+VPqGnKu/Tg== X-Received: by 2002:a05:6358:9327:b0:134:e3e6:c0bd with SMTP id x39-20020a056358932700b00134e3e6c0bdmr6399483rwa.32.1689358439806; Fri, 14 Jul 2023 11:13:59 -0700 (PDT) Received: from localhost (cpe-76-182-20-124.nc.res.rr.com. [76.182.20.124]) by smtp.gmail.com with ESMTPSA id k63-20020a0dfa42000000b005773babc3cdsm2434024ywf.83.2023.07.14.11.13.59 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 14 Jul 2023 11:13:59 -0700 (PDT) Date: Fri, 14 Jul 2023 14:13:58 -0400 From: Josef Bacik To: Sweet Tea Dorminy Cc: "Theodore Y. Ts'o" , Jaegeuk Kim , Eric Biggers , Chris Mason , David Sterba , linux-fscrypt@vger.kernel.org, linux-btrfs@vger.kernel.org, kernel-team@meta.com Subject: Re: [PATCH v2 03/14] fscrypt: adjust effective lblks based on extents Message-ID: <20230714181358.GA510453@perftesting> 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 Sun, Jul 09, 2023 at 02:53:36PM -0400, Sweet Tea Dorminy wrote: > If a filesystem uses extent-based encryption, then the offset within a > file is not a constant which can be used for calculating an IV. > For instance, the same extent could be blocks 0-8 in one file, and > blocks 100-108 in another file. Instead, the block offset within the > extent must be used instead. > > Update all uses of logical block offset within the file to use logical > block offset within the extent, if applicable. > > Signed-off-by: Sweet Tea Dorminy > --- > fs/crypto/crypto.c | 3 ++- > fs/crypto/inline_crypt.c | 24 +++++++++++++++++------- > 2 files changed, 19 insertions(+), 8 deletions(-) > > diff --git a/fs/crypto/crypto.c b/fs/crypto/crypto.c > index 1b7e375b1c6b..d75f1b3f5795 100644 > --- a/fs/crypto/crypto.c > +++ b/fs/crypto/crypto.c > @@ -107,8 +107,9 @@ int fscrypt_crypt_block(const struct inode *inode, fscrypt_direction_t rw, > struct skcipher_request *req = NULL; > DECLARE_CRYPTO_WAIT(wait); > struct scatterlist dst, src; > + u64 ci_offset = 0; > struct fscrypt_info *ci = > - fscrypt_get_lblk_info(inode, lblk_num, NULL, NULL); > + fscrypt_get_lblk_info(inode, lblk_num, &ci_offset, NULL); > struct crypto_skcipher *tfm = ci->ci_enc_key->tfm; > int res = 0; > > diff --git a/fs/crypto/inline_crypt.c b/fs/crypto/inline_crypt.c > index 885a2ec3d711..b3e7a5291d22 100644 > --- a/fs/crypto/inline_crypt.c > +++ b/fs/crypto/inline_crypt.c > @@ -267,12 +267,15 @@ void fscrypt_set_bio_crypt_ctx(struct bio *bio, const struct inode *inode, > { > const struct fscrypt_info *ci; > u64 dun[BLK_CRYPTO_DUN_ARRAY_SIZE]; > + u64 ci_offset = 0; > > if (!fscrypt_inode_uses_inline_crypto(inode)) > return; > - ci = fscrypt_get_lblk_info(inode, first_lblk, NULL, NULL); > + ci = fscrypt_get_lblk_info(inode, first_lblk, &ci_offset, NULL); > + if (!ci) > + return; > > - fscrypt_generate_dun(ci, first_lblk, dun); > + fscrypt_generate_dun(ci, ci_offset, dun); > bio_crypt_set_ctx(bio, ci->ci_enc_key->blk_key, dun, gfp_mask); > } > EXPORT_SYMBOL_GPL(fscrypt_set_bio_crypt_ctx); > @@ -350,22 +353,23 @@ bool fscrypt_mergeable_bio(struct bio *bio, const struct inode *inode, > const struct bio_crypt_ctx *bc = bio->bi_crypt_context; > u64 next_dun[BLK_CRYPTO_DUN_ARRAY_SIZE]; > struct fscrypt_info *ci; > + u64 ci_offset = 0; > > if (!!bc != fscrypt_inode_uses_inline_crypto(inode)) > return false; > if (!bc) > return true; > > - ci = fscrypt_get_lblk_info(inode, next_lblk, NULL, NULL); > + ci = fscrypt_get_lblk_info(inode, next_lblk, &ci_offset, NULL); > /* > * Comparing the key pointers is good enough, as all I/O for each key > * uses the same pointer. I.e., there's currently no need to support > * merging requests where the keys are the same but the pointers differ. > */ > - if (bc->bc_key != ci->ci_enc_key->blk_key) > + if (!ci || bc->bc_key != ci->ci_enc_key->blk_key) > return false; > This seems like an unrelated change, we weren't checking !ci before and the behavior hasn't changed with the new code. Thanks, Josef