[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <202408131900.xhbYFHR4-lkp@intel.com>
Date: Tue, 13 Aug 2024 19:44:55 +0800
From: kernel test robot <lkp@...el.com>
To: Mickaël Salaün <mic@...ikod.net>,
Christian Brauner <brauner@...nel.org>,
Paul Moore <paul@...l-moore.com>
Cc: oe-kbuild-all@...ts.linux.dev,
Mickaël Salaün <mic@...ikod.net>,
linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-security-module@...r.kernel.org, selinux@...r.kernel.org,
Jan Kara <jack@...e.cz>, Al Viro <viro@...iv.linux.org.uk>,
Casey Schaufler <casey@...aufler-ca.com>,
James Morris <jmorris@...ei.org>, Jann Horn <jannh@...gle.com>,
Ondrej Mosnacek <omosnace@...hat.com>,
"Serge E . Hallyn" <serge@...lyn.com>,
Stephen Smalley <stephen.smalley.work@...il.com>
Subject: Re: [PATCH] fs,security: Fix file_set_fowner LSM hook inconsistencies
Hi Mickaël,
kernel test robot noticed the following build warnings:
[auto build test WARNING on pcmoore-selinux/next]
[also build test WARNING on linus/master v6.11-rc3]
[cannot apply to brauner-vfs/vfs.all next-20240813]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url: https://github.com/intel-lab-lkp/linux/commits/Micka-l-Sala-n/fs-security-Fix-file_set_fowner-LSM-hook-inconsistencies/20240813-004648
base: https://git.kernel.org/pub/scm/linux/kernel/git/pcmoore/selinux.git next
patch link: https://lore.kernel.org/r/20240812144936.1616628-1-mic%40digikod.net
patch subject: [PATCH] fs,security: Fix file_set_fowner LSM hook inconsistencies
config: x86_64-randconfig-122-20240813 (https://download.01.org/0day-ci/archive/20240813/202408131900.xhbYFHR4-lkp@intel.com/config)
compiler: gcc-11 (Debian 11.3.0-12) 11.3.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20240813/202408131900.xhbYFHR4-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@...el.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202408131900.xhbYFHR4-lkp@intel.com/
sparse warnings: (new ones prefixed by >>)
>> fs/file_table.c:153:25: sparse: sparse: incorrect type in assignment (different address spaces) @@ expected struct cred const [noderef] __rcu *cred @@ got struct cred const * @@
fs/file_table.c:153:25: sparse: expected struct cred const [noderef] __rcu *cred
fs/file_table.c:153:25: sparse: got struct cred const *
>> fs/file_table.c:157:36: sparse: sparse: incorrect type in argument 1 (different address spaces) @@ expected struct cred const *cred @@ got struct cred const [noderef] __rcu *cred @@
fs/file_table.c:157:36: sparse: expected struct cred const *cred
fs/file_table.c:157:36: sparse: got struct cred const [noderef] __rcu *cred
fs/file_table.c:69:28: sparse: sparse: incorrect type in argument 1 (different address spaces) @@ expected struct cred const *cred @@ got struct cred const [noderef] __rcu *cred @@
fs/file_table.c:69:28: sparse: expected struct cred const *cred
fs/file_table.c:69:28: sparse: got struct cred const [noderef] __rcu *cred
fs/file_table.c:69:28: sparse: sparse: incorrect type in argument 1 (different address spaces) @@ expected struct cred const *cred @@ got struct cred const [noderef] __rcu *cred @@
fs/file_table.c:69:28: sparse: expected struct cred const *cred
fs/file_table.c:69:28: sparse: got struct cred const [noderef] __rcu *cred
vim +153 fs/file_table.c
147
148 static int init_file(struct file *f, int flags, const struct cred *cred)
149 {
150 int error;
151
152 f->f_cred = get_cred(cred);
> 153 f->f_owner.cred = get_cred(cred);
154 error = security_file_alloc(f);
155 if (unlikely(error)) {
156 put_cred(f->f_cred);
> 157 put_cred(f->f_owner.cred);
158 return error;
159 }
160
161 rwlock_init(&f->f_owner.lock);
162 spin_lock_init(&f->f_lock);
163 mutex_init(&f->f_pos_lock);
164 f->f_flags = flags;
165 f->f_mode = OPEN_FMODE(flags);
166 /* f->f_version: 0 */
167
168 /*
169 * We're SLAB_TYPESAFE_BY_RCU so initialize f_count last. While
170 * fget-rcu pattern users need to be able to handle spurious
171 * refcount bumps we should reinitialize the reused file first.
172 */
173 atomic_long_set(&f->f_count, 1);
174 return 0;
175 }
176
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
Powered by blists - more mailing lists