mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Pedro Falcato <pfalcato@suse.de>
To: Jan Kara <jack@suse.cz>
Cc: Jan Kara <jack@suse.com>,
	linux-ext4@vger.kernel.org,  linux-kernel@vger.kernel.org
Subject: Re: [PATCH] ext2: take invalidate_lock in ext2_write_failed()
Date: Mon, 26 Oct 2026 16:48:03 +0000	[thread overview]
Message-ID: <at-BCY4VuCMiwICf@pedro-suse.tail5790ac.ts.net> (raw)
In-Reply-To: <akdbsbqjyqpju5a42sh64yovrl47p7ty3yp5nm36pmfgrduaxj@tlx6yc5atpiy>

On Mon, Oct 26, 2026 at 02:16:19PM +0100, Jan Kara wrote:
> On Sat 24-10-26 23:27:26, Pedro Falcato wrote:
> > Currently, ext2_write_failed() takes care of removing extra data
> > (folios & blocks) from the page cache by first truncating the page cache,
> > then truncating the actual inode's blocks.
> > 
> > Understanding that this is correct - namely, that a concurrent page cache
> > lookup can't create stale pages and stale block mappings between
> > truncate_pagecache() and ext2_truncate_blocks() - is non trivial. This is
> > correct for two non-obvious reasons:
> > 
> > 1) every caller of ext2_write_failed() holds some sort of exclusion
> > against truncation. In most cases, callers hold (in some way) the inode
> > lock. ext2_write_failed() is only reachable from buffered/direct IO write
> > paths, which hold it. page_symlink() can also call write_begin _without
> > the inode lock_, but at that point the inode is I_NEW, so there are no other
> > users.
> > 
> > 2) the page cache is generally extremely careful at never instantiating
> > pages beyond EOF.
> > 
> > This is all quite confusing. Holding the invalidate lock across both
> > operations is largely simpler, and mirrors other bits of other filesystems
> > (like ext4_truncate_failed_write). Do that.
> > 
> > This has the side effect of making it so ext2_evict_inode() doesn't take
> > the invalidate_lock when truncating blocks on inode deletion. This is safe
> > as the inode should not have any users at that point.
> > 
> > Signed-off-by: Pedro Falcato <pfalcato@suse.de>
> 
> There's actually one more reason - filesystems that don't support hole
> punching are generally ok with the synchronization provided by inode lock
> and i_size checks (as within i_size allocated space can never disappear
> under you). But I agree this is all too subtle so you're change is a good
> one. Added to my tree.

Thanks!

Right. So I'm wondering if we couldn't assert some locks in truncate code.
Something like (in truncate_inode_pages_range):
	/* truncation is only safe in a couple of cases:
	 * 1) caller holds the invalidate_lock. This protects against hole
	 * punching and other truncate-like activities.
	 * 2) caller holds the inode lock. This excludes against truncate-like
	 * operations in a variety of cases.
	 * 3) inode is new or freeing - no need to synchronize anything since
	 * we should be the only user for this inode.
	 */
	lockdep_assert(lockdep_is_held(&mapping->invalidate_lock) ||
			((lockdep_is_held(&mapping->host->i_rwsem) &&
			 (lstart >= i_size_read(mapping->host) ||
			 file_does_not_support_holes) ||
			inode_new_or_freeing);

I'm sure I'm missing some silly edgecase, but it would be nice to have this
properly written down and asserted.

-- 
Pedro

      reply	other threads:[~2026-10-26 16:48 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-24 22:27 Pedro Falcato
2026-10-26 13:16 ` Jan Kara
2026-10-26 16:48   ` Pedro Falcato [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=at-BCY4VuCMiwICf@pedro-suse.tail5790ac.ts.net \
    --to=pfalcato@suse.de \
    --cc=jack@suse.com \
    --cc=jack@suse.cz \
    --cc=linux-ext4@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®