Hi,
(Please cc me as I'm not subscribed to the list, thanks.)
I'm trying to set things up using some policy routing, and having some
weird issues I can't really explain. It looks to me like there might be
a bug somewhere...
This is done under Arch Linux 64bits, iproute2 4.9.0 (`ip -V` says ip
On Mon, 2 Jan 2017 09:48:12 -0700
David Ahern <d...@cumulusnetworks.com> wrote:
> On 1/1/17 12:52 PM, Olivier Brunel wrote:
> > Indeed, if I first delete the rule for lookup local and recreate it
> > w/ higher prio than my "lookup 50", then no more issue.
>
&g
On Sat, 31 Dec 2016 13:15:44 -0700
David Ahern <d...@cumulusnetworks.com> wrote:
> On 12/30/16 4:00 PM, Olivier Brunel wrote:
> > Hi,
> >
> > (Please cc me as I'm not subscribed to the list, thanks.)
> >
> > I'm trying to set things up using some policy ro
On Mon, 27 Aug 2018 20:35:02 -0700
Alexei Starovoitov wrote:
> I'm also running Arch Linux in my VM, but I'm not able to reproduce
> umount issue. I'm guessing it's somehow related to non-static build
> and libc.so being busy with old systemd.
Oh, I mentioned it in a previous draft of my
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
Small addentum: Of course I failed to realize this bpfilter helper is
also mentioned in the kernel log:
kern.info: [8.997711] bpfilter: Loaded bpfilter_umh pid 920
It also seems to be absolutely required when CONFIG_BPFILTER is
enabled, that is I tried blacklisting the module bpfilter,
Hi,
Quick follow-up on this:
- first off, Arch devs have updated their kernel config so the next
kernel will not have bpfilter enabled anymore, thus avoiding any
issue.
- having said that, I've found a neasy way to reproduce it in an Arch
VM, in case you're interested :
Boot the latest
On Tue, 28 Aug 2018 22:35:38 -0700
Alexei Starovoitov wrote:
> > Yeah, I have a similar thing happening on shutdown, except that
> > we're talking about a kernel thread here, so that process is
> > ignored by the mentionned killing spree as a result, thus leaving
> > that process running.
>
>
