从应⽤到内核，分析top命令显⽰的进程名包含中括号[]的含义背景
在执⾏top/ps命令的时候，在COMMAND⼀列，我们会发现，有些进程名被[]括起来了，例如
PID PPID USER STAT VSZ %VSZ %CPU COMMAND
1542 928 root R 1064 2% 5% top
1 0 root S 1348 2% 0% /sbin/procd
928 1 root S 1060 2% 0% /bin/ash --login
115 2 root SW 0 0% 0% [kworker/u4:2]
6 2 root SW 0 0% 0% [kworker/u4:0]
4 2 root SW 0 0% 0% [kworker/0:0]
697 2 root SW 0 0% 0% [kworker/1:3]
703 2 root SW 0 0% 0% [kworker/0:3]
15 2 root SW 0 0% 0% [kworker/1:0]
27 2 root SW 0 0% 0% [kworker/1:1]
本⽂除了探索top中[]的含义外，更重要的是，我们如何从仅有的信息定位到问题？
从应⽤代码到内核代码，授⼈以鱼不如授⼈以渔，你觉得呢？
对分析过程不感兴趣的童鞋，可以直接跳转到结论
应⽤代码逻辑分析
关键字：COMMAND
获取busybox的源码后，试试简单粗暴的检索关键字
[GMPY@12:22 busybox-1.27.2]$grep "COMMAND" -rnw *
结果发现，太多匹配的数据
applets/usage_pod.c:79: printf("=head1 COMMAND DESCRIPTIONS\n\n");
archival/cpio.c:100: --rsh-command=COMMAND Use remote COMMAND instead of rsh
docs/BusyBox.html:1655:<p>which [COMMAND]...</p>
docs/BusyBox.html:1657:<p>Locate a COMMAND</p>
:93:COMMAND DESCRIPTIONS
:112: brctl COMMAND [BRIDGE [INTERFACE]]
:612: ip ip [OPTIONS] address|route|link|neigh|rule [COMMAND]
:614: OPTIONS := -f[amily] inet|inet6|link | -o[neline] COMMAND := ip addr
:1354: which [COMMAND]...
:1356: Locate a COMMAND
......
此时我发现，第⼀次匹配时因为存在⼤量⾮源码⽂件，所以显得很多，那么我能不能只检索C⽂件呢？
[GMPY@12:25 busybox-1.27.2]$find -name "*.c" -exec grep -Hn --color=auto "COMMAND" {} \;
这次结果只有71⾏，简单扫了下匹配的⽂件，有个有意思的发现
......
./shell/ash.c:9707: if (d == COMMANDCMD) {
./editors/vi.c:1109: // get the COMMAND into cmd[]
./procps/lsof.c:31: * COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME
./procps/top.c:626: " COMMAND");
./procps/top.c:701: /* PID PPID USER STAT VSZ %VSZ [%CPU] COMMAND */
./procps/top.c:841: strcpy(line_buf, HDR_STR " COMMAND");
./procps/top.c:854: /* PID VSZ VSZRW RSS (SHR) DIRTY (SHR) COMMAND */
./procps/ps.c:441: { 16 , "comm" ,"COMMAND",func_comm ,PSSCAN_COMM },
.
.....
在busybox中，每⼀个命令都是单独⼀个⽂件，这代码逻辑结构好，我们直接进⼊procps/top.c⽂件626⾏
函数：display_process_list
procps/top.c的626⾏属于函数display_process_list，简单看⼀下代码逻辑
static NOINLINE void display_process_list(int lines_rem, int scr_width)
{
......
/* 打印表头 */
printf(OPT_BATCH_MODE ? "%.*s" : "\033[7m%.*s\033[0m", scr_width,
" PID PPID USER STAT VSZ %VSZ"
IF_FEATURE_TOP_SMP_PROCESS(" CPU")
IF_FEATURE_TOP_CPU_USAGE_PERCENTAGE(" %CPU")
" COMMAND");
......
grep命令有什么用/* 遍历每⼀个进程对应的描述 */
while (--lines_rem >= 0) {
if (s->vsz >= 100000)
sprintf(vsz_str_buf, "%6ldm", s->vsz/1024);
else
sprintf(vsz_str_buf, "%7lu", s->vsz);
/*打印每⼀⾏中除了COMMAND之外的信息，例如PID，USER，STAT等 */
col = snprintf(line_buf, scr_width,
"\n" "%5u%6u %-8.8s %s%s" FMT
IF_FEATURE_TOP_SMP_PROCESS(" %3d")
IF_FEATURE_TOP_CPU_USAGE_PERCENTAGE(FMT)
" ",
s->pid, s->ppid, get_cached_username(s->uid),
s->state, vsz_str_buf,
SHOW_STAT(pmem)
IF_FEATURE_TOP_SMP_PROCESS(, s->last_seen_on_cpu)
IF_FEATURE_TOP_CPU_USAGE_PERCENTAGE(, SHOW_STAT(pcpu))
);
/* 关键在这，读取cmdline */
if ((int)(col + 1) < scr_width)
read_cmdline(line_buf + col, scr_width - col, s->pid, s->comm);
......
}
}
剔除⽆关代码后，函数逻辑就清晰了
1. 在此函数之前的代码中已经遍历了所有进程，并构建了描述结构体
2. 在display_process_list中遍历描述结构体，并按规定顺序打印信息
3. 通过read_cmdline，获取并打印进程名
我们进⼊到函数read_cmdline
函数：read_cmdline
void FAST_FUNC read_cmdline(char *buf, int col, unsigned pid, const char *comm)
{
......
sprintf(filename, "/proc/%u/cmdline", pid);
sz = open_read_close(filename, buf, col - 1);
if (sz > 0) {
......
while (sz >= 0) {
if ((unsigned char)(buf[sz]) < ' ')
buf[sz] = ' ';
sz--;
}
......
if (strncmp(base, comm, comm_len) != 0) {
......
snprintf(buf, col, "{%s}", comm);
......
} else {
snprintf(buf, col, "[%s]", comm ? comm : "?");
}
}
剔除⽆关代码后，我发现
1. 通过/proc/<PID>/cmdline获取进程名
2. 如果/proc/<PID>/cmdline为空时，则使⽤comm，此时⽤[]括起来
3. 如果cmdline的basename与comm不⼀致，则⽤{}括起来
为了⽅便阅读，不再展开分析cmdline和comm。
我们把问题聚焦在，什么情况下，/proc/<PID>/cmdline为空？
内核代码逻辑分析
关键字：cmdline
/proc挂载的是proc，⼀种特殊的⽂件系统，cmdline也肯定是其特有的功能，
假设我们是内核⼩⽩，此时我们可以做的就是在内核proc源码中检索关键字cmdline [GMPY@09:54 proc]$cd fs/proc && grep "cmdline" -rnw *
发现有两个关键的匹配⽂件 base.c 和 cmdline.c
array.c:11: * Pauline Middelink : Made cmdline,envline only break at '\0's, to
base.c:224: /* Check if process spawned far enough to have cmdline. */
base.c:708: * May current process learn task's sched/cmdline info (for hide_pid_min=1)
base.c:2902: REG("cmdline", S_IRUGO, proc_pid_cmdline_ops),
base.c:3294: REG("cmdline", S_IRUGO, proc_pid_cmdline_ops),
cmdline.c:26: proc_create("cmdline", 0, NULL, &cmdline_proc_fops);
Makefile:16:proc-y += cmdline.o
vmcore.c:1158: * If elfcorehdr= has been passed in cmdline or created in 2nd kernel,
cmdline.c的代码逻辑⾮常简单，很容易发现其是/proc/cmdline的实现，并不是我们的需求
让我们把⽬光聚焦到base.c，相关代码
REG("cmdline", S_IRUGO, proc_pid_cmdline_ops),
经验的直觉告诉我，
1. cmdline：是⽂件名
2. S_IRUGO：是⽂件权限
3. proc_pid_cmdline_ops：是⽂件对应的操作结构体
果不其然，进⼊proc_pid_cmdline_ops我们发现其定义为
static const struct file_operations proc_pid_cmdline_ops = {
.read = proc_pid_cmdline_read,
.llseek = generic_file_llseek,
}
函数：proc_pid_cmdline_read
static ssize_t proc_pid_cmdline_read(struct file *file, char __user *buf,
size_t _count, loff_t *pos)
{
......
/* 获取进程对应的虚拟地址空间描述符 */
mm = get_task_mm(tsk);
......
/* 获取argv的地址和env的地址 */
arg_start = mm->arg_start;
arg_end = mm->arg_end;
env_start = mm->env_start;
env_end = mm->env_end;
......
while (count > 0 && len > 0) {
......
/* 计算地址偏移 */
p = arg_start + *pos;
while (count > 0 && len > 0) {
......
/* 获取进程地址空间的数据 */
nr_read = access_remote_vm(mm, p, page, _count, FOLL_ANON);
......
}
}
}
⼩⽩此时可能就疑惑了，你怎么知道access_remote_vm是⼲嘛的？
很简单，跳转到access_remote_vm函数中，可以看到此函数是有注释的
/**
* access_remote_vm - access another process' address space
* @mm: the mm_struct of the target address space
* @addr: start address to access
* @buf: source or destination buffer
* @len: number of bytes to transfer
* @gup_flags: flags modifying lookup behaviour
*
* The caller must hold a reference on @mm.
*/
int access_remote_vm(struct mm_struct *mm, unsigned long addr,
void *buf, int len, unsigned int gup_flags)
{
return __access_remote_vm(NULL, mm, addr, buf, len, gup_flags);
}
Linux内核源码中，很多函数都有很规范的功能说明，参数说明，注意事项等等，我们要充分利⽤这些资源学习代码。扯远了，让我们回到主题上。
从proc_pid_cmdline_read中我们发现，读/proc/<PID>/cmdline实际上就是读取arg_start开始的的地址空间数据。所以，当这地址空间数据为空时，当然就读不到任何数据了。那么问题来了，什么时候arg_start标识的地址空间数据为空？
关键字：arg_start
地址空间相关的，绝对不仅仅是proc的事⼉，我们试着在内核源码全局检索关键字
[GMPY@09:55 proc]$find -name "*.c" -exec grep --color=auto -Hnw "arg_start" {} \;
匹配不少，不想⼀个⼀个看，且从检索出来的代码不到⽅向
./mm/util.c:635: unsigned long arg_start, arg_end, env_start, env_end;
......
./kernel/sys.c:1747: offsetof(struct prctl_mm_map, arg_start),
......
./fs/exec.c:709: mm->arg_start = bprm->p - stack_shift;
./fs/exec.c:722: mm->arg_start = bprm->p;
......
.
/fs/binfmt_elf.c:301: p = current->mm->arg_end = current->mm->arg_start;
./fs/binfmt_elf.c:1495: len = mm->arg_end - mm->arg_start;
./fs/binfmt_elf.c:1499: (const char __user *)mm->arg_start, len))
......
./fs/proc/base.c:246: len1 = arg_end - arg_start;
......
但是从匹配的⽂件名给了我灵感：
/proc/<PID>/cmdline是每个进程的属性，从task_struct到mm_struct都是描述进程以及相关资源，那什么时候会修改到arg_start所在的
mm_struct呢？进程初始化的时候！
进⼀步联想到在⽤户空间创建进程不外乎两个步骤：
1. fork
2. exec
在fork时只是创建新的task_struct，⽗⼦进程共⽤⼀份mm_struct，只有在exec的时候，才会独⽴出mm_struct，所以arg_start⼀定是在exec时被修改！⽽匹配arg_start的⽂件中，刚好有exec.c。
查看了fs/exec.c中关键字所在函数setup_arg_pages后，并没到关键代码，于是继续查看匹配的⽂件名，产⽣了进⼀步联想：
exec执⾏⼀个新的程序，实际是加载新程序的bin⽂件，关键字匹配的⽂件中刚好也有binfmt_elf.c！
定位问题不仅仅要看得懂代码，联想有时候也是⾮常有效的
函数：create_elf_tables
binfmt_elf.c中匹配关键字arg_start的是函数create_elf_tables，函数挺长，我们精简⼀下
static int
create_elf_tables(struct linux_binprm *bprm, struct elfhdr *exec,
unsigned long load_addr, unsigned long interp_load_addr)
{
......
/* Populate argv and envp */
p = current->mm->arg_end = current->mm->arg_start;
while (argc-- > 0) {
......
if (__put_user((elf_addr_t)p, argv++))
return -EFAULT;
......
}
......
current->mm->arg_end = current->mm->env_start = p;
while (envc-- > 0) {
......
if (__put_user((elf_addr_t)p, envp++))
return -EFAULT;
......
}
......
}
在此函数中，实现了把argv和envp⽅别存⼊arg_start和env_start的地址空间。
接下来，我们试试溯本逐源，⼀起追溯函数create_elf_tables的调⽤
⾸先，create_elf_tables声明为static，表⽰其有效范围不可能超过所在⽂件。在⽂件中检索，发现上级函数为
static int load_elf_binary(struct linux_binprm *bprm)
竟然还是static，进⽽继续在本⽂件中检索load_elf_binary，到了以下代码：
static struct linux_binfmt elf_format = {
.module = THIS_MODULE,
.load_binary = load_elf_binary,
.load_shlib = load_elf_library
.core_dump = elf_core_dump,
.min_coredump = ELF_EXEC_PAGESIZE,
};
static int __init init_elf_binfmt(void)
{
register_binfmt(&elf_format);
return 0;
}
core_initcall(init_elf_binfmt);
检索到这⾥，代码结构⾮常清晰了，load_elf_binary函数赋值于struct linux_binfmt，通过````register_binfmt```向上层注册，提供上层回调。
关键字：load_binary
为什么要锁定关键字load_binary呢？既然.load_binary = load_elf_binary,，表⽰上层的调⽤应该是XXX->load_binary(...)，因此锁定关键字
load_binary即可定位，哪⾥调⽤了此回调。
[GMPY@09:55 proc]$ grep "\->load_binary" -rn *
⾮常幸运，此回调只有fs/exec.c调⽤
fs/exec.c:78: if (WARN_ON(!fmt->load_binary))
fs/exec.c:1621: retval = fmt->load_binary(bprm);
进⼊fs/exex.c的1621⾏，归属于函数search_binary_handler，⽽不幸的是EXPORT_SYMBOL(search_binary_handler)；的存在，表⽰很可能此函数会有多处被调⽤，此时继续正向分析显然⾮常困难，为什么不试试逆向分析呢？
道路⾛不通的时候，换个⾓度看问题，答案就在眼前
既然从search_binary_handler继续分析不容易，我们不妨看看execve的系统调⽤是否可以⼀步步到search_binary_handler?
关键字：exec
在Linux-4.9上，系统调⽤的定义⼀般是SYSCALL_DEFILNE<；参数数量>(<；函数名>...，因此我们全局检索关键字，先确定系统调⽤定义在哪⾥？
[GMPY@09:55 proc]$ grep "SYSCALL_DEFINE.*exec" -rn *
定位到⽂件fs/exec.c
fs/exec.c:1905:SYSCALL_DEFINE3(execve,
fs/exec.c:1913:SYSCALL_DEFINE5(execveat,
fs/exec.c:1927:COMPAT_SYSCALL_DEFINE3(execve, const char __user *, filename,
fs/exec.c:1934:COMPAT_SYSCALL_DEFINE5(execveat, int, fd,
kernel/kexec.c:187:SYSCALL_DEFINE4(kexec_load, unsigned long, entry, unsigned long, nr_segments,
kernel/kexec.c:233:COMPAT_SYSCALL_DEFINE4(kexec_load, compat_ulong_t, entry,
kernel/kexec_file.c:256:SYSCALL_DEFINE5(kexec_file_load, int, kernel_fd, int, initrd_fd,
后⾯跟进函数的调⽤不再累赘，总结其调⽤关系为
execve -> do_execveat -> do_execveat_common -> exec_binprm -> search_binary_handler
终究是回归到了search_binary_handler
分析到这，我们确定了赋值逻辑：
1. 在execve执⾏新程序时，会初始化mm_struct
2. 把execve中传递的argv和envp保存到arg_start和env_start指定的地址中
3. 在cat /proc/<PID>/cmdline时则从arg_start的虚拟地址获取数据
因此，只要是⽤户空间创建的进程经过execve的系统调⽤，都会有/proc/<PID>/cmdline，但依然没澄清，什么时候会cmdline会为空？
我们知道，在Linux中，进程可分为⽤户空间进程和内核空间进程，既然⽤户空间进程cmdline⾮空，我们再看看内核进程。
函数：kthread_run
内核驱动中，经常通过kthread_run创建内核进程，我们以此函数为切⼊⼝，分析创建内核进程时，是否会赋值cmdline？
直接从kthread_run开始，跟踪调⽤关系，发现真正⼲活的是函数__kthread_create_on_node
kthread_run -> kthread_create -> kthread_create_on_node -> __kthread_create_on_node
版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。
发表评论