Re: [PATCH v5 2/2] xfs: prevent close() from hanging on frozen filesystems

On Fri, Aug 14, 2026 at 11:24:49AM -0700, Darrick J. Wong wrote:
> On Fri, Aug 14, 2026 at 06:25:41PM +0200, Carlos Maiolino wrote:
> > On Fri, Aug 14, 2026 at 12:28:19AM -0700, Christoph Hellwig wrote:
> > > On Thu, Aug 13, 2026 at 09:43:44PM +0530, Aditya Prakash Srivastava wrote:
> > > > 
> > > > Are there any remaining concerns or feedback that need
> > > > to be addressed with this patch?
> > > 
> > > Still looks good to me, but I think it just go lost.  It's a bit close
> > > for the 7.3 merge window now, but I'd suggest you resend it in a week
> > > or two to get it onto the agenda for 7.4 early.
> > 
> > Yup, I was waiting for Darrick to follow-up then it fell on limbo.
> > Please follow Christoph's advice, please rebase and re-send on top of
> > the tree after 7.3 merge window.
> 
> I ignored the response because it's clearly AI slop, and obviously
> wrong.

I haven't read that email until now, just noticed it was addressed to
you, thanks for pointing it out.

Aditya... I don't care how you generate your patches, but YOU are
responsible for the content you generate.

Replying somebody's review comments with LLM generated content... I
can't emphasize enough how disrespectful I think this kind of attitude
is.

Darrick spent his time reviewing your patch. You used a LLM model to
reply his email which I already find disrespectful enough, and worse,
you didn't even check the result? Why do you delegate to others your
responsibility to review your content? If you didn't understand the
generated content, that would already be a red flag that you shouldn't
be sending it. If you thought it was right, it means you didn't check it
carefully enough as you didn't even add any information saying you got
this from a LLM and wasn't sure how right the information was.

We are all overwhelmed with the inflow of patches now that writing them
has never been easier.... Yet, we dedicate our time and effort reviewing
them in an effort to keep the project's quality high. And yet we have
just so much time in our hands and we would appreciate a little respect
with at least reviewing the garbage you generated.

You can use whatever tool you want to generate the patches, but Linux
policy has been that YOU are responsible for whatever you wrote with
whatever tool you use.

And yet, I can't really emphasize how disrespectful I think such attitude
is. Somebody's using a LLM to reply to somebody's else emails/messages,
to say the least, make me believe you think your time is much more valuable
than ours, giving you didn't even bother to review the email you sent to
Darrick.

Carlos

> 
> "In XFS, the canonical locking hierarchy is:
> 
> "sb_start_write (freeze lock) -> IOLOCK -> ILOCK ->
> xfs_trans_alloc"
> 
> Nope.
> 
> "xfs_file_release() already holds XFS_IOLOCK_EXCL (acquired via
> xfs_ilock_nowait())..."
> 
> Nope.  The snippet I suggested isn't fully formed, but this is obviously
> wrong; go read xfs_file_release.
> 
> static inline void xfs_file_release_eofblocks(struct xfs_inode *ip)
> {
> 	if (!xfs_can_free_eofblocks(ip))
> 		return;
> 	if (xfs_iflags_test(ip, XFS_EOFBLOCKS_RELEASED))
> 		return;
> 
> 	/* take freeze protection and i_rwsem */
> 	if (!sb_start_write_trylock(...))
> 		return;
> 	if (!xfs_ilock_nowait(ip, XFS_IOLOCK_EXCL))
> 		goto out_sb_write;
> 
> 	/*
> 	 * recheck if we want to trim eofblocks and someone else hasn't
> 	 * already done this
> 	 */
> 	if (!xfs_can_free_eofblocks(ip))
> 		goto out_iolock;
> 	if (xfs_iflags_test_and_set(ip, XFS_EOFBLOCKS_RELEASED))
> 		goto out_iolock;
> 
> 	xfs_free_eofblocks(ip);
> 
> out_iolock:
> 	xfs_iunlock(ip, XFS_IOLOCK_EXCL);
> out_sb_write:
> 	sb_end_write(...);
> }
> 
> "xfs_trans_alloc() is the canonical, centralized place in XFS to
> manage write-count blocking semantics."
> 
> Nope.  This isn't even talking about the same vfs lock here.
> 
> --D
>