From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (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 3F8951EB5F8; Thu, 19 Feb 2026 06:31:49 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771482709; cv=none; b=NPAPqR3t8sb3n8LRsg/1yMF364kvQzkvYHTzp5jEAcqD8rSlV3XlUz5Q6msuqgYRarWgIrjFTUVQEFdxzsVuha5Cg7XNVKMF+Cu0cnEc38Jgc58CNbMVR5CejLWBIyLkGlekQM8gCEFaEiYAy4wMmn4VN8B6bddXebDLjfg3yWc= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771482709; c=relaxed/simple; bh=0HX4J8Dqjk/eO9ijBN0eFtuJSD4xDBAQIR6xOfcZTZA=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=jneuyWvjVkVMplzp8iOM7Gn456hMuc1GCLHARKRmz5RC6Y+c3avYEvAasQ2aHM/X17WJFr2mQAsL7tvLUTzEBYQR712USOATHZl9uxj8KsSK8cYtOe2NPB85+rw9IXeusnkEEB8UGJMJeIvQWRoTyp6SMfUtyJMJqowniPl3RpU= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=RNZPzLij; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="RNZPzLij" Received: by smtp.kernel.org (Postfix) with ESMTPSA id B0F05C4CEF7; Thu, 19 Feb 2026 06:31:48 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1771482709; bh=0HX4J8Dqjk/eO9ijBN0eFtuJSD4xDBAQIR6xOfcZTZA=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=RNZPzLijTHEDRBrPjNXbh8hR0rWIdeIkjxt0UeVC7oNOSxO7LTDD3FXlEVcpMuXOe rPqoE1Z0Z+aDhRKOn+RB8+CAIyss+to39eMZr9nQBK3ZLPq2UdX2sTLSbCFQ9nSvRc ty3XzoxLH0IwwNgSV6K6UO3sTPJquKEr/C7nDrxmVD5m5P5b8AGQEGOoTeE3Iw2Qxk t2WtyOxmokBFCmloXRpZhEM+pkrMS/SCXkwRllvl4tvqL0tAgBYY36xMIyOXRIyXbu 6YWyL+GQAoNRO57yWb+f9tuza5RG9e8vMgEfvWxjjhcwpYWjHIXzVvwOIZtYgmdZW6 ExAYUlzEeiWOQ== Date: Wed, 18 Feb 2026 22:30:59 -0800 From: Eric Biggers To: Christoph Hellwig Cc: Andrey Albershteyn , Andrey Albershteyn , linux-xfs@vger.kernel.org, fsverity@lists.linux.dev, linux-fsdevel@vger.kernel.org, djwong@kernel.org Subject: Re: [PATCH v3 06/35] fsverity: pass digest size and hash of the empty block to ->write Message-ID: <20260219063059.GA13306@sol> References: <20260217231937.1183679-1-aalbersh@kernel.org> <20260217231937.1183679-7-aalbersh@kernel.org> <20260218061834.GB8416@lst.de> <20260219055857.GA3739@lst.de> Precedence: bulk X-Mailing-List: linux-fsdevel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20260219055857.GA3739@lst.de> On Thu, Feb 19, 2026 at 06:58:57AM +0100, Christoph Hellwig wrote: > On Wed, Feb 18, 2026 at 01:17:52PM +0100, Andrey Albershteyn wrote: > > On 2026-02-18 07:18:34, Christoph Hellwig wrote: > > > On Wed, Feb 18, 2026 at 12:19:06AM +0100, Andrey Albershteyn wrote: > > > > Let filesystem iterate over hashes in the block and check if these are > > > > hashes of zeroed data blocks. XFS will use this to decide if it want to > > > > store tree block full of these hashes. > > > > > > Does it make sense to pass in the zero_digest vs just having a global > > > symbol or accessor? This should be static information. > > > > I think this won't work if we have two filesystems with different > > block sizes and therefore different merkle block sizes => different > > hash. > > Looking at this a bit more - you're storing the entirely zero_digest > in struct merkle_tree_params, which is embedded intothe > fsverity_info. This means that you can trivially access it using an > accessor of the fsverity_inode. Not in ->write_merkle_tree_block(), since that's called during FS_IOC_ENABLE_VERITY before the fsverity_info has been set. > It also means that you actually bloat that structure quite a bit for > constant file system wide information. Maybe it's time to split > out the file system wide part of it into a separate structure? The hash of a block of zeroes depends on the salt, which is a per-file value. The salt is optional, though. There is already another dynamic allocation done only for files that use a salt: merkle_tree_params::hashstate. The hash could be stored in that same allocation for salted files, or as a fixed value in struct fsverity_hash_alg for unsalted files. Then at least unsalted files wouldn't use any additional memory per-file. - Eric