netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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

             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).