* Re: [bpf PATCH v2 1/2] bpf: sockmap, fix crash when ipv6 sock is added
From: John Fastabend @ 2018-06-12 13:57 UTC (permalink / raw)
To: Daniel Borkmann, edumazet, weiwan, ast; +Cc: netdev
In-Reply-To: <e96c1dcf-c811-3252-d7fb-0aedd8c70921@iogearbox.net>
On 06/11/2018 04:14 PM, Daniel Borkmann wrote:
> Hi John,
>
> On 06/08/2018 05:06 PM, John Fastabend wrote:
>> This fixes a crash where we assign tcp_prot to IPv6 sockets instead
>> of tcpv6_prot.
>>
>> Previously we overwrote the sk->prot field with tcp_prot even in the
>> AF_INET6 case. This patch ensures the correct tcp_prot and tcpv6_prot
>> are used. Further, only allow ESTABLISHED connections to join the
>> map per note in TLS ULP,
>>
>> /* The TLS ulp is currently supported only for TCP sockets
>> * in ESTABLISHED state.
>> * Supporting sockets in LISTEN state will require us
>> * to modify the accept implementation to clone rather then
>> * share the ulp context.
>> */
>>
>> Also tested with 'netserver -6' and 'netperf -H [IPv6]' as well as
>> 'netperf -H [IPv4]'. The ESTABLISHED check resolves the previously
>> crashing case here.
>>
>> Fixes: 174a79ff9515 ("bpf: sockmap with sk redirect support")
>> Reported-by: syzbot+5c063698bdbfac19f363@syzkaller.appspotmail.com
>> Signed-off-by: John Fastabend <john.fastabend@gmail.com>
>> Signed-off-by: Wei Wang <weiwan@google.com>
> [...]
>
> Still one question for some more clarification below that popped up while
> review:
>
>> @@ -162,6 +164,8 @@ static bool bpf_tcp_stream_read(const struct sock *sk)
>> }
>>
>> static struct proto tcp_bpf_proto;
>> +static struct proto tcpv6_bpf_proto;
>
> These two are global, w/o locking.
>
>> static int bpf_tcp_init(struct sock *sk)
>> {
>> struct smap_psock *psock;
>> @@ -181,14 +185,30 @@ static int bpf_tcp_init(struct sock *sk)
>> psock->save_close = sk->sk_prot->close;
>> psock->sk_proto = sk->sk_prot;
>>
>> + if (sk->sk_family == AF_INET6) {
>> + tcpv6_bpf_proto = *sk->sk_prot;
>> + tcpv6_bpf_proto.close = bpf_tcp_close;
>> + } else {
>> + tcp_bpf_proto = *sk->sk_prot;
>> + tcp_bpf_proto.close = bpf_tcp_close;
>> + }
>
> And each time we add a BPF ULP to a v4/v6 socket, we override tcp{,v6}_bpf_proto
> from scratch.
>
>> if (psock->bpf_tx_msg) {
>> + tcpv6_bpf_proto.sendmsg = bpf_tcp_sendmsg;
>> + tcpv6_bpf_proto.sendpage = bpf_tcp_sendpage;
>> + tcpv6_bpf_proto.recvmsg = bpf_tcp_recvmsg;
>> + tcpv6_bpf_proto.stream_memory_read = bpf_tcp_stream_read;
>> tcp_bpf_proto.sendmsg = bpf_tcp_sendmsg;
>> tcp_bpf_proto.sendpage = bpf_tcp_sendpage;
>> tcp_bpf_proto.recvmsg = bpf_tcp_recvmsg;
>> tcp_bpf_proto.stream_memory_read = bpf_tcp_stream_read;
>> }
>>
>> - sk->sk_prot = &tcp_bpf_proto;
>> + if (sk->sk_family == AF_INET6)
>> + sk->sk_prot = &tcpv6_bpf_proto;
>> + else
>> + sk->sk_prot = &tcp_bpf_proto;
>
> Where every active socket would be affected from it as well. Isn't that
> generally racy? E.g. existing ones where tcpv6_bpf_proto.sendmsg points
> to bpf_tcp_sendmsg would get overridden with earlier assignment on the
> tcpv6_bpf_proto = *sk->sk_prot during their lifetime after bpf_tcp_init().
>
In general yes. At best it does feel fragile.
> In the kTLS case, the v4 protos are built up in module init via tls_register()
> and never change from there. The v6 ones are only reloaded when their addr
> changes e.g. module reload would come to mind, which should only be possible
> once no active v6 socket is present. What speaks against adapting similar
> scheme resp. what am I missing that the above would work? (Would be nice if
> there was some discussion in commit log related to it on 'why' this approach
> was done differently.)
I think its best to use the same scheme. Will post a new version. Also
would be nice to fix the selftests in the same series. Finally, I set
these pointers lazily adding a sendmsg hook for example even if it not
needed. Its harmless but does create an extra call through bpf for
no reason on some socks. To be complete we should avoid that.
>
> Thanks,
> Daniel
>
>> rcu_read_unlock();
>> return 0;
>> }
>> @@ -1111,8 +1131,6 @@ static void bpf_tcp_msg_add(struct smap_psock *psock,
>>
>> static int bpf_tcp_ulp_register(void)
>> {
>> - tcp_bpf_proto = tcp_prot;
>> - tcp_bpf_proto.close = bpf_tcp_close;
>> /* Once BPF TX ULP is registered it is never unregistered. It
>> * will be in the ULP list for the lifetime of the system. Doing
>> * duplicate registers is not a problem.
>>
>
^ permalink raw reply
* Re: [PATCH 1/3] m68k: coldfire: Normalize clk API
From: Greg Ungerer @ 2018-06-12 13:31 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Ralf Baechle, James Hogan, Giuseppe Cavallaro, Alexandre Torgue,
Jose Abreu, Corentin Labbe, David S. Miller, Arnd Bergmann,
linux-m68k, Linux MIPS Mailing List, netdev,
Linux Kernel Mailing List
In-Reply-To: <CAMuHMdUyD8d2yoe6v8TEinEH3hhS7Znv99pPxDCkr_uEFS0Fzg@mail.gmail.com>
Hi Geert,
On 12/06/18 17:31, Geert Uytterhoeven wrote:
> On Tue, Jun 12, 2018 at 9:27 AM Greg Ungerer <gerg@linux-m68k.org> wrote:
>> On 11/06/18 18:44, Geert Uytterhoeven wrote:
>>> Coldfire still provides its own variant of the clk API rather than using
>>> the generic COMMON_CLK API. This generally works, but it causes some
>>> link errors with drivers using the clk_round_rate(), clk_set_rate(),
>>> clk_set_parent(), or clk_get_parent() functions when a platform lacks
>>> those interfaces.
>>>
>>> This adds empty stub implementations for each of them, and I don't even
>>> try to do something useful here but instead just print a WARN() message
>>> to make it obvious what is going on if they ever end up being called.
>>>
>>> The drivers that call these won't be used on these platforms (otherwise
>>> we'd get a link error today), so the added code is harmless bloat and
>>> will warn about accidental use.
>>>
>>> Based on commit bd7fefe1f06ca6cc ("ARM: w90x900: normalize clk API").
>>>
>>> Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
>>
>> I am fine with this for ColdFire, so
>>
>> Acked-by: Greg Ungerer <gerg@linux-m68k.org>
>
> Thanks!
>
>> Are you going to take this/these via your m68k git tree?
>
> I''m fine delagating this to you.
No problem. I'll add it to the m68knommu git tree (for-next branch)
when the merge window closes.
Thanks
Greg
^ permalink raw reply
* Re: netdevice notifier and device private data
From: Alexander Aring @ 2018-06-12 13:22 UTC (permalink / raw)
To: Michael Richardson; +Cc: netdev, linux-wpan, linux-bluetooth
In-Reply-To: <1326.1528682979@localhost>
Hi,
On Sun, Jun 10, 2018 at 10:09:39PM -0400, Michael Richardson wrote:
>
> Alexander Aring <aring@mojatatu.com> wrote:
> >> It totally seems like broken behaviour. Maybe it's not even
> >> intentional. Maybe they are just foobar.
>
> > They simple don't know what they doing... somebody thought 6LoWPAN need
> > to be 6LoWPAN, but they actually don't use the 6LoWPAN handling inside
> > the kernel. _Except_ they doing out of tree stuff which I don't
> > believe.
>
> So, it seems like this ioctl() should be disabled, or restricted to cases
> that actually work. hate to break their code, but if it's broken anyway, at
> least the kernel won't crash under them.
>
before we breaking their software I will gentle ask before why they
doing that and I get a good reason then. Then we look more how we deal
with an illegal read/dereference in dev->priv.
I will figure out how I can do that over github.
- Alex
^ permalink raw reply
* Re: FW: [PATCH 2/2] ath10k: allow ATH10K_SNOC with COMPILE_TEST
From: Niklas Cassel @ 2018-06-12 12:44 UTC (permalink / raw)
To: Govind Singh, bjorn.andersson
Cc: kvalo, davem, netdev, linux-wireless, linux-kernel
In-Reply-To: <47cf8ec1b11d727ea928a307a431d4a2@codeaurora.org>
On Tue, Jun 12, 2018 at 06:02:48PM +0530, Govind Singh wrote:
> On 2018-06-12 17:45, Govind Singh wrote:
> > -----Original Message-----
> > From: ath10k <ath10k-bounces@lists.infradead.org> On Behalf Of Niklas
> > Cassel
> > Sent: Tuesday, June 12, 2018 5:09 PM
> > To: Kalle Valo <kvalo@codeaurora.org>; David S. Miller
> > <davem@davemloft.net>
> > Cc: Niklas Cassel <niklas.cassel@linaro.org>; netdev@vger.kernel.org;
> > linux-wireless@vger.kernel.org; linux-kernel@vger.kernel.org;
> > ath10k@lists.infradead.org
> > Subject: [PATCH 2/2] ath10k: allow ATH10K_SNOC with COMPILE_TEST
> >
> > ATH10K_SNOC builds just fine with COMPILE_TEST, so make that possible.
> >
> > Signed-off-by: Niklas Cassel <niklas.cassel@linaro.org>
> > ---
> > drivers/net/wireless/ath/ath10k/Kconfig | 3 ++-
> > 1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/net/wireless/ath/ath10k/Kconfig
> > b/drivers/net/wireless/ath/ath10k/Kconfig
> > index 54ff5930126c..6572a43590a8 100644
> > --- a/drivers/net/wireless/ath/ath10k/Kconfig
> > +++ b/drivers/net/wireless/ath/ath10k/Kconfig
> > @@ -42,7 +42,8 @@ config ATH10K_USB
> >
> > config ATH10K_SNOC
> > tristate "Qualcomm ath10k SNOC support (EXPERIMENTAL)"
> > - depends on ATH10K && ARCH_QCOM
> > + depends on ATH10K
> > + depends on ARCH_QCOM || COMPILE_TEST
> > ---help---
> > This module adds support for integrated WCN3990 chip connected
> > to system NOC(SNOC). Currently work in progress and will not
>
> Thanks Niklas for enabling COMPILE_TEST. With QMI set of
> changes(https://patchwork.kernel.org/patch/10448183/), we need to enable
> COMPILE_TEST for
> QCOM_SCM/QMI_HELPERS which seems broken today. Are you planning to fix the
> same.
Argh..
qcom_scm seems fine, it is just missing a single definition in the
#else clause of include/linux/qcom_scm.h.
+++ b/include/linux/qcom_scm.h
@@ -89,6 +89,10 @@ static inline int qcom_scm_pas_mem_setup(u32 peripheral, phys_addr_t addr,
static inline int
qcom_scm_pas_auth_and_reset(u32 peripheral) { return -ENODEV; }
static inline int qcom_scm_pas_shutdown(u32 peripheral) { return -ENODEV; }
+static inline int qcom_scm_assign_mem(phys_addr_t mem_addr, size_t mem_sz,
+ unsigned int *src,
+ struct qcom_scm_vmperm *newvm,
+ int dest_cnt) { return -ENODEV; }
static inline void qcom_scm_cpu_power_down(u32 flags) {}
static inline u32 qcom_scm_get_version(void) { return 0; }
include/linux/soc/qcom/qmi.h on the other hand doesn't have any
dummy defintions at all.
I think that it makes sense to be able to compile test
the QMI helpers also on other archs..
Bjorn, any opinion?
>
> config QCOM_SCM
> bool
> - depends on ARM || ARM64
> + depends on ARM || ARM64 || COMPILE_TEST
> select RESET_CONTROLLER
>
>
> config QCOM_SCM_64
> def_bool y
> - depends on QCOM_SCM && ARM64
> + depends on QCOM_SCM && ARM64 || COMPILE_TEST
>
> config QCOM_QMI_HELPERS
> tristate
> - depends on ARCH_QCOM && NET
> + depends on (ARCH_QCOM || COMPILE_TEST) && NET
>
> -obj-$(CONFIG_ARCH_QCOM) += qcom/
> +obj-y += qcom/
>
> __qcom_scm_init/qcom_scm_call wrapper to support COMPILE_TEST.
>
>
>
> BR,
> Govind
^ permalink raw reply
* Re: FW: [PATCH 2/2] ath10k: allow ATH10K_SNOC with COMPILE_TEST
From: Govind Singh @ 2018-06-12 12:32 UTC (permalink / raw)
To: niklas.cassel, kvalo, davem; +Cc: netdev, linux-wireless, linux-kernel
In-Reply-To: <7058492257914633b55fcd423e4c0b59@aphydexm01b.ap.qualcomm.com>
On 2018-06-12 17:45, Govind Singh wrote:
> -----Original Message-----
> From: ath10k <ath10k-bounces@lists.infradead.org> On Behalf Of Niklas
> Cassel
> Sent: Tuesday, June 12, 2018 5:09 PM
> To: Kalle Valo <kvalo@codeaurora.org>; David S. Miller
> <davem@davemloft.net>
> Cc: Niklas Cassel <niklas.cassel@linaro.org>; netdev@vger.kernel.org;
> linux-wireless@vger.kernel.org; linux-kernel@vger.kernel.org;
> ath10k@lists.infradead.org
> Subject: [PATCH 2/2] ath10k: allow ATH10K_SNOC with COMPILE_TEST
>
> ATH10K_SNOC builds just fine with COMPILE_TEST, so make that possible.
>
> Signed-off-by: Niklas Cassel <niklas.cassel@linaro.org>
> ---
> drivers/net/wireless/ath/ath10k/Kconfig | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/wireless/ath/ath10k/Kconfig
> b/drivers/net/wireless/ath/ath10k/Kconfig
> index 54ff5930126c..6572a43590a8 100644
> --- a/drivers/net/wireless/ath/ath10k/Kconfig
> +++ b/drivers/net/wireless/ath/ath10k/Kconfig
> @@ -42,7 +42,8 @@ config ATH10K_USB
>
> config ATH10K_SNOC
> tristate "Qualcomm ath10k SNOC support (EXPERIMENTAL)"
> - depends on ATH10K && ARCH_QCOM
> + depends on ATH10K
> + depends on ARCH_QCOM || COMPILE_TEST
> ---help---
> This module adds support for integrated WCN3990 chip connected
> to system NOC(SNOC). Currently work in progress and will not
Thanks Niklas for enabling COMPILE_TEST. With QMI set of
changes(https://patchwork.kernel.org/patch/10448183/), we need to enable
COMPILE_TEST for
QCOM_SCM/QMI_HELPERS which seems broken today. Are you planning to fix
the same.
config QCOM_SCM
bool
- depends on ARM || ARM64
+ depends on ARM || ARM64 || COMPILE_TEST
select RESET_CONTROLLER
config QCOM_SCM_64
def_bool y
- depends on QCOM_SCM && ARM64
+ depends on QCOM_SCM && ARM64 || COMPILE_TEST
config QCOM_QMI_HELPERS
tristate
- depends on ARCH_QCOM && NET
+ depends on (ARCH_QCOM || COMPILE_TEST) && NET
-obj-$(CONFIG_ARCH_QCOM) += qcom/
+obj-y += qcom/
__qcom_scm_init/qcom_scm_call wrapper to support COMPILE_TEST.
BR,
Govind
^ permalink raw reply
* Re: mainline: x86_64: kernel panic: RIP: 0010:__xfrm_policy_check+0xcb/0x690
From: Anders Roxell @ 2018-06-12 12:09 UTC (permalink / raw)
To: Steffen Klassert
Cc: Naresh Kamboju, Networking, David S. Miller, herbert,
open list:KERNEL SELFTEST FRAMEWORK, open list
In-Reply-To: <20180612083435.7f7k4exergraaa2u@gauss3.secunet.de>
On 12 June 2018 at 10:34, Steffen Klassert <steffen.klassert@secunet.com> wrote:
> On Mon, Jun 11, 2018 at 10:11:46PM +0530, Naresh Kamboju wrote:
>> Kernel panic on x86_64 machine running mainline 4.17.0 kernel while testing
>> selftests bpf test_tunnel.sh test caused this kernel panic.
>> I have noticed this kernel panic start happening from
>> 4.17.0-rc7-next-20180529 and still happening on 4.17.0-next-20180608.
>>
>> [ 213.638287] BUG: unable to handle kernel NULL pointer dereference
>> at 0000000000000008
>> ++[ ip xfrm poli 213.674036] PGD 0 P4D 0
>> [ 213.674118] audit: type=1327 audit(1528917683.623:7):
>> proctitle=6970007866726D00706F6C69637900616464007372630031302E312E312E3130302F3332006473740031302E312E312E3230302F33320064697200696E00746D706C00737263003137322E31362E312E31303000647374003137322E31362E312E3230300070726F746F006573700072657169640031006D6F64650074756E6E
>> [ 213.677950] Oops: 0000 [#1] SMP PTI
>> cy[ add src 10.1. 213.677952] CPU: 2 PID: 0 Comm: swapper/2 Tainted:
>> G W 4.17.0-next-20180608 #1
>> [ 213.677953] Hardware name: Supermicro SYS-5019S-ML/X11SSH-F, BIOS
>> 2.0b 07/27/2017
>> [ 213.726998] RIP: 0010:__xfrm_policy_check+0xcb/0x690
>> [ 213.731962] Code: 80 3d 0a d8 f1 00 00 0f 84 c1 02 00 00 4c 8b 25
>> 2b af f4 00 e8 66 a6 6a ff 85 c0 74 0d 80 3d eb d7 f1 00 00 0f 84 d5
>> 02 00 00 <49> 8b 44 24 08 48 85 c0 74 0c 48 8d b5 78 ff ff ff 4c 89 ff
>> ff d0
>
> This looks like a bug that I've seen already. If it is what I think,
> then commit 2c205dd3981f ("netfilter: add struct nf_nat_hook and use
> it") introduced this bug.
>
> There was already a fix for this on the netdev list, but
> I don't know the current status of that patch:
>
> https://patchwork.ozlabs.org/patch/921387/
Hi, I applied the patch and ran bpf/test_tunnel.sh and I I couldn't
see any crash.
However, the script never returned (I had to Ctrl+c to get back), any ideas ?
See log from the test below.
Cheers,
Anders
Testing IPSec tunnel...
[ 269.060050] IPv6: ADDRCONF(NETDEV_UP): veth0: link is not ready
[ 269.090000] IPv6: ADDRCONF(NETDEV_CHANGE): veth0: link becomes ready
<idle>-0 [000] ..s3 190.987095: 0: key 2 remote ip 0xac100164
ping-3043 [000] ..s3 190.988715: 0: key 2 remote ip 0xac100164
ksoftirqd/0-9 [000] ..s2 190.988986: 0: key 2 remote ip 0xac100164
systemd-resolve-2664 [003] ..s3 191.083771: 0: ERROR line:77 ret:-22
systemd-resolve-2664 [003] ..s3 191.333763: 0: ERROR line:77 ret:-22
kworker/0:1-33 [000] ..s4 191.419445: 0: key 2 remote ip 0xac100164
ping-3043 [000] ..s3 191.989437: 0: key 2 remote ip 0xac100164
kworker/0:1-33 [000] ..s4 192.443460: 0: key 2 remote ip 0xac100164
kworker/0:1-33 [000] ..s4 192.443508: 0: key 2 remote ip 0xac100164
<idle>-0 [000] ..s3 192.446318: 0: key 2 remote ip 0xac100164
systemd-resolve-2664 [000] ..s3 192.768767: 0: ERROR line:77 ret:-22
ping-3043 [000] ..s3 192.989902: 0: key 2 remote ip 0xac100164
ping-3044 [000] ..s3 193.025776: 0: key 2 remote ip 0xac100164
systemd-resolve-2664 [000] ..s3 193.083650: 0: ERROR line:77 ret:-22
systemd-resolve-2664 [000] ..s3 193.333865: 0: ERROR line:77 ret:-22
ping-3044 [000] ..s3 194.026240: 0: key 2 remote ip 0xac100164
ping-3044 [000] ..s3 195.026707: 0: key 2 remote ip 0xac100164
ksoftirqd/2-21 [002] ..s2 198.075583: 0: key 2 remote ip6
::11000000 label bcdef
ksoftirqd/2-21 [002] ..s2 198.075597: 0: key 2 remot[
269.270883] audit: type=1415 audit(1532018021.150:6): op=SAD-add
auid=0 ses=2 subj=kerne
l src=172.16.1.100 dst=172.16.1.200 spi=1(0x1) res=1
[ 269.284308] audit: type=1300 audit(1532018021.150:6): arch=c000003e
syscall=46 success=yes exit=424 a0=4 a1=7ffff18d1ba0 a2=0 a3=5e9
items=0 ppid=2924
pid=4333 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0
fsgid=0 tty=pts0 ses=2 comm=\"ip\" exe=\"/sbin/ip.iproute2\"
subj=kernel key=(null)
[ 269.310249] audit: type=1327 audit(1532018021.150:6):
proctitle=6970007866726D0073746174650061646400737263003137322E31362E312E31303000647374003137322E
31362E312E3230300070726F746F0065737000737069003078310072657169640031006D6F64650074756E6E656C00617574682D7472756E6300686D616328736861312900307831313131313
13131313131313131
e ip6 ::11000000 label bcdef
ping-3164 [003] ..s3 198.113160: 0: key 2 remote ip6
::11000000 label bcdef
ping-3164 [003] ..s3 199.113661: 0: key 2 remote ip6
::11000000 label bcdef
<idle>-0 [000] ..s3 199.931430: 0: key 2 remote ip6
::11000000 label bcdef
ping-3164 [003] ..s3 200.114432: 0: key 2 remote ip6
::11000000 label bcdef
ping-3[ 269.374987] audit: type=1415
audit(1532018021.373:7): op=SPD-add auid=0 ses=2 subj=kernel res=1
src=10.1.1.100 dst=10.1.1.200
165 [002] ..s3 [ 269.386787] audit: type=1300
audit(1532018021.373:7): arch=c000003e syscall=46 success=yes exit=252
a0=4 a1=7ffe1e400ff0 a2=0 a3=5e9 i
tems=0 ppid=2924 pid=4354 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0
egid=0 sgid=0 fsgid=0 tty=pts0 ses=2 comm=\"ip\"
exe=\"/sbin/ip.iproute2\" subj=kernel
key=(null)
[ 269.414124] audit: type=1327 audit(1532018021.373:7):
proctitle=6970007866726D00706F6C69637900616464007372630031302E312E312E3130302F333200647374003130
2E312E312E3230302F333200646972006F757400746D706C00737263003137322E31362E312E31303000647374003137322E31362E312E3230300070726F746F0065737000726571696400310
06D6F64650074756E
200.133573: 0: key 2 remote ip6 ::11000000 label bcdef
ping-3165 [002] ..s3 201.134091: 0: key 2 remote ip6
::11000000 label bcdef
ping-3165 [002] ..s3 202.134600: 0: key 2 remote ip6
::11000000 label bcdef
ping6-3167 [000] ..s3 202.172808: 0: key 2 remote ip6
::11000000 label bcdef
[ 269.471306] audit: type=1415 audit(1532018021.470:8): op=SAD-add
auid=0 ses=2 subj=kernel src=172.16.1.200 dst=172.16.1.100 spi=2(0x2)
res=1
[ 269.484439] audit: type=1300 audit(1532018021.470:8): arch=c000003e
syscall=46 success=yes exit=424 a0=4 a1=7ffc79931450 a2=0 a3=5e9
items=0 ppid=2924
pid=4355 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0
fsgid=0 tty=pts0 ses=2 comm=\"ip\" exe=\"/sbin/ip.iproute2\"
subj=kernel key=(null)
[ 269.510375] audit: type=1327 audit(1532018021.470:8):
proctitle=6970007866726D0073746174650061646400737263003137322E31362E312E32303000647374003137322E
31362E312E3130300070726F746F0065737000737069003078320072657169640032006D6F64650074756E6E656C00617574682D7472756E6300686D616328736861312900307831313131313
13131313131313131
ping6-3167 [000] ..s3 203.173251: 0: key 2 remote ip6
::11000000 label bcdef
ping6-3167 [000] ..s3 204.173741: 0: key 2 remote ip6
::11000000 label bcdef
systemd-resolve-2664 [001] ..s3 205.333801: 0: ERROR line:119 ret:-22
systemd-resolve-2664 [001] ..s3 205.583819: 0: ERROR line:119 ret:-22
systemd-resolve-2664 [001] ..s3 205.833437: 0: E[ 269.572155]
audit: type=1415 audit(1532018021.571:9): op=SPD-add auid=0 ses=2
subj=kernel res=1 sr
c=10.1.1.200 dst=10.1.1.100
RROR line:119 ret:-22
systemd-resolve-2664 [001] ..s3 206.583819: 0: ERROR line:119 ret:-22
systemd-resolve-2664 [003] ..s3 206.782769: 0: ERROR line:119 ret:-22
kworker/3:2-1537 [003] ..s4 207.035785: 0: key 2 remote ip6
::11000000 label bcdef
kworker/3:2-1537 [003] ..s4 207.035796: 0: key 2 remote ip6
::11000000 label bcdef
kworker/3:2-1537 [003] ..s4 207.035890: 0: key 2 remote ip6
::11000000 label bcdef
kworker/3:2-1537 [003] ..s4 207.035926: 0: key 2 remote ip6
::11000000 label bcdef
systemd-resolve-2664 [000] ..s3 207.083608: 0: ERROR line:119 ret:-22
ksoftirqd/3-26 [003] ..s2 207.739454: 0: key 2 remote ip6
::11000000 label bcdef
ping-3298 [000] ..s3 208.263120: 0: key 2 remote ip6
::11000000 label bcdef
ping-3298 [000] ..s3 208.263224: 0: key 2 remote ip6
::11000000 label bcdef
ping-3298 [000] ..s3 209.263703: 0: key 2 remote ip6
::11000000 label bcdef
ping-3298 [000] ..s3 210.264203: 0: key 2 remote ip6
::11000000 label bcdef
ping-3299 [002] ..s3 210.279710: 0: key 2 remote ip6
::11000000 label bcdef
<idle>-0 [003] ..s3 210.875420: 0: key 2 remote ip6
::11000000 label bcdef
ping-3299 [002] ..s3 211.280241: 0: key 2 remote ip6
::11000000 label bcdef
ksoftirqd/3-26 [003] ..s2 212.219559: 0: key 2 remote ip6
::11000000 label bcdef
ping-3299 [002] ..s3 212.280741: 0: key 2 remote ip6
::11000000 label bcdef
ping6-3300 [002] ..s3 212.315807: 0: key 2 remote ip6
::11000000 label bcdef
ping6-3300 [002] ..s3 213.316255: 0: key 2 remote ip6
::11000000 label bcdef
<idle>-0 [000] ..s3 213.755462: 0: key 2 remote ip6
::11000000 label bcdef
ping6-3300 [002] ..s3 214.316506: 0: key 2 remote ip6
::11000000 label bcdef
ping6-3300 [002] ..s3 215.316951: 0: key 2 remote ip6
::11000000 label bcdef
ping6-3300 [002] ..s3 216.317320: 0: key 2 remote ip6
::11000000 label bcdef
ping6-3300 [002] ..s3 217.317765: 0: key 2 remote ip6
::11000000 label bcdef
ksoftirqd/3-26 [003] ..s2 217.339464: 0: key 2 remote ip6
::11000000 label bcdef
ping6-3300 [002] ..s3 218.318227: 0: key 2 remote ip6
::11000000 label bcdef
ksoftirqd/3-26 [003] ..s2 218.875455: 0: key 2 remote ip6
::11000000 label bcdef
ping6-3300 [002] ..s3 219.318671: 0: key 2 remote ip6
::11000000 label bcdef
ping6-3300 [002] ..s3 220.319141: 0: key 2 remote ip6
::11000000 label bcdef
ping6-3300 [002] ..s3 221.319585: 0: key 2 remote ip6
::11000000 label bcdef
ping-3419 [002] ..s3 223.036234: 0: key 2 remote ip
0xac100164 erspan version 2
ping-3419 [002] ..s3 223.036236: 0: direction 1
hwid 3 timestamp 31402699
ping-3419 [002] ..s3 223.036256: 0: key 2 remote ip
0xac100164 erspan version 2
ping-3419 [002] ..s3 223.036256: 0: direction 1
hwid 3 timestamp 31402699
<idle>-0 [000] ..s3 223.067438: 0: key 2 remote ip
0xac100164 erspan version 2
<idle>-0 [000] ..s3 223.067443: 0: direction 1
hwid 3 timestamp 31403010
systemd-resolve-2664 [000] ..s3 223.083837: 0: ERROR line:183 ret:-22
kworker/0:1-33 [000] ..s4 223.283447: 0: key 2 remote ip
0xac100164 erspan version 2
kworker/0:1-33 [000] ..s4 223.283452: 0: direction 1
hwid 3 timestamp 31405171
systemd-resolve-2664 [000] ..s3 223.333807: 0: ERROR line:183 ret:-22
systemd-resolve-2664 [000] ..s3 223.583816: 0: ERROR line:183 ret:-22
ping-3419 [002] ..s3 224.036713: 0: key 2 remote ip
0xac100164 erspan version 2
ping-3419 [002] ..s3 224.036718: 0: direction 1
hwid 3 timestamp 31412704
kworker/0:1-33 [000] ..s4 224.315459: 0: key 2 remote ip
0xac100164 erspan version 2
kworker/0:1-33 [000] ..s4 224.315464: 0: direction 1
hwid 3 timestamp 31415491
kworker/0:1-33 [000] ..s4 224.315514: 0: key 2 remote ip
0xac100164 erspan version 2
kworker/0:1-33 [000] ..s4 224.315516: 0: direction 1
hwid 3 timestamp 31415492
<idle>-0 [000] ..s3 224.675428: 0: key 2 remote ip
0xac100164 erspan version 2
<idle>-0 [000] ..s3 224.675433: 0: direction 1
hwid 3 timestamp 31419090
ping-3419 [002] ..s3 225.036920: 0: key 2 remote ip
0xac100164 erspan version 2
ping-3419 [002] ..s3 225.036925: 0: direction 1
hwid 3 timestamp 31422706
ping-3420 [003] ..s3 225.064293: 0: key 2 remote ip
0xac100164 erspan version 2
ping-3420 [003] ..s3 225.064298: 0: direction 1
hwid 3 timestamp 31422979
systemd-resolve-2664 [000] ..s3 225.083664: 0: ERROR line:183 ret:-22
systemd-resolve-2664 [000] ..s3 225.333742: 0: ERROR line:183 ret:-22
systemd-resolve-2664 [000] ..s3 225.583778: 0: ERROR line:183 ret:-22
ping-3420 [003] ..s3 226.064761: 0: key 2 remote ip
0xac100164 erspan version 2
ping-3420 [003] ..s3 226.064765: 0: direction 1
hwid 3 timestamp 31432984
ping-3420 [003] ..s3 227.065237: 0: key 2 remote ip
0xac100164 erspan version 2
ping-3420 [003] ..s3 227.065242: 0: direction 1
hwid 3 timestamp 31442989
systemd-resolve-2664 [003] ..s3 228.186369: 0: ERROR line:269 ret:-22
systemd-resolve-2664 [003] ..s3 228.333716: 0: ERROR line:269 ret:-22
systemd-resolve-2664 [003] ..s3 228.583747: 0: ERROR line:269 ret:-22
systemd-resolve-2664 [001] ..s3 229.833537: 0: ERROR line:269 ret:-22
kworker/0:1-33 [000] ..s4 229.947659: 0: ip6erspan get key 2
remote ip6 ::0 erspan version 2
kworker/0:1-33 [000] ..s4 229.947664: 0: direction 1
hwid 7 timestamp 31471811
kworker/0:1-33 [000] ..s4 229.947708: 0: ip6erspan get key 2
remote ip6 ::0 erspan version 2
kworker/0:1-33 [000] ..s4 229.947711: 0: direction 1
hwid 7 timestamp 31471814
systemd-resolve-2664 [001] ..s3 230.083782: 0: ERROR line:269 ret:-22
systemd-resolve-2664 [001] ..s3 230.333523: 0: ERROR line:269 ret:-22
<idle>-0 [000] ..s3 230.779419: 0: ip6erspan get key 2
remote ip6 ::0 erspan version 2
<idle>-0 [000] ..s3 230.779424: 0: direction 1
hwid 7 timestamp 31480130
ping-3540 [003] ..s3 231.091633: 0: ip6erspan get key 2
remote ip6 ::0 erspan version 2
ping-3540 [003] ..s3 231.091638: 0: direction 1
hwid 7 timestamp 31483253
ping-3540 [003] ..s3 231.091737: 0: ip6erspan get key 2
remote ip6 ::0 erspan version 2
ping-3540 [003] ..s3 231.091739: 0: direction 1
hwid 7 timestamp 31483254
ping-3540 [003] ..s3 232.092227: 0: ip6erspan get key 2
remote ip6 ::0 erspan version 2
ping-3540 [003] ..s3 232.092232: 0: direction 1
hwid 7 timestamp 31493259
ping-3540 [003] ..s3 233.092737: 0: ip6erspan get key 2
remote ip6 ::0 erspan version 2
ping-3540 [003] ..s3 233.092742: 0: direction 1
hwid 7 timestamp 31503264
ping-3655 [000] ..s3 233.957186: 0: key 2 remote ip
0xac100164 vxlan gbp 0x800ff
systemd-resolve-2664 [001] ..s3 234.065463: 0: ERROR line:339 ret:-22
<idle>-0 [000] ..s3 234.171427: 0: key 2 remote ip
0xac100164 vxlan gbp 0x94
kworker/0:1-33 [000] ..s4 234.235502: 0: ERROR line:345 ret:-2
systemd-resolve-2664 [001] ..s3 234.333813: 0: ERROR line:339 ret:-22
systemd-resolve-2664 [001] ..s3 234.583761: 0: ERROR line:339 ret:-22
ping-3655 [000] ..s3 234.957640: 0: key 2 remote ip
0xac100164 vxlan gbp 0x800ff
kworker/0:1-33 [000] ..s4 235.259475: 0: key 2 remote ip
0xac100164 vxlan gbp 0x94
kworker/0:1-33 [000] ..s4 235.259528: 0: ERROR line:345 ret:-2
systemd-resolve-2664 [001] ..s3 235.752142: 0: ERROR line:339 ret:-22
ping-3655 [000] ..s3 235.958144: 0: key 2 remote ip
0xac100164 vxlan gbp 0x800ff
<idle>-0 [000] ..s3 235.963159: 0: key 2 remote ip
0xac100164 vxlan gbp 0x94
ping-3663 [002] ..s3 235.990422: 0: key 2 remote ip
0xac100164 vxlan gbp 0x800ff
systemd-resolve-2664 [001] ..s3 236.083782: 0: ERROR line:339 ret:-22
systemd-resolve-2664 [001] ..s3 236.333591: 0: ERROR line:339 ret:-22
ping-3663 [002] ..s3 236.990900: 0: key 2 remote ip
0xac100164 vxlan gbp 0x800ff
ping-3663 [002] ..s3 237.991370: 0: key 2 remote ip
0xac100164 vxlan gbp 0x800ff
systemd-resolve-2664 [002] ..s3 239.083778: 0: ERROR line:387 ret:-22
systemd-resolve-2664 [002] ..s3 239.333765: 0: ERROR line:387 ret:-22
systemd-resolve-2664 [002] ..s3 239.583765: 0: ERROR line:387 ret:-22
systemd-resolve-2664 [001] ..s3 240.194218: 0: ERROR line:387 ret:-22
systemd-resolve-2664 [001] ..s3 240.333718: 0: ERROR line:387 ret:-22
systemd-resolve-2664 [001] ..s3 240.583708: 0: ERROR line:387 ret:-22
<idle>-0 [002] ..s3 240.955492: 0: key 22 remote ip6
::11000000 label 0
<idle>-0 [002] ..s3 240.955505: 0: key 22 remote ip6
::11000000 label 0
<idle>-0 [002] ..s3 240.955512: 0: key 22 remote ip6
::11000000 label 0
<idle>-0 [002] ..s3 240.955518: 0: key 22 remote ip6
::11000000 label 0
<idle>-0 [002] ..s3 240.955524: 0: key 22 remote ip6
::11000000 label 0
<idle>-0 [002] ..s3 241.211432: 0: key 22 remote ip6
::11000000 label 0
ksoftirqd/1-16 [001] ..s2 242.012579: 0: key 22 remote ip6
::11000000 label 0
ksoftirqd/1-16 [001] ..s2 242.026381: 0: key 22 remote ip6
::11000000 label 0
ksoftirqd/3-26 [003] ..s2 243.028099: 0: key 22 remote ip6
::11000000 label 0
ksoftirqd/3-26 [003] ..s2 244.040809: 0: key 22 remote ip6
::11000000 label 0
ping-3774 [001] ..s3 244.062314: 0: key 22 remote ip6
::11000000 label 0
<idle>-0 [002] ..s3 244.219413: 0: key 22 remote ip6
::11000000 label 0
ping-3774 [001] ..s3 245.075208: 0: key 22 remote ip6
::11000000 label 0
ping-3774 [001] ..s3 246.088218: 0: key 22 remote ip6
::11000000 label 0
ping-3887 [002] ..s3 246.831153: 0: key 2 remote ip
0xac100164 geneve class 0x0
ping-3887 [002] ..s3 246.831226: 0: key 2 remote ip
0xac100164 geneve class 0x0
systemd-resolve-2664 [003] ..s3 246.963398: 0: ERROR line:445 ret:-22
systemd-resolve-2664 [003] ..s3 247.083859: 0: ERROR line:445 ret:-22
systemd-resolve-2664 [003] ..s3 247.333815: 0: ERROR line:445 ret:-22
kworker/1:2-1480 [001] ..s4 247.355451: 0: key 2 remote ip
0xac100164 geneve class 0x0
<idle>-0 [001] ..s3 247.419431: 0: key 2 remote ip
0xac100164 geneve class 0x0
ping-3887 [002] ..s3 247.831692: 0: key 2 remote ip
0xac100164 geneve class 0x0
kworker/1:2-1480 [001] ..s4 248.379561: 0: key 2 remote ip
0xac100164 geneve class 0x0
kworker/1:2-1480 [001] ..s4 248.379605: 0: key 2 remote ip
0xac100164 geneve class 0x0
systemd-resolve-2664 [001] ..s3 248.440767: 0: ERROR line:445 ret:-22
<idle>-0 [001] ..s3 248.459429: 0: key 2 remote ip
0xac100164 geneve class 0x0
systemd-resolve-2664 [001] ..s3 248.583784: 0: ERROR line:445 ret:-22
ping-3887 [002] ..s3 248.832187: 0: key 2 remote ip
0xac100164 geneve class 0x0
systemd-resolve-2664 [001] ..s3 248.833517: 0: ERROR line:445 ret:-22
ping-3888 [000] ..s3 248.874871: 0: key 2 remote ip
0xac100164 geneve class 0x0
ping-3888 [000] ..s3 249.875339: 0: key 2 remote ip
0xac100164 geneve class 0x0
ping-3888 [000] ..s3 250.875805: 0: key 2 remote ip
0xac100164 geneve class 0x0
systemd-resolve-2664 [003] ..s3 252.032344: 0: ERROR line:509 ret:-22
systemd-resolve-2664 [003] ..s3 252.333767: 0: ERROR line:509 ret:-22
systemd-resolve-2664 [003] ..s3 252.583766: 0: ERROR line:509 ret:-22
kworker/0:1-33 [000] ..s4 253.627615: 0: key 22 remote ip
0x0 geneve class 0x0
kworker/0:1-33 [000] ..s4 253.627634: 0: key 22 remote ip
0x0 geneve class 0x0
kworker/0:1-33 [000] ..s4 253.627766: 0: key 22 remote ip
0x0 geneve class 0x0
kworker/0:1-33 [000] ..s4 253.627797: 0: key 22 remote ip
0x0 geneve class 0x0
kworker/0:1-33 [000] ..s4 253.627833: 0: key 22 remote ip
0x0 geneve class 0x0
ping-3997 [001] ..s3 253.915594: 0: key 22 remote ip
0x0 geneve class 0x0
ping-3998 [002] ..s3 253.946604: 0: key 22 remote ip
0x0 geneve class 0x0
systemd-resolve-2664 [002] ..s3 253.956160: 0: ERROR line:509 ret:-22
systemd-resolve-2664 [002] ..s3 254.083777: 0: ERROR line:509 ret:-22
<idle>-0 [000] ..s3 254.331437: 0: key 22 remote ip
0x0 geneve class 0x0
systemd-resolve-2664 [002] ..s3 254.333628: 0: ERROR line:509 ret:-22
ping-3998 [002] ..s3 254.947116: 0: key 22 remote ip
0x0 geneve class 0x0
ping-3998 [001] ..s3 255.947392: 0: key 22 remote ip
0x0 geneve class 0x0
ping-4118 [002] ..s3 256.654930: 0: remote ip 0xac100164
ping-4118 [002] ..s3 257.655393: 0: remote ip 0xac100164
ping-4118 [002] ..s3 258.655851: 0: remote ip 0xac100164
ping-4119 [000] ..s3 258.695970: 0: remote ip 0xac100164
ping-4119 [000] ..s3 259.696426: 0: remote ip 0xac100164
ping-4119 [000] ..s3 260.696886: 0: remote ip 0xac100164
ping-4231 [002] ..s3 264.713834: 0: remote ip6 0::11
ping-4231 [002] ..s3 265.714327: 0: remote ip6 0::11
<idle>-0 [002] ..s3 265.979423: 0: remote ip6 0::11
ping-4231 [002] ..s3 266.714822: 0: remote ip6 0::11
ping-4239 [001] ..s3 266.748758: 0: remote ip6 0::11
ping-4239 [001] ..s3 267.749244: 0: remote ip6 0::11
ping-4239 [001] ..s3 268.749737: 0: remote ip6 0::11
ping-4367 [003] ..s3 270.047776: 0: reqid 1 spi 0x1
remote ip 0xac100164
ksoftirqd/3-26 [003] ..s2 271.048427: 0: reqid 1 spi 0x1
remote ip 0xac100164
PING 10.1.1.200 (10.1.1.200): 56 data bytes
--- 10.1.1.200 ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 0.263/0.370/0.579 ms
ping-4367 [003] ..s3 272.048870: 0: reqid 1 spi 0x1
remote ip 0xac100164
ping-4367 [003] ..s3 270.047776: 0: reqid 1 spi 0x1
remote ip 0xac100164
ksoftirqd/3-26 [003] ..s2 271.048427: 0: reqid 1 spi 0x1
remote ip 0xac100164
ping-4367 [003] ..s3 272.048870: 0: reqid 1 spi 0x1
remote ip 0xac100164
ping-4367 [003] ..s3 270.047776: 0: reqid 1 spi 0x1
remote ip 0xac100164
ksoftirqd/3-26 [003] ..s2 271.048427: 0: reqid 1 spi 0x1
remote ip 0xac100164
ping-4367 [003] ..s3 272.048870: 0: reqid 1 spi 0x1
remote ip 0xac100164
<idle>-0 [000] ..s3 190.987095: 0: key 2 remote ip 0xac100164
ping-3043 [000] ..s3 190.988715: 0: key 2 remote ip 0xac100164
ksoftirqd/0-9 [000] ..s2 190.988986: 0: key 2 remote ip 0xac100164
kworker/0:1-33 [000] ..s4 191.419445: 0: key 2 remote ip 0xac100164
ping-3043 [000] ..s3 191.989437: 0: key 2 remote ip 0xac100164
kworker/0:1-33 [000] ..s4 192.443460: 0: key 2 remote ip 0xac100164
kworker/0:1-33 [000] ..s4 192.443508: 0: key 2 remote ip 0xac100164
<idle>-0 [000] ..s3 192.446318: 0: key 2 remote ip 0xac100164
ping-3043 [000] ..s3 192.989902: 0: key 2 remote ip 0xac100164
ping-3044 [000] ..s3 193.025776: 0: key 2 remote ip 0xac100164
ping-3044 [000] ..s3 194.026240: 0: key 2 remote ip 0xac100164
ping-3044 [000] ..s3 195.026707: 0: key 2 remote ip 0xac100164
ping-3419 [002] ..s3 223.036234: 0: key 2 remote ip
0xac100164 erspan version 2
ping-3419 [002] ..s3 223.036256: 0: key 2 remote ip
0xac100164 erspan version 2
<idle>-0 [000] ..s3 223.067438: 0: key 2 remote ip
0xac100164 erspan version 2
kworker/0:1-33 [000] ..s4 223.283447: 0: key 2 remote ip
0xac100164 erspan version 2
ping-3419 [002] ..s3 224.036713: 0: key 2 remote ip
0xac100164 erspan version 2
kworker/0:1-33 [000] ..s4 224.315459: 0: key 2 remote ip
0xac100164 erspan version 2
kworker/0:1-33 [000] ..s4 224.315514: 0: key 2 remote ip
0xac100164 erspan version 2
<idle>-0 [000] ..s3 224.675428: 0: key 2 remote ip
0xac100164 erspan version 2
ping-3419 [002] ..s3 225.036920: 0: key 2 remote ip
0xac100164 erspan version 2
ping-3420 [003] ..s3 225.064293: 0: key 2 remote ip
0xac100164 erspan version 2
ping-3420 [003] ..s3 226.064761: 0: key 2 remote ip
0xac100164 erspan version 2
ping-3420 [003] ..s3 227.065237: 0: key 2 remote ip
0xac100164 erspan version 2
ping-3655 [000] ..s3 233.957186: 0: key 2 remote ip
0xac100164 vxlan gbp 0x800ff
<idle>-0 [000] ..s3 234.171427: 0: key 2 remote ip
0xac100164 vxlan gbp 0x94
ping-3655 [000] ..s3 234.957640: 0: key 2 remote ip
0xac100164 vxlan gbp 0x800ff
kworker/0:1-33 [000] ..s4 235.259475: 0: key 2 remote ip
0xac100164 vxlan gbp 0x94
ping-3655 [000] ..s3 235.958144: 0: key 2 remote ip
0xac100164 vxlan gbp 0x800ff
<idle>-0 [000] ..s3 235.963159: 0: key 2 remote ip
0xac100164 vxlan gbp 0x94
ping-3663 [002] ..s3 235.990422: 0: key 2 remote ip
0xac100164 vxlan gbp 0x800ff
ping-3663 [002] ..s3 236.990900: 0: key 2 remote ip
0xac100164 vxlan gbp 0x800ff
ping-3663 [002] ..s3 237.991370: 0: key 2 remote ip
0xac100164 vxlan gbp 0x800ff
ping-3887 [002] ..s3 246.831153: 0: key 2 remote ip
0xac100164 geneve class 0x0
ping-3887 [002] ..s3 246.831226: 0: key 2 remote ip
0xac100164 geneve class 0x0
kworker/1:2-1480 [001] ..s4 247.355451: 0: key 2 remote ip
0xac100164 geneve class 0x0
<idle>-0 [001] ..s3 247.419431: 0: key 2 remote ip
0xac100164 geneve class 0x0
ping-3887 [002] ..s3 247.831692: 0: key 2 remote ip
0xac100164 geneve class 0x0
kworker/1:2-1480 [001] ..s4 248.379561: 0: key 2 remote ip
0xac100164 geneve class 0x0
kworker/1:2-1480 [001] ..s4 248.379605: 0: key 2 remote ip
0xac100164 geneve class 0x0
<idle>-0 [001] ..s3 248.459429: 0: key 2 remote ip
0xac100164 geneve class 0x0
ping-3887 [002] ..s3 248.832187: 0: key 2 remote ip
0xac100164 geneve class 0x0
ping-3888 [000] ..s3 248.874871: 0: key 2 remote ip
0xac100164 geneve class 0x0
ping-3888 [000] ..s3 249.875339: 0: key 2 remote ip
0xac100164 geneve class 0x0
ping-3888 [000] ..s3 250.875805: 0: key 2 remote ip
0xac100164 geneve class 0x0
ping-4118 [002] ..s3 256.654930: 0: remote ip 0xac100164
ping-4118 [002] ..s3 257.655393: 0: remote ip 0xac100164
ping-4118 [002] ..s3 258.655851: 0: remote ip 0xac100164
ping-4119 [000] ..s3 258.695970: 0: remote ip 0xac100164
ping-4119 [000] ..s3 259.696426: 0: remote ip 0xac100164
ping-4119 [000] ..s3 260.696886: 0: remote ip 0xac100164
ping-4367 [003] ..s3 270.047776: 0: reqid 1 spi 0x1
remote ip 0xac100164
ksoftirqd/3-26 [003] ..s2 271.048427: 0: reqid 1 spi 0x1
remote ip 0xac100164
ping-4367 [003] ..s3 272.048870: 0: reqid 1 spi 0x1
remote ip 0xac100164
[0;92mPASS: xfrm tunnel[0m
^ permalink raw reply
* Re: WARNING: kmalloc bug in xdp_umem_create
From: Daniel Borkmann @ 2018-06-12 12:08 UTC (permalink / raw)
To: Björn Töpel, penguin-kernel
Cc: dvyukov, syzbot+4abadc5d69117b346506, Björn Töpel,
Karlsson, Magnus, David Miller, LKML, Netdev, syzkaller-bugs
In-Reply-To: <CAJ+HfNh9pRGcd9EO7BEfPPEdCmP5EDdu_rNgLR7r4oDrcLgvQQ@mail.gmail.com>
On 06/10/2018 03:03 PM, Björn Töpel wrote:
> Den sön 10 juni 2018 kl 14:53 skrev Tetsuo Handa
> <penguin-kernel@i-love.sakura.ne.jp>:
>> On 2018/06/10 20:52, Dmitry Vyukov wrote:
>>> On Sun, Jun 10, 2018 at 11:31 AM, Björn Töpel <bjorn.topel@gmail.com> wrote:
>>>> Den sön 10 juni 2018 kl 04:53 skrev Tetsuo Handa
>>>> <penguin-kernel@i-love.sakura.ne.jp>:
>>>>> On 2018/06/10 7:47, syzbot wrote:
>>>>>> Hello,
>>>>>>
>>>>>> syzbot found the following crash on:
>>>>>>
>>>>>> HEAD commit: 7d3bf613e99a Merge tag 'libnvdimm-for-4.18' of git://git.k..
>>>>>> git tree: upstream
>>>>>> console output: https://syzkaller.appspot.com/x/log.txt?x=1073f68f800000
>>>>>> kernel config: https://syzkaller.appspot.com/x/.config?x=f04d8d0a2afb789a
>>>>>> dashboard link: https://syzkaller.appspot.com/bug?extid=4abadc5d69117b346506
>>>>>> compiler: gcc (GCC) 8.0.1 20180413 (experimental)
>>>>>> syzkaller repro:https://syzkaller.appspot.com/x/repro.syz?x=13c9756f800000
>>>>>> C reproducer: https://syzkaller.appspot.com/x/repro.c?x=16366f9f800000
>>>>>>
>>>>>> IMPORTANT: if you fix the bug, please add the following tag to the commit:
>>>>>> Reported-by: syzbot+4abadc5d69117b346506@syzkaller.appspotmail.com
>>>>>>
>>>>>> random: sshd: uninitialized urandom read (32 bytes read)
>>>>>> random: sshd: uninitialized urandom read (32 bytes read)
>>>>>> random: sshd: uninitialized urandom read (32 bytes read)
>>>>>> random: sshd: uninitialized urandom read (32 bytes read)
>>>>>> random: sshd: uninitialized urandom read (32 bytes read)
>>>>>> WARNING: CPU: 1 PID: 4537 at mm/slab_common.c:996 kmalloc_slab+0x56/0x70 mm/slab_common.c:996
>>>>>> Kernel panic - not syncing: panic_on_warn set ...
>>>>>
>>>>> syzbot gave up upon kmalloc(), but actually error handling path has
>>>>> NULL pointer dereference bug.
>>>>
>>>> Thanks Tetsuo! This crash has been fixed by Daniel Borkmann in commit
>>>> c09290c56376 ("bpf, xdp: fix crash in xdp_umem_unaccount_pages").
>>>
>>> Let's tell syzbot about this:
>>>
>>> #syz fix: bpf, xdp: fix crash in xdp_umem_unaccount_pages
>>>
>> Excuse me, but that patch fixes NULL pointer dereference which occurs after kmalloc()'s
>> "WARNING: CPU: 1 PID: 4537 at mm/slab_common.c:996 kmalloc_slab+0x56/0x70 mm/slab_common.c:996"
>> message. That is, "Too large memory allocation" itself is not yet fixed.
>
> The code relies on that the sl{u,a,o}b layer says no, and the
> setsockopt bails out. The warning could be opted out using
> __GFP_NOWARN. Is there another preferred way? Two get_user_pages
> calls, where the first call would set pages to NULL just to fault the
> region? Walk the process' VMAs? Something else?
(Now resolved as well.)
#syz fix: xsk: silence warning on memory allocation failure
^ permalink raw reply
* [PATCH 2/2] ath10k: allow ATH10K_SNOC with COMPILE_TEST
From: Niklas Cassel @ 2018-06-12 11:39 UTC (permalink / raw)
To: Kalle Valo, David S. Miller
Cc: Niklas Cassel, ath10k, linux-wireless, netdev, linux-kernel
In-Reply-To: <20180612113907.15043-1-niklas.cassel@linaro.org>
ATH10K_SNOC builds just fine with COMPILE_TEST, so make that possible.
Signed-off-by: Niklas Cassel <niklas.cassel@linaro.org>
---
drivers/net/wireless/ath/ath10k/Kconfig | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ath/ath10k/Kconfig b/drivers/net/wireless/ath/ath10k/Kconfig
index 54ff5930126c..6572a43590a8 100644
--- a/drivers/net/wireless/ath/ath10k/Kconfig
+++ b/drivers/net/wireless/ath/ath10k/Kconfig
@@ -42,7 +42,8 @@ config ATH10K_USB
config ATH10K_SNOC
tristate "Qualcomm ath10k SNOC support (EXPERIMENTAL)"
- depends on ATH10K && ARCH_QCOM
+ depends on ATH10K
+ depends on ARCH_QCOM || COMPILE_TEST
---help---
This module adds support for integrated WCN3990 chip connected
to system NOC(SNOC). Currently work in progress and will not
--
2.17.1
^ permalink raw reply related
* [PATCH 1/2] ath10k: do not mix spaces and tabs in Kconfig
From: Niklas Cassel @ 2018-06-12 11:39 UTC (permalink / raw)
To: Kalle Valo, David S. Miller
Cc: Niklas Cassel, ath10k, linux-wireless, netdev, linux-kernel
Do not mix spaces and tabs in Kconfig.
Signed-off-by: Niklas Cassel <niklas.cassel@linaro.org>
---
drivers/net/wireless/ath/ath10k/Kconfig | 24 ++++++++++++------------
1 file changed, 12 insertions(+), 12 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/Kconfig b/drivers/net/wireless/ath/ath10k/Kconfig
index 84f071ac0d84..54ff5930126c 100644
--- a/drivers/net/wireless/ath/ath10k/Kconfig
+++ b/drivers/net/wireless/ath/ath10k/Kconfig
@@ -1,15 +1,15 @@
config ATH10K
- tristate "Atheros 802.11ac wireless cards support"
- depends on MAC80211 && HAS_DMA
+ tristate "Atheros 802.11ac wireless cards support"
+ depends on MAC80211 && HAS_DMA
select ATH_COMMON
select CRC32
select WANT_DEV_COREDUMP
select ATH10K_CE
- ---help---
- This module adds support for wireless adapters based on
- Atheros IEEE 802.11ac family of chipsets.
+ ---help---
+ This module adds support for wireless adapters based on
+ Atheros IEEE 802.11ac family of chipsets.
- If you choose to build a module, it'll be called ath10k.
+ If you choose to build a module, it'll be called ath10k.
config ATH10K_CE
bool
@@ -41,12 +41,12 @@ config ATH10K_USB
work in progress and will not fully work.
config ATH10K_SNOC
- tristate "Qualcomm ath10k SNOC support (EXPERIMENTAL)"
- depends on ATH10K && ARCH_QCOM
- ---help---
- This module adds support for integrated WCN3990 chip connected
- to system NOC(SNOC). Currently work in progress and will not
- fully work.
+ tristate "Qualcomm ath10k SNOC support (EXPERIMENTAL)"
+ depends on ATH10K && ARCH_QCOM
+ ---help---
+ This module adds support for integrated WCN3990 chip connected
+ to system NOC(SNOC). Currently work in progress and will not
+ fully work.
config ATH10K_DEBUG
bool "Atheros ath10k debugging"
--
2.17.1
^ permalink raw reply related
* Re: [Qemu-devel] [PATCH] qemu: Introduce VIRTIO_NET_F_STANDBY feature bit to virtio_net
From: Michael S. Tsirkin @ 2018-06-12 11:34 UTC (permalink / raw)
To: Samudrala, Sridhar
Cc: alexander.h.duyck, virtio-dev, aaron.f.brown, jiri, kubakici,
netdev, qemu-devel, loseweigh, virtualization
In-Reply-To: <23fc4aa4-ec41-d6e2-3354-10cbfc13b7ec@intel.com>
On Mon, Jun 11, 2018 at 10:02:45PM -0700, Samudrala, Sridhar wrote:
> On 6/11/2018 7:17 PM, Michael S. Tsirkin wrote:
> > On Tue, Jun 12, 2018 at 09:54:44AM +0800, Jason Wang wrote:
> > >
> > > On 2018年06月12日 01:26, Michael S. Tsirkin wrote:
> > > > On Mon, May 07, 2018 at 04:09:54PM -0700, Sridhar Samudrala wrote:
> > > > > This feature bit can be used by hypervisor to indicate virtio_net device to
> > > > > act as a standby for another device with the same MAC address.
> > > > >
> > > > > I tested this with a small change to the patch to mark the STANDBY feature 'true'
> > > > > by default as i am using libvirt to start the VMs.
> > > > > Is there a way to pass the newly added feature bit 'standby' to qemu via libvirt
> > > > > XML file?
> > > > >
> > > > > Signed-off-by: Sridhar Samudrala <sridhar.samudrala@intel.com>
> > > > So I do not think we can commit to this interface: we
> > > > really need to control visibility of the primary device.
> > > The problem is legacy guest won't use primary device at all if we do this.
> > And that's by design - I think it's the only way to ensure the
> > legacy guest isn't confused.
>
> Yes. I think so. But i am not sure if Qemu is the right place to control the visibility
> of the primary device. The primary device may not be specified as an argument to Qemu. It
> may be plugged in later.
> The cloud service provider is providing a feature that enables low latency datapath and live
> migration capability.
> A tenant can use this feature only if he is running a VM that has virtio-net with failover support.
Well live migration is there already. The new feature is low latency
data path.
And it's the guest that needs failover support not the VM.
> I think Qemu should check if guest virtio-net supports this feature and provide a mechanism for
> an upper layer indicating if the STANDBY feature is successfully negotiated or not.
> The upper layer can then decide if it should hot plug a VF with the same MAC and manage the 2 links.
> If VF is successfully hot plugged, virtio-net link should be disabled.
Did you even talk to upper layer management about it?
Just list the steps they need to do and you will see
that's a lot of machinery to manage by the upper layer.
What do we gain in flexibility? As far as I can see the
only gain is some resources saved for legacy VMs.
That's not a lot as tenant of the upper layer probably already has
at least a hunch that it's a new guest otherwise
why bother specifying the feature at all - you
save even more resources without it.
>
> >
> > > How about control the visibility of standby device?
> > >
> > > Thanks
> > standy the always there to guarantee no downtime.
> >
> > > > However just for testing purposes, we could add a non-stable
> > > > interface "x-standby" with the understanding that as any
> > > > x- prefix it's unstable and will be changed down the road,
> > > > likely in the next release.
> > > >
> > > >
> > > > > ---
> > > > > hw/net/virtio-net.c | 2 ++
> > > > > include/standard-headers/linux/virtio_net.h | 3 +++
> > > > > 2 files changed, 5 insertions(+)
> > > > >
> > > > > diff --git a/hw/net/virtio-net.c b/hw/net/virtio-net.c
> > > > > index 90502fca7c..38b3140670 100644
> > > > > --- a/hw/net/virtio-net.c
> > > > > +++ b/hw/net/virtio-net.c
> > > > > @@ -2198,6 +2198,8 @@ static Property virtio_net_properties[] = {
> > > > > true),
> > > > > DEFINE_PROP_INT32("speed", VirtIONet, net_conf.speed, SPEED_UNKNOWN),
> > > > > DEFINE_PROP_STRING("duplex", VirtIONet, net_conf.duplex_str),
> > > > > + DEFINE_PROP_BIT64("standby", VirtIONet, host_features, VIRTIO_NET_F_STANDBY,
> > > > > + false),
> > > > > DEFINE_PROP_END_OF_LIST(),
> > > > > };
> > > > > diff --git a/include/standard-headers/linux/virtio_net.h b/include/standard-headers/linux/virtio_net.h
> > > > > index e9f255ea3f..01ec09684c 100644
> > > > > --- a/include/standard-headers/linux/virtio_net.h
> > > > > +++ b/include/standard-headers/linux/virtio_net.h
> > > > > @@ -57,6 +57,9 @@
> > > > > * Steering */
> > > > > #define VIRTIO_NET_F_CTRL_MAC_ADDR 23 /* Set MAC address */
> > > > > +#define VIRTIO_NET_F_STANDBY 62 /* Act as standby for another device
> > > > > + * with the same MAC.
> > > > > + */
> > > > > #define VIRTIO_NET_F_SPEED_DUPLEX 63 /* Device set linkspeed and duplex */
> > > > > #ifndef VIRTIO_NET_NO_LEGACY
> > > > > --
> > > > > 2.14.3
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
^ permalink raw reply
* Re: [PULL] vhost: cleanups and fixes
From: Wei Wang @ 2018-06-12 11:05 UTC (permalink / raw)
To: Linus Torvalds, Michael S. Tsirkin
Cc: KVM list, Network Development, Linux Kernel Mailing List,
Bjorn Andersson, Andrew Morton, virtualization
In-Reply-To: <CA+55aFyNhEzzufw0XP9DcqZNS1CH+jDGdN4CVnazb3ssFxFbzQ@mail.gmail.com>
On 06/12/2018 09:59 AM, Linus Torvalds wrote:
> On Mon, Jun 11, 2018 at 6:36 PM Michael S. Tsirkin <mst@redhat.com> wrote:
>> Maybe it will help to have GFP_NONE which will make any allocation
>> fail if attempted. Linus, would this address your comment?
> It would definitely have helped me initially overlook that call chain.
>
> But then when I started looking at the whole dma_map_page() thing, it
> just raised my hackles again.
>
> I would seriously suggest having a much simpler version for the "no
> allocation, no dma mapping" case, so that it's *obvious* that that
> never happens.
>
> So instead of having virtio_balloon_send_free_pages() call a really
> generic complex chain of functions that in _some_ cases can do memory
> allocation, why isn't there a short-circuited "vitruque_add_datum()"
> that is guaranteed to never do anything like that?
>
> Honestly, I look at "add_one_sg()" and it really doesn't make me
> happy. It looks hacky as hell. If I read the code right, you're really
> trying to just queue up a simple tuple of <pfn,len>, except you encode
> it as a page pointer in order to play games with the SG logic, and
> then you hmap that to the ring, except in this case it's all a fake
> ring that just adds the cpu-physical address instead.
>
> And to figuer that out, it's like five layers of indirection through
> different helper functions that *can* do more generic things but in
> this case don't.
>
> And you do all of this from a core VM callback function with some
> _really_ core VM locks held.
>
> That makes no sense to me.
>
> How about this:
>
> - get rid of all that code
>
> - make the core VM callback save the "these are the free memory
> regions" in a fixed and limited array. One that DOES JUST THAT. No
> crazy "SG IO dma-mapping function crap". Just a plain array of a fixed
> size, pre-allocated for that virtio instance.
>
> - make it obvious that what you do in that sequence is ten
> instructions and no allocations ("Look ma, I wrote a value to an array
> and incremented the array idex, and I'M DONE")
>
> - then in that workqueue entry that you start *anyway*, you empty the
> array and do all the crazy virtio stuff.
>
> In fact, while at it, just simplify the VM interface too. Instead of
> traversing a random number of buddy lists, just trraverse *one* - the
> top-level one. Are you seriously ever going to shrink or mark
> read-only anythin *but* something big enough to be in the maximum
> order?
>
> MAX_ORDER is what, 11? So we're talking 8MB blocks. Do you *really*
> want the balloon code to work on smaller things, particularly since
> the whole interface is fundamentally racy and opportunistic to begin
> with?
OK, I will implement a new version based on the suggestions. Thanks.
Best,
Wei
^ permalink raw reply
* [PATCH] selftests: bpf: config: add config fragments
From: Anders Roxell @ 2018-06-12 11:05 UTC (permalink / raw)
To: ast, daniel, shuah; +Cc: netdev, linux-kernel, linux-kselftest, Anders Roxell
Tests test_tunnel.sh fails due to config fragments ins't enabled.
Fixes: 933a741e3b82 ("selftests/bpf: bpf tunnel test.")
Signed-off-by: Anders Roxell <anders.roxell@linaro.org>
---
All tests passes except ip6gretap that still fails. I'm unsure why.
Ideas?
Cheers,
Anders
tools/testing/selftests/bpf/config | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/tools/testing/selftests/bpf/config b/tools/testing/selftests/bpf/config
index 1eefe211a4a8..7eb613ffef55 100644
--- a/tools/testing/selftests/bpf/config
+++ b/tools/testing/selftests/bpf/config
@@ -7,3 +7,13 @@ CONFIG_CGROUP_BPF=y
CONFIG_NETDEVSIM=m
CONFIG_NET_CLS_ACT=y
CONFIG_NET_SCH_INGRESS=y
+CONFIG_NET_IPIP=y
+CONFIG_IPV6=y
+CONFIG_NET_IPGRE_DEMUX=y
+CONFIG_NET_IPGRE=y
+CONFIG_IPV6_GRE=y
+CONFIG_CRYPTO_USER_API_HASH=m
+CONFIG_CRYPTO_HMAC=m
+CONFIG_CRYPTO_SHA256=m
+CONFIG_VXLAN=y
+CONFIG_GENEVE=y
--
2.17.1
^ permalink raw reply related
* Re: [PATCH net] tls: fix NULL pointer dereference on poll
From: Daniel Borkmann @ 2018-06-12 10:43 UTC (permalink / raw)
To: Christoph Hellwig; +Cc: davem, davejwatson, netdev, ast
In-Reply-To: <20180612053749.GA16853@lst.de>
On 06/12/2018 07:37 AM, Christoph Hellwig wrote:
>> Looks like the recent conversion from poll to poll_mask callback started
>> in 152524231023 ("net: add support for ->poll_mask in proto_ops") missed
>> to eventually convert kTLS, too: TCP's ->poll was converted over to the
>> ->poll_mask in commit 2c7d3dacebd4 ("net/tcp: convert to ->poll_mask")
>> and therefore kTLS wrongly saved the ->poll old one which is now NULL.
>
> Looks like this TLS code was added in the same cycle.
>
>> diff --git a/net/tls/tls_main.c b/net/tls/tls_main.c
>> index 301f224..a127d61 100644
>> --- a/net/tls/tls_main.c
>> +++ b/net/tls/tls_main.c
>> @@ -712,7 +712,7 @@ static int __init tls_register(void)
>> build_protos(tls_prots[TLSV4], &tcp_prot);
>>
>> tls_sw_proto_ops = inet_stream_ops;
>> - tls_sw_proto_ops.poll = tls_sw_poll;
>> + tls_sw_proto_ops.poll_mask = tls_sw_poll_mask;
>> tls_sw_proto_ops.splice_read = tls_sw_splice_read;
>
> Not new in this patch, but copying ops vectors is a very bad idea, not
> only because your new instance can't be marked const and you thus open
> up exploit vectors. I would suggest to clean this up eventually.
Generally, agree with you. It could at minimum also be a __ro_after_init
candidate, at least the TLSV4 ops which wouldn't change. In v6 case though
it could be loaded as a module after TLS was initialized.
>> +__poll_t tls_sw_poll_mask(struct socket *sock, __poll_t events)
>> {
>> struct sock *sk = sock->sk;
>> struct tls_context *tls_ctx = tls_get_ctx(sk);
>> struct tls_sw_context_rx *ctx = tls_sw_ctx_rx(tls_ctx);
>> + __poll_t mask;
>>
>> + /* Grab EPOLLOUT and EPOLLHUP from the underlying socket */
>> + mask = ctx->sk_poll_mask(sock, events);
>>
>> + /* Clear EPOLLIN bits, and set based on recv_pkt */
>> + mask &= ~(EPOLLIN | EPOLLRDNORM);
>> if (ctx->recv_pkt)
>> + mask |= EPOLLIN | EPOLLRDNORM;
>>
>> + return mask;
>
> So you call the underlying protocol method on the struct sock of
> the TLS code? Again not reall new in this patch, but how is this
> even supposed to work?
Yeah, patch doesn't change it, but reason is that TLS relies on kernel's
stream parser to determine TLS message boundary on ingress, so once a full
message got received only then we want to signal this to the user space
application. Latter skb is then held in ctx->recv_pkt via stream parser.
Thanks,
Daniel
^ permalink raw reply
* Re: [PATCH bpf] xsk: re-add queue id check for XDP_SKB path
From: Daniel Borkmann @ 2018-06-12 10:21 UTC (permalink / raw)
To: Björn Töpel, magnus.karlsson, magnus.karlsson, ast,
netdev
Cc: Björn Töpel, qi.z.zhang
In-Reply-To: <20180612100256.21300-1-bjorn.topel@gmail.com>
On 06/12/2018 12:02 PM, Björn Töpel wrote:
> From: Björn Töpel <bjorn.topel@intel.com>
>
> Commit 173d3adb6f43 ("xsk: add zero-copy support for Rx") introduced a
> regression on the XDP_SKB receive path, when the queue id checks were
> removed. Now, they are back again.
>
> Fixes: 173d3adb6f43 ("xsk: add zero-copy support for Rx")
> Reported-by: Qi Zhang <qi.z.zhang@intel.com>
> Signed-off-by: Björn Töpel <bjorn.topel@intel.com>
Applied to bpf, thanks Björn!
^ permalink raw reply
* Re: [PATCH net-next 4/6] net: ethernet: ti: cpsw: add CBS Qdisc offload
From: Ilias Apalodimas @ 2018-06-12 10:18 UTC (permalink / raw)
To: Ivan Khoronzhuk
Cc: grygorii.strashko, davem, corbet, akpm, netdev, linux-doc,
linux-kernel, linux-omap, vinicius.gomes, henrik,
jesus.sanchez-palencia, p-varis, spatton, francois.ozog, yogeshs,
nsekhar
In-Reply-To: <20180611133047.4818-5-ivan.khoronzhuk@linaro.org>
On Mon, Jun 11, 2018 at 04:30:45PM +0300, Ivan Khoronzhuk wrote:
> The cpsw has up to 4 FIFOs per port and upper 3 FIFOs can feed rate
> limited queue with shaping. In order to set and enable shaping for
> those 3 FIFOs queues the network device with CBS qdisc attached is
> needed. The CBS configuration is added for dual-emac/single port mode
> only, but potentially can be used in switch mode also, based on
> switchdev for instance.
>
> Despite the FIFO shapers can work w/o cpdma level shapers the base
> usage must be in combine with cpdma level shapers as described in TRM,
> that are set as maximum rates for interface queues with sysfs.
>
> One of the possible configuration with txq shapers and CBS shapers:
>
> Configured with echo RATE >
> /sys/class/net/eth0/queues/tx-0/tx_maxrate
> /---------------------------------------------------
> /
> / cpdma level shapers
> +----+ +----+ +----+ +----+ +----+ +----+ +----+ +----+
> | c7 | | c6 | | c5 | | c4 | | c3 | | c2 | | c1 | | c0 |
> \ / \ / \ / \ / \ / \ / \ / \ /
> \ / \ / \ / \ / \ / \ / \ / \ /
> \/ \/ \/ \/ \/ \/ \/ \/
> +---------|------|------|------|-------------------------------------+
> | +----+ | | +---+ |
> | | +----+ | | |
> | v v v v |
> | +----+ +----+ +----+ +----+ p p+----+ +----+ +----+ +----+ |
> | | | | | | | | | o o| | | | | | | | |
> | | f3 | | f2 | | f1 | | f0 | r CPSW r| f3 | | f2 | | f1 | | f0 | |
> | | | | | | | | | t t| | | | | | | | |
> | \ / \ / \ / \ / 0 1\ / \ / \ / \ / |
> | \ X \ / \ / \ / \ / \ / \ / \ / |
> | \/ \ \/ \/ \/ \/ \/ \/ \/ |
> +-------\------------------------------------------------------------+
> \
> \ FIFO shaper, set with CBS offload added in this patch,
> \ FIFO0 cannot be rate limited
> ------------------------------------------------------
>
> CBS shaper configuration is supposed to be used with root MQPRIO Qdisc
> offload allowing to add sk_prio->tc->txq maps that direct traffic to
> appropriate tx queue and maps L2 priority to FIFO shaper.
>
> The CBS shaper is intended to be used for AVB where L2 priority
> (pcp field) is used to differentiate class of traffic. So additionally
> vlan needs to be created with appropriate egress sk_prio->l2 prio map.
>
> If CBS has several tx queues assigned to it, the sum of their
> bandwidth has not overlap bandwidth set for CBS. It's recomended the
> CBS bandwidth to be a little bit more.
>
> The CBS shaper is configured with CBS qdisc offload interface using tc
> tool from iproute2 packet.
>
> For instance:
>
> $ tc qdisc replace dev eth0 handle 100: parent root mqprio num_tc 3 \
> map 2 2 1 0 2 2 2 2 2 2 2 2 2 2 2 2 queues 1@0 1@1 2@2 hw 1
>
> $ tc -g class show dev eth0
> +---(100:ffe2) mqprio
> | +---(100:3) mqprio
> | +---(100:4) mqprio
> |
> +---(100:ffe1) mqprio
> | +---(100:2) mqprio
> |
> +---(100:ffe0) mqprio
> +---(100:1) mqprio
>
> $ tc qdisc add dev eth0 parent 100:1 cbs locredit -1440 \
> hicredit 60 sendslope -960000 idleslope 40000 offload 1
>
> $ tc qdisc add dev eth0 parent 100:2 cbs locredit -1470 \
> hicredit 62 sendslope -980000 idleslope 20000 offload 1
>
> The above code set CBS shapers for tc0 and tc1, for that txq0 and
> txq1 is used. Pay attention, the real set bandwidth can differ a bit
> due to discreteness of configuration parameters.
>
> Here parameters like locredit, hicredit and sendslope are ignored
> internally and are supposed to be set with assumption that maximum
> frame size for frame - 1500.
>
> It's supposed that interface speed is not changed while reconnection,
> not always is true, so inform user in case speed of interface was
> changed, as it can impact on dependent shapers configuration.
>
> For more examples see Documentation.
>
> Signed-off-by: Ivan Khoronzhuk <ivan.khoronzhuk@linaro.org>
> ---
> drivers/net/ethernet/ti/cpsw.c | 221 +++++++++++++++++++++++++++++++++
> 1 file changed, 221 insertions(+)
>
> diff --git a/drivers/net/ethernet/ti/cpsw.c b/drivers/net/ethernet/ti/cpsw.c
> index fd967d2bce5d..87a5586c5ea5 100644
> --- a/drivers/net/ethernet/ti/cpsw.c
> +++ b/drivers/net/ethernet/ti/cpsw.c
> @@ -46,6 +46,8 @@
> #include "cpts.h"
> #include "davinci_cpdma.h"
>
> +#include <net/pkt_sched.h>
> +
> #define CPSW_DEBUG (NETIF_MSG_HW | NETIF_MSG_WOL | \
> NETIF_MSG_DRV | NETIF_MSG_LINK | \
> NETIF_MSG_IFUP | NETIF_MSG_INTR | \
> @@ -154,8 +156,12 @@ do { \
> #define IRQ_NUM 2
> #define CPSW_MAX_QUEUES 8
> #define CPSW_CPDMA_DESCS_POOL_SIZE_DEFAULT 256
> +#define CPSW_FIFO_QUEUE_TYPE_SHIFT 16
> +#define CPSW_FIFO_SHAPE_EN_SHIFT 16
> +#define CPSW_FIFO_RATE_EN_SHIFT 20
> #define CPSW_TC_NUM 4
> #define CPSW_FIFO_SHAPERS_NUM (CPSW_TC_NUM - 1)
> +#define CPSW_PCT_MASK 0x7f
>
> #define CPSW_RX_VLAN_ENCAP_HDR_PRIO_SHIFT 29
> #define CPSW_RX_VLAN_ENCAP_HDR_PRIO_MSK GENMASK(2, 0)
> @@ -457,6 +463,8 @@ struct cpsw_priv {
> bool rx_pause;
> bool tx_pause;
> bool mqprio_hw;
> + int fifo_bw[CPSW_TC_NUM];
> + int shp_cfg_speed;
> u32 emac_port;
> struct cpsw_common *cpsw;
> };
> @@ -1081,6 +1089,38 @@ static void cpsw_set_slave_mac(struct cpsw_slave *slave,
> slave_write(slave, mac_lo(priv->mac_addr), SA_LO);
> }
>
> +static bool cpsw_shp_is_off(struct cpsw_priv *priv)
> +{
> + struct cpsw_common *cpsw = priv->cpsw;
> + struct cpsw_slave *slave;
> + u32 shift, mask, val;
> +
> + val = readl_relaxed(&cpsw->regs->ptype);
> +
> + slave = &cpsw->slaves[cpsw_slave_index(cpsw, priv)];
> + shift = CPSW_FIFO_SHAPE_EN_SHIFT + 3 * slave->slave_num;
> + mask = 7 << shift;
> + val = val & mask;
> +
> + return !val;
> +}
> +
> +static void cpsw_fifo_shp_on(struct cpsw_priv *priv, int fifo, int on)
> +{
> + struct cpsw_common *cpsw = priv->cpsw;
> + struct cpsw_slave *slave;
> + u32 shift, mask, val;
> +
> + val = readl_relaxed(&cpsw->regs->ptype);
> +
> + slave = &cpsw->slaves[cpsw_slave_index(cpsw, priv)];
> + shift = CPSW_FIFO_SHAPE_EN_SHIFT + 3 * slave->slave_num;
> + mask = (1 << --fifo) << shift;
> + val = on ? val | mask : val & ~mask;
> +
> + writel_relaxed(val, &cpsw->regs->ptype);
> +}
> +
> static void _cpsw_adjust_link(struct cpsw_slave *slave,
> struct cpsw_priv *priv, bool *link)
> {
> @@ -1120,6 +1160,12 @@ static void _cpsw_adjust_link(struct cpsw_slave *slave,
> mac_control |= BIT(4);
>
> *link = true;
> +
> + if (priv->shp_cfg_speed &&
> + priv->shp_cfg_speed != slave->phy->speed &&
> + !cpsw_shp_is_off(priv))
> + dev_warn(priv->dev,
> + "Speed was changed, CBS sahper speeds are changed!");
> } else {
> mac_control = 0;
> /* disable forwarding */
> @@ -1589,6 +1635,178 @@ static int cpsw_tc_to_fifo(int tc, int num_tc)
> return CPSW_FIFO_SHAPERS_NUM - tc;
> }
>
> +static int cpsw_set_fifo_bw(struct cpsw_priv *priv, int fifo, int bw)
> +{
> + struct cpsw_common *cpsw = priv->cpsw;
> + u32 val = 0, send_pct, shift;
> + struct cpsw_slave *slave;
> + int pct = 0, i;
> +
> + if (bw > priv->shp_cfg_speed * 1000)
> + goto err;
> +
> + /* shaping has to stay enabled for highest fifos linearly
> + * and fifo bw no more then interface can allow
> + */
> + slave = &cpsw->slaves[cpsw_slave_index(cpsw, priv)];
> + send_pct = slave_read(slave, SEND_PERCENT);
> + for (i = CPSW_FIFO_SHAPERS_NUM; i > 0; i--) {
> + if (!bw) {
> + if (i >= fifo || !priv->fifo_bw[i])
> + continue;
> +
> + dev_warn(priv->dev, "Prev FIFO%d is shaped", i);
> + continue;
> + }
> +
> + if (!priv->fifo_bw[i] && i > fifo) {
> + dev_err(priv->dev, "Upper FIFO%d is not shaped", i);
> + return -EINVAL;
> + }
> +
> + shift = (i - 1) * 8;
> + if (i == fifo) {
> + send_pct &= ~(CPSW_PCT_MASK << shift);
> + val = DIV_ROUND_UP(bw, priv->shp_cfg_speed * 10);
> + if (!val)
> + val = 1;
> +
> + send_pct |= val << shift;
> + pct += val;
> + continue;
> + }
> +
> + if (priv->fifo_bw[i])
> + pct += (send_pct >> shift) & CPSW_PCT_MASK;
> + }
> +
> + if (pct >= 100)
> + goto err;
> +
> + slave_write(slave, send_pct, SEND_PERCENT);
> + priv->fifo_bw[fifo] = bw;
> +
> + dev_warn(priv->dev, "set FIFO%d bw = %d\n", fifo,
> + DIV_ROUND_CLOSEST(val * priv->shp_cfg_speed, 100));
> +
> + return 0;
> +err:
> + dev_err(priv->dev, "Bandwidth doesn't fit in tc configuration");
> + return -EINVAL;
> +}
> +
> +static int cpsw_set_fifo_rlimit(struct cpsw_priv *priv, int fifo, int bw)
> +{
> + struct cpsw_common *cpsw = priv->cpsw;
> + struct cpsw_slave *slave;
> + u32 tx_in_ctl_rg, val;
> + int ret;
> +
> + ret = cpsw_set_fifo_bw(priv, fifo, bw);
> + if (ret)
> + return ret;
> +
> + slave = &cpsw->slaves[cpsw_slave_index(cpsw, priv)];
> + tx_in_ctl_rg = cpsw->version == CPSW_VERSION_1 ?
> + CPSW1_TX_IN_CTL : CPSW2_TX_IN_CTL;
> +
> + if (!bw)
> + cpsw_fifo_shp_on(priv, fifo, bw);
> +
> + val = slave_read(slave, tx_in_ctl_rg);
> + if (cpsw_shp_is_off(priv)) {
> + /* disable FIFOs rate limited queues */
> + val &= ~(0xf << CPSW_FIFO_RATE_EN_SHIFT);
> +
> + /* set type of FIFO queues to normal priority mode */
> + val &= ~(3 << CPSW_FIFO_QUEUE_TYPE_SHIFT);
> +
> + /* set type of FIFO queues to be rate limited */
> + if (bw)
> + val |= 2 << CPSW_FIFO_QUEUE_TYPE_SHIFT;
> + else
> + priv->shp_cfg_speed = 0;
> + }
> +
> + /* toggle a FIFO rate limited queue */
> + if (bw)
> + val |= BIT(fifo + CPSW_FIFO_RATE_EN_SHIFT);
> + else
> + val &= ~BIT(fifo + CPSW_FIFO_RATE_EN_SHIFT);
> + slave_write(slave, val, tx_in_ctl_rg);
> +
> + /* FIFO transmit shape enable */
> + cpsw_fifo_shp_on(priv, fifo, bw);
> + return 0;
> +}
> +
> +/* Defaults:
> + * class A - prio 3
> + * class B - prio 2
> + * shaping for class A should be set first
> + */
> +static int cpsw_set_cbs(struct net_device *ndev,
> + struct tc_cbs_qopt_offload *qopt)
> +{
> + struct cpsw_priv *priv = netdev_priv(ndev);
> + struct cpsw_common *cpsw = priv->cpsw;
> + struct cpsw_slave *slave;
> + int prev_speed = 0;
> + int tc, ret, fifo;
> + u32 bw = 0;
> +
> + tc = netdev_txq_to_tc(priv->ndev, qopt->queue);
> +
> + /* enable channels in backward order, as highest FIFOs must be rate
> + * limited first and for compliance with CPDMA rate limited channels
> + * that also used in bacward order. FIFO0 cannot be rate limited.
> + */
> + fifo = cpsw_tc_to_fifo(tc, ndev->num_tc);
> + if (!fifo) {
> + dev_err(priv->dev, "Last tc%d can't be rate limited", tc);
> + return -EINVAL;
> + }
> +
> + /* do nothing, it's disabled anyway */
> + if (!qopt->enable && !priv->fifo_bw[fifo])
> + return 0;
> +
> + /* shapers can be set if link speed is known */
> + slave = &cpsw->slaves[cpsw_slave_index(cpsw, priv)];
> + if (slave->phy && slave->phy->link) {
> + if (priv->shp_cfg_speed &&
> + priv->shp_cfg_speed != slave->phy->speed)
> + prev_speed = priv->shp_cfg_speed;
> +
> + priv->shp_cfg_speed = slave->phy->speed;
> + }
> +
> + if (!priv->shp_cfg_speed) {
> + dev_err(priv->dev, "Link speed is not known");
> + return -1;
> + }
> +
> + ret = pm_runtime_get_sync(cpsw->dev);
> + if (ret < 0) {
> + pm_runtime_put_noidle(cpsw->dev);
> + return ret;
> + }
> +
> + bw = qopt->enable ? qopt->idleslope : 0;
> + ret = cpsw_set_fifo_rlimit(priv, fifo, bw);
> + if (ret) {
> + priv->shp_cfg_speed = prev_speed;
> + prev_speed = 0;
> + }
> +
> + if (bw && prev_speed)
> + dev_warn(priv->dev,
> + "Speed was changed, CBS sahper speeds are changed!");
> +
> + pm_runtime_put_sync(cpsw->dev);
> + return ret;
> +}
> +
> static int cpsw_ndo_open(struct net_device *ndev)
> {
> struct cpsw_priv *priv = netdev_priv(ndev);
> @@ -2263,6 +2481,9 @@ static int cpsw_ndo_setup_tc(struct net_device *ndev, enum tc_setup_type type,
> void *type_data)
> {
> switch (type) {
> + case TC_SETUP_QDISC_CBS:
> + return cpsw_set_cbs(ndev, type_data);
> +
> case TC_SETUP_QDISC_MQPRIO:
> return cpsw_set_tc(ndev, type_data);
>
> --
> 2.17.1
>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
^ permalink raw reply
* Re: [PATCH] isdn/i4l: add error handling for try_module_get
From: Sergei Shtylyov @ 2018-06-12 10:11 UTC (permalink / raw)
To: Zhouyang Jia
Cc: Karsten Keil, Kees Cook, Annie Cherkaev, Al Viro, Jiten Thakkar,
netdev, linux-kernel
In-Reply-To: <1528778635-41763-1-git-send-email-jiazhouyang09@gmail.com>
On 6/12/2018 7:43 AM, Zhouyang Jia wrote:
> When try_module_get fails, the lack of error-handling code may
> cause unexpected results.
>
> This patch adds error-handling code after calling try_module_get.
>
> Signed-off-by: Zhouyang Jia <jiazhouyang09@gmail.com>
> ---
> drivers/isdn/i4l/isdn_common.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/isdn/i4l/isdn_common.c b/drivers/isdn/i4l/isdn_common.c
> index 7c6f3f5..7e52851 100644
> --- a/drivers/isdn/i4l/isdn_common.c
> +++ b/drivers/isdn/i4l/isdn_common.c
> @@ -71,7 +71,8 @@ static int isdn_add_channels(isdn_driver_t *d, int drvidx, int n, int adding);
> static inline void
> isdn_lock_driver(isdn_driver_t *drv)
> {
> - try_module_get(drv->interface->owner);
> + if (!try_module_get(drv->interface->owner))
> + printk(KERN_WARNING "isdn_lock_driver: cannot get module\n");
Do you call this error handling code? :-)
And BTW we have pr_warn() for that.
> drv->locks++;
> }
>
MBR, Sergei
^ permalink raw reply
* [PATCH bpf] xsk: re-add queue id check for XDP_SKB path
From: Björn Töpel @ 2018-06-12 10:02 UTC (permalink / raw)
To: magnus.karlsson, magnus.karlsson, ast, daniel, netdev
Cc: Björn Töpel, qi.z.zhang
From: Björn Töpel <bjorn.topel@intel.com>
Commit 173d3adb6f43 ("xsk: add zero-copy support for Rx") introduced a
regression on the XDP_SKB receive path, when the queue id checks were
removed. Now, they are back again.
Fixes: 173d3adb6f43 ("xsk: add zero-copy support for Rx")
Reported-by: Qi Zhang <qi.z.zhang@intel.com>
Signed-off-by: Björn Töpel <bjorn.topel@intel.com>
---
net/xdp/xsk.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/net/xdp/xsk.c b/net/xdp/xsk.c
index 36919a254ba3..3b3410ada097 100644
--- a/net/xdp/xsk.c
+++ b/net/xdp/xsk.c
@@ -118,6 +118,9 @@ int xsk_generic_rcv(struct xdp_sock *xs, struct xdp_buff *xdp)
u64 addr;
int err;
+ if (xs->dev != xdp->rxq->dev || xs->queue_id != xdp->rxq->queue_index)
+ return -EINVAL;
+
if (!xskq_peek_addr(xs->umem->fq, &addr) ||
len > xs->umem->chunk_size_nohr) {
xs->rx_dropped++;
--
2.14.1
^ permalink raw reply related
* [PATCH 2/2] r8169: Reinstate ASPM Support
From: Kai-Heng Feng @ 2018-06-12 9:57 UTC (permalink / raw)
To: davem
Cc: ryankao, hayeswang, hau, hkallweit1, romieu, bhelgaas, netdev,
linux-pci, linux-kernel, Kai-Heng Feng
In-Reply-To: <20180612095759.6828-1-kai.heng.feng@canonical.com>
On newer Intel platforms, ASPM support in r8169 is the last missing
puzzle to let Package C-State achieves PC8. Without ASPM support, the
deepest Package C-State can hit is PC3.
PC8 can save additional ~3W in comparison with PC3 on my testing
platform.
The original patch is from Realtek.
Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
---
v2:
- Remove module parameter.
- Remove pci_disable_link_state().
drivers/net/ethernet/realtek/r8169.c | 41 +++++++++++++++++++---------
1 file changed, 28 insertions(+), 13 deletions(-)
diff --git a/drivers/net/ethernet/realtek/r8169.c b/drivers/net/ethernet/realtek/r8169.c
index 9b55ce513a36..85f4e746b040 100644
--- a/drivers/net/ethernet/realtek/r8169.c
+++ b/drivers/net/ethernet/realtek/r8169.c
@@ -5289,6 +5289,18 @@ static void rtl_pcie_state_l2l3_enable(struct rtl8169_private *tp, bool enable)
RTL_W8(tp, Config3, data);
}
+static void rtl_hw_internal_aspm_clkreq_enable(struct rtl8169_private *tp,
+ bool enable)
+{
+ if (enable) {
+ RTL_W8(tp, Config2, RTL_R8(tp, Config2) | ClkReqEn);
+ RTL_W8(tp, Config5, RTL_R8(tp, Config5) | ASPM_en);
+ } else {
+ RTL_W8(tp, Config2, RTL_R8(tp, Config2) & ~ClkReqEn);
+ RTL_W8(tp, Config5, RTL_R8(tp, Config5) & ~ASPM_en);
+ }
+}
+
static void rtl_hw_start_8168bb(struct rtl8169_private *tp)
{
RTL_W8(tp, Config3, RTL_R8(tp, Config3) & ~Beacon_en);
@@ -5645,9 +5657,9 @@ static void rtl_hw_start_8168g_1(struct rtl8169_private *tp)
rtl_hw_start_8168g(tp);
/* disable aspm and clock request before access ephy */
- RTL_W8(tp, Config2, RTL_R8(tp, Config2) & ~ClkReqEn);
- RTL_W8(tp, Config5, RTL_R8(tp, Config5) & ~ASPM_en);
+ rtl_hw_internal_aspm_clkreq_enable(tp, false);
rtl_ephy_init(tp, e_info_8168g_1, ARRAY_SIZE(e_info_8168g_1));
+ rtl_hw_internal_aspm_clkreq_enable(tp, true);
}
static void rtl_hw_start_8168g_2(struct rtl8169_private *tp)
@@ -5680,9 +5692,9 @@ static void rtl_hw_start_8411_2(struct rtl8169_private *tp)
rtl_hw_start_8168g(tp);
/* disable aspm and clock request before access ephy */
- RTL_W8(tp, Config2, RTL_R8(tp, Config2) & ~ClkReqEn);
- RTL_W8(tp, Config5, RTL_R8(tp, Config5) & ~ASPM_en);
+ rtl_hw_internal_aspm_clkreq_enable(tp, false);
rtl_ephy_init(tp, e_info_8411_2, ARRAY_SIZE(e_info_8411_2));
+ rtl_hw_internal_aspm_clkreq_enable(tp, true);
}
static void rtl_hw_start_8168h_1(struct rtl8169_private *tp)
@@ -5699,8 +5711,7 @@ static void rtl_hw_start_8168h_1(struct rtl8169_private *tp)
};
/* disable aspm and clock request before access ephy */
- RTL_W8(tp, Config2, RTL_R8(tp, Config2) & ~ClkReqEn);
- RTL_W8(tp, Config5, RTL_R8(tp, Config5) & ~ASPM_en);
+ rtl_hw_internal_aspm_clkreq_enable(tp, false);
rtl_ephy_init(tp, e_info_8168h_1, ARRAY_SIZE(e_info_8168h_1));
RTL_W32(tp, TxConfig, RTL_R32(tp, TxConfig) | TXCFG_AUTO_FIFO);
@@ -5779,6 +5790,8 @@ static void rtl_hw_start_8168h_1(struct rtl8169_private *tp)
r8168_mac_ocp_write(tp, 0xe63e, 0x0000);
r8168_mac_ocp_write(tp, 0xc094, 0x0000);
r8168_mac_ocp_write(tp, 0xc09e, 0x0000);
+
+ rtl_hw_internal_aspm_clkreq_enable(tp, true);
}
static void rtl_hw_start_8168ep(struct rtl8169_private *tp)
@@ -5830,11 +5843,12 @@ static void rtl_hw_start_8168ep_1(struct rtl8169_private *tp)
};
/* disable aspm and clock request before access ephy */
- RTL_W8(tp, Config2, RTL_R8(tp, Config2) & ~ClkReqEn);
- RTL_W8(tp, Config5, RTL_R8(tp, Config5) & ~ASPM_en);
+ rtl_hw_internal_aspm_clkreq_enable(tp, false);
rtl_ephy_init(tp, e_info_8168ep_1, ARRAY_SIZE(e_info_8168ep_1));
rtl_hw_start_8168ep(tp);
+
+ rtl_hw_internal_aspm_clkreq_enable(tp, true);
}
static void rtl_hw_start_8168ep_2(struct rtl8169_private *tp)
@@ -5846,14 +5860,15 @@ static void rtl_hw_start_8168ep_2(struct rtl8169_private *tp)
};
/* disable aspm and clock request before access ephy */
- RTL_W8(tp, Config2, RTL_R8(tp, Config2) & ~ClkReqEn);
- RTL_W8(tp, Config5, RTL_R8(tp, Config5) & ~ASPM_en);
+ rtl_hw_internal_aspm_clkreq_enable(tp, false);
rtl_ephy_init(tp, e_info_8168ep_2, ARRAY_SIZE(e_info_8168ep_2));
rtl_hw_start_8168ep(tp);
RTL_W8(tp, DLLPR, RTL_R8(tp, DLLPR) & ~PFM_EN);
RTL_W8(tp, MISC_1, RTL_R8(tp, MISC_1) & ~PFM_D3COLD_EN);
+
+ rtl_hw_internal_aspm_clkreq_enable(tp, true);
}
static void rtl_hw_start_8168ep_3(struct rtl8169_private *tp)
@@ -5867,8 +5882,7 @@ static void rtl_hw_start_8168ep_3(struct rtl8169_private *tp)
};
/* disable aspm and clock request before access ephy */
- RTL_W8(tp, Config2, RTL_R8(tp, Config2) & ~ClkReqEn);
- RTL_W8(tp, Config5, RTL_R8(tp, Config5) & ~ASPM_en);
+ rtl_hw_internal_aspm_clkreq_enable(tp, false);
rtl_ephy_init(tp, e_info_8168ep_3, ARRAY_SIZE(e_info_8168ep_3));
rtl_hw_start_8168ep(tp);
@@ -5888,6 +5902,8 @@ static void rtl_hw_start_8168ep_3(struct rtl8169_private *tp)
data = r8168_mac_ocp_read(tp, 0xe860);
data |= 0x0080;
r8168_mac_ocp_write(tp, 0xe860, data);
+
+ rtl_hw_internal_aspm_clkreq_enable(tp, true);
}
static void rtl_hw_start_8168(struct rtl8169_private *tp)
@@ -7646,7 +7662,6 @@ static int rtl_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
mii->reg_num_mask = 0x1f;
mii->supports_gmii = cfg->has_gmii;
-
/* enable device (incl. PCI PM wakeup and hotplug setup) */
rc = pcim_enable_device(pdev);
if (rc < 0) {
--
2.17.0
^ permalink raw reply related
* [PATCH 1/2] r8169: Don't disable ASPM in the driver
From: Kai-Heng Feng @ 2018-06-12 9:57 UTC (permalink / raw)
To: davem
Cc: ryankao, hayeswang, hau, hkallweit1, romieu, bhelgaas, netdev,
linux-pci, linux-kernel, Kai-Heng Feng
Enable or disable ASPM should be done in PCI core instead of in the
device driver.
Commit ba04c7c93bbc ("r8169: disable ASPM") uses
pci_disable_link_state() to disable ASPM. This is incorrect, if the
device really needs to disable ASPM, we should use a quirk in PCI core
to prevent the PCI core from setting ASPM altogether.
Let's remove pci_disable_link_state() for now. Use PCI core quirks if
any regression happens.
Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
---
v2:
- Remove module parameter.
- Remove pci_disable_link_state().
drivers/net/ethernet/realtek/r8169.c | 5 -----
1 file changed, 5 deletions(-)
diff --git a/drivers/net/ethernet/realtek/r8169.c b/drivers/net/ethernet/realtek/r8169.c
index 75dfac0248f4..9b55ce513a36 100644
--- a/drivers/net/ethernet/realtek/r8169.c
+++ b/drivers/net/ethernet/realtek/r8169.c
@@ -25,7 +25,6 @@
#include <linux/dma-mapping.h>
#include <linux/pm_runtime.h>
#include <linux/firmware.h>
-#include <linux/pci-aspm.h>
#include <linux/prefetch.h>
#include <linux/ipv6.h>
#include <net/ip6_checksum.h>
@@ -7647,10 +7646,6 @@ static int rtl_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
mii->reg_num_mask = 0x1f;
mii->supports_gmii = cfg->has_gmii;
- /* disable ASPM completely as that cause random device stop working
- * problems as well as full system hangs for some PCIe devices users */
- pci_disable_link_state(pdev, PCIE_LINK_STATE_L0S | PCIE_LINK_STATE_L1 |
- PCIE_LINK_STATE_CLKPM);
/* enable device (incl. PCI PM wakeup and hotplug setup) */
rc = pcim_enable_device(pdev);
--
2.17.0
^ permalink raw reply related
* Re: [PATCH net 2/3] hv_netvsc: fix network namespace issues with VF support
From: Dan Carpenter @ 2018-06-12 9:51 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: kys, haiyangz, sthemmin, devel, netdev
In-Reply-To: <20180611194456.8268-3-sthemmin@microsoft.com>
On Mon, Jun 11, 2018 at 12:44:55PM -0700, Stephen Hemminger wrote:
> When finding the parent netvsc device, the search needs to be across
> all netvsc device instances (independent of network namespace).
>
> Find parent device of VF using upper_dev_get routine which
> searches only adjacent list.
>
> Fixes: e8ff40d4bff1 ("hv_netvsc: improve VF device matching")
> Signed-off-by: Stephen Hemminger <sthemmin@microsoft.com>
>
> netns aware byref
What? Presumably that wasn't supposed to be part of the commit message.
> ---
regards,
dan carpenter
^ permalink raw reply
* Re: [RFC nf-next 0/5] netfilter: add ebpf translation infrastructure
From: Florian Westphal @ 2018-06-12 9:28 UTC (permalink / raw)
To: Alexei Starovoitov
Cc: Florian Westphal, netfilter-devel, ast, daniel, netdev,
David S. Miller, ecree
In-Reply-To: <20180611221257.qzip3iqh45kqqkpy@ast-mbp.dhcp.thefacebook.com>
Alexei Starovoitov <alexei.starovoitov@gmail.com> wrote:
> On Fri, Jun 01, 2018 at 05:32:11PM +0200, Florian Westphal wrote:
> > The userspace helper translates the rules, and, if successful, installs the
> > generated program(s) via bpf syscall.
> >
> > For each rule a small response containing the corresponding epbf file
> > descriptor (can be -1 on failure) and a attribute count (how many
> > expressions were jitted) gets sent back to kernel via pipe.
> >
> > If translation fails, the rule is will be processed by nf_tables
> > interpreter (as before this patch).
> >
> > If translation succeeded, nf_tables fetches the bpf program using the file
> > descriptor identifier, allocates a new rule blob containing the new 'ebpf'
> > expression (and possible trailing un-translated expressions).
> >
> > It then replaces the original rule in the transaction log with the new
> > 'ebpf-rule'. The original rule is retained in a private area inside the epbf
> > expression to be able to present the original expressions back to userspace
> > on 'nft list ruleset'.
> >
> > For easier review, this contains the kernel-side only.
> > nf_tables_jit_work() will not do anything, yet.
> >
> > Unresolved issues:
> > - maps and sets.
> > It might be possible to add a new ebpf map type that just wraps
> > the nft set infrastructure for lookups.
> > This would allow nft userspace to continue to work as-is while
> > not requiring new ebpf helper.
> > Anonymous set should be a lot easier as they're immutable
> > and could probably be handled already by existing infra.
> >
> > - BPF_PROG_RUN() is bolted into nft main loop via a middleman expression.
> > I'm also abusing skb->cb[] to pass network and transport header offsets.
> > Its not 'public' api so this can be changed later.
> >
> > - always uses BPF_PROG_TYPE_SCHED_CLS.
> > This is because it "works" for current RFC purposes.
> >
> > - we should eventually support translating multiple (adjacent) rules
> > into single program.
> >
> > If we do this kernel will need to track mapping of rules to
> > program (to re-jit when a rule is changed. This isn't implemented
> > so far, but can be added later. Alternatively, one could also add a
> > 'readonly' table switch to just prevent further updates.
> >
> > We will also need to dump the 'next' generation of the
> > to-be-translated table. The kernel has this information, so its only
> > a matter of serializing it back to userspace from the commit phase.
> >
> > The jitter is still limited. So far it supports:
> >
> > * payload expression for network and transport header
> > * meta mark, nfproto, l4proto
> > * 32 bit immediates
> > * 32 bit bitmask ops
> > * accept/drop verdicts
> >
> > As this uses netlink, there is also no technical requirement for
> > libnftnl, its simply used here for convienience.
> >
> > It doesn't need any userspace changes. Patches for libnftnl and nftables
> > make debug info available (e.g. to map rule to its bpf prog id).
> >
> > Comments welcome.
>
> The implementation of patch 5 looks good to me, but I'm concerned with
> patch 2 that adds 'ebpf expression' to nft. I see no reason to do so.
I think its important user(space) can see which rules are jitted, and
which ebpf prog corresponds to which rule(s), using an expression as
container allows to re-use existing nft config plane code to serialze
this via netlink attributes.
> It seems existing support for infinite number of nft expressions is
> used as a way to execute infinite number of bpf programs sequentially.
In this RFC, yes.
> I don't think it was a scalable approach before and won't scale in the future.
> I think the algorithm should consider all nft rules at once and generate
> a program or two that will execute fast even when number of rules is large.
Yes, but existence of the epbf expression doesn't prevent doing this in
the future. Doing it now complicates things and given unresolved issues
(see above cover letter) I'm reluctant to implement this already. The
UMH in this RFC can translate only a very small subset of
expressions. To make full-table realistic I think issues outlined above
need to be addressed first.
It can be done, in such case the epbf expression would replace not just
rule but possibly all of them.
Netlink dump of such a fully-translated table would have the epbf
expression at the beginning of the first rule, exposing epbf program id/tag,
and a list of the nft rule IDs that it replaced. In the extreme (ideal)
case, it would thus list all rule handle IDs of the chain (including
those reachable via jump-to-user-defined-chains).
Rest of dump would be as if ebpf did not exist, but these rules would
all be "dead" from packet-path point of view. They are linked from via
the nft epbf pseudo-expression, but no different from an arbitrary
cookie/comment.
As explained above, this also needs kernel to track mapping of
n nft rules to m ebpf progs, rather than the simple 1:1 mapping done
in this RFC.
The 1:1 mapping is not being set stone here, its just the inital
step to get the needed plumbing in, also see "Unresolved issues"
in cover letter above.
So:
Step 1: 1:1 mapping, an nft rule has at most one ebpf prog.
Step 2: figure out how to handle maps, sets, and how to cope with
not-yet-translateable expressions
Step 3: m:n mapping: kernel provides adjacent rules to the UMH for
jitting. Example: user appends rules a, b, c. UMH creates
single ebpf prog from a/b/c.
nft-pseudo-expression replaces a/b/c in the
packet path, original rules a/b/c are linked from the pseudo
expression for tracking. If user deletes rule b, we provide
a/c to UMH to create new epbf prog that replaces new
sequence a/c.
Step 4: always provide entire future base chain and all reachable chains
to the umh. Ideally all of it is replaced by single program.
Eventually, entire eval loop could be replaced by ebpf prog.
But it will need some time to get there -- at this point existing
nft expressions would no longer provide an ->eval() function.
Does that make sense to you?
If you see this as flawed, please let me know, but as I have no idea
how to resolve these issues going from 0 to 4 makes no sense to me.
> There are papers on scalable packet classification algorithms that
> use decision trees (hicuts, hypercuts, efficuts, etc)
> Imo that is the direction should we should be looking at.
Okay, but without any idea how to consider existing expressions,
sets, maps etc. I'm not sure it makes sense to work on that at this
point.
We also have the second problem that the netfilter base hook infra
(NF_HOOK) already imposes indirect calls on us.
Is there a plan to have a away to replace those indirect calls with
direct ones? We can't do that easily because most of the functions are
in modules, but AFAIU ebpf could rewrite that to a sequence of direct
calls.
[..]
> imo this way majority of iptables/nft rules can be converted and
> performance will be great even with large rulesets.
Oh, I do not doubt that multiple rules can be compiled into single program,
sorry if the RFC 1:1 mapping was confusing or gave that impression.
^ permalink raw reply
* Re: mainline: x86_64: kernel panic: RIP: 0010:__xfrm_policy_check+0xcb/0x690
From: Steffen Klassert @ 2018-06-12 8:34 UTC (permalink / raw)
To: Naresh Kamboju
Cc: netdev, David S. Miller, herbert,
open list:KERNEL SELFTEST FRAMEWORK, open list
In-Reply-To: <CA+G9fYuuiYES7ucAhgf8P-YXJPaYY2pi6kRKf6eBrfHvXJbQiw@mail.gmail.com>
On Mon, Jun 11, 2018 at 10:11:46PM +0530, Naresh Kamboju wrote:
> Kernel panic on x86_64 machine running mainline 4.17.0 kernel while testing
> selftests bpf test_tunnel.sh test caused this kernel panic.
> I have noticed this kernel panic start happening from
> 4.17.0-rc7-next-20180529 and still happening on 4.17.0-next-20180608.
>
> [ 213.638287] BUG: unable to handle kernel NULL pointer dereference
> at 0000000000000008
> ++[ ip xfrm poli 213.674036] PGD 0 P4D 0
> [ 213.674118] audit: type=1327 audit(1528917683.623:7):
> proctitle=6970007866726D00706F6C69637900616464007372630031302E312E312E3130302F3332006473740031302E312E312E3230302F33320064697200696E00746D706C00737263003137322E31362E312E31303000647374003137322E31362E312E3230300070726F746F006573700072657169640031006D6F64650074756E6E
> [ 213.677950] Oops: 0000 [#1] SMP PTI
> cy[ add src 10.1. 213.677952] CPU: 2 PID: 0 Comm: swapper/2 Tainted:
> G W 4.17.0-next-20180608 #1
> [ 213.677953] Hardware name: Supermicro SYS-5019S-ML/X11SSH-F, BIOS
> 2.0b 07/27/2017
> [ 213.726998] RIP: 0010:__xfrm_policy_check+0xcb/0x690
> [ 213.731962] Code: 80 3d 0a d8 f1 00 00 0f 84 c1 02 00 00 4c 8b 25
> 2b af f4 00 e8 66 a6 6a ff 85 c0 74 0d 80 3d eb d7 f1 00 00 0f 84 d5
> 02 00 00 <49> 8b 44 24 08 48 85 c0 74 0c 48 8d b5 78 ff ff ff 4c 89 ff
> ff d0
This looks like a bug that I've seen already. If it is what I think,
then commit 2c205dd3981f ("netfilter: add struct nf_nat_hook and use
it") introduced this bug.
There was already a fix for this on the netdev list, but
I don't know the current status of that patch:
https://patchwork.ozlabs.org/patch/921387/
^ permalink raw reply
* Re: BUG: 4.14.11 unable to handle kernel NULL pointer dereference in xfrm_lookup
From: Kristian Evensen @ 2018-06-12 8:29 UTC (permalink / raw)
To: Steffen Klassert; +Cc: Tobias Hommel, Markus Berner, Network Development
In-Reply-To: <20180612080355.g3z6fu4owubjbgzn@gauss3.secunet.de>
Hi,
On Tue, Jun 12, 2018 at 10:03 AM, Steffen Klassert
<steffen.klassert@secunet.com> wrote:
> I spent quite some time again yesterday in trying to find a
> case where dst_orig can be NULL in xfrm_lookup(). I don't see
> how this can happen, so I fear we need a bisection on this.
Thanks for spending time on this. I will see what I can manage in
terms of a bisect. Our last good kernel was 4.9, so at least it
narrows the scope down a bit compared to 4.4 or 4.1.
BR,
Kristian
^ permalink raw reply
* Re: [PATCH iproute2-next] ip-xfrm: Add support for OUTPUT_MARK
From: Steffen Klassert @ 2018-06-12 8:08 UTC (permalink / raw)
To: Lorenzo Colitti
Cc: Subash Abhinov Kasiviswanathan, netdev, Stephen Hemminger,
David Ahern
In-Reply-To: <CAKD1Yr0Z8ZgyE=b2MXtGOaJSRm0Y8spnU2pDxuWLd5FFgfx=eQ@mail.gmail.com>
On Tue, Jun 12, 2018 at 11:33:41AM +0900, Lorenzo Colitti wrote:
> On Tue, Jun 12, 2018 at 11:12 AM Subash Abhinov Kasiviswanathan
> <subashab@codeaurora.org> wrote:
> >
> > This patch adds support for OUTPUT_MARK in xfrm state to exercise the
> > functionality added by kernel commit 077fbac405bf
> > ("net: xfrm: support setting an output mark.").
> >
> > Sample output with output-mark -
> >
> > src 192.168.1.1 dst 192.168.1.2
> > proto esp spi 0x00004321 reqid 0 mode tunnel
> > replay-window 0 flag af-unspec
> > auth-trunc xcbc(aes) 0x3ed0af408cf5dcbf5d5d9a5fa806b211 96
> > enc cbc(aes) 0x3ed0af408cf5dcbf5d5d9a5fa806b233
> > anti-replay context: seq 0x0, oseq 0x0, bitmap 0x00000000
> > output-mark 0x20000
>
> Have you considered putting this earlier up in the output, where the
> mark is printed as well?
>
> > + if (tb[XFRMA_OUTPUT_MARK]) {
> > + __u32 output_mark = rta_getattr_u32(tb[XFRMA_OUTPUT_MARK]);
> > +
> > + fprintf(fp, "\toutput-mark 0x%x %s", output_mark, _SL_);
> > + }
> > }
>
> If you wanted to implement the suggestion above, I think you could do
> that by moving this code into xfrm_xfrma_print.
>
> Other than that, LGTM.
>
> Acked-by: Lorenzo Colitti <lorenzo@google.com>
>
> Steffen - what's the status of the set_mark patches? Are you holding
> them until the tree opens again?
Yes, I hold them back until after v4.18-rc1 is released and the
-next trees open again. But I plan to do a RFC version this week,
so that everybody knows about the plan we have.
^ permalink raw reply
* Re: BUG: 4.14.11 unable to handle kernel NULL pointer dereference in xfrm_lookup
From: Steffen Klassert @ 2018-06-12 8:03 UTC (permalink / raw)
To: Kristian Evensen; +Cc: Tobias Hommel, Markus Berner, Network Development
In-Reply-To: <CAKfDRXiq2c2ruvT8XoXGQntHYccAOp0zUZ3uH4iJM3cSAQkNVw@mail.gmail.com>
On Fri, Jun 08, 2018 at 10:41:37AM +0200, Kristian Evensen wrote:
> Hi,
>
> On Wed, Jun 6, 2018 at 6:03 PM, Tobias Hommel <netdev-list@genoetigt.de> wrote:
> > Sorry no progress until now, I currently do not get time to have a deeper look
> > into that. We're back to 4.1.6 right now.
>
> Thanks for letting me know. In the project I am currently involved in,
> we unfortunately don't have the option of reverting the kernel, so we
> are finding ways to live with the error. We have been looking into the
> error a bit more, and have made the following observations:
>
> * First of all, as discussed earlier in the thread, the error is
> triggered by dst_orig being NULL.
I spent quite some time again yesterday in trying to find a
case where dst_orig can be NULL in xfrm_lookup(). I don't see
how this can happen, so I fear we need a bisection on this.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox