From: Olivier Brunel <jjk@jjacky.com>
To: netdev@vger.kernel.org
Subject: bpfilter causes a leftover kernel process
Date: Sun, 26 Aug 2018 18:08:16 +0200 [thread overview]
Message-ID: <20180826180816.04ef7d16@jjacky.com> (raw)
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
next reply other threads:[~2018-08-26 20:31 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-08-26 16:08 Olivier Brunel [this message]
2018-08-27 16:31 ` bpfilter causes a leftover kernel process Olivier Brunel
2018-08-28 3:35 ` Alexei Starovoitov
2018-08-28 11:23 ` Olivier Brunel
2018-08-29 5:35 ` Alexei Starovoitov
2018-08-29 16:21 ` Olivier Brunel
2018-09-05 15:52 ` Olivier Brunel
2018-10-16 16:38 ` Alexei Starovoitov
2018-10-20 17:39 ` [PATCH 0/2] " Olivier Brunel
2018-10-20 17:39 ` [PATCH 1/2] umh: Add command line to user mode helpers Olivier Brunel
2018-10-23 2:37 ` David Miller
2018-10-20 17:39 ` [PATCH 2/2] net: bpfilter: Set user mode helper's command line Olivier Brunel
2018-10-23 2:37 ` David Miller
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=20180826180816.04ef7d16@jjacky.com \
--to=jjk@jjacky.com \
--cc=netdev@vger.kernel.org \
/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;
as well as URLs for NNTP newsgroup(s).