From: kernel test robot <lkp@intel.com>
To: luca.boccassi@gmail.com, linux-fsdevel@vger.kernel.org
Cc: oe-kbuild-all@lists.linux.dev, christian@brauner.io,
linux-kernel@vger.kernel.org, oleg@redhat.com
Subject: Re: [PATCH v11] pidfd: add ioctl to retrieve pid info
Date: Sun, 13 Oct 2024 15:19:00 +0800 [thread overview]
Message-ID: <202410131455.zyQFJN9p-lkp@intel.com> (raw)
In-Reply-To: <20241010155401.2268522-1-luca.boccassi@gmail.com>
Hi,
kernel test robot noticed the following build errors:
[auto build test ERROR on 8cf0b93919e13d1e8d4466eb4080a4c4d9d66d7b]
url: https://github.com/intel-lab-lkp/linux/commits/luca-boccassi-gmail-com/pidfd-add-ioctl-to-retrieve-pid-info/20241010-235621
base: 8cf0b93919e13d1e8d4466eb4080a4c4d9d66d7b
patch link: https://lore.kernel.org/r/20241010155401.2268522-1-luca.boccassi%40gmail.com
patch subject: [PATCH v11] pidfd: add ioctl to retrieve pid info
config: alpha-randconfig-r054-20241013 (https://download.01.org/0day-ci/archive/20241013/202410131455.zyQFJN9p-lkp@intel.com/config)
compiler: alpha-linux-gcc (GCC) 13.3.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20241013/202410131455.zyQFJN9p-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@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202410131455.zyQFJN9p-lkp@intel.com/
All errors (new ones prefixed by >>):
fs/pidfs.c: In function 'pidfd_info':
>> fs/pidfs.c:162:34: error: 'pids_cgrp_id' undeclared (first use in this function); did you mean 'misc_cgrp_id'?
162 | cgrp = task_cgroup(task, pids_cgrp_id);
| ^~~~~~~~~~~~
| misc_cgrp_id
fs/pidfs.c:162:34: note: each undeclared identifier is reported only once for each function it appears in
vim +162 fs/pidfs.c
129
130 if (!uinfo)
131 return -EINVAL;
132 if (usize < sizeof(struct pidfd_info))
133 return -EINVAL; /* First version, no smaller struct possible */
134
135 if (copy_from_user(&request_mask, &uinfo->request_mask, sizeof(request_mask)))
136 return -EFAULT;
137
138 c = get_task_cred(task);
139 if (!c)
140 return -ESRCH;
141
142 /* Unconditionally return identifiers and credentials, the rest only on request */
143
144 user_ns = current_user_ns();
145 kinfo.ruid = from_kuid_munged(user_ns, c->uid);
146 kinfo.rgid = from_kgid_munged(user_ns, c->gid);
147 kinfo.euid = from_kuid_munged(user_ns, c->euid);
148 kinfo.egid = from_kgid_munged(user_ns, c->egid);
149 kinfo.suid = from_kuid_munged(user_ns, c->suid);
150 kinfo.sgid = from_kgid_munged(user_ns, c->sgid);
151 kinfo.fsuid = from_kuid_munged(user_ns, c->fsuid);
152 kinfo.fsgid = from_kgid_munged(user_ns, c->fsgid);
153 kinfo.request_mask |= PIDFD_INFO_CREDS;
154 put_cred(c);
155
156 #ifdef CONFIG_CGROUPS
157 /*
158 * The cgroup id cannot be retrieved anymore after the task has exited
159 * (even if it has not been reaped yet), contrary to other fields. Set
160 * the flag only if we can still access it. */
161 rcu_read_lock();
> 162 cgrp = task_cgroup(task, pids_cgrp_id);
163 if (cgrp) {
164 kinfo.cgroupid = cgroup_id(cgrp);
165 kinfo.request_mask |= PIDFD_INFO_CGROUPID;
166 }
167 rcu_read_unlock();
168 #endif
169
170 /*
171 * Copy pid/tgid last, to reduce the chances the information might be
172 * stale. Note that it is not possible to ensure it will be valid as the
173 * task might return as soon as the copy_to_user finishes, but that's ok
174 * and userspace expects that might happen and can act accordingly, so
175 * this is just best-effort. What we can do however is checking that all
176 * the fields are set correctly, or return ESRCH to avoid providing
177 * incomplete information. */
178
179 kinfo.ppid = task_ppid_nr_ns(task, NULL);
180 kinfo.tgid = task_tgid_vnr(task);
181 kinfo.pid = task_pid_vnr(task);
182 kinfo.request_mask |= PIDFD_INFO_PID;
183
184 if (kinfo.pid == 0 || kinfo.tgid == 0 || (kinfo.ppid == 0 && kinfo.pid != 1))
185 return -ESRCH;
186
187 /*
188 * If userspace and the kernel have the same struct size it can just
189 * be copied. If userspace provides an older struct, only the bits that
190 * userspace knows about will be copied. If userspace provides a new
191 * struct, only the bits that the kernel knows about will be copied.
192 */
193 if (copy_to_user(uinfo, &kinfo, min(usize, sizeof(kinfo))))
194 return -EFAULT;
195
196 return 0;
197 }
198
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
next prev parent reply other threads:[~2024-10-13 7:19 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-10-10 15:52 [PATCH v11] pidfd: add ioctl to retrieve pid info luca.boccassi
2024-10-13 7:19 ` kernel test robot [this message]
2024-10-21 14:45 ` Christian Brauner
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=202410131455.zyQFJN9p-lkp@intel.com \
--to=lkp@intel.com \
--cc=christian@brauner.io \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=luca.boccassi@gmail.com \
--cc=oe-kbuild-all@lists.linux.dev \
--cc=oleg@redhat.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