24.09.2018 19:52, Lennart Poettering пишет: > On Mo, 24.09.18 19:30, Andrei Borzenkov (arvidj...@gmail.com) wrote: > >> 24.09.2018 16:20, Lennart Poettering пишет: >>> On So, 23.09.18 10:38, Andrei Borzenkov (arvidj...@gmail.com) wrote: >>> >>>> Dracut /shutdown script first tries to kill all processes still running >>>> off old root. Unfortunately this fails for special user process that >>>> runs bpfilter because it does not include reference to /oldroot in >>>> places where dracut looks for in kilall_proc_mountpoint() >>> >>> Hmm, when we invoke the /shutdown executable we already executed our >>> process killing spree as part of systemd-shutdown. How come your >>> processes even survive that long? >> >> >> p = procfs_file_alloca(pid, "cmdline"); >> f = fopen(p, "re"); >> if (!f) >> return true; /* not really, but has the desired effect */ >> >> count = fread(&c, 1, 1, f); >> >> /* Kernel threads have an empty cmdline */ >> if (count <= 0) >> return true; >> >> >> This process is spawned as special kernel thread, even though it is >> otherwise normal user process. > > I am sorry, what? Are you saying there's now a third kind of task? > real kernel threads, real userspace processes, and weird shit running > kernel code that in turn runs userspace supplied programs, and all > that under user control? >
No, it is not exactly "user control". It runs executable embedded into kernel module. So it is not arbitrary code. In this particular case at least. > If so, yuck... > > Under which parent PID do they show up? kthreadd or somewhere further > down? > I showed it in original post. 10:~ # ps -ef | fgrep '[none]' root 984 2 0 09:46 ? 00:00:00 [none] Yes, this is kthreadd. > Do these processes report PF_KTHREAD in /proc/$PID/stat? i.e. do they > pass the recently reworked is_kernel_thread() tests? > No. The flags are 4194560 == 0x400100 == PF_RANDOMIZE|PF_SUPERPRIV. And sorry, I cannot comment on "these processes"; I have seen only one concrete example. I have no idea how widespread use of this facility is. > We might want to update killall.c then so that it does not make > assumptions on /proc/$PID/cmdline validity anymore, but strictly uses > is_kernel_thread(). That should fix things properly for you, no? That > way dracut won't even see these new kind processes at all... > Well, I suppose there could be corner cases when executable and libraries are from different filesystems, but this better waits for real life example then. _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
