From: kernel test robot <lkp@intel.com>
To: Christian Brauner <brauner@kernel.org>
Cc: llvm@lists.linux.dev, kbuild-all@lists.01.org,
linux-kernel@vger.kernel.org
Subject: [vfs-idmapping:fs.posix_acl.vfsuid 14/37] fs/cifs/cifssmb.c:3474:48: warning: variable 'i' is uninitialized when used here
Date: Mon, 12 Sep 2022 07:23:06 +0800 [thread overview]
Message-ID: <202209120746.50JlBseF-lkp@intel.com> (raw)
tree: https://git.kernel.org/pub/scm/linux/kernel/git/vfs/idmapping.git fs.posix_acl.vfsuid
head: d37e11d9b40fc35810217121aa3205b7975fd4c6
commit: 7839133c91c444aa039e18550338d10b7e30d51e [14/37] cifs: add ->set_acl() method
config: i386-allyesconfig (https://download.01.org/0day-ci/archive/20220912/202209120746.50JlBseF-lkp@intel.com/config)
compiler: clang version 14.0.6 (https://github.com/llvm/llvm-project f28c006a5895fc0e329fe15fead81e37457cb1d1)
reproduce (this is a W=1 build):
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# https://git.kernel.org/pub/scm/linux/kernel/git/vfs/idmapping.git/commit/?id=7839133c91c444aa039e18550338d10b7e30d51e
git remote add vfs-idmapping https://git.kernel.org/pub/scm/linux/kernel/git/vfs/idmapping.git
git fetch --no-tags vfs-idmapping fs.posix_acl.vfsuid
git checkout 7839133c91c444aa039e18550338d10b7e30d51e
# save the config file
mkdir build_dir && cp config build_dir/.config
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross W=1 O=build_dir ARCH=i386 SHELL=/bin/bash drivers/auxdisplay/ drivers/bus/ drivers/gpu/drm/i915/ drivers/net/ethernet/stmicro/stmmac/ drivers/usb/core/ drivers/vdpa/ drivers/vfio/ fs/cifs/ net/mptcp/ net/netfilter/
If you fix the issue, kindly add following tag where applicable
Reported-by: kernel test robot <lkp@intel.com>
All warnings (new ones prefixed by >>):
>> fs/cifs/cifssmb.c:3474:48: warning: variable 'i' is uninitialized when used here [-Wuninitialized]
convert_ace_to_cifs_ace(&cifs_acl->ace_array[i], pa);
^
fs/cifs/cifssmb.c:3447:7: note: initialize the variable 'i' to silence this warning
int i;
^
= 0
1 warning generated.
vim +/i +3474 fs/cifs/cifssmb.c
3431
3432 /**
3433 * ACL_to_cifs_posix - convert ACLs from POSIX ACL to cifs format
3434 * @parm_data: ACLs in cifs format to conver to
3435 * @acl: ACLs in POSIX ACL format to convert from
3436 * @acl_type: the type of POSIX ACLs stored in @acl
3437 *
3438 * Return: the number cifs ACL entries after conversion
3439 */
3440 static __u16 ACL_to_cifs_posix(char *parm_data, const struct posix_acl *acl,
3441 const int acl_type)
3442 {
3443 __u16 rc = 0;
3444 struct cifs_posix_acl *cifs_acl = (struct cifs_posix_acl *)parm_data;
3445 const struct posix_acl_entry *pa, *pe;
3446 int count;
3447 int i;
3448
3449 if ((acl == NULL) || (cifs_acl == NULL))
3450 return 0;
3451
3452 count = acl->a_count;
3453 cifs_dbg(FYI, "setting acl with %d entries\n", count);
3454
3455 /*
3456 * Note that the uapi POSIX ACL version is verified by the VFS and is
3457 * independent of the cifs ACL version. Changing the POSIX ACL version
3458 * is a uapi change and if it's changed we will pass down the POSIX ACL
3459 * version in struct posix_acl from the VFS. For now there's really
3460 * only one that all filesystems know how to deal with.
3461 */
3462 cifs_acl->version = cpu_to_le16(1);
3463 if (acl_type == ACL_TYPE_ACCESS) {
3464 cifs_acl->access_entry_count = cpu_to_le16(count);
3465 cifs_acl->default_entry_count = cpu_to_le16(0xFFFF);
3466 } else if (acl_type == ACL_TYPE_DEFAULT) {
3467 cifs_acl->default_entry_count = cpu_to_le16(count);
3468 cifs_acl->access_entry_count = cpu_to_le16(0xFFFF);
3469 } else {
3470 cifs_dbg(FYI, "unknown ACL type %d\n", acl_type);
3471 return 0;
3472 }
3473 FOREACH_ACL_ENTRY(pa, acl, pe) {
> 3474 convert_ace_to_cifs_ace(&cifs_acl->ace_array[i], pa);
3475 }
3476 if (rc == 0) {
3477 rc = (__u16)(count * sizeof(struct cifs_posix_ace));
3478 rc += sizeof(struct cifs_posix_acl);
3479 /* BB add check to make sure ACL does not overflow SMB */
3480 }
3481 return rc;
3482 }
3483
--
0-DAY CI Kernel Test Service
https://01.org/lkp
reply other threads:[~2022-09-11 23:23 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=202209120746.50JlBseF-lkp@intel.com \
--to=lkp@intel.com \
--cc=brauner@kernel.org \
--cc=kbuild-all@lists.01.org \
--cc=linux-kernel@vger.kernel.org \
--cc=llvm@lists.linux.dev \
/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