[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ccb38a9b-4192-4863-9b29-497b55d99a6a@web.de>
Date: Thu, 9 Oct 2025 17:44:54 +0200
From: Markus Elfring <Markus.Elfring@....de>
To: Steve French <smfrench@...il.com>, linux-cifs@...r.kernel.org,
samba-technical@...ts.samba.org, Bharath SM <bharathsm@...rosoft.com>,
Paulo Alcantara <pc@...guebit.org>,
Ronnie Sahlberg <ronniesahlberg@...il.com>,
Shyam Prasad N <sprasad@...rosoft.com>, Steve French <sfrench@...ba.org>,
Tom Talpey <tom@...pey.com>, llvm@...ts.linux.dev,
oe-kbuild-all@...ts.linux.dev
Cc: LKML <linux-kernel@...r.kernel.org>, kernel-janitors@...r.kernel.org
Subject: Re: [PATCH] smb: client: Simplify a return statement in
get_smb2_acl_by_path()
> As pointed out by the kernel test robot a few minutes ago, this patch
> would introduce a regression (uninitialized rc variable in free_xid
> macro), so will remove this patch from for-next.
Will this (clang) compiler report be reconsidered once more under other circumstances?
…>> +++ b/fs/smb/client/smb2ops.c
>> @@ -3216,9 +3216,8 @@ get_smb2_acl_by_path(struct cifs_sb_info *cifs_sb,
>>
>> utf16_path = cifs_convert_path_to_utf16(path, cifs_sb);
>> if (!utf16_path) {
>> - rc = -ENOMEM;
>> free_xid(xid);
>> - return ERR_PTR(rc);
>> + return ERR_PTR(-ENOMEM);
>> }
>>
>> oparms = (struct cifs_open_parms) {
…
Can it be that the uninitialized rc variable would not really matter for
the adjusted statements in such an if branch?
Regards,
Markus
Powered by blists - more mailing lists