Re: [PATCH v3 resend 3/3] smb/client: fix nlink of an overwritten open file

On Fri, Aug 7, 2026 at 7:28 PM hehuiwen <[email protected]> wrote:
>
> The AI review of the overwrite rename patch raised two possible races.
>
> 1. A handle opened through a surviving hard link may be marked deleted:
>
>    target_fh -- target --+
>                          +--> inode X (nlink = 2)
>    alias_fh  -- alias  --+
>
>    CPU A                                   CPU B
>    -----                                   -----
>    rename(source, target)
>      server nlink: 2 -> 1
>
>                                            statx(alias,
>                                                  AT_STATX_FORCE_SYNC)
>                                              cached i_nlink: 2 -> 1
>
>    cifs_mark_open_handles_for_deleted_file()
>      sees i_nlink == 1
>      marks every handle:
>        target_fh: deleted                   correct
>        alias_fh:  deleted                   wrong
>
> 2. A concurrently refreshed link count may be decremented again:
>
>    CPU A                                   CPU B
>    -----                                   -----
>    rename(source, target)
>      server nlink: 2 -> 1
>
>                                            statx(alias,
>                                                  AT_STATX_FORCE_SYNC)
>                                              cached i_nlink: 2 -> 1
>
>    cifs_drop_nlink()
>      actual:   cached i_nlink: 1 -> 0       wrong
>      expected: cached i_nlink remains 1
>
> I tried addressing these problems by taking an i_nlink snapshot before
> the unlink/rename request, using it to decide which handles to mark,
> and decrementing the cached link count only if it still matched the
> snapshot.
>
> Unfortunately, an nlink snapshot does not show whether revalidation
> happened before or after unlink/rename. Therefore, it cannot fully
> address these races or reject stale attribute responses that arrive late.
>
> NFS addresses these issues with per-dentry silly rename, attribute
> generation counters, and cache invalidation. A similar CIFS solution
> may be challenging, as it must coordinate namespace operations,
> open-handle state, and asynchronous attribute updates.
>
> Do you have any ideas?
This appears to be a possible issue, so the current patch needs
improvement. I will drop the applied patch and await a response
regarding this.