From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f41.google.com (mail-wm1-f41.google.com [209.85.128.41]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 249202EBB8C for ; Wed, 12 Aug 2026 14:01:26 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=pass smtp.client-ip=209.85.128.41 ARC-Seal:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786543293; cv=pass; b=dth4AaiKcqA7K/2mU44sakAgt+03GDZV2bbJdsKF9xnYb7JRAvGCclNh7oNIAtSpP0g0cN194q7NdUyhqLOsGBCGpBkMlvyCvrfaV09yayHeTj0C4ANuWLLBGu+RcpLgkbk4CC5g90yrUT36Sr0TLuDMbjQY5kDOC9fLLxQUUxw= ARC-Message-Signature:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786543293; c=relaxed/simple; bh=NwhV7wARecxQh7esHydA5zPzLYoC9TtdLCxqqsKZyKg=; h=MIME-Version:References:In-Reply-To:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=dJ7+B3OJONL0itnszIwun5KEE55MqWVcinrH12enFypveRL5BfruAs8gawiA3WyfIKFz+/H8t3dDJX9M34EDkv+cVS2jn305M1A0tGXoaWY1ZfB4PuvJR/Hz8XfHeVEaU8q+01G6x/8n3HSptoyBJBDpIIsDgmTSEoy9wwt2/MU= ARC-Authentication-Results:i=2; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=suse.com; spf=pass smtp.mailfrom=suse.com; dkim=pass (2048-bit key) header.d=suse.com header.i=@suse.com header.b=bMzpZF95; arc=pass smtp.client-ip=209.85.128.41 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=suse.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=suse.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=suse.com header.i=@suse.com header.b="bMzpZF95" Received: by mail-wm1-f41.google.com with SMTP id 5b1f17b1804b1-4994c49f588so10200295e9.0 for ; Wed, 12 Aug 2026 07:01:26 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1786543285; cv=none; d=google.com; s=arc-20260327; b=hLMhnmJg7rdxyRfvr8pks39XmB2YLpTVz0FJP5/ABa6nN2VKVRPyjjDauNaRTBE5Kz 3GKpiK0TR0JVKPQBQ4X9Kyr+Pk5Oi/Nz5it/PoaU6Z+lUOLGpRD7F70AbwbJjjYgRiKK 7ihKCIZDle4V+m92Pqe4/eSJVQfdPRS+4LQ942j+Kf6vxAbi+C0UdvlR5L0FWPoEo7HI RmARva6DojtlaATHpOeEPrVefiRXOf4QHHjDYXiYa2jldTOhZub3t4SWmdVD+mGLNd9D NC3WYp8Ca+v4Tv0+Tb1q+vvYUSaGoPW2Zcz0KPE09tYM+Re0TPMwJgOSTYkUXPBjUlXl ZNzA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20260327; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:dkim-signature; bh=jDqguviqlm3mcw1WL6mm0X2Ptol7dkWT6XZ2U3iPzp8=; fh=KNfdRxE1sEELT/8mNM+cQBRRtNos/NgNlxltdh7qDQM=; b=ZrC1B4JLZsigMg2TB7+QUlPDZ62SLtcPFXwGoinC+GZvyxD3jaLx+hGdPma40ykig8 u/bpSRF/+grXW+RZUhR83PmF0vBz2s9KIfd6nKSXtSRfIAH1to0/IFuCthmuNRooXJJf m1HMWtK6BRJgHM2u9QKiuK7MuShdKQNTrhaiJR7Sp/8rpXt87l8fSK+gcIrnoqkspx9B HrPJyL8WoXRjCmP3NYPNcjWXL7DEtVv6hVap8+y5YWJq8uNUrzLVRXikSgemNEP6VdY0 33o33/nEQyQIp32fhg5SjSnOVGoXjg/RR0URKdjqzJUkpN/ygfHRrWYvBrCXkXT1AqkJ +SbA==; darn=vger.kernel.org ARC-Authentication-Results: i=1; mx.google.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1786543285; x=1787148085; darn=vger.kernel.org; h=content-type:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:from:to:cc:subject:date:message-id:reply-to :content-type; bh=jDqguviqlm3mcw1WL6mm0X2Ptol7dkWT6XZ2U3iPzp8=; b=bMzpZF95Zyx59JzfpcJo+ylEYm+3oxDx4U37dg5o3XJSkZyQ21hWHC5FXbiFKJCtwz nfL8s0PNyewVe5v64SBtAquLGvNNGElEyDtfv1m7v/EUT0QcQaNwuW9wyRpIIR/y1/I2 qyuHfiXFEhkuVCzOfGa1P/JJm1Ww3OlOIFQUOqURWgtRFK8kysRFJzxjb7OvMNzhfMpb W8+AmyBf7xHon4mrE1Z3nJl7h0UZkwJNtUv59bhlanZJs285lei7wEGlgIgFrIFE7aDd 1XE8+MzdFW1P0WnvvjHC5W9GJsp1YOEF6XalZDyutJgLrMAtkyEA347rD9gx0K5SzFQC UBmQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1786543285; x=1787148085; h=content-type:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to:content-type; bh=jDqguviqlm3mcw1WL6mm0X2Ptol7dkWT6XZ2U3iPzp8=; b=OHq0lkKCyldHBnkcIU9xUX2iDRa8wTByFAVQAa4eiH96dqKVKyooIwygjWzIsUhJrX bmzgigRhWU1u2JJeO7dC6+vmkdG8/qugzHYjDAQixaAqNOK+GHP93CRRsliditVdw5G8 /gGeYLCwM2L/xsdrTgqjSnC3EIIncMl/3By6/jHErneSAfwrtMOJI9ZkzogNrVdufkyQ yoJMJ/OaXnlFyeqP1Cy5994Rd6MycCRzYQU6gkCuTe1iP7IWQ+n9Y1EpenWGLECntz9g NlZGh9qqzGuq5SGQrXG2hEjrKbIv+/vo78TIrnoO3tqhZJAGBW+DASc++ooKGOZdm0XM fKVg== X-Forwarded-Encrypted: i=1; AHgh+RpwA/FwAPoWqF/EqeK1/9j1T1b3yH5wzzUyGeaALxmbIifwoe3etEVssEIoI3MXX0OzOCzOgc9yTQM99ZA=@vger.kernel.org X-Gm-Message-State: AOJu0YxK/UjOzrsPpUk8yENlR0HFc+rra1btHA3UamHuxbg3I0M+QJ+Q hNTEsdeCYzNsY/7VTYyPMQLlfg60Ik8UuPyVedwgBo3t98XrunYf8N1iOWEVBq8PUmDyTJId1Db /pFiZTSmxEczdzxVcV7qBl2GVitlMSmHN2GJL5mTQoQ== X-Gm-Gg: AR+sD13p3HhtDMRfN1ueDNpvPuc7gyyd5Wss4TAXdzE46vfIZXA1IkyIIjSVEkUIznI Fih1IZUzUj3qp8NEcgGaxBAXrulMP6Vz21ToMOhZ66N7CMvvgMn1XI0KRN9vorKFebJD1ay3dgG 54SnBzf0HGc2/x87qkG/0/NjDmNlx2AH21JZ/3zyslHeSe3JVj47gzn9yiBls4adLNjjQNfiYNd 2+9IGof9y6k4CY9mzWRLLYTbHE3MH8xV0fHC1ehLNrgkT47bMhmCXjHlibmwO+QkcWzlCdsX0Cq Y9SKyOkxZK4vPlIzXMUUhTydiS/ZZQoHXuG2wbzVhEXynYYiSXT6wNuSq24axO9W7EtDDzIhw4U zF6iWbmawV8Lb94Wma+ERUt9MXoPYtj5jKmsAM2hWcw== X-Received: by 2002:a05:600c:3545:b0:499:71d6:359a with SMTP id 5b1f17b1804b1-4997a656f46mr109313045e9.8.1786543284052; Wed, 12 Aug 2026 07:01:24 -0700 (PDT) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 References: <20260513085340.3673127-1-neelx@suse.com> <20260513085340.3673127-4-neelx@suse.com> <20260602023330.GB2295@sol> In-Reply-To: <20260602023330.GB2295@sol> From: Daniel Vacek Date: Wed, 12 Aug 2026 16:01:12 +0200 X-Gm-Features: AUfX_myvt915vzGFwNYRlfFfUivl5kbirxl8PA9N2EQBXfOqTu-HUsUGoJNjjyY Message-ID: Subject: Re: [PATCH v7 03/43] fscrypt: add a __fscrypt_file_open helper To: Eric Biggers Cc: Chris Mason , Josef Bacik , "Theodore Y. Ts'o" , Jaegeuk Kim , Jens Axboe , David Sterba , linux-block@vger.kernel.org, linux-fscrypt@vger.kernel.org, linux-btrfs@vger.kernel.org, linux-kernel@vger.kernel.org Content-Type: text/plain; charset="UTF-8" On Tue, 2 Jun 2026 at 04:34, Eric Biggers wrote: > On Wed, May 13, 2026 at 10:52:37AM +0200, Daniel Vacek wrote: > > From: Josef Bacik > > > > We have fscrypt_file_open() which is meant to be called on files being > > opened so that their key is loaded when we start reading data from them. > > > > However for btrfs send we are opening the inode directly without a filp, > > so we need a different helper to make sure we can load the fscrypt > > context for the inode before reading its contents. > > > > Signed-off-by: Josef Bacik > > Signed-off-by: Daniel Vacek > > --- > > > > No changes in v7. > > v6 changes: > > * Adapted to fscrypt changes since the last two years. > > v5: https://lore.kernel.org/linux-btrfs/4a372419c3fe6ad425e1b124c342a054e9d6db23.1706116485.git.josef@toxicpanda.com/ > > --- > > fs/crypto/hooks.c | 38 ++++++++++++++++++++++++++++++++------ > > include/linux/fscrypt.h | 8 ++++++++ > > 2 files changed, 40 insertions(+), 6 deletions(-) > > > > diff --git a/fs/crypto/hooks.c b/fs/crypto/hooks.c > > index a7a8a3f581a0..3142cf106bde 100644 > > --- a/fs/crypto/hooks.c > > +++ b/fs/crypto/hooks.c > > @@ -9,6 +9,37 @@ > > > > #include "fscrypt_private.h" > > > > +/** > > + * __fscrypt_file_open() - prepare for filesystem-internal access to a > > + * possibly-encrypted regular file > > + * @dir: the inode for the directory via which the file is being accessed > > + * @inode: the inode being "opened" > > + * > > + * This is like fscrypt_file_open(), but instead of taking the 'struct file' > > + * being opened it takes the parent directory explicitly. This is intended for > > + * use cases such as "send/receive" which involve the filesystem accessing file > > + * contents without setting up a 'struct file'. > > + * > > + * Return: 0 on success, -ENOKEY if the key is missing, or another -errno code > > + */ > > +int __fscrypt_file_open(struct inode *dir, struct inode *inode) > > +{ > > + int err; > > + > > + err = fscrypt_require_key(inode); > > + if (err) > > + return err; > > + > > + if (!fscrypt_has_permitted_context(dir, inode)) { > > + fscrypt_warn(inode, > > + "Inconsistent encryption context (parent directory: %llu)", > > + dir->i_ino); > > + return -EPERM; > > + } > > + return 0; > > +} > > +EXPORT_SYMBOL_GPL(__fscrypt_file_open); > > + > > /** > > * fscrypt_file_open() - prepare to open a possibly-encrypted regular file > > * @inode: the inode being opened > > @@ -60,12 +91,7 @@ int fscrypt_file_open(struct inode *inode, struct file *filp) > > rcu_read_unlock(); > > > > dentry_parent = dget_parent(dentry); > > - if (!fscrypt_has_permitted_context(d_inode(dentry_parent), inode)) { > > - fscrypt_warn(inode, > > - "Inconsistent encryption context (parent directory: %llu)", > > - d_inode(dentry_parent)->i_ino); > > - err = -EPERM; > > - } > > + err = __fscrypt_file_open(d_inode(dentry_parent), inode); > > dput(dentry_parent); > > return err; > > } > > This change makes fscrypt_file_open() execute an unnecessary extra > fscrypt_require_key(). Could we just leave fscrypt_file_open() as-is? Yes, I'm aware of that. Well, it's static inline and gated only for encrypted inodes. But yeah, I'll refactor it a bit further. --nX > - Eric