Linux CIFS filesystem development
 help / color / mirror / Atom feed
From: "Reiterer, Horst" <horst.reiterer@fabasoft.com>
To: Steve French <smfrench@gmail.com>, Paulo Alcantara <pc@manguebit.com>
Cc: "linux-cifs@vger.kernel.org" <linux-cifs@vger.kernel.org>
Subject: RE: [PATCH] smb: client: fix chmod(2) regression with ATTR_READONLY
Date: Wed, 19 Feb 2025 10:04:50 +0000	[thread overview]
Message-ID: <08e226c8df7246fbaf710f36b39ead4a@fabasoft.com> (raw)

Hi,

thanks, Steve and Paulo! Considering the severity (chmod does not take effect anymore) and the fact that this regression was caused by dropping a condition in two lines of code that is merely being restored by the fix (basically, it's a partial revert), is there any way to prioritize this change as there's no production-ready workaround? It's difficult to avoid updating to 6.6+ at this point.

Cheers,

Horst Reiterer

-----Ursprüngliche Nachricht-----
Von: Steve French <smfrench@gmail.com> 
Gesendet: Montag, 17. Februar 2025 00:20
An: Paulo Alcantara <pc@manguebit.com>
Cc: linux-cifs@vger.kernel.org; Reiterer, Horst <horst.reiterer@fabasoft.com>
Betreff: Re: [PATCH] smb: client: fix chmod(2) regression with ATTR_READONLY

tentatively merged into cifs-2.6.git for-next pending more testing and review

On Sun, Feb 16, 2025 at 3:02 PM Paulo Alcantara <pc@manguebit.com> wrote:
>
> When the user sets a file or directory as read-only (e.g. ~S_IWUGO), 
> the client will set the ATTR_READONLY attribute by sending an 
> SMB2_SET_INFO request to the server in cifs_setattr_{,nounix}(), but 
> cifsInodeInfo::cifsAttrs will be left unchanged as the client will 
> only update the new file attributes in the next call to
> {smb311_posix,cifs}_get_inode_info() with the new metadata filled in 
> @data parameter.
>
> Commit a18280e7fdea ("smb: cilent: set reparse mount points as
> automounts") mistakenly removed the @data NULL check when calling 
> is_inode_cache_good(), which broke the above case as the new 
> ATTR_READONLY attribute would end up not being updated on files with a 
> read lease.
>
> Fix this by updating the inode whenever we have cached metadata in 
> @data parameter.
>
> Reported-by: Horst Reiterer <horst.reiterer@fabasoft.com>
> Closes: 
> https://lore.kernel.org/r/85a16504e09147a195ac0aac1c801280@fabasoft.co
> m
> Fixes: a18280e7fdea ("smb: cilent: set reparse mount points as 
> automounts")
> Signed-off-by: Paulo Alcantara (Red Hat) <pc@manguebit.com>
> ---
>  fs/smb/client/inode.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/fs/smb/client/inode.c b/fs/smb/client/inode.c index 
> 214240612549..616149c7f0a5 100644
> --- a/fs/smb/client/inode.c
> +++ b/fs/smb/client/inode.c
> @@ -1421,7 +1421,7 @@ int cifs_get_inode_info(struct inode **inode,
>         struct cifs_fattr fattr = {};
>         int rc;
>
> -       if (is_inode_cache_good(*inode)) {
> +       if (!data && is_inode_cache_good(*inode)) {
>                 cifs_dbg(FYI, "No need to revalidate cached inode sizes\n");
>                 return 0;
>         }
> @@ -1520,7 +1520,7 @@ int smb311_posix_get_inode_info(struct inode **inode,
>         struct cifs_fattr fattr = {};
>         int rc;
>
> -       if (is_inode_cache_good(*inode)) {
> +       if (!data && is_inode_cache_good(*inode)) {
>                 cifs_dbg(FYI, "No need to revalidate cached inode sizes\n");
>                 return 0;
>         }
> --
> 2.48.1
>


--
Thanks,

Steve

             reply	other threads:[~2025-02-19 10:11 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-02-19 10:04 Reiterer, Horst [this message]
2025-02-19 13:49 ` [PATCH] smb: client: fix chmod(2) regression with ATTR_READONLY Paulo Alcantara
  -- strict thread matches above, loose matches on Subject: below --
2025-02-16 21:02 Paulo Alcantara
2025-02-16 23:20 ` 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=08e226c8df7246fbaf710f36b39ead4a@fabasoft.com \
    --to=horst.reiterer@fabasoft.com \
    --cc=linux-cifs@vger.kernel.org \
    --cc=pc@manguebit.com \
    --cc=smfrench@gmail.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