* Re: [PATCH net-next] rhashtable: remove insecure_max_entries param
From: David Miller @ 2017-04-26 18:39 UTC (permalink / raw)
To: fw; +Cc: netdev
In-Reply-To: <20170425094134.21885-1-fw@strlen.de>
From: Florian Westphal <fw@strlen.de>
Date: Tue, 25 Apr 2017 11:41:34 +0200
> no users in the tree, insecure_max_entries is always set to
> ht->p.max_size * 2 in rhtashtable_init().
>
> Replace only spot that uses it with a ht->p.max_size check.
>
> Signed-off-by: Florian Westphal <fw@strlen.de>
Applied, thanks Florian.
^ permalink raw reply
* Re: [RFC PATCH] netxen_nic: null-terminate serial number string in netxen_check_options()
From: David Miller @ 2017-04-26 18:38 UTC (permalink / raw)
To: jmarchan
Cc: manish.chopra, rahul.verma, Dept-GELinuxNICDev, netdev,
linux-kernel
In-Reply-To: <20170425074229.28267-1-jmarchan@redhat.com>
From: "Jerome Marchand" <jmarchan@redhat.com>
Date: Tue, 25 Apr 2017 09:42:29 +0200
> The serial_num string in netxen_check_options() is not always properly
> null-terminated. I couldn't find the documention on the serial number
> format and I suspect a proper integer to string conversion is in
> order, but this patch a least prevents the out-of-bound access.
>
> It solves the following kasan warning:
...
> @@ -842,7 +842,7 @@ netxen_check_options(struct netxen_adapter *adapter)
> {
> u32 fw_major, fw_minor, fw_build, prev_fw_version;
> char brd_name[NETXEN_MAX_SHORT_NAME];
> - char serial_num[32];
> + char serial_num[33];
> int i, offset, val, err;
> __le32 *ptr32;
> struct pci_dev *pdev = adapter->pdev;
Another problem is that the serial_num array is only 4-byte aligned by
accident. Steps are necessary to make sure the ptr32 assignments don't
take unaligned traps.
Something like:
union {
char buf[33];
__le32 dummy;
} serial_num;
^ permalink raw reply
* [PATCH v2 net-next] ip6_tunnel: Fix missing tunnel encapsulation limit option
From: Craig Gallek @ 2017-04-26 18:37 UTC (permalink / raw)
To: Hideaki YOSHIFUJI, Alexey Kuznetsov, David S . Miller; +Cc: netdev
In-Reply-To: <20170426170707.165201-1-kraigatgoog@gmail.com>
From: Craig Gallek <cgallek@google.com>
The IPv6 tunneling code tries to insert IPV6_TLV_TNL_ENCAP_LIMIT and
IPV6_TLV_PADN options when an encapsulation limit is defined (the
default is a limit of 4). An MTU adjustment is done to account for
these options as well. However, the options are never present in the
generated packets.
The issue appears to be a subtlety between IPV6_DSTOPTS and
IPV6_RTHDRDSTOPTS defined in RFC 3542. When the IPIP tunnel driver was
written, the encap limit options were included as IPV6_RTHDRDSTOPTS in
dst0opt of struct ipv6_txoptions. Later, ipv6_push_nfrags_opts was
(correctly) updated to require IPV6_RTHDR options when IPV6_RTHDRDSTOPTS
are to be used. This caused the options to no longer be included in v6
encapsulated packets.
The fix is to use IPV6_DSTOPTS (in dst1opt of struct ipv6_txoptions)
instead. IPV6_DSTOPTS do not have the additional IPV6_RTHDR requirement.
Fixes: 1df64a8569c7: ("[IPV6]: Add ip6ip6 tunnel driver.")
Fixes: 333fad5364d6: ("[IPV6]: Support several new sockopt / ancillary data in Advanced API (RFC3542)")
Signed-off-by: Craig Gallek <kraig@google.com>
---
v2: Change tunnel code to use dst1opt rather than making the checks for
dst0opt more permissive.
net/ipv6/ip6_tunnel.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/ipv6/ip6_tunnel.c b/net/ipv6/ip6_tunnel.c
index ad15d38b41e8..c81f9541f1f7 100644
--- a/net/ipv6/ip6_tunnel.c
+++ b/net/ipv6/ip6_tunnel.c
@@ -954,7 +954,7 @@ static void init_tel_txopt(struct ipv6_tel_txoption *opt, __u8 encap_limit)
opt->dst_opt[5] = IPV6_TLV_PADN;
opt->dst_opt[6] = 1;
- opt->ops.dst0opt = (struct ipv6_opt_hdr *) opt->dst_opt;
+ opt->ops.dst1opt = (struct ipv6_opt_hdr *) opt->dst_opt;
opt->ops.opt_nflen = 8;
}
@@ -1176,7 +1176,7 @@ int ip6_tnl_xmit(struct sk_buff *skb, struct net_device *dev, __u8 dsfield,
if (encap_limit >= 0) {
init_tel_txopt(&opt, encap_limit);
- ipv6_push_nfrag_opts(skb, &opt.ops, &proto, NULL, NULL);
+ ipv6_push_frag_opts(skb, &opt.ops, &proto);
}
/* Calculate max headroom for all the headers and adjust
--
2.13.0.rc0.306.g87b477812d-goog
^ permalink raw reply related
* GSO + changing TX queues == crash?
From: Jakub Kicinski @ 2017-04-26 18:35 UTC (permalink / raw)
To: netdev@vger.kernel.org; +Cc: Eric Dumazet
Hi!
I'm seeing crashes with GSO on when changing the number of TX rings. I
initially thought it was a nfp driver problem but I managed to
reproduce it with i40e now.
What I run on the nfp was iperf sending two dozen streams. Then I run
this little script while 40Gbps is being sent:
bl() {
tc -s qdisc show dev p4p1 | \
tail -$((MAX_TX*3)) | \
grep backlog | \
grep -v "backlog 0b"
}
while true
do
ethtool -L p4p1 tx 0
a=$(bl | wc -l)
echo down $a
# there are 8 combined queues, we shouldn't see more backlog
[ $a -gt 8 ] && break
sleep 2
ethtool -L p4p1 tx 10
echo up $(bl | wc -l)
sleep 2
done
The idea is to catch when after reconfig more queues have backlog than
are configured. Right after this script exits driver gets traffic on
queues which are down. It usually reproduces within a minute, I run it
with tso on gso off and tso off gso off for 15 minutes and that didn't
crash.
i40e machine was running kernel 4.10, with the NFP driver I'm able to
reproduce on net-next all the way back to 3.16 (I haven't tried older).
FWIW the nfp driver is doing:
netif_carrier_off()
for enabled rings:
disable_irq()
napi_disable()
netif_tx_disable()
nfp's free_tx_bufs()
netif_set_real_num_tx_queues()
for enabled rings:
napi_enable()
enable_irq()
netif_tx_wake_all_queues()
nfp's read_link() # does netif_carrier_on()
I was entirely convinced that it's a driver problem, but the fact I
crashed the i40e made me worry :|
This is a crash from i40e, it takes a bit longer to kill it than the
nfp, maybe because it takes longer to reconfig:
[ 461.822381] BUG: unable to handle kernel NULL pointer dereference at 0000000000000008
[ 461.831229] IP: i40e_lan_xmit_frame+0xf1/0x1420 [i40e]
[ 461.837045] PGD 0
[ 461.837046]
[ 461.841089] Oops: 0002 [#1] SMP
[ 461.844665] Modules linked in: xfs nls_iso8859_1 ipmi_devintf ipt_MASQUERADE nf_nat_masquerade_ipv4 iptable_nat nf_nat_ipv4 nf_nat nf_conntrack_ipv4 nf_defrag_ipv4 xtc
[ 461.924168] fscache tg3 i40e ptp ahci pps_core libahci fjes
[ 461.930595] CPU: 15 PID: 0 Comm: swapper/15 Not tainted 4.11.0-041100rc1-generic #201703051731
[ 461.940340] Hardware name: Dell Inc. PowerEdge R730/072T6D, BIOS 2.3.4 11/08/2016
[ 461.948823] task: ffffa087db2b0000 task.stack: ffffb9b903350000
[ 461.955546] RIP: 0010:i40e_lan_xmit_frame+0xf1/0x1420 [i40e]
[ 461.961965] RSP: 0018:ffffa087df1c3d80 EFLAGS: 00010293
[ 461.967899] RAX: 0000000000000000 RBX: ffffa087c3077d00 RCX: 0000000000000000
[ 461.975971] RDX: 0000000000000000 RSI: 0000000000000007 RDI: ffffa087b4e1d70c
[ 461.984044] RBP: ffffa087df1c3e20 R08: ffffa087d440349c R09: 0000000000000000
[ 461.992117] R10: ffffa087de821a08 R11: 0000000000000000 R12: ffffa087b7c60000
[ 462.000188] R13: 0000000000000002 R14: 00000000000005ea R15: ffffa087d97b3000
[ 462.008261] FS: 0000000000000000(0000) GS:ffffa087df1c0000(0000) knlGS:0000000000000000
[ 462.017423] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 462.023941] CR2: 0000000000000008 CR3: 00000006efe09000 CR4: 00000000003406e0
[ 462.032014] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 462.040083] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[ 462.048154] Call Trace:
[ 462.050969] <IRQ>
[ 462.053311] ? update_load_avg+0x79/0x520
[ 462.057876] ? sched_clock_cpu+0x11/0xb0
[ 462.062356] dev_hard_start_xmit+0xa3/0x1f0
[ 462.067127] sch_direct_xmit+0xfc/0x1c0
[ 462.071509] __qdisc_run+0x122/0x270
[ 462.075598] net_tx_action+0xfd/0x1e0
[ 462.079786] __do_softirq+0x104/0x2af
[ 462.083973] irq_exit+0xb6/0xc0
[ 462.087577] smp_apic_timer_interrupt+0x3d/0x50
[ 462.092732] apic_timer_interrupt+0x89/0x90
[ 462.097501] RIP: 0010:cpuidle_enter_state+0x122/0x2c0
[ 462.103240] RSP: 0018:ffffb9b903353e58 EFLAGS: 00000246 ORIG_RAX: ffffffffffffff10
[ 462.111818] RAX: 0000000000000000 RBX: 0000000000000004 RCX: 000000000000001f
[ 462.119890] RDX: 0000006b86c1bdc1 RSI: ffffa087df1d8998 RDI: 0000000000000000
[ 462.127962] RBP: ffffb9b903353e98 R08: 0000000000084c3f R09: 0000000000000018
[ 462.136032] R10: 00000000000310a2 R11: 0000000000055e38 R12: ffffa087df1e5800
[ 462.144094] R13: ffffffffb86ec998 R14: 0000000000000004 R15: ffffffffb86ec980
[ 462.152165] </IRQ>
[ 462.154601] ? cpuidle_enter_state+0x110/0x2c0
[ 462.159662] cpuidle_enter+0x17/0x20
[ 462.163748] call_cpuidle+0x23/0x40
[ 462.167740] do_idle+0x189/0x200
[ 462.171438] cpu_startup_entry+0x71/0x80
[ 462.175908] start_secondary+0x154/0x190
[ 462.180384] start_cpu+0x14/0x14
[ 462.184080] Code: 8d 75 05 66 39 c8 0f 86 e4 04 00 00 01 d0 0f b7 d1 29 d0 83 e8 01 39 c6 0f 8f ed 05 00 00 49 8b 44 24 20 48 8d 14 89 4c 8d 1c d0 <49> 89 5b 08 8b 83
[ 462.205347] RIP: i40e_lan_xmit_frame+0xf1/0x1420 [i40e] RSP: ffffa087df1c3d80
[ 462.213418] CR2: 0000000000000008
[ 462.217226] ---[ end trace 0ee2eefbe09283a8 ]---
[ 462.272123] Kernel panic - not syncing: Fatal exception in interrupt
[ 462.279393] Kernel Offset: 0x36800000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff)
[ 462.345422] ---[ end Kernel panic - not syncing: Fatal exception in interrupt
^ permalink raw reply
* Re: [PATCH v1] net: phy: fix auto-negotiation stall due to unavailable interrupt
From: David Miller @ 2017-04-26 18:36 UTC (permalink / raw)
To: al.kochet
Cc: f.fainelli, netdev, linux-kernel, sergei.shtylyov, rogerq,
madalin.bucur
In-Reply-To: <1492686004-30527-2-git-send-email-al.kochet@gmail.com>
From: Alexander Kochetkov <al.kochet@gmail.com>
Date: Thu, 20 Apr 2017 14:00:04 +0300
> The Ethernet link on an interrupt driven PHY was not coming up if the Ethernet
> cable was plugged before the Ethernet interface was brought up.
>
> The patch trigger PHY state machine to update link state if PHY was requested to
> do auto-negotiation and auto-negotiation complete flag already set.
>
> During power-up cycle the PHY do auto-negotiation, generate interrupt and set
> auto-negotiation complete flag. Interrupt is handled by PHY state machine but
> doesn't update link state because PHY is in PHY_READY state. After some time
> MAC bring up, start and request PHY to do auto-negotiation. If there are no new
> settings to advertise genphy_config_aneg() doesn't start PHY auto-negotiation.
> PHY continue to stay in auto-negotiation complete state and doesn't fire
> interrupt. At the same time PHY state machine expect that PHY started
> auto-negotiation and is waiting for interrupt from PHY and it won't get it.
>
> Signed-off-by: Alexander Kochetkov <al.kochet@gmail.com>
> Cc: stable <stable@vger.kernel.org> # v4.9+
Applied, and I reverted the micrel commit too.
Thanks.
^ permalink raw reply
* Re: [PATCH] stmmac: Add support for SIMATIC IOT2000 platform
From: Andy Shevchenko @ 2017-04-26 18:29 UTC (permalink / raw)
To: Jan Kiszka
Cc: Giuseppe Cavallaro, Alexandre Torgue, netdev,
Linux Kernel Mailing List, Sascha Weisenberger
In-Reply-To: <5705c598-7721-fca5-d4e3-8a1a88907173@siemens.com>
On Tue, Apr 25, 2017 at 3:15 PM, Jan Kiszka <jan.kiszka@siemens.com> wrote:
> On 2017-04-25 13:42, Andy Shevchenko wrote:
>> On Tue, Apr 25, 2017 at 1:09 PM, Jan Kiszka <jan.kiszka@siemens.com> wrote:
>>> On 2017-04-25 12:07, Jan Kiszka wrote:
>>>> On 2017-04-25 11:46, Andy Shevchenko wrote:
>>>>> On Tue, Apr 25, 2017 at 12:00 PM, Jan Kiszka <jan.kiszka@siemens.com> wrote:
>>>>> {
>>>>> .name = "SIMATIC IOT2000",
>>>>> .func = 6,
>>>>> .phy_addr = 1,
>>>>> },
>>>>> {
>>>>> .name = "SIMATIC IOT2000",
>>>>> .func = 7,
>>>>> .phy_addr = 1,
>>>>> },
>>>>>
>>>>> That's all what you need.
>>>>
>>>> Nope. Again: the asset tag is the way to tell both apart AND to ensure
>>>> that we do not match on future devices.
>>
>>> To be more verbose: your version (which is our old one) would even
>>> enable the second, not connected port on the IOT2020. Incorrectly.
>>
>> So, name has 2000 for 2020 device? It's clear bug in DMI table you have. :-(
>>
>> What else do you have in DMI which can be used to distinguish those devices?
So, except asset tag is there anything else to use?
Whatever you choose would be nice to split this long conditional:
if (!strcmp(dmi->name, name) && dmi->func == func) {
/* ASSET_TAG is optional */
if (dmi->asset_tag && strcmp(dmi->asset_tag, asset_tag))
continue;
return dmi->phy_addr;
}
> Andy, there are devices out there in the field, if we as engineers like
> it or not, that are all called "IOT2000" although they are sightly
> different inside. This patch accounts for that. And it does that even
> without adding "platform_data" hacks like in other patches of mine. ;)
Yes, which is good.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* [PATCH net-next 3/6] bpf: bpf_progs stores all loaded programs
From: Hannes Frederic Sowa @ 2017-04-26 18:24 UTC (permalink / raw)
To: netdev; +Cc: ast, daniel, jbenc, aconole
In-Reply-To: <20170426182419.14574-1-hannes@stressinduktion.org>
We later want to give users a quick dump of what is possible with procfs,
so store a list of all currently loaded bpf programs. Later this list
will be printed in procfs.
Signed-off-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
---
include/linux/filter.h | 4 ++--
kernel/bpf/core.c | 51 +++++++++++++++++++++++---------------------------
kernel/bpf/syscall.c | 4 ++--
3 files changed, 27 insertions(+), 32 deletions(-)
diff --git a/include/linux/filter.h b/include/linux/filter.h
index 9a7786db14fa53..63624c619e371b 100644
--- a/include/linux/filter.h
+++ b/include/linux/filter.h
@@ -753,8 +753,8 @@ bpf_address_lookup(unsigned long addr, unsigned long *size,
return ret;
}
-void bpf_prog_kallsyms_add(struct bpf_prog *fp);
-void bpf_prog_kallsyms_del(struct bpf_prog *fp);
+void bpf_prog_link(struct bpf_prog *fp);
+void bpf_prog_unlink(struct bpf_prog *fp);
#else /* CONFIG_BPF_JIT */
diff --git a/kernel/bpf/core.c b/kernel/bpf/core.c
index 043f634ff58d87..2139118258cdf8 100644
--- a/kernel/bpf/core.c
+++ b/kernel/bpf/core.c
@@ -365,22 +365,6 @@ static struct latch_tree_root bpf_tree __cacheline_aligned;
int bpf_jit_kallsyms __read_mostly;
-static void bpf_prog_ksym_node_add(struct bpf_prog_aux *aux)
-{
- WARN_ON_ONCE(!list_empty(&aux->bpf_progs_head));
- list_add_tail_rcu(&aux->bpf_progs_head, &bpf_progs);
- latch_tree_insert(&aux->ksym_tnode, &bpf_tree, &bpf_tree_ops);
-}
-
-static void bpf_prog_ksym_node_del(struct bpf_prog_aux *aux)
-{
- if (list_empty(&aux->bpf_progs_head))
- return;
-
- latch_tree_erase(&aux->ksym_tnode, &bpf_tree, &bpf_tree_ops);
- list_del_rcu(&aux->bpf_progs_head);
-}
-
static bool bpf_prog_kallsyms_candidate(const struct bpf_prog *fp)
{
return fp->jited && !bpf_prog_was_classic(fp);
@@ -392,38 +376,45 @@ static bool bpf_prog_kallsyms_verify_off(const struct bpf_prog *fp)
fp->aux->bpf_progs_head.prev == LIST_POISON2;
}
-void bpf_prog_kallsyms_add(struct bpf_prog *fp)
+void bpf_prog_link(struct bpf_prog *fp)
{
- if (!bpf_prog_kallsyms_candidate(fp) ||
- !capable(CAP_SYS_ADMIN))
- return;
+ struct bpf_prog_aux *aux = fp->aux;
spin_lock_bh(&bpf_lock);
- bpf_prog_ksym_node_add(fp->aux);
+ list_add_tail_rcu(&aux->bpf_progs_head, &bpf_progs);
+ if (bpf_prog_kallsyms_candidate(fp))
+ latch_tree_insert(&aux->ksym_tnode, &bpf_tree, &bpf_tree_ops);
spin_unlock_bh(&bpf_lock);
}
-void bpf_prog_kallsyms_del(struct bpf_prog *fp)
+void bpf_prog_unlink(struct bpf_prog *fp)
{
- if (!bpf_prog_kallsyms_candidate(fp))
- return;
+ struct bpf_prog_aux *aux = fp->aux;
spin_lock_bh(&bpf_lock);
- bpf_prog_ksym_node_del(fp->aux);
+ list_del_rcu(&aux->bpf_progs_head);
+ if (bpf_prog_kallsyms_candidate(fp))
+ latch_tree_erase(&aux->ksym_tnode, &bpf_tree, &bpf_tree_ops);
spin_unlock_bh(&bpf_lock);
}
static struct bpf_prog *bpf_prog_kallsyms_find(unsigned long addr)
{
struct latch_tree_node *n;
+ struct bpf_prog *prog;
if (!bpf_jit_kallsyms_enabled())
return NULL;
n = latch_tree_find((void *)addr, &bpf_tree, &bpf_tree_ops);
- return n ?
- container_of(n, struct bpf_prog_aux, ksym_tnode)->prog :
- NULL;
+ if (!n)
+ return NULL;
+
+ prog = container_of(n, struct bpf_prog_aux, ksym_tnode)->prog;
+ if (!prog->priv_cap_sys_admin)
+ return NULL;
+
+ return prog;
}
const char *__bpf_address_lookup(unsigned long addr, unsigned long *size,
@@ -474,6 +465,10 @@ int bpf_get_kallsym(unsigned int symnum, unsigned long *value, char *type,
rcu_read_lock();
list_for_each_entry_rcu(aux, &bpf_progs, bpf_progs_head) {
+ if (!bpf_prog_kallsyms_candidate(aux->prog) ||
+ !aux->prog->priv_cap_sys_admin)
+ continue;
+
if (it++ != symnum)
continue;
diff --git a/kernel/bpf/syscall.c b/kernel/bpf/syscall.c
index 13642c73dca0b4..d61d1bd3e6fee6 100644
--- a/kernel/bpf/syscall.c
+++ b/kernel/bpf/syscall.c
@@ -664,7 +664,7 @@ void bpf_prog_put(struct bpf_prog *prog)
{
if (atomic_dec_and_test(&prog->aux->refcnt)) {
trace_bpf_prog_put_rcu(prog);
- bpf_prog_kallsyms_del(prog);
+ bpf_prog_unlink(prog);
call_rcu(&prog->aux->rcu, __bpf_prog_put_rcu);
}
}
@@ -858,7 +858,7 @@ static int bpf_prog_load(union bpf_attr *attr)
/* failed to allocate fd */
goto free_used_maps;
- bpf_prog_kallsyms_add(prog);
+ bpf_prog_link(prog);
trace_bpf_prog_load(prog, err);
return err;
--
2.9.3
^ permalink raw reply related
* [PATCH net-next 5/6] bpf: add skeleton for procfs printing of bpf_progs
From: Hannes Frederic Sowa @ 2017-04-26 18:24 UTC (permalink / raw)
To: netdev; +Cc: ast, daniel, jbenc, aconole
In-Reply-To: <20170426182419.14574-1-hannes@stressinduktion.org>
Signed-off-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
---
kernel/bpf/core.c | 90 +++++++++++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 90 insertions(+)
diff --git a/kernel/bpf/core.c b/kernel/bpf/core.c
index 048e2d79718a16..3ba175a24e971a 100644
--- a/kernel/bpf/core.c
+++ b/kernel/bpf/core.c
@@ -32,6 +32,9 @@
#include <linux/kallsyms.h>
#include <linux/rcupdate.h>
+#include <linux/proc_fs.h>
+#include <linux/seq_file.h>
+
#include <asm/unaligned.h>
/* Registers */
@@ -488,6 +491,93 @@ int bpf_get_kallsym(unsigned int symnum, unsigned long *value, char *type,
return ret;
}
+/* ebpf procfs implementation */
+
+static struct proc_dir_entry *ebpf_proc_dir;
+
+static void *ebpf_proc_start(struct seq_file *s, loff_t *pos)
+ __acquires(RCU_BH)
+{
+ struct bpf_prog_aux *aux;
+ loff_t off = 0;
+
+ rcu_read_lock();
+
+ if (*pos == 0)
+ return SEQ_START_TOKEN;
+
+ list_for_each_entry_rcu(aux, &bpf_progs, bpf_progs_head)
+ if (++off == *pos)
+ return aux;
+
+ return NULL;
+}
+
+static void *ebpf_proc_next(struct seq_file *s, void *v, loff_t *pos)
+{
+ struct bpf_prog_aux *aux;
+
+ ++*pos;
+
+ if (v == SEQ_START_TOKEN)
+ return list_first_or_null_rcu(&bpf_progs, struct bpf_prog_aux,
+ bpf_progs_head);
+
+ aux = v;
+ return list_next_or_null_rcu(&bpf_progs,
+ &aux->bpf_progs_head,
+ struct bpf_prog_aux,
+ bpf_progs_head);
+}
+
+static void ebpf_proc_stop(struct seq_file *s, void *v)
+ __releases(RCU_BH)
+{
+ rcu_read_unlock();
+}
+
+static int ebpf_proc_show(struct seq_file *s, void *v)
+{
+ if (v == SEQ_START_TOKEN) {
+ seq_printf(s, "# tag\n");
+ return 0;
+ }
+
+ return 0;
+}
+
+static const struct seq_operations ebpf_seq_ops = {
+ .start = ebpf_proc_start,
+ .next = ebpf_proc_next,
+ .stop = ebpf_proc_stop,
+ .show = ebpf_proc_show,
+};
+
+static int ebpf_proc_open(struct inode *inode, struct file *file)
+{
+ return seq_open(file, &ebpf_seq_ops);
+}
+
+static const struct file_operations ebpf_proc_operations = {
+ .open = ebpf_proc_open,
+ .read = seq_read,
+ .llseek = seq_lseek,
+ .release = seq_release,
+};
+
+static int __init ebpf_proc_init(void)
+{
+ ebpf_proc_dir = proc_mkdir("bpf", NULL);
+ if (!ebpf_proc_dir)
+ return 0;
+ proc_create("programs", 0400, ebpf_proc_dir, &ebpf_proc_operations);
+ return 0;
+}
+
+device_initcall(ebpf_proc_init);
+
+/* end of bpf proc inmplementation */
+
struct bpf_binary_header *
bpf_jit_binary_alloc(unsigned int proglen, u8 **image_ptr,
unsigned int alignment,
--
2.9.3
^ permalink raw reply related
* [PATCH net-next 6/6] bpf: show bpf programs
From: Hannes Frederic Sowa @ 2017-04-26 18:24 UTC (permalink / raw)
To: netdev; +Cc: ast, daniel, jbenc, aconole
In-Reply-To: <20170426182419.14574-1-hannes@stressinduktion.org>
Signed-off-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
---
include/uapi/linux/bpf.h | 32 +++++++++++++++++++-------------
kernel/bpf/core.c | 30 +++++++++++++++++++++++++++++-
2 files changed, 48 insertions(+), 14 deletions(-)
diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h
index e553529929f683..d6506e320953d5 100644
--- a/include/uapi/linux/bpf.h
+++ b/include/uapi/linux/bpf.h
@@ -101,20 +101,26 @@ enum bpf_map_type {
BPF_MAP_TYPE_HASH_OF_MAPS,
};
+#define BPF_PROG_TYPES \
+ X(BPF_PROG_TYPE_UNSPEC), \
+ X(BPF_PROG_TYPE_SOCKET_FILTER), \
+ X(BPF_PROG_TYPE_KPROBE), \
+ X(BPF_PROG_TYPE_SCHED_CLS), \
+ X(BPF_PROG_TYPE_SCHED_ACT), \
+ X(BPF_PROG_TYPE_TRACEPOINT), \
+ X(BPF_PROG_TYPE_XDP), \
+ X(BPF_PROG_TYPE_PERF_EVENT), \
+ X(BPF_PROG_TYPE_CGROUP_SKB), \
+ X(BPF_PROG_TYPE_CGROUP_SOCK), \
+ X(BPF_PROG_TYPE_LWT_IN), \
+ X(BPF_PROG_TYPE_LWT_OUT), \
+ X(BPF_PROG_TYPE_LWT_XMIT),
+
+
enum bpf_prog_type {
- BPF_PROG_TYPE_UNSPEC,
- BPF_PROG_TYPE_SOCKET_FILTER,
- BPF_PROG_TYPE_KPROBE,
- BPF_PROG_TYPE_SCHED_CLS,
- BPF_PROG_TYPE_SCHED_ACT,
- BPF_PROG_TYPE_TRACEPOINT,
- BPF_PROG_TYPE_XDP,
- BPF_PROG_TYPE_PERF_EVENT,
- BPF_PROG_TYPE_CGROUP_SKB,
- BPF_PROG_TYPE_CGROUP_SOCK,
- BPF_PROG_TYPE_LWT_IN,
- BPF_PROG_TYPE_LWT_OUT,
- BPF_PROG_TYPE_LWT_XMIT,
+#define X(type) type
+ BPF_PROG_TYPES
+#undef X
};
enum bpf_attach_type {
diff --git a/kernel/bpf/core.c b/kernel/bpf/core.c
index 3ba175a24e971a..685c1d0f31e029 100644
--- a/kernel/bpf/core.c
+++ b/kernel/bpf/core.c
@@ -536,13 +536,41 @@ static void ebpf_proc_stop(struct seq_file *s, void *v)
rcu_read_unlock();
}
+static const char *bpf_type_string(enum bpf_prog_type type)
+{
+ static const char *bpf_type_names[] = {
+#define X(type) #type
+ BPF_PROG_TYPES
+#undef X
+ };
+
+ if (type >= ARRAY_SIZE(bpf_type_names))
+ return "<unknown>";
+
+ return bpf_type_names[type];
+}
+
static int ebpf_proc_show(struct seq_file *s, void *v)
{
+ struct bpf_prog *prog;
+ struct bpf_prog_aux *aux;
+ char prog_tag[sizeof(prog->tag) * 2 + 1] = { };
+
if (v == SEQ_START_TOKEN) {
- seq_printf(s, "# tag\n");
+ seq_printf(s, "# tag\t\t\ttype\t\t\truntime\tcap\tmemlock\n");
return 0;
}
+ aux = v;
+ prog = aux->prog;
+
+ bin2hex(prog_tag, prog->tag, sizeof(prog->tag));
+ seq_printf(s, "%s\t%s\t%s\t%s\t%llu\n", prog_tag,
+ bpf_type_string(prog->type),
+ prog->jited ? "jit" : "int",
+ prog->priv_cap_sys_admin ? "priv" : "unpriv",
+ prog->pages * 1ULL << PAGE_SHIFT);
+
return 0;
}
--
2.9.3
^ permalink raw reply related
* [PATCH net-next 1/6] bpf: bpf_lock needs only block bottom half
From: Hannes Frederic Sowa @ 2017-04-26 18:24 UTC (permalink / raw)
To: netdev; +Cc: ast, daniel, jbenc, aconole
In-Reply-To: <20170426182419.14574-1-hannes@stressinduktion.org>
We never modify bpf programs from hardirqs ever.
Signed-off-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
---
kernel/bpf/core.c | 12 ++++--------
1 file changed, 4 insertions(+), 8 deletions(-)
diff --git a/kernel/bpf/core.c b/kernel/bpf/core.c
index b4f1cb0c5ac710..6f81e0f5a0faa2 100644
--- a/kernel/bpf/core.c
+++ b/kernel/bpf/core.c
@@ -394,27 +394,23 @@ static bool bpf_prog_kallsyms_verify_off(const struct bpf_prog *fp)
void bpf_prog_kallsyms_add(struct bpf_prog *fp)
{
- unsigned long flags;
-
if (!bpf_prog_kallsyms_candidate(fp) ||
!capable(CAP_SYS_ADMIN))
return;
- spin_lock_irqsave(&bpf_lock, flags);
+ spin_lock_bh(&bpf_lock);
bpf_prog_ksym_node_add(fp->aux);
- spin_unlock_irqrestore(&bpf_lock, flags);
+ spin_unlock_bh(&bpf_lock);
}
void bpf_prog_kallsyms_del(struct bpf_prog *fp)
{
- unsigned long flags;
-
if (!bpf_prog_kallsyms_candidate(fp))
return;
- spin_lock_irqsave(&bpf_lock, flags);
+ spin_lock_bh(&bpf_lock);
bpf_prog_ksym_node_del(fp->aux);
- spin_unlock_irqrestore(&bpf_lock, flags);
+ spin_unlock_bh(&bpf_lock);
}
static struct bpf_prog *bpf_prog_kallsyms_find(unsigned long addr)
--
2.9.3
^ permalink raw reply related
* [PATCH net-next 4/6] bpf: track if the bpf program was loaded with SYS_ADMIN capabilities
From: Hannes Frederic Sowa @ 2017-04-26 18:24 UTC (permalink / raw)
To: netdev; +Cc: ast, daniel, jbenc, aconole
In-Reply-To: <20170426182419.14574-1-hannes@stressinduktion.org>
Signed-off-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
---
include/linux/filter.h | 6 ++++--
kernel/bpf/core.c | 4 +++-
kernel/bpf/syscall.c | 7 ++++---
kernel/bpf/verifier.c | 4 ++--
net/core/filter.c | 6 +++---
5 files changed, 16 insertions(+), 11 deletions(-)
diff --git a/include/linux/filter.h b/include/linux/filter.h
index 63624c619e371b..635311f57bf24f 100644
--- a/include/linux/filter.h
+++ b/include/linux/filter.h
@@ -413,7 +413,8 @@ struct bpf_prog {
locked:1, /* Program image locked? */
gpl_compatible:1, /* Is filter GPL compatible? */
cb_access:1, /* Is control block accessed? */
- dst_needed:1; /* Do we need dst entry? */
+ dst_needed:1, /* Do we need dst entry? */
+ priv_cap_sys_admin:1; /* Where we loaded as sys_admin? */
kmemcheck_bitfield_end(meta);
enum bpf_prog_type type; /* Type of BPF program */
u32 len; /* Number of filter blocks */
@@ -615,7 +616,8 @@ static inline int sk_filter(struct sock *sk, struct sk_buff *skb)
struct bpf_prog *bpf_prog_select_runtime(struct bpf_prog *fp, int *err);
void bpf_prog_free(struct bpf_prog *fp);
-struct bpf_prog *bpf_prog_alloc(unsigned int size, gfp_t gfp_extra_flags);
+struct bpf_prog *bpf_prog_alloc(unsigned int size, gfp_t gfp_extra_flags,
+ bool cap_sys_admin);
struct bpf_prog *bpf_prog_realloc(struct bpf_prog *fp_old, unsigned int size,
gfp_t gfp_extra_flags);
void __bpf_prog_free(struct bpf_prog *fp);
diff --git a/kernel/bpf/core.c b/kernel/bpf/core.c
index 2139118258cdf8..048e2d79718a16 100644
--- a/kernel/bpf/core.c
+++ b/kernel/bpf/core.c
@@ -74,7 +74,8 @@ void *bpf_internal_load_pointer_neg_helper(const struct sk_buff *skb, int k, uns
return NULL;
}
-struct bpf_prog *bpf_prog_alloc(unsigned int size, gfp_t gfp_extra_flags)
+struct bpf_prog *bpf_prog_alloc(unsigned int size, gfp_t gfp_extra_flags,
+ bool cap_sys_admin)
{
gfp_t gfp_flags = GFP_KERNEL | __GFP_HIGHMEM | __GFP_ZERO |
gfp_extra_flags;
@@ -94,6 +95,7 @@ struct bpf_prog *bpf_prog_alloc(unsigned int size, gfp_t gfp_extra_flags)
return NULL;
}
+ fp->priv_cap_sys_admin = cap_sys_admin;
fp->pages = size / PAGE_SIZE;
fp->aux = aux;
fp->aux->prog = fp;
diff --git a/kernel/bpf/syscall.c b/kernel/bpf/syscall.c
index d61d1bd3e6fee6..ed698c17578a49 100644
--- a/kernel/bpf/syscall.c
+++ b/kernel/bpf/syscall.c
@@ -786,7 +786,7 @@ EXPORT_SYMBOL_GPL(bpf_prog_get_type);
/* last field in 'union bpf_attr' used by this command */
#define BPF_PROG_LOAD_LAST_FIELD kern_version
-static int bpf_prog_load(union bpf_attr *attr)
+static int bpf_prog_load(union bpf_attr *attr, bool cap_sys_admin)
{
enum bpf_prog_type type = attr->prog_type;
struct bpf_prog *prog;
@@ -817,7 +817,8 @@ static int bpf_prog_load(union bpf_attr *attr)
return -EPERM;
/* plain bpf_prog allocation */
- prog = bpf_prog_alloc(bpf_prog_size(attr->insn_cnt), GFP_USER);
+ prog = bpf_prog_alloc(bpf_prog_size(attr->insn_cnt), GFP_USER,
+ cap_sys_admin);
if (!prog)
return -ENOMEM;
@@ -1053,7 +1054,7 @@ SYSCALL_DEFINE3(bpf, int, cmd, union bpf_attr __user *, uattr, unsigned int, siz
err = map_get_next_key(&attr);
break;
case BPF_PROG_LOAD:
- err = bpf_prog_load(&attr);
+ err = bpf_prog_load(&attr, capable(CAP_SYS_ADMIN));
break;
case BPF_OBJ_PIN:
err = bpf_obj_pin(&attr);
diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
index 6f8b6ed690be93..24c9dac374770f 100644
--- a/kernel/bpf/verifier.c
+++ b/kernel/bpf/verifier.c
@@ -3488,7 +3488,7 @@ int bpf_check(struct bpf_prog **prog, union bpf_attr *attr)
if (ret < 0)
goto skip_full_check;
- env->allow_ptr_leaks = capable(CAP_SYS_ADMIN);
+ env->allow_ptr_leaks = env->prog->priv_cap_sys_admin;
ret = do_check(env);
@@ -3589,7 +3589,7 @@ int bpf_analyzer(struct bpf_prog *prog, const struct bpf_ext_analyzer_ops *ops,
if (ret < 0)
goto skip_full_check;
- env->allow_ptr_leaks = capable(CAP_SYS_ADMIN);
+ env->allow_ptr_leaks = prog->priv_cap_sys_admin;
ret = do_check(env);
diff --git a/net/core/filter.c b/net/core/filter.c
index 9a37860a80fc78..dc020d40bb770a 100644
--- a/net/core/filter.c
+++ b/net/core/filter.c
@@ -1100,7 +1100,7 @@ int bpf_prog_create(struct bpf_prog **pfp, struct sock_fprog_kern *fprog)
if (!bpf_check_basics_ok(fprog->filter, fprog->len))
return -EINVAL;
- fp = bpf_prog_alloc(bpf_prog_size(fprog->len), 0);
+ fp = bpf_prog_alloc(bpf_prog_size(fprog->len), 0, false);
if (!fp)
return -ENOMEM;
@@ -1147,7 +1147,7 @@ int bpf_prog_create_from_user(struct bpf_prog **pfp, struct sock_fprog *fprog,
if (!bpf_check_basics_ok(fprog->filter, fprog->len))
return -EINVAL;
- fp = bpf_prog_alloc(bpf_prog_size(fprog->len), 0);
+ fp = bpf_prog_alloc(bpf_prog_size(fprog->len), 0, false);
if (!fp)
return -ENOMEM;
@@ -1249,7 +1249,7 @@ struct bpf_prog *__get_filter(struct sock_fprog *fprog, struct sock *sk)
if (!bpf_check_basics_ok(fprog->filter, fprog->len))
return ERR_PTR(-EINVAL);
- prog = bpf_prog_alloc(bpf_prog_size(fprog->len), 0);
+ prog = bpf_prog_alloc(bpf_prog_size(fprog->len), 0, false);
if (!prog)
return ERR_PTR(-ENOMEM);
--
2.9.3
^ permalink raw reply related
* [PATCH net-next 0/6] bpf: list all loaded ebpf programs in /proc/bpf/programs
From: Hannes Frederic Sowa @ 2017-04-26 18:24 UTC (permalink / raw)
To: netdev; +Cc: ast, daniel, jbenc, aconole
Right now it seems difficult to list all active ebpf programs in a
system. This new /proc/bpf/programs node should help and print
basically essential information about loaded ebpf programs.
This should help an admin to get a quick look of what is going on in
his system.
Feedback welcome!
Hannes Frederic Sowa (6):
bpf: bpf_lock needs only block bottom half
bpf: rename bpf_kallsyms to bpf_progs, ksym_lnode to bpf_progs_head
bpf: bpf_progs stores all loaded programs
bpf: track if the bpf program was loaded with SYS_ADMIN capabilities
bpf: add skeleton for procfs printing of bpf_progs
bpf: show bpf programs
include/linux/bpf.h | 2 +-
include/linux/filter.h | 10 ++-
include/uapi/linux/bpf.h | 32 ++++----
kernel/bpf/core.c | 195 +++++++++++++++++++++++++++++++++++++----------
kernel/bpf/syscall.c | 11 +--
kernel/bpf/verifier.c | 4 +-
net/core/filter.c | 6 +-
7 files changed, 190 insertions(+), 70 deletions(-)
--
2.9.3
^ permalink raw reply
* [PATCH net-next 2/6] bpf: rename bpf_kallsyms to bpf_progs, ksym_lnode to bpf_progs_head
From: Hannes Frederic Sowa @ 2017-04-26 18:24 UTC (permalink / raw)
To: netdev; +Cc: ast, daniel, jbenc, aconole
In-Reply-To: <20170426182419.14574-1-hannes@stressinduktion.org>
We will soon put all bpf programs on this list, thus use apropriate names.
Signed-off-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
---
include/linux/bpf.h | 2 +-
kernel/bpf/core.c | 18 +++++++++---------
2 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/include/linux/bpf.h b/include/linux/bpf.h
index 6bb38d76faf42a..0fbf6a76555cc9 100644
--- a/include/linux/bpf.h
+++ b/include/linux/bpf.h
@@ -172,7 +172,7 @@ struct bpf_prog_aux {
u32 used_map_cnt;
u32 max_ctx_offset;
struct latch_tree_node ksym_tnode;
- struct list_head ksym_lnode;
+ struct list_head bpf_progs_head;
const struct bpf_verifier_ops *ops;
struct bpf_map **used_maps;
struct bpf_prog *prog;
diff --git a/kernel/bpf/core.c b/kernel/bpf/core.c
index 6f81e0f5a0faa2..043f634ff58d87 100644
--- a/kernel/bpf/core.c
+++ b/kernel/bpf/core.c
@@ -98,7 +98,7 @@ struct bpf_prog *bpf_prog_alloc(unsigned int size, gfp_t gfp_extra_flags)
fp->aux = aux;
fp->aux->prog = fp;
- INIT_LIST_HEAD_RCU(&fp->aux->ksym_lnode);
+ INIT_LIST_HEAD_RCU(&fp->aux->bpf_progs_head);
return fp;
}
@@ -360,25 +360,25 @@ static const struct latch_tree_ops bpf_tree_ops = {
};
static DEFINE_SPINLOCK(bpf_lock);
-static LIST_HEAD(bpf_kallsyms);
+static LIST_HEAD(bpf_progs);
static struct latch_tree_root bpf_tree __cacheline_aligned;
int bpf_jit_kallsyms __read_mostly;
static void bpf_prog_ksym_node_add(struct bpf_prog_aux *aux)
{
- WARN_ON_ONCE(!list_empty(&aux->ksym_lnode));
- list_add_tail_rcu(&aux->ksym_lnode, &bpf_kallsyms);
+ WARN_ON_ONCE(!list_empty(&aux->bpf_progs_head));
+ list_add_tail_rcu(&aux->bpf_progs_head, &bpf_progs);
latch_tree_insert(&aux->ksym_tnode, &bpf_tree, &bpf_tree_ops);
}
static void bpf_prog_ksym_node_del(struct bpf_prog_aux *aux)
{
- if (list_empty(&aux->ksym_lnode))
+ if (list_empty(&aux->bpf_progs_head))
return;
latch_tree_erase(&aux->ksym_tnode, &bpf_tree, &bpf_tree_ops);
- list_del_rcu(&aux->ksym_lnode);
+ list_del_rcu(&aux->bpf_progs_head);
}
static bool bpf_prog_kallsyms_candidate(const struct bpf_prog *fp)
@@ -388,8 +388,8 @@ static bool bpf_prog_kallsyms_candidate(const struct bpf_prog *fp)
static bool bpf_prog_kallsyms_verify_off(const struct bpf_prog *fp)
{
- return list_empty(&fp->aux->ksym_lnode) ||
- fp->aux->ksym_lnode.prev == LIST_POISON2;
+ return list_empty(&fp->aux->bpf_progs_head) ||
+ fp->aux->bpf_progs_head.prev == LIST_POISON2;
}
void bpf_prog_kallsyms_add(struct bpf_prog *fp)
@@ -473,7 +473,7 @@ int bpf_get_kallsym(unsigned int symnum, unsigned long *value, char *type,
return ret;
rcu_read_lock();
- list_for_each_entry_rcu(aux, &bpf_kallsyms, ksym_lnode) {
+ list_for_each_entry_rcu(aux, &bpf_progs, bpf_progs_head) {
if (it++ != symnum)
continue;
--
2.9.3
^ permalink raw reply related
* Re: linux-next: Tree for Apr 26 (net/can/bcm.c)
From: Oliver Hartkopp @ 2017-04-26 18:18 UTC (permalink / raw)
To: Randy Dunlap, Stephen Rothwell, Linux-Next Mailing List
Cc: Linux Kernel Mailing List, netdev@vger.kernel.org, linux-can
In-Reply-To: <05bd24d8-6840-3551-a529-c464f3b26d0a@infradead.org>
Hi Randy,
thanks for the report!
Some fallout of my namespace support integration %-)
I posted a patch for it:
http://marc.info/?l=linux-can&m=149323049630039&w=2
Many thanks & best regards,
Oliver
On 04/26/2017 04:53 PM, Randy Dunlap wrote:
> On 04/26/17 01:03, Stephen Rothwell wrote:
>> Hi all,
>>
>> Changes since 20170424:
>>
>
> on x86_64:
>
> when CONFIG_PROC_FS is not enabled:
>
> ../net/can/bcm.c:1541:14: error: 'struct netns_can' has no member named 'bcmproc_dir'
> ../net/can/bcm.c:1601:14: error: 'struct netns_can' has no member named 'bcmproc_dir'
> ../net/can/bcm.c:1696:11: error: 'struct netns_can' has no member named 'bcmproc_dir'
> ../net/can/bcm.c:1707:15: error: 'struct netns_can' has no member named 'bcmproc_dir'
>
> 2 of those are "protected" by
> if (IS_ENABLED(CONFIG_PROC_FS)) {
> but that doesn't seem to help/work here.
>
> gcc v4.8.5
>
>
>
^ permalink raw reply
* Re: Bug and configuration MPLS error?
From: David Ahern @ 2017-04-26 18:18 UTC (permalink / raw)
To: Алексей Болдырев,
netdev
In-Reply-To: <1728581493210432@web45j.yandex.ru>
On 4/26/17 6:40 AM, Алексей Болдырев wrote:
>
>
> 26.04.2017, 05:23, "David Ahern" <dsahern@gmail.com>:
>> On 4/25/17 11:28 AM, Алексей Болдырев wrote:
>>> 226 sysctl -w net.mpls.conf.lo.input=1
>>> 227 sysctl -w net.mpls.platform_labels=1048575
>>> 228 ip link add veth0 type veth peer name veth1
>>> 229 ip link add veth2 type veth peer name veth3
>>> 230 sysctl -w net.mpls.conf.veth0.input=1
>>> 231 sysctl -w net.mpls.conf.veth2.input=1
>>> 232 ifconfig veth0 10.3.3.1 netmask 255.255.255.0
>>> 233 ifconfig veth2 10.4.4.1 netmask 255.255.255.0
>>> 234 ip netns add host1
>>> 235 ip netns add host2
>>> 236 ip link set veth1 netns host1
>>> 237 ip link set veth3 netns host2
>>> 238 ip netns exec host1 ifconfig veth1 10.3.3.2 netmask 255.255.255.0 up
>>> 239 ip netns exec host2 ifconfig veth3 10.4.4.2 netmask 255.255.255.0 up
>>> 240 ip netns exec host1 ip route add 10.10.10.2/32 encap mpls 112 via inet 10.3.3.1
>>> 241 ip netns exec host2 ip route add 10.10.10.1/32 encap mpls 111 via inet 10.4.4.1
>>> 242 ip -f mpls route add 111 via inet 10.3.3.2
>>> 243 ip -f mpls route add 112 via inet 10.4.4.2
>>
>> your setup is incomplete.
>>
>> # ip netns exec host2 ping 10.10.10.1
>> PING 10.10.10.1 (10.10.10.1) 56(84) bytes of data.
>> ^C
>> --- 10.10.10.1 ping statistics ---
>> 2 packets transmitted, 0 received, 100% packet loss, time 1038ms
>>
>> If you run tcpdump on veth1 in host1 you see the packets come in but no
>> response:
>>
>> # ip netns exec host1 tcpdump -n -i veth1
>> tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
>> listening on veth1, link-type EN10MB (Ethernet), capture size 262144 bytes
>> 19:20:24.599529 IP6 fe80::347d:e3ff:fe93:944b > ff02::2: ICMP6, router
>> solicitation, length 16
>> 19:20:27.413901 IP 10.4.4.2 > 10.10.10.1: ICMP echo request, id 978, seq
>> 1, length 64
>> 19:20:28.439574 IP 10.4.4.2 > 10.10.10.1: ICMP echo request, id 978, seq
>> 2, length 64
>>
>> and the lack of response is b/c:
>> 1. host1 has no address for 10.10.10.1 and
>> 2. even if it did, there is no return route to 10.4.4.2:
>>
>> # ip -netns host1 ro ls
>> 10.3.3.0/24 dev veth1 proto kernel scope link src 10.3.3.2
>> 10.10.10.2 encap mpls 112 via 10.3.3.1 dev veth1
>
> As for ping, you need to enter this:
> Ip netns exec host2 ping 10.10.10.1 -A 10.10.10.2
> Here I published the results of testing on new (>4.9) cores. (in Russian):
> http://forum.nag.ru/forum/index.php?s=d09f0e5186fda59b3099eb81ad07ee63&showtopic=128927
> But on the old kernels:
> http://forum.nag.ru/forum/index.php?showtopic=128927&view=findpost&p=1396067
>
host1 does not have 10.10.10.1 as a local address.
host2 does not have 10.10.10.2 as a local address.
Given that, host1 has no business replying to a ping destined to
10.10.10.1, and host2 will not use 10.10.10.2 as a source address.
I don't have time right now to build and test on older kernels, but
based on the network config I do not see how it can work.
If you add:
ip -netns host1 addr add dev lo 10.10.10.1/32
ip -netns host2 addr add dev lo 10.10.10.2/32
Then it works.
^ permalink raw reply
* [PATCH net-next] can: fix CAN BCM build with CONFIG_PROC_FS disabled
From: Oliver Hartkopp @ 2017-04-26 18:14 UTC (permalink / raw)
To: linux-can, davem, rdunlap; +Cc: Oliver Hartkopp, mkl, netdev
The introduced namespace support moved the BCM variables for procfs into a
per-net data structure. This leads to a build failure with disabled procfs:
on x86_64:
when CONFIG_PROC_FS is not enabled:
../net/can/bcm.c:1541:14: error: 'struct netns_can' has no member named 'bcmproc_dir'
../net/can/bcm.c:1601:14: error: 'struct netns_can' has no member named 'bcmproc_dir'
../net/can/bcm.c:1696:11: error: 'struct netns_can' has no member named 'bcmproc_dir'
../net/can/bcm.c:1707:15: error: 'struct netns_can' has no member named 'bcmproc_dir'
http://marc.info/?l=linux-can&m=149321842526524&w=2
Reported-by: Randy Dunlap <rdunlap@infradead.org>
Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
---
net/can/bcm.c | 22 ++++++++++++++--------
1 file changed, 14 insertions(+), 8 deletions(-)
diff --git a/net/can/bcm.c b/net/can/bcm.c
index 0e855917b7e1..78409841b74c 100644
--- a/net/can/bcm.c
+++ b/net/can/bcm.c
@@ -147,6 +147,7 @@ static inline ktime_t bcm_timeval_to_ktime(struct bcm_timeval tv)
/*
* procfs functions
*/
+#if IS_ENABLED(CONFIG_PROC_FS)
static char *bcm_proc_getifname(struct net *net, char *result, int ifindex)
{
struct net_device *dev;
@@ -251,6 +252,7 @@ static const struct file_operations bcm_proc_fops = {
.llseek = seq_lseek,
.release = single_release,
};
+#endif /* CONFIG_PROC_FS */
/*
* bcm_can_tx - send the (next) CAN frame to the appropriate CAN interface
@@ -1537,9 +1539,11 @@ static int bcm_release(struct socket *sock)
bcm_remove_op(op);
}
+#if IS_ENABLED(CONFIG_PROC_FS)
/* remove procfs entry */
if (net->can.bcmproc_dir && bo->bcm_proc_read)
remove_proc_entry(bo->procname, net->can.bcmproc_dir);
+#endif /* CONFIG_PROC_FS */
/* remove device reference */
if (bo->bound) {
@@ -1598,6 +1602,7 @@ static int bcm_connect(struct socket *sock, struct sockaddr *uaddr, int len,
bo->ifindex = 0;
}
+#if IS_ENABLED(CONFIG_PROC_FS)
if (net->can.bcmproc_dir) {
/* unique socket address as filename */
sprintf(bo->procname, "%lu", sock_i_ino(sk));
@@ -1609,6 +1614,7 @@ static int bcm_connect(struct socket *sock, struct sockaddr *uaddr, int len,
goto fail;
}
}
+#endif /* CONFIG_PROC_FS */
bo->bound = 1;
@@ -1691,22 +1697,22 @@ static const struct can_proto bcm_can_proto = {
static int canbcm_pernet_init(struct net *net)
{
+#if IS_ENABLED(CONFIG_PROC_FS)
/* create /proc/net/can-bcm directory */
- if (IS_ENABLED(CONFIG_PROC_FS)) {
- net->can.bcmproc_dir =
- proc_net_mkdir(net, "can-bcm", net->proc_net);
- }
+ net->can.bcmproc_dir =
+ proc_net_mkdir(net, "can-bcm", net->proc_net);
+#endif /* CONFIG_PROC_FS */
return 0;
}
static void canbcm_pernet_exit(struct net *net)
{
+#if IS_ENABLED(CONFIG_PROC_FS)
/* remove /proc/net/can-bcm directory */
- if (IS_ENABLED(CONFIG_PROC_FS)) {
- if (net->can.bcmproc_dir)
- remove_proc_entry("can-bcm", net->proc_net);
- }
+ if (net->can.bcmproc_dir)
+ remove_proc_entry("can-bcm", net->proc_net);
+#endif /* CONFIG_PROC_FS */
}
static struct pernet_operations canbcm_pernet_ops __read_mostly = {
--
2.11.0
^ permalink raw reply related
* Re: [PATCH v2 01/21] scatterlist: Introduce sg_map helper functions
From: Logan Gunthorpe @ 2017-04-26 18:11 UTC (permalink / raw)
To: Christoph Hellwig
Cc: dri-devel, Stephen Bates, dm-devel, target-devel, Sumit Semwal,
devel, James E.J. Bottomley, linux-scsi, linux-nvdimm, linux-rdma,
Ross Zwisler, open-iscsi, linux-media, intel-gfx, sparmaintainer,
linux-raid, Dan Williams, megaraidlinux.pdl, Jens Axboe,
Martin K. Petersen, netdev, Matthew Wilcox, linux-mmc,
linux-kernel, linux-crypto, Greg Kroah-Hartman
In-Reply-To: <20170426074416.GA7936@lst.de>
On 26/04/17 01:44 AM, Christoph Hellwig wrote:
> I think we'll at least need a draft of those to make sense of these
> patches. Otherwise they just look very clumsy.
Ok, I'll work up a draft proposal and send it in a couple days. But
without a lot of cleanup such as this series it's not going to even be
able to compile.
> I'm sorry but this API is just a trainwreck. Right now we have the
> nice little kmap_atomic API, which never fails and has a very nice
> calling convention where we just pass back the return address, but does
> not support sleeping inside the critical section.
>
> And kmap, whіch may fail and requires the original page to be passed
> back. Anything that mixes these two concepts up is simply a non-starter.
Ok, well for starters I think you are mistaken about kmap being able to
fail. I'm having a hard time finding many users of that function that
bother to check for an error when calling it. The main difficulty we
have now is that neither of those functions are expected to fail and we
need them to be able to in cases where the page doesn't map to system
RAM. This patch series is trying to address it for users of scatterlist.
I'm certainly open to other suggestions.
I also have to disagree that kmap and kmap_atomic are all that "nice".
Except for the sleeping restriction and performance, they effectively do
the same thing. And it was necessary to write a macro wrapper around
kunmap_atomic to ensure that users of that function don't screw it up.
(See 597781f3e5.) I'd say the kmap/kmap_atomic functions are the
trainwreck and I'm trying to do my best to cleanup a few cases.
There are a fair number of cases in the kernel that do something like:
if (something)
x = kmap(page);
else
x = kmap_atomic(page);
...
if (something)
kunmap(page)
else
kunmap_atomic(x)
Which just seems cumbersome to me.
In any case, if you can accept an sg_kmap and sg_kmap_atomic api just
say so and I'll make the change. But I'll still need a flags variable
for SG_MAP_MUST_NOT_FAIL to support legacy cases that have no fail path
and both of those functions will need to be pretty nearly replicas of
each other.
Logan
_______________________________________________
devel mailing list
devel@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
^ permalink raw reply
* Re: [PATCH net-next] ip6_tunnel: Fix missing tunnel encapsulation limit option
From: Craig Gallek @ 2017-04-26 17:59 UTC (permalink / raw)
To: Hideaki YOSHIFUJI, Alexey Kuznetsov, David S . Miller; +Cc: netdev
In-Reply-To: <20170426170707.165201-1-kraigatgoog@gmail.com>
On Wed, Apr 26, 2017 at 1:07 PM, Craig Gallek <kraigatgoog@gmail.com> wrote:
> From: Craig Gallek <kraig@google.com>
>
> The IPv6 tunneling code tries to insert IPV6_TLV_TNL_ENCAP_LIMIT and
> IPV6_TLV_PADN options when an encapsulation limit is defined (the
> default is a limit of 4). An MTU adjustment is done to account for
> these options as well. However, the options are never present in the
> generated packets.
>
> ipv6_push_nfrag_opts requires that IPV6_RTHDR be present in order to
> include any IPV6_DSTOPTS options. The v6 tunnel code does not
> use routing options, so the encap limit options are not included.
>
> A brief reading of RFC 3542 section 9.2 (specifically the 4th paragraph)
> makes me believe that this requirement in the kernel is incorrect.
Looking more closely, I think I'm wrong here. Specifically, the cmsg
parser puts IPV6_RTHDRDSTOPTS in dst0opt and IPV6_DSTOPTS in dst1opt.
The tunnel code is currently building dst0opt and using
ipv6_push_nfrag_opts. Perhaps it should be building dst1opt and
calling ipv6_push_frag_opts?
^ permalink raw reply
* Re: xdp_redirect ifindex vs port. Was: best API for returning/setting egress port?
From: Alexei Starovoitov @ 2017-04-26 17:58 UTC (permalink / raw)
To: John Fastabend, Jesper Dangaard Brouer
Cc: Alexei Starovoitov, Daniel Borkmann, Andy Gospodarek,
Daniel Borkmann, netdev@vger.kernel.org,
xdp-newbies@vger.kernel.org
In-Reply-To: <5900CC41.2070502@gmail.com>
On 4/26/17 9:35 AM, John Fastabend wrote:
>
>> As Alexei also mentioned before, ifindex vs port makes no real
>> difference seen from the bpf program side. It is userspace's
>> responsibility to add ifindex/port's to the bpf-maps, according to how
>> the bpf program "policy" want to "connect" these ports. The
>> port-table system add one extra step, of also adding this port to the
>> port-table (which lives inside the kernel).
>>
>
> I'm not sure I understand the "lives inside the kernel" bit. I assumed
> the 'map' should be a bpf map and behave like any other bpf map.
>
> I wanted a new map to be defined, something like this from the bpf programmer
> side.
>
> struct bpf_map_def SEC("maps") port_table =
> .type = BPF_MAP_TYPE_PORT_CONNECTION,
> .key_size = sizeof(u32),
> .value_size = BPF_PORT_CONNECTION_SIZE,
> .max_entries = 256,
> };
I like the idea.
We have prog_array, perf_event_array, cgroup_array map specializations.
This one can be new netdev_array with some new bpf_redirect-like helper
accessing it.
>> When loading the XDP program, we also need to pass along a port table
>> "id" this XDP program is associated with (and if it doesn't exists you
>> create it). And your userspace "control-plane" application also need
>> to know this port table "id", when adding a new port.
>
> So the user space application that is loading the program also needs
> to handle this map. This seems correct to me. But I don't see the
> value in making some new port table when we already have well understood
> framework for maps.
+1
>>
>> The concept of having multiple port tables is key. As this implies we
>> can have several simultaneous "data-planes" that is *isolated* from
>> each-other. Think about how network-namespaces/containers want
>> isolation. A subtle thing I'm afraid to mention, is that oppose to the
>> ifindex model, a port table with mapping to a net_device pointer, would
>> allow (faster) delivery into the container's inner net_device, which
>> sort of violates the isolation, but I would argue it is not a problem
>> as this net_device pointer could only be added from a process within the
>> namespace. I like this feature, but it could easily be disallowed via
>> port insertion-time validation.
>>
>
> I think the above optimization should be allowed. And agree multiple port
> tables (maps?) is needed. Again all this points to using standard maps
> logic in my mind. For permissions and different domains, which I think
> you were starting to touch on, it looks like we could extend the pinning API.
> At the moment it does an inode_permission(inode, MAY_WRITE) check but I
> presume this could be extended. None of this would be needed in v1 and
> could be added subsequently. read-only maps seems doable.
this is great idea. Once BPF_MAP_TYPE_NETDEV_ARRAY is populated
the user space can make it readonly to prevent further changes.
From user space it can be done similar to perf_events/cgroups as well.
bpf_map_update_elem(&netdev_array, &port_num, &ifindex)
should work.
For bpf_map_lookup_elem() from such netdev_array we can return
ifindex back.
The bpf_map_show_fdinfo() can be customized as well to pretty print
ifindexes of netdevs stored in there.
^ permalink raw reply
* Re: [Patch net 3/3] team: use a larger struct for mac address
From: Jarod Wilson @ 2017-04-26 17:59 UTC (permalink / raw)
To: Cong Wang; +Cc: Jiri Pirko, Linux Kernel Network Developers, Andrey Konovalov
In-Reply-To: <CAM_iQpUGSy7My+hLXhsreq-8wPEdAKzNkQRzu-aiP5nkk+wSdw@mail.gmail.com>
On 2017-04-26 1:28 PM, Cong Wang wrote:
> On Wed, Apr 26, 2017 at 9:46 AM, Jarod Wilson <jarod@redhat.com> wrote:
>> On 2017-04-26 12:11 PM, Cong Wang wrote:
>>>
>>> On Wed, Apr 26, 2017 at 8:55 AM, Jarod Wilson <jarod@redhat.com> wrote:
>>>>
>>>>
>>>> We already have struct sockaddr_storage that could be used throughout
>>>> this
>>>> set as well. We just converted a few pieces of the bonding driver over to
>>>> using it for better support of ipoib bonds, via commit
>>>> faeeb317a5615076dff1ff44b51e862e6064dbd0. Might be better to just use
>>>> that
>>>> in both bonding and team, rather than having different per-driver
>>>> structs,
>>>> or Yet Another Address Storage implementation.
>>>
>>>
>>> Technically, struct sockaddr_storage is not enough either, given the
>>> max is MAX_ADDR_LEN. This is why I gave up on sockaddr_storage.
>>
>>
>> Wait, what? Am I missing something? MAX_ADDR_LEN is 32, and sockaddr_storage
>> is a #define for __kernel_sockaddr_storage, which has it's __data member
>> defined as being of size 128 - sizeof(unsigned short).
>
> My bad, I thought it is same with sizeof(in6addr) without looking into it.
> The question is, why do we waste 126 - 32 = 94 bytes on stack to just
> use struct sockaddr_storage?
That's a fair point.
> I totally understand we want a unified struct, but we already redefine
> it in multiple places in tree...
Something unified and centralized with a data storage of MAX_ADDR_LEN
does seem reasonable to get both consistency and minimized waste, and I
could certainly do a follow-up patch for the bonding driver to switch
the bits now using sockaddr_storage over to whatever new struct gets added.
--
Jarod Wilson
jarod@redhat.com
^ permalink raw reply
* RE: qed*: debug infrastructures
From: Elior, Ariel @ 2017-04-26 17:57 UTC (permalink / raw)
To: Florian Fainelli, David Miller, Jakub Kicinski, Jiri Pirko
Cc: netdev@vger.kernel.org, Mintz, Yuval, Tayar, Tomer, Dupuis, Chad
In-Reply-To: <c8751a31-f493-45c1-5bf2-596b367ea034@gmail.com>
Jiri, Florian, Jakub,
Thanks all for you suggestions.
Some answers to questions posted: The signal tracing in our device can be used
for tracing things like load/store/program_counter from our fastpath processors
(which handle every packet) which can then be re-run in a simulative environment
(recreating the recorded scenario). Other interesting uses for this feature can
be partial pci recording or partial network recording (poor man's analyzer)
which can also be very effective where full blown lab equipment is unavailable.
I reviewed the code of the drivers under hw_tracing (thanks Florian) and I think
we might be a good fit.
Jiri indicated dpipe was not intended for this sort of thing and suggested an
additional dev link object, although it seems to me that this will have to be
either a very generic object which would be susceptible to abuse similar to
debugfs, or it would be tailored to our device so much that no one else would
use it, so I am somewhat less inclined to go down this path (the code
abstracting our debug feature is accessed via ~20 api functions accepting ~10
params each, i.e. quite a handful of configuraion to generalize).
The ethtool debug dump presets (thanks Jakub) are far too narrow to encompass
the full flexibility required here.
Dave, I think my next step would be to send an RFC adding to our core module
(qed) the necessary APIs (mostly to provide some details to this rather abstract
discussion). I will plan to connect those to a new hwtracing driver I'll create
for this purpose, unless a different direction is suggested.
Thanks,
Ariel
^ permalink raw reply
* Re: Corrupted SKB
From: Cong Wang @ 2017-04-26 17:38 UTC (permalink / raw)
To: Michael Ma; +Cc: Linux Kernel Network Developers, jin.oyj
In-Reply-To: <CAAmHdhwncVcbeKN+K4EnmWqwBRXPwuMOSFwtOfuwmgc6gw-5=g@mail.gmail.com>
On Tue, Apr 25, 2017 at 9:42 PM, Michael Ma <make0818@gmail.com> wrote:
> 2017-04-18 21:46 GMT-07:00 Michael Ma <make0818@gmail.com>:
>> 2017-04-18 16:12 GMT-07:00 Cong Wang <xiyou.wangcong@gmail.com>:
>>> On Mon, Apr 17, 2017 at 5:39 PM, Michael Ma <make0818@gmail.com> wrote:
>>>> Hi -
>>>>
>>>> We've implemented a "glue" qdisc similar to mqprio which can associate
>>>> one qdisc to multiple txqs as the root qdisc. Reference count of the
>>>> child qdiscs have been adjusted properly in this case so that it
>>>> represents the number of txqs it has been attached to. However when
>>>> sending packets we saw the skb from dequeue_skb() corrupted with the
>>>> following call stack:
>>>>
>>>> [exception RIP: netif_skb_features+51]
>>>> RIP: ffffffff815292b3 RSP: ffff8817f6987940 RFLAGS: 00010246
>>>>
>>>> #9 [ffff8817f6987968] validate_xmit_skb at ffffffff815294aa
>>>> #10 [ffff8817f69879a0] validate_xmit_skb at ffffffff8152a0d9
>>>> #11 [ffff8817f69879b0] __qdisc_run at ffffffff8154a193
>>>> #12 [ffff8817f6987a00] dev_queue_xmit at ffffffff81529e03
>>>>
>>>> It looks like the skb has already been released since its dev pointer
>>>> field is invalid.
>>>>
>>>> Any clue on how this can be investigated further? My current thought
>>>> is to add some instrumentation to the place where skb is released and
>>>> analyze whether there is any race condition happening there. However
>>>
>>> Either dropwatch or perf could do the work to instrument kfree_skb().
>>
>> Thanks - will try it out.
>
> I'm using perf to collect the callstack for kfree_skb and trying to
> correlate that with the corrupted SKB address however when system
> crashes the perf.data file is also corrupted - how can I view this
> file in case the system crashes before perf exits?
Hmm, KASAN is pretty good at detecting use-after-free,
its report can nicely shows where we allocate/free it and the
use after free.
https://01.org/linuxgraphics/gfx-docs/drm/dev-tools/kasan.html
^ permalink raw reply
* Re: [Patch net 3/3] team: use a larger struct for mac address
From: Cong Wang @ 2017-04-26 17:28 UTC (permalink / raw)
To: Jarod Wilson
Cc: Jiri Pirko, Linux Kernel Network Developers, Andrey Konovalov
In-Reply-To: <3f48c69c-3ff4-f895-3c0f-2e8c9c5f063a@redhat.com>
On Wed, Apr 26, 2017 at 9:46 AM, Jarod Wilson <jarod@redhat.com> wrote:
> On 2017-04-26 12:11 PM, Cong Wang wrote:
>>
>> On Wed, Apr 26, 2017 at 8:55 AM, Jarod Wilson <jarod@redhat.com> wrote:
>>>
>>>
>>> We already have struct sockaddr_storage that could be used throughout
>>> this
>>> set as well. We just converted a few pieces of the bonding driver over to
>>> using it for better support of ipoib bonds, via commit
>>> faeeb317a5615076dff1ff44b51e862e6064dbd0. Might be better to just use
>>> that
>>> in both bonding and team, rather than having different per-driver
>>> structs,
>>> or Yet Another Address Storage implementation.
>>
>>
>> Technically, struct sockaddr_storage is not enough either, given the
>> max is MAX_ADDR_LEN. This is why I gave up on sockaddr_storage.
>
>
> Wait, what? Am I missing something? MAX_ADDR_LEN is 32, and sockaddr_storage
> is a #define for __kernel_sockaddr_storage, which has it's __data member
> defined as being of size 128 - sizeof(unsigned short).
My bad, I thought it is same with sizeof(in6addr) without looking into it.
The question is, why do we waste 126 - 32 = 94 bytes on stack to just
use struct sockaddr_storage?
I totally understand we want a unified struct, but we already redefine
it in multiple places in tree...
^ permalink raw reply
* [PATCH] net: hso: register netdev later to avoid a race condition
From: Andreas Kemnade @ 2017-04-26 17:26 UTC (permalink / raw)
To: davem, joe, gregkh, peter, hns, linux-usb, netdev, linux-kernel
Cc: Andreas Kemnade
If the netdev is accessed before the urbs are initialized,
there will be NULL pointer dereferences. That is avoided by
registering it when it is fully initialized.
This case occurs e.g. if dhcpcd is running in the background
and the device is probed, either after insmod hso or
when the device appears on the usb bus.
A backtrace is the following:
[ 1357.356048] usb 1-2: new high-speed USB device number 12 using ehci-omap
[ 1357.551177] usb 1-2: New USB device found, idVendor=0af0, idProduct=8800
[ 1357.558654] usb 1-2: New USB device strings: Mfr=3, Product=2, SerialNumber=0
[ 1357.568572] usb 1-2: Product: Globetrotter HSUPA Modem
[ 1357.574096] usb 1-2: Manufacturer: Option N.V.
[ 1357.685882] hso 1-2:1.5: Not our interface
[ 1460.886352] hso: unloaded
[ 1460.889984] usbcore: deregistering interface driver hso
[ 1513.769134] hso: ../drivers/net/usb/hso.c: Option Wireless
[ 1513.846771] Unable to handle kernel NULL pointer dereference at virtual address 00000030
[ 1513.887664] hso 1-2:1.5: Not our interface
[ 1513.906890] usbcore: registered new interface driver hso
[ 1513.937988] pgd = ecdec000
[ 1513.949890] [00000030] *pgd=acd15831, *pte=00000000, *ppte=00000000
[ 1513.956573] Internal error: Oops: 817 [#1] PREEMPT SMP ARM
[ 1513.962371] Modules linked in: hso usb_f_ecm omap2430 bnep bluetooth g_ether usb_f_rndis u_ether libcomposite configfs ipv6 arc4 wl18xx wlcore mac80211 cfg80211 bq27xxx_battery panel_tpo_td028ttec1 omapdrm drm_kms_helper cfbfillrect snd_soc_simple_card syscopyarea cfbimgblt snd_soc_simple_card_utils sysfillrect sysimgblt fb_sys_fops snd_soc_omap_twl4030 cfbcopyarea encoder_opa362 drm twl4030_madc_hwmon wwan_on_off snd_soc_gtm601 pwm_omap_dmtimer generic_adc_battery connector_analog_tv pwm_bl extcon_gpio omap3_isp wlcore_sdio videobuf2_dma_contig videobuf2_memops w1_bq27000 videobuf2_v4l2 videobuf2_core omap_hdq snd_soc_omap_mcbsp ov9650 snd_soc_omap bmp280_i2c bmg160_i2c v4l2_common snd_pcm_dmaengine bmp280 bmg160_core at24 bmc150_magn_i2c nvmem_core videodev phy_twl4030_usb bmc150_acce
l_i2c tsc2007
[ 1514.037384] bmc150_magn bmc150_accel_core media leds_tca6507 bno055 industrialio_triggered_buffer kfifo_buf gpio_twl4030 musb_hdrc snd_soc_twl4030 twl4030_vibra twl4030_madc twl4030_pwrbutton twl4030_charger industrialio w2sg0004 ehci_omap omapdss [last unloaded: hso]
[ 1514.062622] CPU: 0 PID: 3433 Comm: dhcpcd Tainted: G W 4.11.0-rc8-letux+ #1
[ 1514.071136] Hardware name: Generic OMAP36xx (Flattened Device Tree)
[ 1514.077758] task: ee748240 task.stack: ecdd6000
[ 1514.082580] PC is at hso_start_net_device+0x50/0xc0 [hso]
[ 1514.088287] LR is at hso_net_open+0x68/0x84 [hso]
[ 1514.093231] pc : [<bf79c304>] lr : [<bf79ced8>] psr: a00f0013
sp : ecdd7e20 ip : 00000000 fp : ffffffff
[ 1514.105316] r10: 00000000 r9 : ed0e080c r8 : ecd8fe2c
[ 1514.110839] r7 : bf79cef4 r6 : ecd8fe00 r5 : 00000000 r4 : ed0dbd80
[ 1514.117706] r3 : 00000000 r2 : c0020c80 r1 : 00000000 r0 : ecdb7800
[ 1514.124572] Flags: NzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none
[ 1514.132110] Control: 10c5387d Table: acdec019 DAC: 00000051
[ 1514.138153] Process dhcpcd (pid: 3433, stack limit = 0xecdd6218)
[ 1514.144470] Stack: (0xecdd7e20 to 0xecdd8000)
[ 1514.149078] 7e20: ed0dbd80 ecd8fe98 00000001 00000000 ecd8f800 ecd8fe00 ecd8fe60 00000000
[ 1514.157714] 7e40: ed0e080c bf79ced8 bf79ce70 ecd8f800 00000001 bf7a0258 ecd8f830 c068d958
[ 1514.166320] 7e60: c068d8b8 ecd8f800 00000001 00001091 00001090 c068dba4 ecd8f800 00001090
[ 1514.174926] 7e80: ecd8f940 ecd8f800 00000000 c068dc60 00000000 00000001 ed0e0800 ecd8f800
[ 1514.183563] 7ea0: 00000000 c06feaa8 c0ca39c2 beea57dc 00000020 00000000 306f7368 00000000
[ 1514.192169] 7ec0: 00000000 00000000 00001091 00000000 00000000 00000000 00000000 00008914
[ 1514.200805] 7ee0: eaa9ab60 beea57dc c0c9bfc0 eaa9ab40 00000006 00000000 00046858 c066a948
[ 1514.209411] 7f00: beea57dc eaa9ab60 ecc6b0c0 c02837b0 00000006 c0282c90 0000c000 c0283654
[ 1514.218017] 7f20: c09b0c00 c098bc31 00000001 c0c5e513 c0c5e513 00000000 c0151354 c01a20c0
[ 1514.226654] 7f40: c0c5e513 c01a3134 ecdd6000 c01a3160 ee7487f0 600f0013 00000000 ee748240
[ 1514.235260] 7f60: ee748734 00000000 ecc6b0c0 ecc6b0c0 beea57dc 00008914 00000006 00000000
[ 1514.243896] 7f80: 00046858 c02837b0 00001091 0003a1f0 00046608 0003a248 00000036 c01071e4
[ 1514.252502] 7fa0: ecdd6000 c0107040 0003a1f0 00046608 00000006 00008914 beea57dc 00001091
[ 1514.261108] 7fc0: 0003a1f0 00046608 0003a248 00000036 0003ac0c 00046608 00046610 00046858
[ 1514.269744] 7fe0: 0003a0ac beea57d4 000167eb b6f23106 400f0030 00000006 00000000 00000000
[ 1514.278411] [<bf79c304>] (hso_start_net_device [hso]) from [<bf79ced8>] (hso_net_open+0x68/0x84 [hso])
[ 1514.288238] [<bf79ced8>] (hso_net_open [hso]) from [<c068d958>] (__dev_open+0xa0/0xf4)
[ 1514.296600] [<c068d958>] (__dev_open) from [<c068dba4>] (__dev_change_flags+0x8c/0x130)
[ 1514.305023] [<c068dba4>] (__dev_change_flags) from [<c068dc60>] (dev_change_flags+0x18/0x48)
[ 1514.313934] [<c068dc60>] (dev_change_flags) from [<c06feaa8>] (devinet_ioctl+0x348/0x714)
[ 1514.322540] [<c06feaa8>] (devinet_ioctl) from [<c066a948>] (sock_ioctl+0x2b0/0x308)
[ 1514.330627] [<c066a948>] (sock_ioctl) from [<c0282c90>] (vfs_ioctl+0x20/0x34)
[ 1514.338165] [<c0282c90>] (vfs_ioctl) from [<c0283654>] (do_vfs_ioctl+0x82c/0x93c)
[ 1514.346038] [<c0283654>] (do_vfs_ioctl) from [<c02837b0>] (SyS_ioctl+0x4c/0x74)
[ 1514.353759] [<c02837b0>] (SyS_ioctl) from [<c0107040>] (ret_fast_syscall+0x0/0x1c)
[ 1514.361755] Code: e3822103 e3822080 e1822781 e5981014 (e5832030)
[ 1514.510833] ---[ end trace dfb3e53c657f34a0 ]---
Reported-by: H. Nikolaus Schaller <hns@goldelico.com>
Signed-off-by: Andreas Kemnade <andreas@kemnade.info>
---
drivers/net/usb/hso.c | 14 +++++++-------
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/net/usb/hso.c b/drivers/net/usb/hso.c
index 93411a3..00067a0 100644
--- a/drivers/net/usb/hso.c
+++ b/drivers/net/usb/hso.c
@@ -2534,13 +2534,6 @@ static struct hso_device *hso_create_net_device(struct usb_interface *interface,
SET_NETDEV_DEV(net, &interface->dev);
SET_NETDEV_DEVTYPE(net, &hso_type);
- /* registering our net device */
- result = register_netdev(net);
- if (result) {
- dev_err(&interface->dev, "Failed to register device\n");
- goto exit;
- }
-
/* start allocating */
for (i = 0; i < MUX_BULK_RX_BUF_COUNT; i++) {
hso_net->mux_bulk_rx_urb_pool[i] = usb_alloc_urb(0, GFP_KERNEL);
@@ -2560,6 +2553,13 @@ static struct hso_device *hso_create_net_device(struct usb_interface *interface,
add_net_device(hso_dev);
+ /* registering our net device */
+ result = register_netdev(net);
+ if (result) {
+ dev_err(&interface->dev, "Failed to register device\n");
+ goto exit;
+ }
+
hso_log_port(hso_dev);
hso_create_rfkill(hso_dev, interface);
--
2.1.4
^ permalink raw reply related
* Re: [PATCH v2 2/2] ARM: dts: Add the ethernet and ethernet PHY to the cygnus core DT.
From: Eric Anholt @ 2017-04-26 17:26 UTC (permalink / raw)
To: Florian Fainelli, Vivien Didelot, Andrew Lunn,
netdev-u79uwXL29TY76Z2rM5mHXA, Rob Herring, Mark Rutland,
devicetree-u79uwXL29TY76Z2rM5mHXA
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
bcm-kernel-feedback-list-dY08KVG/lbpWk0Htik3J/w, Ray Jui,
Scott Branden, Jon Mason
In-Reply-To: <0cb00eb7-41d0-0390-4687-d966499ed9f4-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 1564 bytes --]
Florian Fainelli <f.fainelli-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> writes:
> On 04/25/2017 04:53 PM, Eric Anholt wrote:
>> Cygnus has a single AMAC controller connected to the B53 switch with 2
>> PHYs. On the BCM911360_EP platform, those two PHYs are connected to
>> the external ethernet jacks.
>>
>> Signed-off-by: Eric Anholt <eric-WhKQ6XTQaPysTnJN9+BGXg@public.gmane.org>
>> Reviewed-by: Florian Fainelli <f.fainelli-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
>> ---
>>
>> v2: Call the node "switch", just call the ports "port" (suggestions by
>> Florian), drop max-speed on the phys (suggestion by Andrew Lunn),
>> call the other nodes "ethernet" and "ethernet-phy" (suggestions by
>> Sergei Shtylyov)
>>
>> arch/arm/boot/dts/bcm-cygnus.dtsi | 58 ++++++++++++++++++++++++++++++++++
>> arch/arm/boot/dts/bcm911360_entphn.dts | 8 +++++
>> 2 files changed, 66 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/bcm-cygnus.dtsi b/arch/arm/boot/dts/bcm-cygnus.dtsi
>> index 009f1346b817..9fd89be0f5e0 100644
>> --- a/arch/arm/boot/dts/bcm-cygnus.dtsi
>> +++ b/arch/arm/boot/dts/bcm-cygnus.dtsi
>> @@ -142,6 +142,54 @@
>> interrupts = <0>;
>> };
>>
>> + mdio: mdio@18002000 {
>> + compatible = "brcm,iproc-mdio";
>> + reg = <0x18002000 0x8>;
>> + #size-cells = <1>;
>> + #address-cells = <0>;
>
> Sorry for not noticing earlier, since you override this correctly in the
> board-level DTS file can you put a:
>
> status = "disabled"
>
> property in there by default?
Done.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]
^ 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