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 11118E7FDDB for ; Mon, 2 Feb 2026 21:04:26 +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: Reply-To:From:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:Subject:In-Reply-To:MIME-Version:References: Message-ID:To:Date:Sender:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=YPvP8yGbO2hoc65TAaFCKhfYCqsnBhRVzdxW8o8vhbg=; b=eZ/1J4jbycv09WdJRvgkF2ER3k 2K4g8BGB72iSnSi5NMhwvFGuSMhrwPfNwBjFJIqZJlj5Mk0bWHuKRGPZPkma/tqLJ9OYuwkcDYdXj nUUxr8mDi8+wwPmpuc4BYtLqJz+Cfp2xirLxiDNMs1k4nmxVApZNrcRmbKlmQTsKi194=; Received: from [127.0.0.1] (helo=sfs-ml-1.v29.lw.sourceforge.com) by sfs-ml-1.v29.lw.sourceforge.com with esmtp (Exim 4.95) (envelope-from ) id 1vn15s-00038j-FB; Mon, 02 Feb 2026 21:04:24 +0000 Received: from [172.30.29.66] (helo=mx.sourceforge.net) by sfs-ml-1.v29.lw.sourceforge.com with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.95) (envelope-from ) id 1vn15r-00038d-HG for linux-f2fs-devel@lists.sourceforge.net; Mon, 02 Feb 2026 21:04:23 +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=PBcL48l4p0jVU22zlz8h0CmSJlzg8wNOT5+P559Vc8E=; b=OSKCzt7hCBYeMZb2Ek8X8Our7h d5yDjJNKosdd+9B7U1i7vkeTKv//sosLVtcSd4hEX7H7z4aj6l/I1VXNvYd3jRVXpso/b60uAuxAd nusw7tOqNXnvYkQMezYF1sHqwOxIlcZKIrmGk53Bn7esdE+z/K4+iuY6h8AkXFTbvSg4=; 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=PBcL48l4p0jVU22zlz8h0CmSJlzg8wNOT5+P559Vc8E=; b=FfueP/kbK8Sxo1mRFG9RnM4PBp 8fU0xwA4koEaia603EPdz7xefOktTsfAUQKAr7IZSO3FICQwhAX2RMGZ2NhtGZzuAwDgFSSvryw30 D7kOlwJk1F8Yx+2eUsvfPcfng6vq7GkiyVqUv2AXCkfL0qCXdp7MmtohsYd9rI6erinw=; Received: from tor.source.kernel.org ([172.105.4.254]) by sfi-mx-2.v28.lw.sourceforge.com with esmtps (TLS1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.95) id 1vn15q-0004oV-A2 for linux-f2fs-devel@lists.sourceforge.net; Mon, 02 Feb 2026 21:04:23 +0000 Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by tor.source.kernel.org (Postfix) with ESMTP id A3209600B0; Mon, 2 Feb 2026 21:04:16 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id A01EFC116C6; Mon, 2 Feb 2026 21:04:15 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1770066256; bh=XRzlzAwIzrWwQQCJu0yYDI/QY/MD+z952CyEosMvgJ4=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=akopJkb3IJUb0UY+zPkONhlRaYXvL+MBanv8EvQ06eGrkuDIIuCdgXqTMQwBLD923 rovYpMsNDFP0Hy2s/XpuQC0hETgCjQM8VsLjBGubzj9cmy3x7SAavwwSswydbABffE nQgDK2NgJceLQRNmpX/wCLHbRRbnQMpKSd0k+xQOsDXFGBRvwxepCTL98xtrMKKtmD xRObm8348BVZvMzN/0zXNq712b9oUL2DK9aAFWEg1IGYpqY3dcYQ1ESkgRqJKW/r+f WEN9bmXfY4GVeFGziTXeBgEov43XNehyJMtQXXHS8H231V4Iha289/VQoJHffUNblu KFkHwgDfhwarQ== Date: Mon, 2 Feb 2026 13:04:13 -0800 To: Christoph Hellwig Message-ID: <20260202210413.GA4838@quark> References: <20260202060754.270269-1-hch@lst.de> <20260202060754.270269-3-hch@lst.de> <20260202151755.GA22756@lst.de> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20260202151755.GA22756@lst.de> X-Headers-End: 1vn15q-0004oV-A2 Subject: Re: [f2fs-dev] [PATCH 02/11] readahead: push invalidate_lock out of page_cache_ra_unbounded 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: , From: Eric Biggers via Linux-f2fs-devel Reply-To: Eric Biggers Cc: fsverity@lists.linux.dev, Christian Brauner , Theodore Ts'o , Andrey Albershteyn , Matthew Wilcox , linux-f2fs-devel@lists.sourceforge.net, linux-fsdevel@vger.kernel.org, Al Viro , Jaegeuk Kim , David Sterba , Jan Kara , linux-ext4@vger.kernel.org, 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, Feb 02, 2026 at 04:17:55PM +0100, Christoph Hellwig wrote: > On Mon, Feb 02, 2026 at 03:11:45PM +0000, Matthew Wilcox wrote: > > On Mon, Feb 02, 2026 at 07:06:31AM +0100, Christoph Hellwig wrote: > > > +++ b/fs/f2fs/file.c > > > @@ -4418,7 +4418,9 @@ static int redirty_blocks(struct inode *inode, pgoff_t page_idx, int len) > > > pgoff_t redirty_idx = page_idx; > > > int page_len = 0, ret = 0; > > > > > > + filemap_invalidate_lock_shared(mapping); > > > page_cache_ra_unbounded(&ractl, len, 0); > > > + filemap_invalidate_unlock_shared(mapping); > > > > Why is f2fs calling page_cache_ra_unbounded() here? > > From tracing the callers is seems to be able to be called from the > garbage collector, which might have to move fsverity files. Not sure if > that was the reason or is incidental. > > (using the pagecache for GC is generally a very bad idea, and there is > at least one academic paper showing it is a huge performance problem in > f2fs, and my initial attempts at using the pagecache for GC in zoned XFS > also showed horrible results) > > > > unsigned int nofs = memalloc_nofs_save(); > > > > > > + lockdep_assert_held_read(&mapping->invalidate_lock); > > > > Hm, why are we asserting that it's not write-locked? For the > > purposes of this function, I'd think we want to just > > lockdep_assert_held()? > > Fine with me. > > > In the tree I'm looking at, there are also calls to > > page_cache_ra_unbounded() in fs/ext4/verity.c and fs/f2fs/verity.c > > which probably need the lock taken too? > > I consolidated those into the single call in fs/verity/pagecache.c > in the previous iteration of this series, and Eric merged the > first few patches including that one into the fsverity tree. I changed both instances of lockdep_assert_held_read() to lockdep_assert_held() when applying. - Eric _______________________________________________ Linux-f2fs-devel mailing list Linux-f2fs-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel