From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-api-owner@kernel.org>
X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on
	aws-us-west-2-korg-lkml-1.web.codeaurora.org
X-Spam-Level: 
X-Spam-Status: No, score=-11.3 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH,
	DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,INCLUDES_CR_TRAILER,MAILING_LIST_MULTI,
	SPF_HELO_NONE,SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.0
Received: from mail.kernel.org (mail.kernel.org [198.145.29.99])
	by smtp.lore.kernel.org (Postfix) with ESMTP id DC870C433E9
	for <linux-api@archiver.kernel.org>; Thu, 28 Jan 2021 02:18:04 +0000 (UTC)
Received: from vger.kernel.org (vger.kernel.org [23.128.96.18])
	by mail.kernel.org (Postfix) with ESMTP id 8B45164DCD
	for <linux-api@archiver.kernel.org>; Thu, 28 Jan 2021 02:18:04 +0000 (UTC)
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S229569AbhA1CRr (ORCPT <rfc822;linux-api@archiver.kernel.org>);
        Wed, 27 Jan 2021 21:17:47 -0500
Received: from mail.kernel.org ([198.145.29.99]:43492 "EHLO mail.kernel.org"
        rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
        id S229528AbhA1CRr (ORCPT <rfc822;linux-api@vger.kernel.org>);
        Wed, 27 Jan 2021 21:17:47 -0500
Received: by mail.kernel.org (Postfix) with ESMTPSA id 286BC64D9F;
        Thu, 28 Jan 2021 02:17:06 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
        s=k20201202; t=1611800226;
        bh=kkx2gxqL3eTEODYMMPfss/+rMKGv9VbYrVIUTu2Ff4o=;
        h=Date:From:To:Cc:Subject:References:In-Reply-To:From;
        b=Cssw+EuDfiMMpcWBMW8S00pxx9lnqxS1W91b97rL7PG0rmKgJPZ5xqF6wb/gtp2yZ
         GopReLJwPmf4Gnw6cSI59/I4BiHzQzOtVuXYJW2jboMdRI1BcosIqfsopkBhi9bKL2
         Kp5zj2rgof2d620b1orH0QxaQ6iJO91DSkqZDfrc/AX68wLvUyw7HWTU9wD2W4evcT
         hmxedXHJF7yQ1O8g0ngBrivco2m6rGJhN9FY8RIgb1HApK5YmtXYmN/LYxH/9nXek5
         hl2Z5vb+kxKcIdlaG9skNoOL7ACiBqHgK73pw7VZdlMxaaEz0dPjAz04TY5gHE88+v
         7Gm4drqXaqNyA==
Date:   Wed, 27 Jan 2021 18:17:04 -0800
From:   Eric Biggers <ebiggers@kernel.org>
To:     Jaegeuk Kim <jaegeuk@kernel.org>
Cc:     linux-fscrypt@vger.kernel.org, linux-fsdevel@vger.kernel.org,
        linux-ext4@vger.kernel.org, linux-f2fs-devel@lists.sourceforge.net,
        linux-api@vger.kernel.org, Theodore Ts'o <tytso@mit.edu>,
        Victor Hsieh <victorhsieh@google.com>
Subject: Re: [PATCH 4/6] fs-verity: support reading Merkle tree with ioctl
Message-ID: <YBIeoGowXVrG3QfU@sol.localdomain>
References: <20210115181819.34732-1-ebiggers@kernel.org>
 <20210115181819.34732-5-ebiggers@kernel.org>
 <YBIPD53iVg1US++r@google.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <YBIPD53iVg1US++r@google.com>
Precedence: bulk
List-ID: <linux-api.vger.kernel.org>
X-Mailing-List: linux-api@vger.kernel.org

On Wed, Jan 27, 2021 at 05:10:39PM -0800, Jaegeuk Kim wrote:
> 
> Minor thought:
> How about invalidating or truncating merkel tree pages?
> 
> Reviewed-by: Jaegeuk Kim <jaegeuk@kernel.org>
> 

Removing them from the page cache after the read, you mean?  I'm not sure we can
assume that users of this ioctl would want the pages to *not* be cached, any
more than we could assume that for any regular read().  I think we should just
leave the pages cached (like a regular read) and not do anything special.  Like
other pagecache pages, the kernel will evict the Merkle tree pages eventually if
they aren't being accessed anymore and memory needs to be reclaimed.

- Eric