- 16 Jun, 2016 13 commits
-
-
Arnd Bergmann authored
When building with -Wextra, we get a harmless warning from the EFX_EXTRACT_OWORD32 macro: ethernet/sfc/farch.c: In function 'efx_farch_test_registers': ethernet/sfc/farch.c:119:30: error: comparison of unsigned expression < 0 is always false [-Werror=type-limits] ethernet/sfc/farch.c:124:144: error: comparison of unsigned expression < 0 is always false [-Werror=type-limits] ethernet/sfc/farch.c:124:392: error: comparison of unsigned expression < 0 is always false [-Werror=type-limits] ethernet/sfc/farch.c:124:731: error: comparison of unsigned expression < 0 is always false [-Werror=type-limits] The macro and the caller are both correct, but we can avoid the warning by changing the index variable to a signed type. Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Acked-by:
Bert Kenward <bkenward@solarflare.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
David S. Miller authored
Hayes Wang says: ==================== r8152: fix known issues These patches fix some known issues. ==================== Signed-off-by: -
hayeswang authored
The rx early size should be (agg_buf_sz - packet size) / 8 Signed-off-by:
Hayes Wang <hayeswang@realtek.com> Signed-off-by:
-
hayeswang authored
Reset the BMU to clear the rx/tx fifo. This avoids that the unexpected data remains in the hw. Signed-off-by:
-
hayeswang authored
Disable MAC clock speed down. It may casue the first control transfer to contain the wrong data, when the power state change from U1 to U0. Signed-off-by:
-
David S. Miller authored
Alexei Starovoitov says: ==================== bpf fixes Fixes for two bpf bugs: 1st bug reported by Sasha Goldshtein here: https://github.com/iovisor/bcc/issues/570 2nd discovered by Daniel Borkmann by manual code analysis. See patches for details. ==================== Signed-off-by:
-
Alexei Starovoitov authored
similar to bpf_perf_event_output() the bpf_perf_event_read() helper needs to check the type of the perf_event before reading the counter. Fixes: a43eec30 ("bpf: introduce bpf_perf_event_output() helper") Reported-by:
Daniel Borkmann <daniel@iogearbox.net> Signed-off-by:
Alexei Starovoitov <ast@kernel.org> Acked-by:
-
Alexei Starovoitov authored
The ctx structure passed into bpf programs is different depending on bpf program type. The verifier incorrectly marked ctx->data and ctx->data_end access based on ctx offset only. That caused loads in tracing programs int bpf_prog(struct pt_regs *ctx) { .. ctx->ax .. } to be incorrectly marked as PTR_TO_PACKET which later caused verifier to reject the program that was actually valid in tracing context. Fix this by doing program type specific matching of ctx offsets. Fixes: 969bf05e ("bpf: direct packet access") Reported-by:Sasha Goldshtein <goldshtn@gmail.com> Signed-off-by:
-
Eric Dumazet authored
1) gre_parse_header() can be called from gre_err() At this point transport header points to ICMP header, not the inner header. 2) We can not really change transport header as ipgre_err() will later assume transport header still points to ICMP header (using icmp_hdr()) 3) pskb_may_pull() logic in gre_parse_header() really works if we are interested at zone pointed by skb->data 4) As Jiri explained in commit b7f8fe25 ("gre: do not pull header in ICMP error processing") we should not pull headers in error handler. So this fix : A) changes gre_parse_header() to use skb->data instead of skb_transport_header() B) Adds a nhs parameter to gre_parse_header() so that we can skip the not pulled IP header from error path. This offset is 0 for normal receive path. C) remove obsolete IPV6 includes Signed-off-by:
Eric Dumazet <edumazet@google.com> Cc: Tom Herbert <tom@herbertland.com> Cc: Maciej Żenczykowski <maze@google.com> Cc: Jiri Benc <jbenc@redhat.com> Signed-off-by:
-
Jason A. Donenfeld authored
The implementation of net_dbg_ratelimited in the CONFIG_DYNAMIC_DEBUG case was added with 2c94b537 ("net: Implement net_dbg_ratelimited() for CONFIG_DYNAMIC_DEBUG case"). The implementation strategy was to take the usual definition of the dynamic_pr_debug macro, but alter it by adding a call to "net_ratelimit()" in the if statement. This is, in fact, the correct approach. However, while doing this, the author of the commit forgot to surround fmt by pr_fmt, resulting in unprefixed log messages appearing in the console. So, this commit adds back the pr_fmt(fmt) invocation, making net_dbg_ratelimited properly consistent across DEBUG, no DEBUG, and DYNAMIC_DEBUG cases, and bringing parity with the behavior of dynamic_pr_debug as well. Fixes: 2c94b537 ("net: Implement net_dbg_ratelimited() for CONFIG_DYNAMIC_DEBUG case") Signed-off-by:
Jason A. Donenfeld <Jason@zx2c4.com> Cc: Tim Bingham <tbingham@akamai.com> Signed-off-by:
-
Arnd Bergmann authored
The skfp driver has been moved to drivers/net/fddi/skfp a long time ago, but we still attempt to include headers from the old location, which causes a warning when building with W=1: cc1: error: /git/arm-soc/drivers/net/skfp: No such file or directory [-Werror=missing-include-dirs] cc1: error: drivers/net/skfp: No such file or directory [-Werror=missing-include-dirs] Clearly this include directive is not needed any more, so we can just remove it now. Signed-off-by:
-
Ying Xue authored
net/tipc/link.c: In function ‘tipc_link_timeout’: net/tipc/link.c:744:28: warning: ‘mtyp’ may be used uninitialized in this function [-Wuninitialized] Fixes: 42b18f60 ("tipc: refactor function tipc_link_timeout()") Acked-by:
Jon Maloy <jon.maloy@ericsson.com> Signed-off-by:
Ying Xue <ying.xue@windriver.com> Signed-off-by:
-
Ying Xue authored
When run tipcTS&tipcTC test suite, the following complaint appears: [ 56.926168] =============================== [ 56.926169] [ INFO: suspicious RCU usage. ] [ 56.926171] 4.7.0-rc1+ #160 Not tainted [ 56.926173] ------------------------------- [ 56.926174] net/tipc/bearer.c:408 suspicious rcu_dereference_protected() usage! [ 56.926175] [ 56.926175] other info that might help us debug this: [ 56.926175] [ 56.926177] [ 56.926177] rcu_scheduler_active = 1, debug_locks = 1 [ 56.926179] 3 locks held by swapper/4/0: [ 56.926180] #0: (((&req->timer))){+.-...}, at: [<ffffffff810e79b5>] call_timer_fn+0x5/0x340 [ 56.926203] #1: (&(&req->lock)->rlock){+.-...}, at: [<ffffffffa000c29b>] disc_timeout+0x1b/0xd0 [tipc] [ 56.926212] #2: (rcu_read_lock){......}, at: [<ffffffffa00055e0>] tipc_bearer_xmit_skb+0xb0/0x2e0 [tipc] [ 56.926218] [ 56.926218] stack backtrace: [ 56.926221] CPU: 4 PID: 0 Comm: swapper/4 Not tainted 4.7.0-rc1+ #160 [ 56.926222] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2007 [ 56.926224] 0000000000000000 ffff880016803d28 ffffffff813c4423 ffff8800154252c0 [ 56.926227] 0000000000000001 ffff880016803d58 ffffffff810b7512 ffff8800124d8120 [ 56.926230] ffff880013f8a160 ffff8800132b5ccc ffff8800124d8120 ffff880016803d88 [ 56.926234] Call Trace: [ 56.926235] <IRQ> [<ffffffff813c4423>] dump_stack+0x67/0x94 [ 56.926250] [<ffffffff810b7512>] lockdep_rcu_suspicious+0xe2/0x120 [ 56.926256] [<ffffffffa00051f1>] tipc_l2_send_msg+0x131/0x1c0 [tipc] [ 56.926261] [<ffffffffa000567c>] tipc_bearer_xmit_skb+0x14c/0x2e0 [tipc] [ 56.926266] [<ffffffffa00055e0>] ? tipc_bearer_xmit_skb+0xb0/0x2e0 [tipc] [ 56.926273] [<ffffffffa000c280>] ? tipc_disc_init_msg+0x1f0/0x1f0 [tipc] [ 56.926278] [<ffffffffa000c280>] ? tipc_disc_init_msg+0x1f0/0x1f0 [tipc] [ 56.926283] [<ffffffffa000c2d6>] disc_timeout+0x56/0xd0 [tipc] [ 56.926288] [<ffffffff810e7a68>] call_timer_fn+0xb8/0x340 [ 56.926291] [<ffffffff810e79b5>] ? call_timer_fn+0x5/0x340 [ 56.926296] [<ffffffffa000c280>] ? tipc_disc_init_msg+0x1f0/0x1f0 [tipc] [ 56.926300] [<ffffffff810e8f4a>] run_timer_softirq+0x23a/0x390 [ 56.926306] [<ffffffff810f89ff>] ? clockevents_program_event+0x7f/0x130 [ 56.926316] [<ffffffff819727c3>] __do_softirq+0xc3/0x4a2 [ 56.926323] [<ffffffff8106ba5a>] irq_exit+0x8a/0xb0 [ 56.926327] [<ffffffff81972456>] smp_apic_timer_interrupt+0x46/0x60 [ 56.926331] [<ffffffff81970a49>] apic_timer_interrupt+0x89/0x90 [ 56.926333] <EOI> [<ffffffff81027fda>] ? default_idle+0x2a/0x1a0 [ 56.926340] [<ffffffff81027fd8>] ? default_idle+0x28/0x1a0 [ 56.926342] [<ffffffff810289cf>] arch_cpu_idle+0xf/0x20 [ 56.926345] [<ffffffff810adf0f>] default_idle_call+0x2f/0x50 [ 56.926347] [<ffffffff810ae145>] cpu_startup_entry+0x215/0x3e0 [ 56.926353] [<ffffffff81040ad9>] start_secondary+0xf9/0x100 The warning appears as rtnl_dereference() is wrongly used in tipc_l2_send_msg() under RCU read lock protection. Instead the proper usage should be that rcu_dereference_rtnl() is called here. Fixes: 5b7066c3 ("tipc: stricter filtering of packets in bearer layer") Acked-by:
-
- 15 Jun, 2016 14 commits
-
-
David S. Miller authored
Sabrina Dubroca says: ==================== macsec fixes Patch 1 adds rcu_barrier() during module unload to prevent possible panics. Patch 2 allocates memory for scattergather lists and the IV on the heap, since they can escape the current function's context during crypto callbacks. Patch 3 fixes a failure to create secure associations. ==================== Signed-off-by: -
Sabrina Dubroca authored
The ASYNC flag prevents initialization on some physical machines. Fixes: c09440f7 ("macsec: introduce IEEE 802.1AE driver") Signed-off-by:
Sabrina Dubroca <sd@queasysnail.net> Signed-off-by:
-
Sabrina Dubroca authored
For the crypto callbacks to work properly, we cannot have sg and iv on the stack. Use kmalloc instead, with a single allocation for aead_request + scatterlist + iv. Fixes: c09440f7 ("macsec: introduce IEEE 802.1AE driver") Signed-off-by:
Hannes Frederic Sowa <hannes@stressinduktion.org> Signed-off-by:
-
Sabrina Dubroca authored
Without this, the various uses of call_rcu could cause a kernel panic. Fixes: c09440f7 ("macsec: introduce IEEE 802.1AE driver") Signed-off-by:
-
Florian Westphal authored
saw a debug splat: net/include/net/sch_generic.h:287 suspicious rcu_dereference_check() usage! other info that might help us debug this: rcu_scheduler_active = 1, debug_locks = 0 2 locks held by kworker/2:1/710: #0: ("events"){.+.+.+}, at: [<ffffffff8106ca1d>] #1: ((&q->work)){+.+...}, at: [<ffffffff8106ca1d>] process_one_work+0x14d/0x690 Workqueue: events htb_work_func Call Trace: [<ffffffff812dc763>] dump_stack+0x85/0xc2 [<ffffffff8109fee7>] lockdep_rcu_suspicious+0xe7/0x120 [<ffffffff814ced47>] htb_work_func+0x67/0x70 Signed-off-by:Florian Westphal <fw@strlen.de> Acked-by:
Cong Wang <xiyou.wangcong@gmail.com> Signed-off-by:
-
Jamal Hadi Salim authored
This refers to commands to direct action access as follows: sudo tc actions add action drop index 12 sudo tc actions add action pipe index 10 And then dumping them like so: sudo tc actions ls action gact iproute2 worked because it depended on absence of TCA_ACT_TAB TLV as end of message. This fix has been tested with iproute2 and is backward compatible. Signed-off-by:
Jamal Hadi Salim <jhs@mojatatu.com> Acked-by:
-
WANG Cong authored
And avoid calling tcf_hash_check() twice. Fixes: a57f19d3 ("net sched: ipt action fix late binding") Cc: Jamal Hadi Salim <jhs@mojatatu.com> Signed-off-by:
-
Eric Dumazet authored
Now prio_init() can return -ENOMEM, it also has to make sure any allocated qdiscs are freed, since the caller (qdisc_create()) wont call ->destroy() handler for us. More generally, we want a transactional behavior for "tc qdisc change ...", so prio_tune() should not make modifications if any error is returned. It means that we must validate parameters and allocate missing qdisc(s) before taking root qdisc lock exactly once, to not leave the prio qdisc in an intermediate state. Fixes: cbdf4511 ("net_sched: prio: properly report out of memory errors") Signed-off-by:
-
Eric Dumazet authored
Maciej Żenczykowski reported lockdep warning a spinlock was not registered before being held in mlx4_cmd_wake_completions() cmd.context_lock initialization is not at the right place. 1) mlx4_cmd_use_events() can be called multiple times. Calling spin_lock_init() on a live spinlock can lead to hangs. 2) mlx4_cmd_wake_completions() can be called while lock has not been initialized. Lockdep complains, and current logic is not race prone. It seems better to move the initialization earlier in mlx4_load_one() Signed-off-by:
Maciej Żenczykowski <maze@google.com> Cc: Eugenia Emantayev <eugenia@mellanox.com> Cc: Tariq Toukan <tariqt@mellanox.com> Signed-off-by:
-
David S. Miller authored
Nicolas Dichtel says: ==================== ovs: fix rtnl notifications on interface deletion There was no rtnl notifications for interfaces (gre, vxlan, geneve) created by ovs. This problem is fixed by adjusting the creation path. v1 -> v2: - add patch #1 and #4 - rework error handling in patch #2 ==================== Acked-by:
Pravin B Shelar <pshelar@ovn.org> Signed-off-by:
-
Nicolas Dichtel authored
The function geneve_dev_create_fb() (only used by ovs) never calls rtnl_configure_link(). The consequence is that dev->rtnl_link_state is never set to RTNL_LINK_INITIALIZED. During the deletion phase, the function rollback_registered_many() sends a RTM_DELLINK only if dev->rtnl_link_state is set to RTNL_LINK_INITIALIZED. Fixes: e305ac6c ("geneve: Add support to collect tunnel metadata.") CC: Pravin B Shelar <pshelar@nicira.com> CC: Jesse Gross <jesse@nicira.com> CC: Thomas Graf <tgraf@suug.ch> Signed-off-by:
Nicolas Dichtel <nicolas.dichtel@6wind.com> Signed-off-by:
-
Nicolas Dichtel authored
The function gretap_fb_dev_create() (only used by ovs) never calls rtnl_configure_link(). The consequence is that dev->rtnl_link_state is never set to RTNL_LINK_INITIALIZED. During the deletion phase, the function rollback_registered_many() sends a RTM_DELLINK only if dev->rtnl_link_state is set to RTNL_LINK_INITIALIZED. Fixes: b2acd1dc ("openvswitch: Use regular GRE net_device instead of vport") CC: Thomas Graf <tgraf@suug.ch> CC: Pravin B Shelar <pshelar@nicira.com> Signed-off-by:
-
Nicolas Dichtel authored
The function vxlan_dev_create() (only used by ovs) never calls rtnl_configure_link(). The consequence is that dev->rtnl_link_state is never set to RTNL_LINK_INITIALIZED. During the deletion phase, the function rollback_registered_many() sends a RTM_DELLINK only if dev->rtnl_link_state is set to RTNL_LINK_INITIALIZED. Note that the function vxlan_dev_create() is moved after the rtnl stuff so that vxlan_dellink() can be called in this function. Fixes: dcc38c03 ("openvswitch: Re-add CONFIG_OPENVSWITCH_VXLAN") CC: Thomas Graf <tgraf@suug.ch> CC: Pravin B Shelar <pshelar@nicira.com> Signed-off-by:
-
Nicolas Dichtel authored
After ipgre_newlink()/geneve_configure() call, the netdev is registered. Fixes: 7e059158 ("vxlan, gre, geneve: Set a large MTU on ovs-created tunnel devices") CC: David Wragg <david@weave.works> Signed-off-by:
-
- 14 Jun, 2016 8 commits
-
-
Su, Xuemin authored
There is a corner case in which udp packets belonging to a same flow are hashed to different socket when hslot->count changes from 10 to 11: 1) When hslot->count <= 10, __udp_lib_lookup() searches udp_table->hash, and always passes 'daddr' to udp_ehashfn(). 2) When hslot->count > 10, __udp_lib_lookup() searches udp_table->hash2, but may pass 'INADDR_ANY' to udp_ehashfn() if the sockets are bound to INADDR_ANY instead of some specific addr. That means when hslot->count changes from 10 to 11, the hash calculated by udp_ehashfn() is also changed, and the udp packets belonging to a same flow will be hashed to different socket. This is easily reproduced: 1) Create 10 udp sockets and bind all of them to 0.0.0.0:40000. 2) From the same host send udp packets to 127.0.0.1:40000, record the socket index which receives the packets. 3) Create 1 more udp socket and bind it to 0.0.0.0:44096. The number 44096 is 40000 + UDP_HASH_SIZE(4096), this makes the new socket put into the same hslot as the aformentioned 10 sockets, and makes the hslot->count change from 10 to 11. 4) From the same host send udp packets to 127.0.0.1:40000, and the socket index which receives the packets will be different from the one received in step 2. This should not happen as the socket bound to 0.0.0.0:44096 should not change the behavior of the sockets bound to 0.0.0.0:40000. It's the same case for IPv6, and this patch also fixes that. Signed-off-by:
Su, Xuemin <suxm@chinanetcenter.com> Signed-off-by:
-
Eric Dumazet authored
When the qdisc is full, we drop a packet at the head of the queue, queue the current skb and return NET_XMIT_CN Now we track backlog on upper qdiscs, we need to call qdisc_tree_reduce_backlog(), even if the qlen did not change. Fixes: 2ccccf5f ("net_sched: update hierarchical backlog too") Signed-off-by:
-
Feng Tang authored
Commit 26c5f03b uses a new skb allocator to avoid the RFD overflow issue. But from debugging without datasheet, we found the error always happen when the DMA RX address is set to 0x....fc0, which is very likely to be a HW/silicon problem. So one idea is instead of adding a new allocator, why not just hitting the right target by avaiding the error-prone DMA address? This patch will actually * Remove the commit 26c5f03b * Apply rx skb with 64 bytes longer space, and if the allocated skb has a 0x...fc0 address, it will use skb_resever(skb, 64) to advance the address, so that the RX overflow can be avoided. In theory this method should also apply to atl1c driver, which I can't find anyone who can help to test on real devices. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=70761Signed-off-by:
Feng Tang <feng.tang@intel.com> Suggested-by:
Ole Lukoie <olelukoie@mail.ru> Acked-by:
-
Hannes Frederic Sowa authored
Reported-by:
-
Hannes Frederic Sowa authored
Cc: Tom Herbert <tom@herbertland.com> Fixes: 4068579e ("net: Implmement RFC 6936 (zero RX csums for UDP/IPv6") Signed-off-by:
-
Hannes Frederic Sowa authored
Cc: Florent Fourcot <florent.fourcot@enst-bretagne.fr> Fixes: 1d13a96c ("ipv6: tcp: fix flowlabel value in ACK messages send from TIME_WAIT") Signed-off-by:
-
Hannes Frederic Sowa authored
IPv6 ping socket error handler doesn't correctly convert the new 32 bit mtu to host endianness before using. Cc: Lorenzo Colitti <lorenzo@google.com> Fixes: 6d0bfe22 ("net: ipv6: Add IPv6 support to the ping socket.") Signed-off-by:
Lorenzo Colitti <lorenzo@google.com> Signed-off-by:
-
Clemens Gruber authored
Configuring the PHY LED registers for the Marvell 88E1510 and others is not possible, because regardless of the values in marvell,reg-init, it is later overridden in m88e1121_config_aneg with a non-standard default. This patch moves that default configuration to .config_init to allow setting the LED configuration through marvell,reg-init in the device tree, which should override said default if it exists. Signed-off-by:
Clemens Gruber <clemens.gruber@pqgruber.com> Reviewed-by:
Andrew Lunn <andrew@lunn.ch> Signed-off-by:
-
- 13 Jun, 2016 2 commits
-
-
Ivan Khoronzhuk authored
There is no reason to destroy channels that are destroyed while cpdma_ctlr destroy. In this case no need to remember how much channels where created and destroy them by one, as cpdma_ctlr destroys all of them. Signed-off-by:
Ivan Khoronzhuk <ivan.khoronzhuk@linaro.org> Signed-off-by:
-
Eric Dumazet authored
At Qdisc creation or change time, prio_tune() creates missing pfifo qdiscs but does not return an error code if one qdisc could not be allocated. Leaving a qdisc in non operational state without telling user anything about this problem is not good. Also, testing if we replace something different than noop_qdisc a second time makes no sense so I removed useless code. Signed-off-by:
-
- 12 Jun, 2016 1 commit
-
-
David S. Miller authored
>> net/ipv4/ipconfig.c:130:15: warning: 'ic_addrservaddr' defined but not used [-Wunused-variable] static __be32 ic_addrservaddr = NONE; /* IP Address of the IP addresses'server */ Reported-by:kbuild test robot <fengguang.wu@intel.com> Signed-off-by:
-
- 11 Jun, 2016 2 commits
-
-
Manuel Lauss authored
Commit 7f854420 ("phy: Add API for {un}registering an mdio device to a bus.") broke PHY detection on this driver with a copy-paste bug: The code is looking 32 times for a PHY at address 0. Fixes ethernet on AMD DB1100/DB1500/DB1550 boards which have their (autodetected) PHYs at address 31. Cc: Andrew Lunn <andrew@lunn.ch> Signed-off-by:
Manuel Lauss <manuel.lauss@gmail.com> Signed-off-by:
-
David S. Miller authored
This reverts commit a2f27217. I applied the wrong version of this. Signed-off-by:
-
