Linux CIFS filesystem development
 help / color / mirror / Atom feed
From: Paulo Alcantara <pc@manguebit.org>
To: Frank Sorenson <sorenson@redhat.com>,
	linux-cifs@vger.kernel.org, stfrench@microsoft.com
Subject: Re: [PATCH 0/2] cifs: follow-on fixes to time_last_write mechanism
Date: Mon, 27 Jul 2026 15:18:29 -0300	[thread overview]
Message-ID: <2ff7ecbb966ccaa5dd3768b0fdf38d39@manguebit.org> (raw)
In-Reply-To: <20260724163036.2670328-1-sorenson@redhat.com>

Frank Sorenson <sorenson@redhat.com> writes:

> This series addresses two correctness issues in commit e8a8d54c2d50
> ("cifs: prevent readdir from changing file size due to stale directory
> metadata"), which introduced the time_last_write field to protect cached
> file sizes from stale Windows Server directory enumeration metadata.
>
> Patch 1 consolidates the time_last_write stamp into _cifsFileInfo_put().
> The original commit scattered the stamp across cifs_close(),
> smb2_deferred_work_close(), and three deferred-close drain functions in
> misc.c.  This missed the case where background I/O holds the final file
> reference after userspace close() returns -- the stamp was anchored to
> the earlier userspace-close time rather than the actual server close,
> allowing the protection window to expire before the handle was removed
> from openFileList.  Moving the stamp into _cifsFileInfo_put() under
> open_file_lock provides a single canonical location that covers all close
> paths and uses the spinlock's store-release/load-acquire pairing with
> is_inode_writable() for correct memory ordering.
>
> Patch 2 fixes the stamp placement in the setattr/truncate paths.
> cifs_file_set_size() calls cifs_setsize() on success, which calls
> i_size_write() and updates i_size.  The subsequent check
> attrs->ia_size != i_size_read() therefore always evaluates false after a
> successful cifs_file_set_size(), making the stamp dead code -- the
> truncate path was completely unprotected.  The fix moves the stamp to
> before the RPC call, guarded by attrs->ia_size != i_size_read() to
> exclude no-op same-size ftruncate(2) calls.  On failure the stamp is
> left in place rather than restored: restoring a stale snapshot (prev_tlw)
> could silently erase a concurrent _cifsFileInfo_put() close stamp if that
> close arrived between the READ_ONCE and the smp_store_release.  readdir
> is suppressed until the stamp expires; stat() is unaffected because
> cifs_revalidate_dentry_attr() uses from_readdir=false, bypassing the
> time_last_write check entirely and always returning an authoritative
> QUERY_INFO result.
>
> Frank Sorenson (2):
>   cifs: consolidate time_last_write stamp into _cifsFileInfo_put()
>   cifs: fix time_last_write stamp placement in setattr/truncate paths

Reviewed-by: Paulo Alcantara (Red Hat) <pc@manguebit.org>

  parent reply	other threads:[~2026-07-27 18:18 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-24 16:30 [PATCH 0/2] cifs: follow-on fixes to time_last_write mechanism Frank Sorenson
2026-07-24 16:30 ` [PATCH 1/2] cifs: consolidate time_last_write stamp into _cifsFileInfo_put() Frank Sorenson
2026-07-24 16:30 ` [PATCH 2/2] cifs: fix time_last_write stamp placement in setattr/truncate paths Frank Sorenson
2026-07-27 18:18 ` Paulo Alcantara [this message]
2026-07-28  2:45   ` [PATCH 0/2] cifs: follow-on fixes to time_last_write mechanism Steve French

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=2ff7ecbb966ccaa5dd3768b0fdf38d39@manguebit.org \
    --to=pc@manguebit.org \
    --cc=linux-cifs@vger.kernel.org \
    --cc=sorenson@redhat.com \
    --cc=stfrench@microsoft.com \
    /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