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 kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id AFA1EC433F5 for ; Sat, 14 May 2022 06:10:09 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id C15056B0073; Sat, 14 May 2022 02:10:08 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id B9DD86B0075; Sat, 14 May 2022 02:10:08 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A65596B0078; Sat, 14 May 2022 02:10:08 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 930C46B0073 for ; Sat, 14 May 2022 02:10:08 -0400 (EDT) Received: from smtpin08.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 58A443189D for ; Sat, 14 May 2022 06:10:08 +0000 (UTC) X-FDA: 79463323296.08.F0A196E Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by imf14.hostedemail.com (Postfix) with ESMTP id 55D5E1000BB for ; Sat, 14 May 2022 06:10:05 +0000 (UTC) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id B13A3B81A53; Sat, 14 May 2022 06:10:05 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 1CCAAC34113; Sat, 14 May 2022 06:10:04 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1652508604; bh=q/ID6tbRdZpX5OEsHFcMNO3iAzeVV2HIl2WBCDbIvYo=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=bImNBPV4/NQR0KnMZ9/Qo1vujgs886oVI43Jvo320T1fcATCJqGiBG8NbPwCt2qmD CrOdre3lwUAOBSIweCvXvcJsGvRIV89UHJztD7RzuNrGKWw1HiaYclkmKX1xrgAy36 qkw5ul+seN0+Zgu6mbWSv8UfhKcQKz8zHKQNir3oauzM6CSV/4VgGguCPh4On9eMRH OC5OuQqkTqpFSuuWZzKgATD35VatRxQXcsJLxzpUmXhz1W3xbfILCKUzfILMLs/m2Q RHBDWztcKSVTKYwAvf9i+tFoEVK3pS8jFe2wjYSrI6kqjRP27+HtU7IMlDrx6Y1nWp noIM3+hXFw2EA== Date: Fri, 13 May 2022 23:10:02 -0700 From: Eric Biggers To: Matthew Wilcox Cc: linux-fsdevel@vger.kernel.org, linux-mm@kvack.org Subject: Re: Freeing page flags Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspam-User: X-Rspamd-Server: rspam11 X-Rspamd-Queue-Id: 55D5E1000BB X-Stat-Signature: zjiw7oxgzwnq195j1tgk8x5castx9p46 Authentication-Results: imf14.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=bImNBPV4; spf=pass (imf14.hostedemail.com: domain of ebiggers@kernel.org designates 145.40.68.75 as permitted sender) smtp.mailfrom=ebiggers@kernel.org; dmarc=pass (policy=none) header.from=kernel.org X-HE-Tag: 1652508605-945953 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Thu, May 12, 2022 at 09:54:59PM +0100, Matthew Wilcox wrote: > The LWN writeup [1] on merging the MGLRU reminded me that I need to send > out a plan for removing page flags that we can do without. > > 1. PG_error. It's basically useless. If the page was read successfully, > PG_uptodate is set. If not, PG_uptodate is clear. The page cache > doesn't use PG_error. Some filesystems do, and we need to transition > them away from using it. One of the uses of PG_error is in ext4 and f2fs to keep track of decryption (fscrypt) and verity (fs-verity) failures on pages in a bio being read. Decryption and verity happen in separate phases, so PG_error is used to record which subset of pages a decryption error occurred on. Similarly, PG_error is also used to record which subset of pages a verity error occurred on, which the filesystem uses to decide whether to set PG_uptodate afterwards. If we had to get rid of it, one idea would be: * Don't keep track of decryption failures on a per-page basis; just fail the whole bio if one occurs. That's how the block layer works, after all; you just get one ->bi_status and not an individual status for each page. Also, decryption failures never really happen in practice anyway. * Also merge together the verity step and the setting-uptodate+unlocking step, so that PG_error isn't needed to propagate the page status between these. This should work since verity only happens at the end anyway. I was also thinking about just unlocking pages as errors occur on them. I think that wouldn't work, because the filesystem wouldn't be able to distinguish between pages it still has locked and pages that got re-locked by someone else. - Eric