public inbox for linux-xfs@vger.kernel.org
 help / color / mirror / Atom feed
From: "Darrick J. Wong" <djwong@kernel.org>
To: Christoph Hellwig <hch@lst.de>
Cc: Chandan Babu R <chandan.babu@oracle.com>,
	Dave Chinner <dchinner@redhat.com>,
	linux-xfs@vger.kernel.org
Subject: Re: [PATCH 02/10] xfs: remove the i_mode check in xfs_release
Date: Mon, 24 Jun 2024 08:34:59 -0700	[thread overview]
Message-ID: <20240624153459.GF3058325@frogsfrogsfrogs> (raw)
In-Reply-To: <20240623053532.857496-3-hch@lst.de>

On Sun, Jun 23, 2024 at 07:34:47AM +0200, Christoph Hellwig wrote:
> xfs_release is only called from xfs_file_release, which is wired up as
> the f_op->release handler for regular files only.
> 
> Signed-off-by: Christoph Hellwig <hch@lst.de>
> ---
>  fs/xfs/xfs_inode.c | 3 ---
>  1 file changed, 3 deletions(-)
> 
> diff --git a/fs/xfs/xfs_inode.c b/fs/xfs/xfs_inode.c
> index 38f946e3be2da3..9a9340aebe9d8a 100644
> --- a/fs/xfs/xfs_inode.c
> +++ b/fs/xfs/xfs_inode.c
> @@ -1552,9 +1552,6 @@ xfs_release(
>  	xfs_mount_t	*mp = ip->i_mount;
>  	int		error = 0;
>  
> -	if (!S_ISREG(VFS_I(ip)->i_mode) || (VFS_I(ip)->i_mode == 0))

How would we encounter !i_mode regular files being released?

If an open file's link count is incorrectly low, it can't get freed
until after all the open file descriptors have been released, right?
Or is there some other vector for this?

I'm wondering if this ought to be:

	if (XFS_IS_CORRUPT(mp, !VFS_I(ip)->i_mode)) {
		xfs_inode_mark_sick(ip);
		return -EFSCORRUPTED;
	}

--D

> -		return 0;
> -
>  	/* If this is a read-only mount, don't do this (would generate I/O) */
>  	if (xfs_is_readonly(mp))
>  		return 0;
> -- 
> 2.43.0
> 
> 

  reply	other threads:[~2024-06-24 15:35 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-06-23  5:34 post-EOF block handling revamp Christoph Hellwig
2024-06-23  5:34 ` [PATCH 01/10] xfs: fix freeing speculative preallocations for preallocated files Christoph Hellwig
2024-06-24 15:30   ` Darrick J. Wong
2024-06-23  5:34 ` [PATCH 02/10] xfs: remove the i_mode check in xfs_release Christoph Hellwig
2024-06-24 15:34   ` Darrick J. Wong [this message]
2024-06-24 15:50     ` Christoph Hellwig
2024-08-07 15:01       ` Darrick J. Wong
2024-06-23  5:34 ` [PATCH 03/10] xfs: refactor f_op->release handling Christoph Hellwig
2024-06-24 15:35   ` Darrick J. Wong
2024-06-23  5:34 ` [PATCH 04/10] xfs: don't bother returning errors from xfs_file_release Christoph Hellwig
2024-06-24 15:39   ` Darrick J. Wong
2024-06-24 15:51     ` Christoph Hellwig
2024-08-07 14:59       ` Darrick J. Wong
2024-06-23  5:34 ` [PATCH 05/10] xfs: skip all of xfs_file_release when shut down Christoph Hellwig
2024-06-24 15:41   ` Darrick J. Wong
2024-06-23  5:34 ` [PATCH 06/10] xfs: don't free post-EOF blocks on read close Christoph Hellwig
2024-06-24 15:43   ` Darrick J. Wong
2024-06-23  5:34 ` [PATCH 07/10] xfs: only free posteof blocks on first close Christoph Hellwig
2024-06-24 15:46   ` Darrick J. Wong
2024-06-24 16:08     ` Christoph Hellwig
2024-06-24 16:49       ` Darrick J. Wong
2024-06-23  5:34 ` [PATCH 08/10] xfs: check XFS_IDIRTY_RELEASE earlier in xfs_release_eofblocks Christoph Hellwig
2024-06-24 15:50   ` Darrick J. Wong
2024-06-24 15:54     ` Christoph Hellwig
2024-06-23  5:34 ` [PATCH 09/10] xfs: simplify extent lookup in xfs_can_free_eofblocks Christoph Hellwig
2024-06-24 15:51   ` Darrick J. Wong
2024-06-23  5:34 ` [PATCH 10/10] xfs: reclaim speculative preallocations for append only files Christoph Hellwig
2024-06-24 15:54   ` Darrick J. Wong
2024-06-24 16:07     ` Christoph Hellwig
2024-06-24 17:06       ` Darrick J. Wong
2024-06-24 17:22         ` Christoph Hellwig
2024-06-24 18:44           ` Darrick J. Wong

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=20240624153459.GF3058325@frogsfrogsfrogs \
    --to=djwong@kernel.org \
    --cc=chandan.babu@oracle.com \
    --cc=dchinner@redhat.com \
    --cc=hch@lst.de \
    --cc=linux-xfs@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