Hi, (Please cc me as I'm not subscribed to the list, thanks.)
I'm running an Arch Linux x86_64 system, and recently updated to a 3.18 kernel, which led me to encounter what I believe to be a kernel bug related to the bpfilter framework. What happens is that upon boot, there's a "leftover kernel process" running (shown as "[none]" in ps), which doesn't seem to do anything (anymore) but does have references/fds open to the root fs, and so when trying to shutdown the system umounting the root fs fails (EBUSY) because of it, leading to expected issues. Simply killing that process allows umounting the root fs fine and "resolves" all issues. This process/behavior wasn't there with any previous kernel, and is there with all tried kernels from 4.18.0 to 4.18.4, without any other change to the system -- although this is due to CONFIG_BPFILTER=y in the kernel config. Indeed I managed to compile a kernel 4.18.4 myself using the Arch Linux config[1] with a single change of unsetting CONFIG_BPFILTER, and with the resulting kernel I don't have this "leftover kernel process" anymore, everything is back to normal. Now, about this process, here's a few outputs to try and describe what it is: rafus# pgrep none 920 rafus# cd /proc/920 rafus# readlink exe / (deleted) rafus# ls -l fd total 0 lr-x------ 1 root root 64 Aug 26 17:17 0 -> 'pipe:[13366]' l-wx------ 1 root root 64 Aug 26 17:17 1 -> 'pipe:[13367]' lrwx------ 1 root root 64 Aug 26 17:17 2 -> /dev/console rafus# cat status Name: none Umask: 0022 State: S (sleeping) Tgid: 920 Ngid: 0 Pid: 920 PPid: 2 TracerPid: 0 Uid: 0 0 0 0 Gid: 0 0 0 0 FDSize: 64 Groups: NStgid: 920 NSpid: 920 NSpgid: 0 NSsid: 0 VmPeak: 2296 kB VmSize: 2296 kB VmLck: 0 kB VmPin: 0 kB VmHWM: 748 kB VmRSS: 748 kB RssAnon: 60 kB RssFile: 684 kB RssShmem: 4 kB VmData: 176 kB VmStk: 132 kB VmExe: 8 kB VmLib: 1452 kB VmPTE: 44 kB VmSwap: 0 kB HugetlbPages: 0 kB CoreDumping: 0 Threads: 1 SigQ: 0/7861 SigPnd: 0000000000000000 ShdPnd: 0000000000000000 SigBlk: 0000000000000000 SigIgn: 0000000000000000 SigCgt: 0000000000000000 CapInh: 0000000000000000 CapPrm: 0000003fffffffff CapEff: 0000003fffffffff CapBnd: 0000003fffffffff CapAmb: 0000000000000000 NoNewPrivs: 0 Seccomp: 0 Speculation_Store_Bypass: vulnerable Cpus_allowed: 1 Cpus_allowed_list: 0 Mems_allowed: 00000001 Mems_allowed_list: 0 voluntary_ctxt_switches: 65 nonvoluntary_ctxt_switches: 1 rafus# cat stack [<0>] pipe_wait+0x6c/0xb0 [<0>] pipe_read+0x20a/0x2d0 [<0>] __vfs_read+0x13a/0x180 [<0>] vfs_read+0x8a/0x130 [<0>] ksys_read+0x4f/0xb0 [<0>] do_syscall_64+0x5b/0x170 [<0>] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [<0>] 0xffffffffffffffff rafus# file -L exe exe: ELF 64-bit LSB pie executable x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 3.2.0, BuildID[sha1]=b247cedd3f8daaea3eee38477aa641d84b77f0ba, not stripped rafus# stat -L exe File: exe Size: 16832 Blocks: 40 IO Block: 4096 regular file Device: 1h/1d Inode: 13361 Links: 0 Access: (0777/-rwxrwxrwx) Uid: ( 0/ root) Gid: ( 0/ root) Access: 2018-08-26 17:17:37.334261924 +0200 Modify: 2018-08-26 17:14:27.787595262 +0200 Change: 2018-08-26 17:14:27.787595262 +0200 Birth: - rafus# sha1sum exe 723d59584abe5e1e9917f0ec41d7e9120514afe7 exe rafus# strings exe|grep bpf Started bpfilter I'm not actually sure what the process is, I'm guessing some kind of helper is spawned at some point during boot, and for some reason it never ends. Although I can reproduce it (it happens on every boot with a kernel 4.18 and CONFIG_BPFILTER=y), I'm unfortunately not sure what is actually needed to be done in order to trigger it. I don't use bpfilter myself/directly, as said this happens with the exact same system as with previous kernels, but I obviously have some network configuration (done using iptables/iproute2) set up during boot. Let me know if you need more information or need me to test things, and I'll do my best. Thank you. [1] https://git.archlinux.org/svntogit/packages.git/tree/trunk?h=packages/linux
