* Re: [PATCH 06/18] x86, barrier: stop speculation for failed access_ok
From: David Miller @ 2018-01-08 2:04 UTC (permalink / raw)
To: tglx
Cc: James.Bottomley, w, gnomes, alexei.starovoitov, torvalds,
dan.j.williams, linux-kernel, linux-arch, ak, arnd, gregkh,
peterz, netdev, mingo, hpa
In-Reply-To: <alpine.DEB.2.20.1801071925090.2094@nanos>
From: Thomas Gleixner <tglx@linutronix.de>
Date: Sun, 7 Jan 2018 19:31:41 +0100 (CET)
> 2) Alexei's analyis is purely based on the public information of the google
> zero folks. If it would be complete and the only attack vector all fine.
>
> If not and I doubt it is, we're going to regret this decision faster
> than we made it and this is not the kind of play field where we can
> afford that.
Please state this more clearly.
Do you know about other attack vectors and just are not allowed to
talk about them?
Or is this, ironically, speculation?
^ permalink raw reply
* Re: [PATCH 06/18] x86, barrier: stop speculation for failed access_ok
From: Alexei Starovoitov @ 2018-01-08 2:09 UTC (permalink / raw)
To: Thomas Gleixner
Cc: Alan Cox, Linus Torvalds, Dan Williams, linux-kernel, linux-arch,
Andi Kleen, Arnd Bergmann, Greg Kroah-Hartman, Peter Zijlstra,
netdev, Ingo Molnar, H. Peter Anvin
In-Reply-To: <alpine.DEB.2.20.1801071107001.2606@nanos>
On Sun, Jan 07, 2018 at 11:08:24AM +0100, Thomas Gleixner wrote:
> On Sat, 6 Jan 2018, Alexei Starovoitov wrote:
> > which clearly states that bpf_tail_call() was used in the attack.
> > Yet none of the intel nor arm patches address speculation in
> > this bpf helper!
> > It means that:
> > - gpz didn't share neither exploit nor the detailed description
> > of the POC with cpu vendors until now
> > - coverity rules used to find all these places in the kernel
> > failed to find bpf_tail_call
> > - cpu vendors were speculating what variant 1 can actually do
>
> You forgot to mention that there might be other attacks than the public POC
> which are not covered by a simple AND ....
if above statement is not a pure speculation please share CVE number.
For varaint[123] they've been reserved for months.
> For spectre_v1/2 we face the same problem simply because we got informed so
> much ahead of time and we were all twiddling thumbs, enjoying our christmas
> vacation and having a good time.
right. they were informed in a way that they failed to address
variant1 with pre-embargo and public patches.
> The exploits are out in the wild and they are observed already, so we
this statement contradicts with everything that was publicly stated.
Or you're referring to 'exploit' at the end of spectre paper?
> want to discuss the right way to fix it for the next 3 month and leave all
> doors open until the last bit of performance is squeezed out.
Let's look at facts:
- Linus explains his array_access() idea
- lfence proponents quickly point out that it needs gcc to be smart
enough to emit setbe and go back to lfence patches
- I spent half an hour to tweak array_access() to be generic
on all archs and compiler indepedent
- lfence proponets point out that AND with a variable somehow
won't work, yet after further discussion it's actually fine due to
the nature of variant1 attack that needs to train predictor with in-bounds
access to mispredict with out-of-bounds speculative load
- then lfence proponets claim 'non public POC' not covered by AND
- it all in the matter of 2 days.
- and now the argument that it will take 3 month to discuss a solution
without lfence, yet still no performance numbers for lfence
though 'people in the know' were twiddling thumbs for months.
That's just not cool.
^ permalink raw reply
* Re: [PATCH 06/18] x86, barrier: stop speculation for failed access_ok
From: David Miller @ 2018-01-08 2:23 UTC (permalink / raw)
To: tglx
Cc: torvalds, w, alexei.starovoitov, gnomes, dan.j.williams,
linux-kernel, linux-arch, ak, arnd, gregkh, peterz, netdev, mingo,
hpa
In-Reply-To: <alpine.DEB.2.20.1801072143370.2094@nanos>
From: Thomas Gleixner <tglx@linutronix.de>
Date: Sun, 7 Jan 2018 21:56:39 +0100 (CET)
> I surely agree, but we have gone the way of PTI without the ability of
> exempting individual processes exactly for one reason:
>
> Lack of time
>
> It can be done on top of the PTI implementation and it won't take ages.
>
> For spectre_v1/2 we face the same problem simply because we got informed so
> much ahead of time and we were all twiddling thumbs, enjoying our christmas
> vacation and having a good time.
I just want to point out that this should be noted in history as a
case where all of this controlled disclosure stuff seems to have made
things worse rather than better.
Why is there so much haste and paranoia if supposedly some group of
people had all this extra time to think about and deal with this bug?
>From what I've seen, every single time, the worse a problem is, the
more important it is to expose it to as many smart folks as possible.
And to do so as fast as possible.
And to me that means full disclosure immediately for the super high
level stuff like what we are dealing with here.
Think I'm nuts? Ok, then how did we fare any better by keeping this
junk under wraps for weeks if not months? (seriously, did responsible
people really know about this as far back as... June 2017?)
Controlled disclosure for high propfile bugs seems to only achieve two
things:
1) Vendors can cover their butts and come up with deflection
strategies.
2) The "theatre" aspect of security can be maximized as much as
possible. We even have a pretty web site and cute avatars this
time!
None of this has anything to do with having time to come up with the
best possible implementation of a fix. You know, the technical part?
So after what appears to be as much as 6 months of deliberating the
very wise men in the special room said: "KPTI and lfence"
Do I get this right?
^ permalink raw reply
* Re: [PATCH 06/18] x86, barrier: stop speculation for failed access_ok
From: Alexei Starovoitov @ 2018-01-08 2:24 UTC (permalink / raw)
To: Dan Williams
Cc: Linus Torvalds, Willy Tarreau, Alan Cox,
Linux Kernel Mailing List, linux-arch, Andi Kleen, Arnd Bergmann,
Greg Kroah-Hartman, Peter Zijlstra, Network Development,
Ingo Molnar, H. Peter Anvin, Thomas Gleixner
In-Reply-To: <CAPcyv4gm0tAbLHHyMvsbghV+SpnbaTCmJd6N8imwUnRZ9k2xUA@mail.gmail.com>
On Sun, Jan 07, 2018 at 12:15:40PM -0800, Dan Williams wrote:
>
> I'm thinking we should provide the option to at least build the
> hot-path nospec_array_ptr() usages without an lfence.
>
> CONFIG_SPECTRE1_PARANOIA_SAFE
> CONFIG_SPECTRE1_PARANOIA_PERF
SAFE vs PERF naming is problematic and misleading, since users don't
have the data to make a decision they will be forced to go with SAFE.
What is not safe about array_access() macro with AND ?
How lfence approach makes it safer ?
Only because lfence was blessed by intel earlier when
they couldn't figure out a different way?
How about:
CONFIG_SPECTRE1_WORKAROUND_INDEX_MASK
CONFIG_SPECTRE1_WORKAROUND_LOAD_FENCE
> ...if only for easing performance testing and let the distribution set
> its policy.
>
> Where hot-path usages can do:
>
> nospec_relax(nospec_array_ptr())
AND approach doesn't prevent speculation hence nospec_ is an incorrect prefix.
Alan's "speculation management" terminology fits well here.
Can we keep array_access() name and change it underneath to
either mask or lfence ?
^ permalink raw reply
* Re: pull-request: bpf-next 2018-01-07
From: David Miller @ 2018-01-08 2:27 UTC (permalink / raw)
To: daniel; +Cc: ast, netdev
In-Reply-To: <20180107235616.20607-1-daniel@iogearbox.net>
From: Daniel Borkmann <daniel@iogearbox.net>
Date: Mon, 8 Jan 2018 00:56:16 +0100
> The following pull-request contains BPF updates for your *net-next* tree.
>
> The main changes are:
...
> Please consider pulling these changes from:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git
>
> Thanks a lot & a happy new year!
Looks great, pulled, thanks a lot Daniel!
^ permalink raw reply
* Re: [PATCH net-next 00/18] ipv6: Align nexthop behaviour with IPv4
From: David Miller @ 2018-01-08 2:30 UTC (permalink / raw)
To: idosch
Cc: netdev, dsahern, roopa, nicolas.dichtel, weiwan, kafai, yoshfuji,
mlxsw
In-Reply-To: <20180107104518.31693-1-idosch@mellanox.com>
From: Ido Schimmel <idosch@mellanox.com>
Date: Sun, 7 Jan 2018 12:45:00 +0200
> This set tries to eliminate some differences between IPv4's and IPv6's
> treatment of nexthops. These differences are most likely a side effect
> of IPv6's data structures (specifically 'rt6_info') that incorporate
> both the route and the nexthop and the late addition of ECMP support in
> commit 51ebd3181572 ("ipv6: add support of equal cost multipath
> (ECMP)").
...
> Finally, this series also serves as a good first step towards David
> Ahern's goal of treating nexthops as standalone objects [2], as it makes
> the code more in line with IPv4 where the nexthop and the nexthop group
> are separate objects from the route itself.
...
Looks great, series applied, thanks Ido!
^ permalink raw reply
* Re: [PATCH 06/18] x86, barrier: stop speculation for failed access_ok
From: Alexei Starovoitov @ 2018-01-08 2:57 UTC (permalink / raw)
To: Alan Cox
Cc: Linus Torvalds, Dan Williams, linux-kernel, linux-arch,
Andi Kleen, Arnd Bergmann, Greg Kroah-Hartman, Peter Zijlstra,
netdev, Ingo Molnar, H. Peter Anvin, Thomas Gleixner
In-Reply-To: <20180107135935.6ecfabd5@alans-desktop>
On Sun, Jan 07, 2018 at 01:59:35PM +0000, Alan Cox wrote:
> > which means that POC is relying 64-bit address speculation.
> > In the places coverity found the user supplied value is 32-bit,
>
> People have 32bit computers as well as 64bit and in some cases 32bit is
> fine for an attack depending where your target is relative to the object.
right. absolutely correct on 32-bit archs.
The question whether truncation to 32-bit is enough to workaround
spectre1 on 64-bit archs.
I hope the researchers can clarify.
> lfence timing is also heavily dependent upon what work has to be done to
> retire previous live instructions.
> BPF does not normally do a lot of writing so you'd expect the cost to be low.
right. to retire previous loads. Not sure what 'not a lot of writing'
has to do with lfence.
Our XDP based DDOS mostly does reads with few writes for stats into maps,
whereas XDP based load balancer modifies every packet.
XDP is root only, so not relevant in the spectre context. Just clarifying
read vs writes in BPF.
^ permalink raw reply
* Re: [RFC PATCH bpf-next v2 1/4] tracing/kprobe: bpf: Check error injectable event is on function entry
From: Alexei Starovoitov @ 2018-01-08 3:01 UTC (permalink / raw)
To: Masami Hiramatsu
Cc: Steven Rostedt, Alexei Starovoitov, Josef Bacik, mingo, davem,
netdev, linux-kernel, ast, kernel-team, daniel, linux-btrfs,
darrick.wong, Josef Bacik, Akinobu Mita
In-Reply-To: <20171229172022.8b184d85d3787bc7f8d1c45a@kernel.org>
On 12/29/17 12:20 AM, Masami Hiramatsu wrote:
>> Please run Josef's test in the !ftrace setup.
> Yes, I'll add the result of the test case.
if Josef's test is passing in !ftrace config,
please resend your patches.
I think 2 and 3 were nice simplifications.
and patch 1 is good too if it's passes the test.
Would be great to get them in for this merge window.
Thanks!
^ permalink raw reply
* Re: [net] Revert "net: core: maybe return -EEXIST in __dev_alloc_name"
From: Michael Ellerman @ 2018-01-08 3:26 UTC (permalink / raw)
To: David Miller
Cc: linux, michael, j, netdev, johannes, linuxppc-dev, johannes.berg
In-Reply-To: <20180102.115008.2038929402603091054.davem@davemloft.net>
David Miller <davem@davemloft.net> writes:
> From: Michael Ellerman <mpe@ellerman.id.au>
> Date: Fri, 22 Dec 2017 15:22:22 +1100
>
>>> On Tue, Dec 19 2017, Michael Ellerman <michael@concordia.ellerman.id.au> wrote:
>>>> This revert seems to have broken networking on one of my powerpc
>>>> machines, according to git bisect.
>>>>
>>>> The symptom is DHCP fails and I don't get a link, I didn't dig any
>>>> further than that. I can if it's helpful.
>>>>
>>>> I think the problem is that 87c320e51519 ("net: core: dev_get_valid_name
>>>> is now the same as dev_alloc_name_ns") only makes sense while
>>>> d6f295e9def0 remains in the tree.
>>>
>>> I'm sorry about all of this, I really didn't think there would be such
>>> consequences of changing an errno return. Indeed, d6f29 was preparation
>>> for unifying the two functions that do the exact same thing (and how we
>>> ever got into that situation is somewhat unclear), except for
>>> their behaviour in the case the requested name already exists. So one of
>>> the two interfaces had to change its return value, and as I wrote, I
>>> thought EEXIST was the saner choice when an explicit name (no %d) had
>>> been requested.
>>
>> No worries.
>>
>>>> ie. before the entire series, dev_get_valid_name() would return EEXIST,
>>>> and that was retained when 87c320e51519 was merged, but now that
>>>> d6f295e9def0 has been reverted dev_get_valid_name() is returning ENFILE.
>>>>
>>>> I can get the network up again if I also revert 87c320e51519 ("net:
>>>> core: dev_get_valid_name is now the same as dev_alloc_name_ns"), or with
>>>> the gross patch below.
>>>
>>> I don't think changing -ENFILE to -EEXIST would be right either, since
>>> dev_get_valid_name() used to be able to return both (-EEXIST in the case
>>> where there's no %d, -ENFILE in the case where we end up calling
>>> dev_alloc_name_ns()). If anything, we could do the check for the old
>>> -EEXIST condition first, and then call dev_alloc_name_ns(). But I'm also
>>> fine with reverting.
>>
>> Yeah I think a revert would be best, given it's nearly rc5.
>>
>> My userspace is not exotic AFAIK, just debian something, so presumably
>> this will affect other people too.
>
> I've just queued up the following revert, thanks!
Thanks.
I don't see it in rc7, will it get to Linus sometime before the release?
cheers
^ permalink raw reply
* [PATCH bpf-next] bpf: introduce BPF_JIT_ALWAYS_ON config
From: Alexei Starovoitov @ 2018-01-08 3:35 UTC (permalink / raw)
To: davem; +Cc: daniel, torvalds, jannh, alan, netdev, kernel-team
The BPF interpreter has been used as part of the spectre 2 attack CVE-2017-5715.
A quote from goolge project zero blog:
"At this point, it would normally be necessary to locate gadgets in
the host kernel code that can be used to actually leak data by reading
from an attacker-controlled location, shifting and masking the result
appropriately and then using the result of that as offset to an
attacker-controlled address for a load. But piecing gadgets together
and figuring out which ones work in a speculation context seems annoying.
So instead, we decided to use the eBPF interpreter, which is built into
the host kernel - while there is no legitimate way to invoke it from inside
a VM, the presence of the code in the host kernel's text section is sufficient
to make it usable for the attack, just like with ordinary ROP gadgets."
To make attacker job harder introduce BPF_JIT_ALWAYS_ON config
option that removes interpreter from the kernel in favor of JIT-only mode.
So far eBPF JIT is supported by:
x64, arm64, arm32, sparc64, s390, powerpc64, mips64
The start of JITed program is randomized and code page is marked as read-only.
In addition "constant blinding" can be turned on with net.core.bpf_jit_harden
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
---
init/Kconfig | 7 +++++++
kernel/bpf/core.c | 9 +++++++++
kernel/bpf/verifier.c | 4 ++++
net/core/sysctl_net_core.c | 9 +++++++++
4 files changed, 29 insertions(+)
diff --git a/init/Kconfig b/init/Kconfig
index 2934249fba46..5e2a4a391ba9 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -1392,6 +1392,13 @@ config BPF_SYSCALL
Enable the bpf() system call that allows to manipulate eBPF
programs and maps via file descriptors.
+config BPF_JIT_ALWAYS_ON
+ bool "Permanently enable BPF JIT and remove BPF interpreter"
+ depends on BPF_SYSCALL && HAVE_EBPF_JIT && BPF_JIT
+ help
+ Enables BPF JIT and removes BPF interpreter to avoid
+ speculative execution of BPF instructions by the interpreter
+
config USERFAULTFD
bool "Enable userfaultfd() system call"
select ANON_INODES
diff --git a/kernel/bpf/core.c b/kernel/bpf/core.c
index 70a534549cd3..42756c434e0b 100644
--- a/kernel/bpf/core.c
+++ b/kernel/bpf/core.c
@@ -781,6 +781,7 @@ noinline u64 __bpf_call_base(u64 r1, u64 r2, u64 r3, u64 r4, u64 r5)
}
EXPORT_SYMBOL_GPL(__bpf_call_base);
+#ifndef CONFIG_BPF_JIT_ALWAYS_ON
/**
* __bpf_prog_run - run eBPF program on a given context
* @ctx: is the data we are operating on
@@ -1376,6 +1377,7 @@ void bpf_patch_call_args(struct bpf_insn *insn, u32 stack_depth)
__bpf_call_base_args;
insn->code = BPF_JMP | BPF_CALL_ARGS;
}
+#endif
bool bpf_prog_array_compatible(struct bpf_array *array,
const struct bpf_prog *fp)
@@ -1427,9 +1429,11 @@ static int bpf_check_tail_call(const struct bpf_prog *fp)
*/
struct bpf_prog *bpf_prog_select_runtime(struct bpf_prog *fp, int *err)
{
+#ifndef CONFIG_BPF_JIT_ALWAYS_ON
u32 stack_depth = max_t(u32, fp->aux->stack_depth, 1);
fp->bpf_func = interpreters[(round_up(stack_depth, 32) / 32) - 1];
+#endif
/* eBPF JITs can rewrite the program in case constant
* blinding is active. However, in case of error during
@@ -1453,6 +1457,11 @@ struct bpf_prog *bpf_prog_select_runtime(struct bpf_prog *fp, int *err)
*/
*err = bpf_check_tail_call(fp);
+#ifdef CONFIG_BPF_JIT_ALWAYS_ON
+ if (!fp->jited)
+ *err = -ENOTSUPP;
+#endif
+
return fp;
}
EXPORT_SYMBOL_GPL(bpf_prog_select_runtime);
diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
index a2b211262c25..ca80559c4ec3 100644
--- a/kernel/bpf/verifier.c
+++ b/kernel/bpf/verifier.c
@@ -5267,7 +5267,11 @@ static int fixup_call_args(struct bpf_verifier_env *env)
depth = get_callee_stack_depth(env, insn, i);
if (depth < 0)
return depth;
+#ifdef CONFIG_BPF_JIT_ALWAYS_ON
+ return -ENOTSUPP;
+#else
bpf_patch_call_args(insn, depth);
+#endif
}
return 0;
}
diff --git a/net/core/sysctl_net_core.c b/net/core/sysctl_net_core.c
index cbc3dde4cfcc..1c8af0f4f385 100644
--- a/net/core/sysctl_net_core.c
+++ b/net/core/sysctl_net_core.c
@@ -325,7 +325,13 @@ static struct ctl_table net_core_table[] = {
.data = &bpf_jit_enable,
.maxlen = sizeof(int),
.mode = 0644,
+#ifndef CONFIG_BPF_JIT_ALWAYS_ON
.proc_handler = proc_dointvec
+#else
+ .proc_handler = proc_dointvec_minmax,
+ .extra1 = &one,
+ .extra2 = &one,
+#endif
},
# ifdef CONFIG_HAVE_EBPF_JIT
{
@@ -524,6 +530,9 @@ static __net_initdata struct pernet_operations sysctl_core_ops = {
static __init int sysctl_core_init(void)
{
+#if defined(CONFIG_BPF_JIT) && defined(CONFIG_BPF_JIT_ALWAYS_ON)
+ bpf_jit_enable = 1;
+#endif
register_net_sysctl(&init_net, "net/core", net_core_table);
return register_pernet_subsys(&sysctl_core_ops);
}
--
2.9.5
^ permalink raw reply related
* Re: Subject: [RFC][PATCH 10/11] dwc-xlgmac: fix big-endian breakage
From: Jie Deng @ 2018-01-08 3:35 UTC (permalink / raw)
To: Al Viro, netdev; +Cc: Jie.Deng1, Jose.Abreu
In-Reply-To: <E1eXXje-0002Eh-Jq@ZenIV.linux.org.uk>
On 2018/1/6 3:32, Al Viro wrote:
> Users of XLGMAC_SET_REG_BITS_LE() expect it to take le32 and return
> le32.
>
> Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
> ---
> drivers/net/ethernet/synopsys/dwc-xlgmac.h | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/net/ethernet/synopsys/dwc-xlgmac.h b/drivers/net/ethernet/synopsys/dwc-xlgmac.h
> index cab3e40a86b9..e95c4c250e16 100644
> --- a/drivers/net/ethernet/synopsys/dwc-xlgmac.h
> +++ b/drivers/net/ethernet/synopsys/dwc-xlgmac.h
> @@ -106,7 +106,7 @@
> #define XLGMAC_GET_REG_BITS_LE(var, pos, len) ({ \
> typeof(pos) _pos = (pos); \
> typeof(len) _len = (len); \
> - typeof(var) _var = le32_to_cpu((var)); \
> + u32 _var = le32_to_cpu((var)); \
> ((_var) & GENMASK(_pos + _len - 1, _pos)) >> (_pos); \
> })
>
> @@ -125,8 +125,8 @@
> typeof(len) _len = (len); \
> typeof(val) _val = (val); \
> _val = (_val << _pos) & GENMASK(_pos + _len - 1, _pos); \
> - _var = (_var & ~GENMASK(_pos + _len - 1, _pos)) | _val; \
> - cpu_to_le32(_var); \
> + (_var & ~cpu_to_le32(GENMASK(_pos + _len - 1, _pos))) | \
> + cpu_to_le32(_val); \
> })
>
> struct xlgmac_pdata;
Thanks for your patch.
Acked-by: Jie Deng <jiedeng@synopsys.com>
^ permalink raw reply
* Re: [PATCH net-next V2 2/2] tun: allow to attach ebpf socket filter
From: Jason Wang @ 2018-01-08 3:55 UTC (permalink / raw)
To: Willem de Bruijn
Cc: Network Development, LKML, Michael S. Tsirkin, Willem de Bruijn
In-Reply-To: <CAF=yD-JgA7+8si+0ayGMUrZtsSFv+PTRaNRbbzph-b6uEkWrpg@mail.gmail.com>
On 2018年01月06日 00:21, Willem de Bruijn wrote:
> On Fri, Jan 5, 2018 at 4:54 AM, Jason Wang <jasowang@redhat.com> wrote:
>> This patch allows userspace to attach eBPF filter to tun. This will
>> allow to implement VM dataplane filtering in a more efficient way
>> compared to cBPF filter by allowing either qemu or libvirt to
>> attach eBPF filter to tun.
>>
>> Signed-off-by: Jason Wang <jasowang@redhat.com>
>> ---
>> drivers/net/tun.c | 39 +++++++++++++++++++++++++++++++++++----
>> include/uapi/linux/if_tun.h | 1 +
>> 2 files changed, 36 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/net/tun.c b/drivers/net/tun.c
>> index 0853829..9fc8b70 100644
>> --- a/drivers/net/tun.c
>> +++ b/drivers/net/tun.c
>> @@ -238,6 +238,12 @@ struct tun_struct {
>> struct tun_pcpu_stats __percpu *pcpu_stats;
>> struct bpf_prog __rcu *xdp_prog;
>> struct tun_prog __rcu *steering_prog;
>> + struct tun_prog __rcu *filter_prog;
>> +};
>> +
>> +struct veth {
>> + __be16 h_vlan_proto;
>> + __be16 h_vlan_TCI;
>> };
>>
>> static int tun_napi_receive(struct napi_struct *napi, int budget)
>> @@ -984,12 +990,25 @@ static void tun_automq_xmit(struct tun_struct *tun, struct sk_buff *skb)
>> #endif
>> }
>>
>> +static unsigned int run_ebpf_filter(struct tun_struct *tun,
>> + struct sk_buff *skb,
>> + int len)
>> +{
>> + struct tun_prog *prog = rcu_dereference(tun->filter_prog);
>> +
>> + if (prog)
>> + len = bpf_prog_run_clear_cb(prog->prog, skb);
>> +
>> + return len;
>> +}
>> +
>> /* Net device start xmit */
>> static netdev_tx_t tun_net_xmit(struct sk_buff *skb, struct net_device *dev)
>> {
>> struct tun_struct *tun = netdev_priv(dev);
>> int txq = skb->queue_mapping;
>> struct tun_file *tfile;
>> + int len = skb->len;
>>
>> rcu_read_lock();
>> tfile = rcu_dereference(tun->tfiles[txq]);
>> @@ -1015,6 +1034,16 @@ static netdev_tx_t tun_net_xmit(struct sk_buff *skb, struct net_device *dev)
>> sk_filter(tfile->socket.sk, skb))
>> goto drop;
>>
>> + len = run_ebpf_filter(tun, skb, len);
>> +
>> + /* Trim extra bytes since we may inster vlan proto & TCI
> inster -> insert
Will fix.
>
>> + * in tun_put_user().
>> + */
>> + if (skb_vlan_tag_present(skb))
>> + len -= skb_vlan_tag_present(skb) ? sizeof(struct veth) : 0;
> no need for testing skb_vlan_tag_present twice.
Right.
> more importantly, why trim these bytes unconditionally?
>
> only if the filter trims a packet to a length shorter than the the minimum
> could this cause problems. sk_filter_trim_cap with a lower bound avoids
> that: skb_vlan_tag_present(skb) ? sizeof(struct vlan_ethhdr) : 0;
The problem is, if the filter want to trim to packet to 50 bytes, we may
get 54 bytes if vlan tag is existed. This seems wrong.
Thanks
^ permalink raw reply
* Re: [patch iproute2 v6 0/3] tc: Add -bs option to batch mode
From: David Ahern @ 2018-01-08 4:00 UTC (permalink / raw)
To: Chris Mi, Phil Sutter, marcelo.leitner@gmail.com
Cc: netdev@vger.kernel.org, gerlitz.or@gmail.com,
stephen@networkplumber.org
In-Reply-To: <VI1PR0501MB2143DEEBE30BA02E4ED129C0AB130@VI1PR0501MB2143.eurprd05.prod.outlook.com>
On 1/7/18 7:03 PM, Chris Mi wrote:
>> Did you measure the effect of increasing batch sizes?
> Yes. Even if we enlarge the batch size bigger than 10, there is no big improvement.
That will change over time so the tc command should allow auto-batching
to work up to the message size limit.
> I think that's because current kernel doesn't process the requests in parallel.
> If kernel processes the requests in parallel, I believe specifying a bigger batch size
> will get a better result.
>>
>> I wonder whether specifying the batch size is necessary at all. Couldn't batch
>> mode just collect messages until either EOF or an incompatible command is
>> encountered which then triggers a commit to kernel? This might simplify
>> code quite a bit.
> That's a good suggestion.
Thanks for your time on this, Chris.
^ permalink raw reply
* [PATCH] vhost: Remove the unused variable.
From: Tonghao Zhang @ 2018-01-08 5:13 UTC (permalink / raw)
To: jasowang, netdev; +Cc: Tonghao Zhang
The patch (7235acdb1) changed the way of the work
flushing in which the queued seq, done seq, and the
flushing are not used anymore. Then remove them now.
Fixes: 7235acdb1 ("vhost: simplify work flushing")
Cc: Jason Wang <jasowang@redhat.com>
Signed-off-by: Tonghao Zhang <xiangxia.m.yue@gmail.com>
---
drivers/vhost/vhost.c | 1 -
drivers/vhost/vhost.h | 4 ----
2 files changed, 5 deletions(-)
diff --git a/drivers/vhost/vhost.c b/drivers/vhost/vhost.c
index 33ac2b186b85..9b04cad91d65 100644
--- a/drivers/vhost/vhost.c
+++ b/drivers/vhost/vhost.c
@@ -181,7 +181,6 @@ void vhost_work_init(struct vhost_work *work, vhost_work_fn_t fn)
{
clear_bit(VHOST_WORK_QUEUED, &work->flags);
work->fn = fn;
- init_waitqueue_head(&work->done);
}
EXPORT_SYMBOL_GPL(vhost_work_init);
diff --git a/drivers/vhost/vhost.h b/drivers/vhost/vhost.h
index 79c6e7a60a5e..749fe13e061c 100644
--- a/drivers/vhost/vhost.h
+++ b/drivers/vhost/vhost.h
@@ -20,10 +20,6 @@ typedef void (*vhost_work_fn_t)(struct vhost_work *work);
struct vhost_work {
struct llist_node node;
vhost_work_fn_t fn;
- wait_queue_head_t done;
- int flushing;
- unsigned queue_seq;
- unsigned done_seq;
unsigned long flags;
};
--
2.13.6
^ permalink raw reply related
* Re: [PATCHv3 0/2] capability controlled user-namespaces
From: Serge E. Hallyn @ 2018-01-08 6:24 UTC (permalink / raw)
To: James Morris
Cc: Mahesh Bandewar (महेश बंडेवार),
LKML, Netdev, Kernel-hardening, Linux API, Kees Cook,
Serge Hallyn, Eric W . Biederman, Eric Dumazet, David Miller,
Mahesh Bandewar
In-Reply-To: <alpine.LFD.2.20.1801081131190.8436@localhost>
On Mon, Jan 08, 2018 at 11:35:26AM +1100, James Morris wrote:
> On Tue, 2 Jan 2018, Mahesh Bandewar (महेश बंडेवार) wrote:
>
> > On Sat, Dec 30, 2017 at 12:31 AM, James Morris
> > <james.l.morris@oracle.com> wrote:
> > > On Wed, 27 Dec 2017, Mahesh Bandewar (महेश बंडेवार) wrote:
> > >
> > >> Hello James,
> > >>
> > >> Seems like I missed your name to be added into the review of this
> > >> patch series. Would you be willing be pull this into the security
> > >> tree? Serge Hallyn has already ACKed it.
> > >
> > > Sure!
> > >
> > Thank you James.
>
> I'd like to see what Eric Biederman thinks of this.
>
> Also, why do we need the concept of a controlled user-ns at all, if the
> default whitelist maintains existing behavior?
In past discussions two uses have been brought up:
1. if an 0-day is discovered which is exacerbated by a specific
privilege in user namespaces, that privilege could be turned off until a
reboot with a fixed kernel is scheduled, without fully disabling all
containers.
2. some systems may be specifically designed to run software which
only requires a few capabilities in a userns. In that case all others
could be disabled.
^ permalink raw reply
* RE: WARNING: CPU: 0 PID: 0 at ./include/linux/netfilter.h:233 arp_rcv
From: Andy Duan @ 2018-01-08 6:32 UTC (permalink / raw)
To: Marco Franchi
Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
Fabio Estevam, Marco Antonio Franchi, fw@strlen.de,
pablo@netfilter.org
In-Reply-To: <CAM4PwSX2L-C_HfjbZ8KP6mWnkRnx=WAEgXTw=-mNUhmTcQqcDA@mail.gmail.com>
From: Marco Franchi <marcofrk@gmail.com> Sent: Friday, January 05, 2018 11:03 PM
>Hi,
>
>I am getting the following warning on a imx6ul-evk board running linux-next
>20180105:
>
>[ 9.233290] ------------[ cut here ]------------
>[ 9.242068] WARNING: CPU: 0 PID: 0 at
>./include/linux/netfilter.h:233 arp_rcv+0x1f8/0x228
>[ 9.250381] Modules linked in:
>[ 9.253633] CPU: 0 PID: 0 Comm: swapper/0 Not tainted
>4.15.0-rc6-next-20180104-dirty #2
>[ 9.261764] Hardware name: Freescale i.MX6 Ultralite (Device Tree)
>[ 9.268065] Backtrace:
>[ 9.270719] [<c010d188>] (dump_backtrace) from [<c010d448>]
>(show_stack+0x18/0x1c)
>[ 9.278438] r7:00000000 r6:60000153 r5:00000000 r4:c1079878
>[ 9.284258] [<c010d430>] (show_stack) from [<c0a32468>]
>(dump_stack+0xb4/0xe8)
>[ 9.291641] [<c0a323b4>] (dump_stack) from [<c01260ac>]
>(__warn+0xf0/0x11c)
>[ 9.298763] r9:d8053000 r8:000000e9 r7:00000009 r6:c0da3bdc
>r5:00000000 r4:00000000
>[ 9.306662] [<c0125fbc>] (__warn) from [<c01261f0>]
>(warn_slowpath_null+0x44/0x50)
>[ 9.314383] r8:d8053000 r7:00000608 r6:c08873f8 r5:000000e9 r4:c0da3bdc
>[ 9.321243] [<c01261ac>] (warn_slowpath_null) from [<c08873f8>]
>(arp_rcv+0x1f8/0x228)
>[ 9.329215] r6:c0887200 r5:c107ac58 r4:d899b240
>[ 9.333999] [<c0887200>] (arp_rcv) from [<c07fe680>]
>(__netif_receive_skb_core+0x878/0xbd4)
>[ 9.342491] r6:c0887200 r5:c100ac8c r4:d899b240
>[ 9.347265] [<c07fde08>] (__netif_receive_skb_core) from
>[<c0800fe0>] (__netif_receive_skb+0x2c/0x8c)
>[ 9.356643] r10:00000080 r9:d8053000 r8:e0a26000 r7:c107ab0d
>r6:c1008908 r5:d899b240
>[ 9.364598] r4:c10099c4
>[ 9.367288] [<c0800fb4>] (__netif_receive_skb) from [<c0804c00>]
>(netif_receive_skb_internal+0x7c/0x354)
>[ 9.376904] r5:d899b240 r4:c10099c4
>[ 9.380635] [<c0804b84>] (netif_receive_skb_internal) from
>[<c0805d5c>] (napi_gro_receive+0x88/0xa4)
>[ 9.389918] r8:e0a26000 r7:00000001 r6:d899b240 r5:d899b240 r4:00000003
>[ 9.396784] [<c0805cd4>] (napi_gro_receive) from [<c064609c>]
>(fec_enet_rx_napi+0x3a8/0x9b8)
>[ 9.405357] r5:d8054000 r4:00000000
>[ 9.409093] [<c0645cf4>] (fec_enet_rx_napi) from [<c080552c>]
>(net_rx_action+0x220/0x334)
>[ 9.417431] r10:dbbdfa00 r9:c1001d94 r8:00000040 r7:0000012c
>r6:ffff8e6b r5:00000001
>[ 9.425384] r4:d8053710
>[ 9.428075] [<c080530c>] (net_rx_action) from [<c01022d0>]
>(__do_softirq+0x128/0x2a0)
>[ 9.436063] r10:40000003 r9:c1003080 r8:00000100 r7:c100308c
>r6:c1000000 r5:00000003
>[ 9.444018] r4:00000000
>[ 9.446708] [<c01021a8>] (__do_softirq) from [<c012c16c>]
>(irq_exit+0x14c/0x1a8)
>[ 9.454262] r10:e080a000 r9:d8004400 r8:00000001 r7:00000000
>r6:c1008a98 r5:00000000
>[ 9.462218] r4:ffffe000
>[ 9.464911] [<c012c020>] (irq_exit) from [<c0180464>]
>(__handle_domain_irq+0x74/0xe8)
>[ 9.472879] r5:00000000 r4:c0f7cc24
>[ 9.476614] [<c01803f0>] (__handle_domain_irq) from [<c0467ebc>]
>(gic_handle_irq+0x64/0xc4)
>[ 9.485121] r9:c1028344 r8:c1001e98 r7:00000000 r6:000003ff
>r5:000003eb r4:e080a00c
>[ 9.493016] [<c0467e58>] (gic_handle_irq) from [<c01019f0>]
>(__irq_svc+0x70/0x98)
>[ 9.500632] Exception stack(0xc1001e98 to 0xc1001ee0)
>[ 9.505822] 1e80:
> 00000001 00000001
>[ 9.514157] 1ea0: 00000000 c100bf80 25963796 00000002 00000002
>dbbde5c8 26545294 00000002
>[ 9.522491] 1ec0: 00000000 c1001f14 c1001eb8 c1001ee8 c01724fc
>c0724464 20000153 ffffffff
>[ 9.530824] r10:00000000 r9:c1000000 r8:26545294 r7:c1001ecc
>r6:ffffffff r5:20000153
>[ 9.538778] r4:c0724464
>[ 9.541470] [<c07242f4>] (cpuidle_enter_state) from [<c0724630>]
>(cpuidle_enter+0x1c/0x20)
>[ 9.549893] r10:c100f6a8 r9:dbbde5c8 r8:c0f7c5c0 r7:c1008978
>r6:00000001 r5:c100892c
>[ 9.557857] r4:c1000000 r3:dbbde5c8
>[ 9.561589] [<c0724614>] (cpuidle_enter) from [<c0169dd4>]
>(call_cpuidle+0x28/0x44)
>[ 9.569399] [<c0169dac>] (call_cpuidle) from [<c016a0bc>]
>(do_idle+0x1bc/0x230)
>[ 9.576861] [<c0169f00>] (do_idle) from [<c016a4e0>]
>(cpu_startup_entry+0x20/0x24)
>[ 9.584587] r10:c0f63a50 r9:c1008908 r8:c107b480 r7:c1008900
>r6:c107b480 r5:00000002
>[ 9.592546] r4:000000c4 r3:c0f75354
>[ 9.596283] [<c016a4c0>] (cpu_startup_entry) from [<c0a47720>]
>(rest_init+0x210/0x25c)
>[ 9.604372] [<c0a47510>] (rest_init) from [<c0f00d60>]
>(start_kernel+0x390/0x418)
>[ 9.611998] r5:ffffffff r4:c107b4cc
>[ 9.615723] [<c0f009d0>] (start_kernel) from [<00000000>] ( (null))
>[ 9.622235] r10:10c5387d r9:410fc075 r8:83000000 r7:00000000
>r6:10c0387d r5:00000051
>[ 9.630191] r4:c0f0032c
>[ 9.632851] ---[ end trace 2d5d5f79c0c8da59 ]---
>
>Does anyone know how to fix it?
>
>Thanks
If you enable kernel config "CONFIG_NETFILTER_FAMILY_ARP" can fix the warning.
It is introduced by below commit.
commit 8de98f058360722a1a9febe3970de6dcd4d91513
Author: Florian Westphal <fw@strlen.de>
Date: Thu Dec 7 16:28:26 2017 +0100
netfilter: don't allocate space for arp/bridge hooks unless needed
no need to define hook points if the family isn't supported.
Because we need these hooks for either nftables, arp/ebtables
or the 'call-iptables' hack we have in the bridge layer add two
new dependencies, NETFILTER_FAMILY_{ARP,BRIDGE}, and have the
users select them.
Signed-off-by: Florian Westphal <fw@strlen.de>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
diff --git a/include/linux/netfilter.h b/include/linux/netfilter.h
index ce4e91df..0e46cb4 100644
--- a/include/linux/netfilter.h
+++ b/include/linux/netfilter.h
@@ -213,12 +213,16 @@ static inline int nf_hook(u_int8_t pf, unsigned int hook, struct net *net,
case NFPROTO_IPV6:
hook_head = rcu_dereference(net->nf.hooks_ipv6[hook]);
break;
+#ifdef CONFIG_NETFILTER_FAMILY_ARP
case NFPROTO_ARP:
hook_head = rcu_dereference(net->nf.hooks_arp[hook]);
break;
+#endif
+#ifdef CONFIG_NETFILTER_FAMILY_BRIDGE
case NFPROTO_BRIDGE:
hook_head = rcu_dereference(net->nf.hooks_bridge[hook]);
break;
+#endif
#if IS_ENABLED(CONFIG_DECNET)
case NFPROTO_DECNET:
hook_head = rcu_dereference(net->nf.hooks_decnet[hook]);
^ permalink raw reply related
* [PATCH] docs-rst: networking: wire up msg_zerocopy
From: Mike Rapoport @ 2018-01-08 6:50 UTC (permalink / raw)
To: linux-doc
Cc: Jonathan Corbet, Mauro Carvalho Chehab, Willem de Bruijn, netdev,
Mike Rapoport
Fix the following 'make htmldocs' complaint:
Documentation/networking/msg_zerocopy.rst:: WARNING: document isn't included in any toctree.
Signed-off-by: Mike Rapoport <rppt@linux.vnet.ibm.com>
---
Documentation/networking/index.rst | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/networking/index.rst b/Documentation/networking/index.rst
index 66e620866245..7d4b15977d61 100644
--- a/Documentation/networking/index.rst
+++ b/Documentation/networking/index.rst
@@ -9,6 +9,7 @@ Contents:
batman-adv
kapi
z8530book
+ msg_zerocopy
.. only:: subproject
@@ -16,4 +17,3 @@ Contents:
=======
* :ref:`genindex`
-
--
2.7.4
^ permalink raw reply related
* Re: [PATCH] atm/clip: Use seq_puts() in svc_addr()
From: SF Markus Elfring @ 2018-01-08 7:25 UTC (permalink / raw)
To: Andy Shevchenko, netdev
Cc: Bhumika Goyal, David S. Miller, David Windsor, Elena Reshetova,
Hans Liljestrand, Johannes Berg, Kees Cook, Roopa Prabhu, LKML,
kernel-janitors
In-Reply-To: <CAHp75Vf-fNi-ATKd-EpkO3HDP2TZCWFc6EEU5a5r-zkZTcHQYg@mail.gmail.com>
>> @@ -708,11 +708,11 @@ static void svc_addr(struct seq_file *seq, struct sockaddr_atmsvc *addr)
>> static int e164[] = { 1, 8, 4, 6, 1, 0 };
>>
>> if (*addr->sas_addr.pub) {
>> - seq_printf(seq, "%s", addr->sas_addr.pub);
>> + seq_puts(seq, addr->sas_addr.pub);
>
> Which opens a lot of security concerns.
How? - The passed string is just copied into a buffer finally, isn't it?
> Never do this again.
Why do you not like such a small source code transformation at the moment?
> P.S. I'm wondering what would be first,
I am curious on how communication difficulties can be adjusted.
> Markus starts looking into the actual code,
I inspected the original source code to some degree.
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/fs/seq_file.c?id=895c0dde398510a5b5ded60e5064c11b94bd30ca#n682
https://elixir.free-electrons.com/linux/v4.15-rc6/source/fs/seq_file.c#L660
> or most (all) of the maintainers just ban him.
The change acceptance is varying for various reasons by the involved contributors.
Regards,
Markus
^ permalink raw reply
* Re: [PATCH net-next] l2tp: adjust comments about L2TPv3 offsets
From: James Chapman @ 2018-01-08 7:32 UTC (permalink / raw)
To: Guillaume Nault, netdev; +Cc: lorenzo.bianconi, liuhangbin
In-Reply-To: <c9187ce29d43767acb9ba50b17b72c75992a63f7.1515177994.git.g.nault@alphalink.fr>
On 05/01/18 18:47, Guillaume Nault wrote:
> The "offset" option has been removed by
> commit 900631ee6a26 ("l2tp: remove configurable payload offset").
>
> Signed-off-by: Guillaume Nault <g.nault@alphalink.fr>
> ---
> include/uapi/linux/l2tp.h | 2 +-
> net/l2tp/l2tp_core.c | 7 +++----
> 2 files changed, 4 insertions(+), 5 deletions(-)
>
> diff --git a/include/uapi/linux/l2tp.h b/include/uapi/linux/l2tp.h
> index f78eef4cc56a..71e62795104d 100644
> --- a/include/uapi/linux/l2tp.h
> +++ b/include/uapi/linux/l2tp.h
> @@ -65,7 +65,7 @@ struct sockaddr_l2tpip6 {
> * TUNNEL_MODIFY - CONN_ID, udpcsum
> * TUNNEL_GETSTATS - CONN_ID, (stats)
> * TUNNEL_GET - CONN_ID, (...)
> - * SESSION_CREATE - SESSION_ID, PW_TYPE, offset, data_seq, cookie, peer_cookie, offset, l2spec
> + * SESSION_CREATE - SESSION_ID, PW_TYPE, data_seq, cookie, peer_cookie, l2spec
> * SESSION_DELETE - SESSION_ID
> * SESSION_MODIFY - SESSION_ID, data_seq
> * SESSION_GET - SESSION_ID, (...)
> diff --git a/net/l2tp/l2tp_core.c b/net/l2tp/l2tp_core.c
> index 786cd7f6a5e8..62285fc6eb59 100644
> --- a/net/l2tp/l2tp_core.c
> +++ b/net/l2tp/l2tp_core.c
> @@ -662,10 +662,9 @@ static int l2tp_recv_data_seq(struct l2tp_session *session, struct sk_buff *skb)
> * |x|S|x|x|x|x|x|x| Sequence Number |
> * +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> *
> - * Cookie value, sublayer format and offset (pad) are negotiated with
> - * the peer when the session is set up. Unlike L2TPv2, we do not need
> - * to parse the packet header to determine if optional fields are
> - * present.
> + * Cookie value and sublayer format are negotiated with the peer when
> + * the session is set up. Unlike L2TPv2, we do not need to parse the
> + * packet header to determine if optional fields are present.
> *
> * Caller must already have parsed the frame and determined that it is
> * a data (not control) frame before coming here. Fields up to the
Acked-by: James Chapman <jchapman@katalix.com>
^ permalink raw reply
* Re: [PATCH 06/18] x86, barrier: stop speculation for failed access_ok
From: Greg KH @ 2018-01-08 7:38 UTC (permalink / raw)
To: David Miller
Cc: tglx, torvalds, w, alexei.starovoitov, gnomes, dan.j.williams,
linux-kernel, linux-arch, ak, arnd, peterz, netdev, mingo, hpa
In-Reply-To: <20180107.212347.315015145942081238.davem@davemloft.net>
On Sun, Jan 07, 2018 at 09:23:47PM -0500, David Miller wrote:
> From: Thomas Gleixner <tglx@linutronix.de>
> Date: Sun, 7 Jan 2018 21:56:39 +0100 (CET)
>
> > I surely agree, but we have gone the way of PTI without the ability of
> > exempting individual processes exactly for one reason:
> >
> > Lack of time
> >
> > It can be done on top of the PTI implementation and it won't take ages.
> >
> > For spectre_v1/2 we face the same problem simply because we got informed so
> > much ahead of time and we were all twiddling thumbs, enjoying our christmas
> > vacation and having a good time.
>
> I just want to point out that this should be noted in history as a
> case where all of this controlled disclosure stuff seems to have made
> things worse rather than better.
I will note that the "controlled disclosure" for this thing was a total
and complete mess, and unlike any that I have ever seen in the past.
The people involved in running it had no idea how to do it at all, and
because of that, it failed miserably, despite being warned about it
numerous times by numerous people.
> Why is there so much haste and paranoia if supposedly some group of
> people had all this extra time to think about and deal with this bug?
Because that group was so small and isolated that they did not actually
talk to anyone who could actually provide input to help deal with the
bug.
So we are stuck now with dealing with this "properly", which is fine,
but please don't think that this is an excuse to blame "controlled
disclosure". We know how to do that correctly, it did not happen in
this case at all because of the people driving the problem refused to do
it.
> Think I'm nuts? Ok, then how did we fare any better by keeping this
> junk under wraps for weeks if not months? (seriously, did responsible
> people really know about this as far back as... June 2017?)
Some "people" did, just not some "responsible people" :)
Oh well, time for the kernel to fix hardware bugs again, that's what we
are here for, you would think we would be used to it by now...
greg k-h
^ permalink raw reply
* RE: [patch iproute2 v6 0/3] tc: Add -bs option to batch mode
From: Chris Mi @ 2018-01-08 8:00 UTC (permalink / raw)
To: David Ahern, Phil Sutter, marcelo.leitner@gmail.com
Cc: netdev@vger.kernel.org, gerlitz.or@gmail.com,
stephen@networkplumber.org
In-Reply-To: <0cbfcbf5-0b54-f810-1891-b0d34fe97c6d@gmail.com>
> >> I wonder whether specifying the batch size is necessary at all.
> >> Couldn't batch mode just collect messages until either EOF or an
> >> incompatible command is encountered which then triggers a commit to
> >> kernel? This might simplify code quite a bit.
> > That's a good suggestion.
>
> Thanks for your time on this, Chris.
After testing, I find that the message passed to kernel should not be too big.
If it is bigger than about 64K, sendmsg returns -1, errno is 90 (EMSGSIZE).
That is about 400 commands. So how about set batch size to 128 which is big enough?
^ permalink raw reply
* RE: [PATCH net] of_mdio: avoid MDIO bus removal when a PHY is missing
From: Madalin-cristian Bucur @ 2018-01-08 8:48 UTC (permalink / raw)
To: Andrew Lunn
Cc: f.fainelli@gmail.com, davem@davemloft.net,
geert+renesas@glider.be, robh+dt@kernel.org,
frowand.list@gmail.com, netdev@vger.kernel.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <20180105151235.GD4038@lunn.ch>
> -----Original Message-----
> From: Andrew Lunn [mailto:andrew@lunn.ch]
> Sent: Friday, January 05, 2018 5:13 PM
> To: Madalin-cristian Bucur <madalin.bucur@nxp.com>
> Subject: Re: [PATCH net] of_mdio: avoid MDIO bus removal when a PHY is
> missing
>
> On Fri, Jan 05, 2018 at 11:36:14AM +0200, Madalin Bucur wrote:
> > If one of the child devices is missing the of_mdiobus_register_phy()
> > call will return -ENODEV. When a missing device is encountered the
> > registration of the remaining PHYs is stopped and the MDIO bus will
> > fail to register. Propagate all errors except ENODEV to avoid it.
>
> Hi Madalin
>
> This is is not clear cut. If the PHY is in device tree, the PHY should
> exist. So returning ENODEV is justified. The device tree blob is
> broken. But i can also see the value for continuing. There is a chance
> some of your other interfaces come up, allowing you to get the correct
> device tree blob for the hardware.
>
> Please add
>
> dev_err(&mdio->dev, "MDIO device at address %d is missing.\n");
>
> Andrew
This appears on boards that include in the device tree the description
for the PHYs found on an optional riser card. When the riser card is
removed, this issue is triggered. I'll send a v2 with the dev_err()
included.
Thanks,
Madalin
^ permalink raw reply
* Re: BUG: 4.14.11 unable to handle kernel NULL pointer dereference in xfrm_lookup
From: Tobias Hommel @ 2018-01-08 8:57 UTC (permalink / raw)
To: Ozgur; +Cc: netdev@vger.kernel.org
In-Reply-To: <20180105215424.cknsmwhnzfh5rfad@delI>
On Fri, Jan 05, 2018 at 09:55:23PM +0000, Tobias Hommel wrote:
> On Sat, Jan 06, 2018 at 12:27:11AM +0300, Ozgur wrote:
> >
> >
> > 06.01.2018, 00:20, "Tobias Hommel" <netdev-list@genoetigt.de>:
> > > Hi,
> >
> > Hi Tobias,
> >
> > > I'm running into a NULL pointer dereference after updating from Linux 4.1.6 to
> > > 4.14.11 (see kernel log below). I tried 4.14.3 initially which did not work
> > > either.
> > > Anyone has an idea what is happening here?
> > >
> > > The affected machine has 2 active ethernet interfaces (igb driver) and acts as
> > > a VPN gateway running strongswan. There are several hundreds of IPSec
> > > roadwarriors connecting to eth1. eth0 connects to an infrastructure running an
> > > HTTP server.
> > > During my tests these roadwarriors connect to the gateway, sometimes download a
> > > large file from the HTTP server, disconnect and after a random delay repeat
> > > these steps.
> > >
> > > Some observations I made:
> > > * SMP Affinity for IRQs of the NICs Rx/Tx queues (/proc/irq/$IRQ/smp_affinity)
> > > * all affinities set to default ff is broken
> > > * setting affinity for all queues of both interfaces to the same CPU seems to
> > > work fine (running stable for more than 1 day now)
> > > * setting affinity of eth0 queues to CPU 1 and affinity of eth1 queues to CPU
> > > 2 is broken and seems to always trigger the bug on CPU 1
> > > * the top 6 entries of the call trace are the same every time the system
> > > crashes, the other entries differ sometimes
> > >
> > > The bug is 100% reproducible on the Intel Atom machine from the log below and
> > > also on a HP ProLiant Gen6 (also igb driver).
> > > I can, of course, provide further information (CPU, NIC, kernel config, more
> > > traces, etc.) if required.
> > > If helpful I could also run tests on HP ProLiant Gen9 which has different NICs
> > > (tg3).
> > >
> > > [ 7998.489094] BUG: unable to handle kernel NULL pointer dereference at 0000000000000020
> > > [ 7998.496993] IP: xfrm_lookup+0x2a/0x7e0
> > > [ 7998.500759] PGD 0 P4D 0
> > > [ 7998.503316] Oops: 0000 [#1] SMP PTI
> > > [ 7998.506835] Modules linked in:
> > > [ 7998.509929] CPU: 2 PID: 22 Comm: ksoftirqd/2 Not tainted 4.14.11 #3
> > > [ 7998.516244] Hardware name: To be filled by O.E.M. CAR-2051/CAR, BIOS 1.01 07/11/2016
> > > [ 7998.524039] task: ffff8826bb118000 task.stack: ffff947ac00f0000
> > > [ 7998.530004] RIP: 0010:xfrm_lookup+0x2a/0x7e0
> > > [ 7998.534298] RSP: 0018:ffff947ac00f3b60 EFLAGS: 00010246
> > > [ 7998.539550] RAX: 0000000000000000 RBX: ffffffff93074040 RCX: 0000000000000000
> > > [ 7998.546709] RDX: ffff947ac00f3bd8 RSI: 0000000000000000 RDI: ffffffff93074040
> > > [ 7998.553868] RBP: ffffffff93074040 R08: 0000000000000002 R09: 0000000000000001
> > > [ 7998.561026] R10: 0000000000000032 R11: 0000000000000000 R12: ffff947ac00f3bd8
> > > [ 7998.568212] R13: 0000000000000000 R14: 0000000000000002 R15: ffff8826b69a8078
> > > [ 7998.575395] FS: 0000000000000000(0000) GS:ffff8826bfc80000(0000) knlGS:0000000000000000
> > > [ 7998.583550] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> > > [ 7998.589324] CR2: 0000000000000020 CR3: 00000001781da000 CR4: 00000000001006e0
> > > [ 7998.596482] Call Trace:
> > > [ 7998.598959] __xfrm_route_forward+0xa4/0x110
> > > [ 7998.603263] ip_forward+0x3e0/0x450
> > > [ 7998.606778] ? ip_rcv_finish+0x61/0x3a0
> > > [ 7998.610645] ip_rcv+0x2c4/0x390
> > > [ 7998.613818] ? inet_del_offload+0x30/0x30
> > > [ 7998.617857] __netif_receive_skb_core+0x751/0xb00
> > > [ 7998.622562] ? skb_send_sock+0x40/0x40
> > > [ 7998.626356] ? netif_receive_skb_internal+0x47/0xf0
> > > [ 7998.631252] netif_receive_skb_internal+0x47/0xf0
> > > [ 7998.635987] napi_gro_receive+0x70/0x90
> > > [ 7998.639835] gro_cell_poll+0x53/0x90
> > > [ 7998.643439] net_rx_action+0x1fc/0x310
> > > [ 7998.647210] ? rebalance_domains+0x101/0x2b0
> > > [ 7998.651500] __do_softirq+0xd5/0x1cf
> > > [ 7998.655105] run_ksoftirqd+0x14/0x30
> > > [ 7998.658712] smpboot_thread_fn+0xf9/0x150
> > > [ 7998.662723] kthread+0xef/0x130
> > > [ 7998.665893] ? sort_range+0x20/0x20
> > > [ 7998.669404] ? kthread_park+0x60/0x60
> > > [ 7998.673098] ret_from_fork+0x1f/0x30
> > > [ 7998.676674] Code: 00 41 57 41 56 45 89 c6 41 55 41 54 49 89 f5 55 53 49 89 d4 48 89 fb 48 83 ec 40 65 48 8b 04 25 28 00 00 00 48 89 44 24 38 31 c0 <48> 8b 46 20 48 85 c9 44 0f b7 38 c7 44 24 0c 00 00 00 00 0f 84
> > > [ 7998.695681] RIP: xfrm_lookup+0x2a/0x7e0 RSP: ffff947ac00f3b60
> > > [ 7998.701479] CR2: 0000000000000020
> > > [ 7998.704799] ---[ end trace 0544b1946919baad ]---
> > > [ 7998.709442] Kernel panic - not syncing: Fatal exception in interrupt
> > > [ 7998.715918] Kernel Offset: 0x11000000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff)
> >
> >
> > this error doesn't look like the last version kernel, I think this problem NIC driver.
> > What is the use network ethernet card model?
> This is what lspci shows for both NICs:
> # lspci -nns 00:14.0
> 00:14.0 Ethernet controller [0200]: Intel Corporation Ethernet Connection I354 [8086:1f41] (rev 03)
>
> I have currently no access to the other hardware where this is happening but I
> could get further information after the weekend.
This is the NIC model on the other machine:
0a:00.0 Ethernet controller [0200]: Intel Corporation 82576 Gigabit Network Connection [8086:10c9] (rev 01)
>
> > And which driver version you use?
> # ethtool -i eth0 # same for eth1
> driver: igb
> version: 5.4.0-k
> firmware-version: 0.0.0
> expansion-rom-version:
> bus-info: 0000:00:14.0
> supports-statistics: yes
> supports-test: yes
> supports-eeprom-access: yes
> supports-register-dump: yes
> supports-priv-flags: yes
>
Btw, this is the driver shipping with Linux 4.14.11.
> >
> > > Best regards,
> > >
> > > Tobias Hommel
> >
> > Ozgur
^ permalink raw reply
* RE: [RFC -next 2/2] net: sched: red: don't reset the backlog on every stat dump
From: Nogah Frankel @ 2018-01-08 9:18 UTC (permalink / raw)
To: Jakub Kicinski, john.fastabend@gmail.com, jiri@resnulli.us,
xiyou.wangcong@gmail.com, Yuval Mintz
Cc: netdev@vger.kernel.org, oss-drivers@netronome.com,
edumazet@google.com
In-Reply-To: <20180104201851.6455-3-jakub.kicinski@netronome.com>
> -----Original Message-----
> From: Jakub Kicinski [mailto:jakub.kicinski@netronome.com]
> Sent: Thursday, January 04, 2018 10:19 PM
> To: john.fastabend@gmail.com; jiri@resnulli.us; xiyou.wangcong@gmail.com;
> Nogah Frankel <nogahf@mellanox.com>; Yuval Mintz
> <yuvalm@mellanox.com>
> Cc: netdev@vger.kernel.org; oss-drivers@netronome.com;
> edumazet@google.com; Jakub Kicinski <jakub.kicinski@netronome.com>
> Subject: [RFC -next 2/2] net: sched: red: don't reset the backlog on every stat
> dump
>
> Commit 0dfb33a0d7e2 ("sch_red: report backlog information") copied
> child's backlog into RED's backlog. Back then RED did not maintain
> its own backlog counts. This has changed after commit 2ccccf5fb43f
> ("net_sched: update hierarchical backlog too") and commit d7f4f332f082
> ("sch_red: update backlog as well"). Copying is no longer necessary.
>
> Tested:
>
> $ tc -s qdisc show dev veth0
> qdisc red 1: root refcnt 2 limit 400000b min 30000b max 30000b ecn
> Sent 20942 bytes 221 pkt (dropped 0, overlimits 0 requeues 0)
> backlog 1260b 14p requeues 14
> marked 0 early 0 pdrop 0 other 0
> qdisc tbf 2: parent 1: rate 1Kbit burst 15000b lat 3585.0s
> Sent 20942 bytes 221 pkt (dropped 0, overlimits 138 requeues 0)
> backlog 1260b 14p requeues 14
>
> Recently RED offload was added. We need to make sure drivers don't
> depend on resetting the stats. This means backlog should be treated
> like any other statistic:
>
> total_stat = new_hw_stat - prev_hw_stat;
>
> Unlike for other statistics new_hw_stat < prev_hw_stat can be true.
> Adjust mlxsw.
There is one problem with this patch, and that is that we can fail in
changing RED that is offloaded. In this case, we delete RED from the driver
but the backlog will still include the hardware backlog.
The solution is to send in the offload-replace command a pointer to the
backlog, so failure in updating the hardware can be follow by backlog update,
if needed.
Thanks
Nogah
>
> Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com>
> ---
> drivers/net/ethernet/mellanox/mlxsw/spectrum.h | 1 +
> drivers/net/ethernet/mellanox/mlxsw/spectrum_qdisc.c | 9 +++++++--
> net/sched/sch_red.c | 1 -
> 3 files changed, 8 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/net/ethernet/mellanox/mlxsw/spectrum.h
> b/drivers/net/ethernet/mellanox/mlxsw/spectrum.h
> index ff8d32bc852c..6755050e4ee0 100644
> --- a/drivers/net/ethernet/mellanox/mlxsw/spectrum.h
> +++ b/drivers/net/ethernet/mellanox/mlxsw/spectrum.h
> @@ -237,6 +237,7 @@ struct mlxsw_sp_qdisc {
> u64 tx_packets;
> u64 drops;
> u64 overlimits;
> + u64 backlog;
> };
>
> /* No need an internal lock; At worse - miss a single periodic iteration */
> diff --git a/drivers/net/ethernet/mellanox/mlxsw/spectrum_qdisc.c
> b/drivers/net/ethernet/mellanox/mlxsw/spectrum_qdisc.c
> index c33beac5def0..d5091740bd40 100644
> --- a/drivers/net/ethernet/mellanox/mlxsw/spectrum_qdisc.c
> +++ b/drivers/net/ethernet/mellanox/mlxsw/spectrum_qdisc.c
> @@ -212,6 +212,7 @@ mlxsw_sp_qdisc_get_red_stats(struct mlxsw_sp_port
> *mlxsw_sp_port, u32 handle,
> u64 tx_bytes, tx_packets, overlimits, drops;
> struct mlxsw_sp_port_xstats *xstats;
> struct rtnl_link_stats64 *stats;
> + s64 backlog;
>
> if (mlxsw_sp_qdisc->handle != handle ||
> mlxsw_sp_qdisc->type != MLXSW_SP_QDISC_RED)
> @@ -226,17 +227,21 @@ mlxsw_sp_qdisc_get_red_stats(struct
> mlxsw_sp_port *mlxsw_sp_port, u32 handle,
> mlxsw_sp_qdisc->overlimits;
> drops = xstats->wred_drop[tclass_num] + xstats-
> >tail_drop[tclass_num] -
> mlxsw_sp_qdisc->drops;
> + backlog = mlxsw_sp_cells_bytes(mlxsw_sp_port->mlxsw_sp,
> + xstats->backlog[tclass_num]) -
> + mlxsw_sp_qdisc->backlog;
>
> _bstats_update(res->bstats, tx_bytes, tx_packets);
> res->qstats->overlimits += overlimits;
> res->qstats->drops += drops;
> - res->qstats->backlog += mlxsw_sp_cells_bytes(mlxsw_sp_port-
> >mlxsw_sp,
> - xstats->backlog[tclass_num]);
> + res->qstats->backlog += backlog;
>
> mlxsw_sp_qdisc->drops += drops;
> mlxsw_sp_qdisc->overlimits += overlimits;
> mlxsw_sp_qdisc->tx_bytes += tx_bytes;
> mlxsw_sp_qdisc->tx_packets += tx_packets;
> + mlxsw_sp_qdisc->backlog += backlog;
> +
> return 0;
> }
>
> diff --git a/net/sched/sch_red.c b/net/sched/sch_red.c
> index a392eaa4a0b4..caebb7e37551 100644
> --- a/net/sched/sch_red.c
> +++ b/net/sched/sch_red.c
> @@ -322,7 +322,6 @@ static int red_dump(struct Qdisc *sch, struct sk_buff
> *skb)
> };
> int err;
>
> - sch->qstats.backlog = q->qdisc->qstats.backlog;
> err = red_dump_offload_stats(sch, &opt);
> if (err)
> goto nla_put_failure;
> --
> 2.15.1
^ permalink raw reply
* BUG: 4.15.0-rc6 unable to handle kernel NULL pointer dereference in ixgbe_down
From: wangyunjian @ 2018-01-08 9:31 UTC (permalink / raw)
To: netdev@vger.kernel.org, intel-wired-lan@lists.osuosl.org
Hi,
I'm running into a NULL pointer dereference in ixgbe_down on b84449dc14d274a3f3c78cd734b702ca31aa4dd1
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/master.
I think the variable adapter->vfinfo has not been protected well, when disable sriov and down nic.
Anyone has an idea to protect it?
Test script 1:
while true
do
ifconfig eth3 up
ifconfig eth3 down
done
Test script 2:
while true
do
echo 63 > /sys/class/net/eth3/device/sriov_numvfs
echo 0 > /sys/class/net/eth3/device/sriov_numvfs
done
2018-01-08T16:27:33.786608+08:00|alert|kernel[-]|[ 906.719083] BUG: unable to handle kernel NULL pointer dereference at 000000000000004c
2018-01-08T16:27:33.786642+08:00|alert|kernel[-]|[ 906.727054] IP: ixgbe_down+0x481/0x490 [ixgbe]
2018-01-08T16:27:33.786663+08:00|info|kernel[-]|[ 906.731569] PGD 0 P4D 0
2018-01-08T16:27:33.786687+08:00|warning|kernel[-]|[ 906.734180] Oops: 0002 [#1] SMP PTI
2018-01-08T16:27:33.787249+08:00|warning|kernel[-]|[ 906.829962] CPU: 12 PID: 28819 Comm: ifconfig Tainted: G OE 4.15.0-rc6+ #4
2018-01-08T16:27:33.787270+08:00|warning|kernel[-]|[ 906.838074] Hardware name: Huawei Technologies Co., Ltd. Tecal XH620 /BC21THSA , BIOS TTSAV020 12/02/2011
2018-01-08T16:27:33.787294+08:00|warning|kernel[-]|[ 906.849738] RIP: 0010:ixgbe_down+0x481/0x490 [ixgbe]
2018-01-08T16:27:33.787315+08:00|warning|kernel[-]|[ 906.854773] RSP: 0018:ffffc9002757fcb0 EFLAGS: 00010246
2018-01-08T16:27:33.787336+08:00|warning|kernel[-]|[ 906.860068] RAX: 0000000000000000 RBX: ffff881ffa2208c0 RCX: 0000000000000000
2018-01-08T16:27:33.787356+08:00|warning|kernel[-]|[ 906.867268] RDX: 0000000000000000 RSI: ffff880fffb96938 RDI: ffff880fffb96938
2018-01-08T16:27:33.787377+08:00|warning|kernel[-]|[ 906.874466] RBP: 0000000000000001 R08: 0000000000000000 R09: 000000000000046e
2018-01-08T16:27:33.787398+08:00|warning|kernel[-]|[ 906.881667] R10: 0000000000000003 R11: 0000000000000000 R12: ffff881ffa221900
2018-01-08T16:27:33.787418+08:00|warning|kernel[-]|[ 906.888867] R13: ffff881ffa221178 R14: 0000000000000040 R15: ffff881fe5934f40
2018-01-08T16:27:33.787439+08:00|warning|kernel[-]|[ 906.896069] FS: 00007f3cadc66740(0000) GS:ffff880fffb80000(0000) knlGS:0000000000000000
2018-01-08T16:27:33.787464+08:00|warning|kernel[-]|[ 906.904275] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
2018-01-08T16:27:33.787488+08:00|warning|kernel[-]|[ 906.910093] CR2: 000000000000004c CR3: 0000000fff260005 CR4: 00000000000206e0
2018-01-08T16:27:33.787508+08:00|warning|kernel[-]|[ 906.917293] Call Trace:
2018-01-08T16:27:33.787528+08:00|warning|kernel[-]|[ 906.919824] ixgbe_close_suspend+0x5c/0x60 [ixgbe]
2018-01-08T16:27:33.787549+08:00|warning|kernel[-]|[ 906.924690] ixgbe_close+0x2d/0xc0 [ixgbe]
2018-01-08T16:27:33.787570+08:00|warning|kernel[-]|[ 906.928862] __dev_close_many+0x9e/0x100
2018-01-08T16:27:33.787593+08:00|warning|kernel[-]|[ 906.932859] __dev_change_flags+0xda/0x1e0
2018-01-08T16:27:33.787614+08:00|warning|kernel[-]|[ 906.937029] dev_change_flags+0x23/0x60
2018-01-08T16:27:33.787636+08:00|warning|kernel[-]|[ 906.940943] devinet_ioctl+0x670/0x740
2018-01-08T16:27:33.787659+08:00|warning|kernel[-]|[ 906.944771] sock_do_ioctl+0x20/0x50
2018-01-08T16:27:33.787680+08:00|warning|kernel[-]|[ 906.948420] sock_ioctl+0x1e4/0x2c0
2018-01-08T16:27:33.787699+08:00|warning|kernel[-]|[ 906.951987] do_vfs_ioctl+0xa6/0x5f0
2018-01-08T16:27:33.787719+08:00|warning|kernel[-]|[ 906.955641] ? __do_page_fault+0x273/0x4d0
2018-01-08T16:27:33.787740+08:00|warning|kernel[-]|[ 906.959812] SyS_ioctl+0x74/0x80
2018-01-08T16:27:33.787759+08:00|warning|kernel[-]|[ 906.963117] ? do_page_fault+0x33/0x120
2018-01-08T16:27:33.787780+08:00|warning|kernel[-]|[ 906.967033] entry_SYSCALL_64_fastpath+0x1a/0x7d
2018-01-08T16:27:33.787805+08:00|warning|kernel[-]|[ 906.971725] RIP: 0033:0x7f3cad784507
2018-01-08T16:27:33.787825+08:00|warning|kernel[-]|[ 906.975374] RSP: 002b:00007fff54fdbe98 EFLAGS: 00000206
2018-01-08T16:27:33.787846+08:00|warning|kernel[-]|[ 906.975376] Code: b2 e0 bf 10 27 00 00 e8 2e 6a b4 e0 48 c7 c7 a4 89 5e a0 31 c0 e8 70 d5 b2 e0 48 63 c5 83 c5 01 48 6b c0 60 48 03 83 70 a0 01 00 <c6> 40 4c 00 e9 e3 fd ff ff 66 0f 1f 44 00 00 66 66 66 66 90 55
2018-01-08T16:27:33.787867+08:00|alert|kernel[-]|[ 906.999682] RIP: ixgbe_down+0x481/0x490 [ixgbe] RSP: ffffc9002757fcb0
2018-01-08T16:27:33.787889+08:00|warning|kernel[-]|[ 907.006188] CR2: 000000000000004c
2018-01-08T16:27:33.787911+08:00|warning|kernel[-]|[ 907.009595] ---[ end trace 4a410621e06f2d79 ]---
^ 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