On Wed, May 16, 2018 at 8:40 AM Tejun Heo <tj@xxxxxxxxxx> wrote:
> # ps -ef | grep kworker
> root 4 2 0 08:10 ? 00:00:00 kworker/0:0 <events>
> root 5 2 0 08:10 ? 00:00:00 [kworker/0:0H]
> root 6 2 0 08:10 ? 00:00:00 kworker/u32:0
<events_unbound>
> root 19 2 0 08:10 ? 00:00:00 kworker/1:0 <events>
> root 20 2 0 08:10 ? 00:00:00 kworker/1:0H <kblockd>
> root 25 2 0 08:10 ? 00:00:00 kworker/2:0
<events_power_efficient>
Me likey. This is exactly the kind of extra information I was hoping would
make it more obvious what the kworkers actually do. Thanks.
But:
> However, please note the [] around kowrker/0:0H. It turns out ps uses
> empty /proc/$PID/cmdline to detect kernel threads and puts [] around
> them. Now that kworkers are reporting non-empty cmdline, ps thinks
> they aren't kthreads and skips [].
Ok, I think we'll need to reintroduce the '[]', since clearly there are
things (at a minimum systemd, there might be others) that cares about the
exact details.
> 1. It doesn't look we can use cmdline to report more info about
> kworkers as it makes userland think they aren't kernel threads
> anymore and misbehave.
Yeah, so what the tools seem to do is
- use /proc/<pid>/cmdline for normal stuff
- if that is empty, use the /proc/stat information.
> 2. comm has always been limited to 16 chars including the termination
> (TASK_COMM_LEN). We can easily report the above kworker
> information through comm but there is some minute chance that
> userland is depending on TASK_COMM_LEN.
Not particularly minute, although I think long ago that field was just 8 or
10 characters, so it *has* changed over time.
What actually worries me more is that there are other ways that
/proc/<pid>/cmdline is empty: I can do things like
#include <sys/mman.h>
int main(void)
{
char empty[16384];
unsigned long ptr;
asm volatile("" :"=r" (ptr) : "0" (empty):"memory");
ptr = (ptr+4095) & ~4095;
munmap((void *)ptr, 32768);
sleep(1000);
asm volatile("" :"=r" (ptr) : "0" (empty):"memory");
}
and now a user program will have an empty /proc/<pid>/cmdline, and so "ps"
will show it as
17357 pts/0 S+ 0:00 [a.out]
too. I didn't look at what systemd does. But the point is, user space
*really* shouldn't think that "empty cmdline" means it's not a kernel
thread.
Anyway, my gut feel is that we should try making the /proc/<pid>/status
field bigger (not necessarily TASK_COMM_LEN - just add a similar
if (tsk->flags & PF_WQ_WORKER) {
to the task_name() code in fs/proc/array.c), and see if that works better.
I'd be surprised if that is limited to TASK_COMM_LEN in user space, since
Hmm?
(The tools _could_ look at /proc/<pid>/stat too, I haven't checked).
> 3. Userland tools using empty cmdline as an indicator for kernel
> threads seems potentially dangerous depending on what the
> distinction is used for. From the looks of it, any process should
> be able to clear out their cmdline using prctl.
Absolutely. Or just unmap it as above.
Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-api" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
