From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from verein.lst.de (verein.lst.de [213.95.11.211]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id EDDD5359F8D for ; Mon, 19 Jan 2026 12:06:14 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=213.95.11.211 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768824376; cv=none; b=cohSpQyF3UNBIMHaQULWF3SXckS20fbdJubhtCE5fj1Z5k5nFIi4pIXJX/KPRDAMo39b8CttxX0+EUNRs85CAkediUhncf1kHuMdoZIgm4/lz59vF7k2h8yz8s6Enpdqkp2h7LmSITCs0fQamYYeXWf1gXTwN+kDA86ijqcJqbk= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768824376; c=relaxed/simple; bh=Cr2GJL9XnBNnOtUICJ1ZUWD3ign/NX/f6uXN9QQy25I=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=NZPF2fJyFI2nUm46tHxlfbWR863k8cSIqOLwXxfrXRS+5fMcmTpRMZr6pmBfKM/V5du605oZJpBP52+pcE6h9OJCINoZJHkbTQOJdM9A9ZhLv5ZB4cAWY9VHFlNC31FP3FeFQuOE9vEE9mB5ht0UIsHII0Y3Qow6Tvy0EQEIetg= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=lst.de; spf=pass smtp.mailfrom=lst.de; arc=none smtp.client-ip=213.95.11.211 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=lst.de Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=lst.de Received: by verein.lst.de (Postfix, from userid 2407) id 9BBA6227A88; Mon, 19 Jan 2026 13:06:11 +0100 (CET) Date: Mon, 19 Jan 2026 13:06:11 +0100 From: Christoph Hellwig To: Christian Brauner Cc: Christoph Hellwig , Eric Biggers , Al Viro , Jan Kara , David Sterba , Theodore Ts'o , Jaegeuk Kim , Chao Yu , Andrey Albershteyn , linux-fsdevel@vger.kernel.org, linux-btrfs@vger.kernel.org, linux-ext4@vger.kernel.org, linux-f2fs-devel@lists.sourceforge.net, fsverity@lists.linux.dev Subject: Re: [PATCH 3/6] fs,fsverity: handle fsverity in generic_file_open Message-ID: <20260119120611.GA23787@lst.de> References: <20260119062250.3998674-1-hch@lst.de> <20260119062250.3998674-4-hch@lst.de> <20260119-davon-krippenkind-78d683621491@brauner> Precedence: bulk X-Mailing-List: fsverity@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20260119-davon-krippenkind-78d683621491@brauner> User-Agent: Mutt/1.5.17 (2007-11-01) On Mon, Jan 19, 2026 at 11:02:37AM +0100, Christian Brauner wrote: > > + if (IS_ENABLED(CONFIG_FS_VERITY) && IS_VERITY(inode)) { > > + if (filp->f_mode & FMODE_WRITE) > > + return -EPERM; > > + return fsverity_file_open(inode, filp); > > + } > > This is the only one where I'm not happy about the location. > This hides the ordering requirement between fsverity and fscrypt. It's > easier to miss now. This also really saves very little compared to the > other changes. So I wonder whether it's really that big of a deal to > have the call located in the open routines of the filesystems. So my idea was to do a similar pass for fscrypt eventually, and enforce the ordering in one place, instead of relying on file systems to get it right. I'd be fine with delaying this patch until then and give it another try. The good thing is that unlike say the stat hook fsverity will simply not work without wiring this up, so it can't be easily forgotten. 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 lists.sourceforge.net (lists.sourceforge.net [216.105.38.7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 9AD4CCCF2EF for ; Mon, 19 Jan 2026 12:06:29 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.sourceforge.net; s=beta; h=Content-Transfer-Encoding:Content-Type:Cc: List-Subscribe:List-Help:List-Post:List-Archive:List-Unsubscribe:List-Id: Subject:In-Reply-To:MIME-Version:References:Message-ID:To:From:Date:Sender: Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender :Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=WB8RqI9FS1PMM1BM17PrRNuGe7YnCKRHmhMeXOks8Ek=; b=h7+ZOtuTGzDkg9Etudtc9cGcE4 xqFa95vyrTb/8bhc+omM2TqdMx5uPpiH3mp3UGBq6XQo0G29AvKWAdvfSa1STylVgg30GmmbEPMlY yeT6TsrNMvbJnJpqpmlx/+m4bq/Z76tKZsbbt/L9BzWlJqJd+cYyKth5BnnS4CXbw2jI=; Received: from [127.0.0.1] (helo=sfs-ml-3.v29.lw.sourceforge.com) by sfs-ml-3.v29.lw.sourceforge.com with esmtp (Exim 4.95) (envelope-from ) id 1vho1b-0000do-B2; Mon, 19 Jan 2026 12:06:27 +0000 Received: from [172.30.29.66] (helo=mx.sourceforge.net) by sfs-ml-3.v29.lw.sourceforge.com with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.95) (envelope-from ) id 1vho1Z-0000dg-Pe for linux-f2fs-devel@lists.sourceforge.net; Mon, 19 Jan 2026 12:06:25 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sourceforge.net; s=x; h=In-Reply-To:Content-Type:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=25bupFG3LbVCBA+mOqgPL3BFSrXRxSp8im/fM36C+ws=; b=PQkwBI4nOSqe4KTMilUmFW4H+y HLK2gUBvovjTbWILUtYX0UksBPv0UjLDDbvfM7qaANWnn9KBY55WKInH8M3E7XxQyN2PbMeALG+0b dixztCGEJB75eyak5kmfWJ9QdL0Id9T0IpLyuYJ6DIrzfoaavvsyVSb2kzJeGeAM1fcY=; DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sf.net; s=x ; h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To :From:Date:Sender:Reply-To:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=25bupFG3LbVCBA+mOqgPL3BFSrXRxSp8im/fM36C+ws=; b=gry7y1JOtoJQ7CWKnnOsdx58M+ ZoTiyhaoi4zBSPTzKZCQnjGaASoIqeGa8EO3Az29iOqG75LJoWFN0drCIS9rHI1neJR+qMxU9CbJS GUnNALCP9+ecYSoVtIvkUikv9JpCV2upzlCFegdWYvounjZVRwSyh9vF+SIAFxUnugzc=; Received: from verein.lst.de ([213.95.11.211]) by sfi-mx-2.v28.lw.sourceforge.com with esmtps (TLS1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.95) id 1vho1Y-000115-OR for linux-f2fs-devel@lists.sourceforge.net; Mon, 19 Jan 2026 12:06:25 +0000 Received: by verein.lst.de (Postfix, from userid 2407) id 9BBA6227A88; Mon, 19 Jan 2026 13:06:11 +0100 (CET) Date: Mon, 19 Jan 2026 13:06:11 +0100 From: Christoph Hellwig To: Christian Brauner Message-ID: <20260119120611.GA23787@lst.de> References: <20260119062250.3998674-1-hch@lst.de> <20260119062250.3998674-4-hch@lst.de> <20260119-davon-krippenkind-78d683621491@brauner> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20260119-davon-krippenkind-78d683621491@brauner> User-Agent: Mutt/1.5.17 (2007-11-01) X-Headers-End: 1vho1Y-000115-OR Subject: Re: [f2fs-dev] [PATCH 3/6] fs, fsverity: handle fsverity in generic_file_open X-BeenThere: linux-f2fs-devel@lists.sourceforge.net X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: fsverity@lists.linux.dev, Jan Kara , Andrey Albershteyn , linux-f2fs-devel@lists.sourceforge.net, Eric Biggers , linux-fsdevel@vger.kernel.org, Al Viro , Jaegeuk Kim , David Sterba , Theodore Ts'o , linux-ext4@vger.kernel.org, Christoph Hellwig , linux-btrfs@vger.kernel.org Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: linux-f2fs-devel-bounces@lists.sourceforge.net On Mon, Jan 19, 2026 at 11:02:37AM +0100, Christian Brauner wrote: > > + if (IS_ENABLED(CONFIG_FS_VERITY) && IS_VERITY(inode)) { > > + if (filp->f_mode & FMODE_WRITE) > > + return -EPERM; > > + return fsverity_file_open(inode, filp); > > + } > > This is the only one where I'm not happy about the location. > This hides the ordering requirement between fsverity and fscrypt. It's > easier to miss now. This also really saves very little compared to the > other changes. So I wonder whether it's really that big of a deal to > have the call located in the open routines of the filesystems. So my idea was to do a similar pass for fscrypt eventually, and enforce the ordering in one place, instead of relying on file systems to get it right. I'd be fine with delaying this patch until then and give it another try. The good thing is that unlike say the stat hook fsverity will simply not work without wiring this up, so it can't be easily forgotten. _______________________________________________ Linux-f2fs-devel mailing list Linux-f2fs-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel