- 10 Aug, 2017 20 commits
-
-
Florian Westphal authored
David Ahern reports following splat: RTNL: assertion failed at net/core/dev.c (5717) netdev_master_upper_dev_get+0x5f/0x70 if_nlmsg_size+0x158/0x240 rtnl_calcit.isra.26+0xa3/0xf0 rtnl_link_get_slave_info_data_size currently assumes RTNL protection, but there appears to be no hard requirement for this, so use rcu instead. At the time of this writing, there are three 'get_slave_size' callbacks (now invoked under rcu): bond_get_slave_size, vrf_get_slave_size and br_port_get_slave_size, all return constant only (i.e. they don't sleep). Fixes: 6853dd48 ("rtnetlink: protect handler table with rcu") Reported-by:
David Ahern <dsahern@gmail.com> Signed-off-by:
Florian Westphal <fw@strlen.de> Acked-by:
David S. Miller <davem@davemloft.net>
-
Florian Westphal authored
Userspace sends RTM_GETLINK type, but the kernel substracts RTM_BASE from this, i.e. 'type' doesn't contain RTM_GETLINK anymore but instead RTM_GETLINK - RTM_BASE. This caused the calcit callback to not be invoked when it should have been (and vice versa). While at it, also fix a off-by one when checking family index. vs handler array size. Fixes: e1fa6d21 ("rtnetlink: call rtnl_calcit directly") Signed-off-by:
-
Florian Westphal authored
Ido reports a rcu splat in __rtnl_register. The splat is correct; as rtnl_register doesn't grab any logs and doesn't use rcu locks either. It has always been like this. handler families are not registered in parallel so there are no races wrt. the kmalloc ordering. The only reason to use rcu_dereference in the first place was to avoid sparse from complaining about this. Thus this switches to _raw() to not have rcu checks here. The alternative is to add rtnl locking to register/unregister, however, I don't see a compelling reason to do so as this has been lockless for the past twenty years or so. Fixes: 6853dd48 ("rtnetlink: protect handler table with rcu") Reported-by:
Ido Schimmel <idosch@idosch.org> Signed-off-by:
Ido Schimmel <idosch@mellanox.com> Signed-off-by:
-
John Crispin authored
The following error was introduced by commit 43e66528 ("net-next: dsa: fix flow dissection") due to a missing #if guard net/core/flow_dissector.c: In function '__skb_flow_dissect': net/core/flow_dissector.c:448:18: error: 'struct net_device' has no member named 'dsa_ptr' ops = skb->dev->dsa_ptr->tag_ops; ^ make[3]: *** [net/core/flow_dissector.o] Error 1 Signed-off-by:
John Crispin <john@phrozen.org> Signed-off-by:
-
David S. Miller authored
John Crispin says: ==================== net-next: dsa: fix flow dissection RPS and probably other kernel features are currently broken on some if not all DSA devices. The root cause of this is that skb_hash will call the flow_dissector. At this point the skb still contains the magic switch header and the skb->protocol field is not set up to the correct 802.3 value yet. By the time the tag specific code is called, removing the header and properly setting the protocol an invalid hash is already set. In the case of the mt7530 this will result in all flows always having the same hash. Changes since RFC: * use a callback instead of static values * add cover letter ==================== Reviewed-by:
Vivien Didelot <vivien.didelot@savoirfairelinux.com> Signed-off-by:
-
John Crispin authored
RPS and probably other kernel features are currently broken on some if not all DSA devices. The root cause of this is that skb_hash will call the flow_dissector. At this point the skb still contains the magic switch header and the skb->protocol field is not set up to the correct 802.3 value yet. By the time the tag specific code is called, removing the header and properly setting the protocol an invalid hash is already set. In the case of the mt7530 this will result in all flows always having the same hash. Signed-off-by:
Muciri Gatimu <muciri@openmesh.com> Signed-off-by:
Shashidhar Lakkavalli <shashidhar.lakkavalli@openmesh.com> Signed-off-by:
Andrew Lunn <andrew@lunn.ch> Signed-off-by:
-
John Crispin authored
The MT7530 inserts the 4 magic header in between the 802.3 address and protocol field. The patch implements the callback that can be called by the flow dissector to figure out the real protocol and offset of the network header. With this patch applied we can properly parse the packet and thus make hashing function properly. Signed-off-by:
-
John Crispin authored
When the flow dissector first sees packets coming in on a DSA devices the 802.3 header wont be located where the code expects it to be as the tag is still present. Adding this new callback allows a DSA device to provide a new function that the flow_dissector can use to get the correct protocol and offset of the network header. Signed-off-by:
-
John Crispin authored
We need to access this struct from within the flow_dissector to fix dissection for packets coming in on DSA devices. Signed-off-by:
-
David S. Miller authored
John Crispin says: ==================== net-next: mediatek: bring up QDMA RX ring 0 The MT7623 has several DMA rings. Inside the SW path, the core will use the PDMA when receiving traffic. While bringing up the HW path we noticed that the PPE requires the QDMA RX to also be brought up as it uses this ring internally for its flow scheduling. ==================== Signed-off-by: -
John Crispin authored
This patch is in preparation for adding HW flow and QoS offloading. For those features to work, the driver needs to bring up the first QDMA RX ring. This ring is used by the PPE offloading HW. Signed-off-by:
-
John Crispin authored
Trivial patch fixing 2 typos. Signed-off-by:
-
Bhumika Goyal authored
Make these const as they are only stored in the ops field of a atm_dev structure, which is const. Done using Coccinelle. Signed-off-by:
Bhumika Goyal <bhumirks@gmail.com> Signed-off-by:
-
Bhumika Goyal authored
Make these structures const as they are either passed to the function atm_dev_register having the corresponding argument as const or stored in the ops field of a atm_dev structure, which is also const. Done using Coccinelle. Signed-off-by:
-
Bhumika Goyal authored
Make these structures const as they are only stored in the ops field of a dsa_switch structure, which is const. Done using Coccinelle. Signed-off-by:
-
Intiyaz Basha authored
Disable napi when interface is going down. Delete napi when destroying the interface. Signed-off-by:
Intiyaz Basha <intiyaz.basha@cavium.com> Signed-off-by:
Felix Manlunas <felix.manlunas@cavium.com> Signed-off-by:
-
David Ahern authored
ndisc_notify is used to send unsolicited neighbor advertisements (e.g., on a link up). Currently, the ndisc notifier is run before the addrconf notifer which means NA's are not sent for link-local addresses which are added by the addrconf notifier. Fix by lowering the priority of the ndisc notifier. Setting the priority to ADDRCONF_NOTIFY_PRIORITY - 5 means it runs after addrconf and before the route notifier which is ADDRCONF_NOTIFY_PRIORITY - 10. Signed-off-by:
-
Nathan Fontenot authored
Commit a248878d ("ibmvnic: Check for transport event on driver resume") removed the loop to kick irqs on driver resume but didn't remove the now unused loop variable 'i'. Signed-off-by:
Nathan Fontenot <nfont@linux.vnet.ibm.com> Signed-off-by:
-
Nathan Fontenot authored
To ease debugging of the ibmvnic driver add a series of netdev_dbg() statements to track driver status, especially during initialization, removal, and resetting of the driver. Signed-off-by:
-
Nathan Fontenot authored
Ensure that any resources allocated during probe are released if the probe of the driver fails. Signed-off-by:
-
- 09 Aug, 2017 20 commits
-
-
David S. Miller authored
Florian Westphal says: ==================== rtnetlink: allow selected handlers to run without rtnl Changes since v1: In patch 6, don't make ipv6 route handlers lockless, they all have assumptions on rtnl being held. Other patches are unchanged. The RTNL mutex is used to serialize both rtnetlink calls and dump requests. Its also used to protect other things such as the list of current net namespaces. Unfortunately RTNL mutex is a performance issue, e.g. a cpu adding an ip address prevents other cpus from seemingly unrelated tasks such as dumping tc classifiers or doing rtnetlink route lookups. This patch set adds basic infrastructure to start pushing the rtnl lock down to those places that need it, or even elide it entirely in some cases. Subsystems can now indicate that their doit() callback can run without RTNL mutex, such callbacks can then run in parallel. This will obviously need a lot of followup work; all current users need to be audited/changed to benefit from this. Initial no-rtnl spot is netns new/getid. We have various 'get' handlers that are also a tempting target, however, several of these depend on rtnl mutex to prevent information from changing while objects are being read by rtnl handlers; however, it doesn't appear impossible to change this. Dumps are another problem entirely, see commit 2907c35f ("net: hold rtnl again in dump callbacks"), this patchset doesn't touch dump requests. ==================== Signed-off-by:
-
Florian Westphal authored
Both functions take nsid_lock and don't rely on rtnl lock. Signed-off-by:
Hannes Frederic Sowa <hannes@stressinduktion.org> Signed-off-by:
-
Florian Westphal authored
Allow callers to tell rtnetlink core that its doit callback should be invoked without holding rtnl mutex. Signed-off-by:
-
Florian Westphal authored
Note that netlink dumps still acquire rtnl mutex via the netlink dump infrastructure. Signed-off-by:
-
Florian Westphal authored
instead of rtnl lock/unload at the top level, push it down to the called function. This is just an intermediate step, next commit switches protection of the rtnl_link ops table to rcu, in which case (for dumps) the rtnl lock is acquired only by the netlink dumper infrastructure (current lock/unlock/dump/lock/unlock rtnl sequence becomes rcu lock/rcu unlock/dump). Signed-off-by:
-
Florian Westphal authored
I don't see what prevents rmmod (unregister_all is called) while a dump is active. Even if we'd add rtnl lock/unlock pair to unregister_all (as done here), thats not enough either as rtnl_lock is released right before the dump process starts. So this adds a refcount: * acquire rtnl mutex * bump refcount * release mutex * start the dump ... and make unregister_all remove the callbacks (no new dumps possible) and then wait until refcount is 0. Signed-off-by:
-
Florian Westphal authored
This change allows us to later indicate to rtnetlink core that certain doit functions should be called without acquiring rtnl_mutex. This change should have no effect, we simply replace the last (now unused) calcit argument with the new flag. Signed-off-by:
-
Florian Westphal authored
There is only a single place in the kernel that regisers the "calcit" callback (to determine min allocation for dumps). This is in rtnetlink.c for PF_UNSPEC RTM_GETLINK. The function that checks for calcit presence at run time will first check the requested family (which will always fail for !PF_UNSPEC as no callsite registers this), then falls back to checking PF_UNSPEC. Therefore we can just check if type is RTM_GETLINK and then do a direct call. Because of fallback to PF_UNSPEC all RTM_GETLINK types used this regardless of family. This has the advantage that we don't need to allocate space for the function pointer for all the other families. A followup patch will drop the calcit function pointer from the rtnl_link callback structure. Signed-off-by:
-
David S. Miller authored
Daniel Borkmann says: ==================== bpf: Add BPF_J{LT,LE,SLT,SLE} instructions This set adds BPF_J{LT,LE,SLT,SLE} instructions to the BPF insn set, interpreter, JIT hardening code and all JITs are also updated to support the new instructions. Basic idea is to reduce register pressure by avoiding BPF_J{GT,GE,SGT,SGE} rewrites. Removing the workaround for the rewrites in LLVM, this can result in shorter BPF programs, less stack usage and less verification complexity. First patch provides some more details on rationale and integration. Thanks a lot! v1 -> v2: - Reworded commit msg in patch 1 ==================== Signed-off-by: -
Daniel Borkmann authored
Add test cases to the verifier selftest suite in order to verify that i) direct packet access, and ii) dynamic map value access is working with the changes related to the new instructions. Signed-off-by:
Daniel Borkmann <daniel@iogearbox.net> Acked-by:
Alexei Starovoitov <ast@kernel.org> Signed-off-by:
-
Daniel Borkmann authored
Enable the newly added jump opcodes, main parts are in two different areas, namely direct packet access and dynamic map value access. For the direct packet access, we now allow for the following two new patterns to match in order to trigger markings with find_good_pkt_pointers(): Variant 1 (access ok when taking the branch): 0: (61) r2 = *(u32 *)(r1 +76) 1: (61) r3 = *(u32 *)(r1 +80) 2: (bf) r0 = r2 3: (07) r0 += 8 4: (ad) if r0 < r3 goto pc+2 R0=pkt(id=0,off=8,r=0) R1=ctx R2=pkt(id=0,off=0,r=0) R3=pkt_end R10=fp 5: (b7) r0 = 0 6: (95) exit from 4 to 7: R0=pkt(id=0,off=8,r=8) R1=ctx R2=pkt(id=0,off=0,r=8) R3=pkt_end R10=fp 7: (71) r0 = *(u8 *)(r2 +0) 8: (05) goto pc-4 5: (b7) r0 = 0 6: (95) exit processed 11 insns, stack depth 0 Variant 2 (access ok on fall-through): 0: (61) r2 = *(u32 *)(r1 +76) 1: (61) r3 = *(u32 *)(r1 +80) 2: (bf) r0 = r2 3: (07) r0 += 8 4: (bd) if r3 <= r0 goto pc+1 R0=pkt(id=0,off=8,r=8) R1=ctx R2=pkt(id=0,off=0,r=8) R3=pkt_end R10=fp 5: (71) r0 = *(u8 *)(r2 +0) 6: (b7) r0 = 1 7: (95) exit from 4 to 6: R0=pkt(id=0,off=8,r=0) R1=ctx R2=pkt(id=0,off=0,r=0) R3=pkt_end R10=fp 6: (b7) r0 = 1 7: (95) exit processed 10 insns, stack depth 0 The above two basically just swap the branches where we need to handle an exception and allow packet access compared to the two already existing variants for find_good_pkt_pointers(). For the dynamic map value access, we add the new instructions to reg_set_min_max() and reg_set_min_max_inv() in order to learn bounds. Verifier test cases for both are added in a follow-up patch. Signed-off-by:John Fastabend <john.fastabend@gmail.com> Signed-off-by:
-
Daniel Borkmann authored
This work implements jiting of BPF_J{LT,LE} instructions with BPF_X/BPF_K variants for the nfp eBPF JIT. The two BPF_J{SLT,SLE} instructions have not been added yet given BPF_J{SGT,SGE} are not supported yet either. Signed-off-by:Jakub Kicinski <jakub.kicinski@netronome.com> Signed-off-by:
-
Daniel Borkmann authored
This work implements jiting of BPF_J{LT,LE,SLT,SLE} instructions with BPF_X/BPF_K variants for the ppc64 eBPF JIT. Signed-off-by:Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com> Tested-by:
-
Daniel Borkmann authored
This work implements jiting of BPF_J{LT,LE,SLT,SLE} instructions with BPF_X/BPF_K variants for the s390x eBPF JIT. Signed-off-by:Michael Holzheu <holzheu@linux.vnet.ibm.com> Signed-off-by:
-
Daniel Borkmann authored
This work implements jiting of BPF_J{LT,LE,SLT,SLE} instructions with BPF_X/BPF_K variants for the sparc64 eBPF JIT. Signed-off-by: -
Daniel Borkmann authored
This work implements jiting of BPF_J{LT,LE,SLT,SLE} instructions with BPF_X/BPF_K variants for the arm64 eBPF JIT. Signed-off-by: -
Daniel Borkmann authored
This work implements jiting of BPF_J{LT,LE,SLT,SLE} instructions with BPF_X/BPF_K variants for the x86_64 eBPF JIT. Signed-off-by: -
Daniel Borkmann authored
Currently, eBPF only understands BPF_JGT (>), BPF_JGE (>=), BPF_JSGT (s>), BPF_JSGE (s>=) instructions, this means that particularly *JLT/*JLE counterparts involving immediates need to be rewritten from e.g. X < [IMM] by swapping arguments into [IMM] > X, meaning the immediate first is required to be loaded into a register Y := [IMM], such that then we can compare with Y > X. Note that the destination operand is always required to be a register. This has the downside of having unnecessarily increased register pressure, meaning complex program would need to spill other registers temporarily to stack in order to obtain an unused register for the [IMM]. Loading to registers will thus also affect state pruning since we need to account for that register use and potentially those registers that had to be spilled/filled again. As a consequence slightly more stack space might have been used due to spilling, and BPF programs are a bit longer due to extra code involving the register load and potentially required spill/fills. Thus, add BPF_JLT (<), BPF_JLE (<=), BPF_JSLT (s<), BPF_JSLE (s<=) counterparts to the eBPF instruction set. Modifying LLVM to remove the NegateCC() workaround in a PoC patch at [1] and allowing it to also emit the new instructions resulted in cilium's BPF programs that are injected into the fast-path to have a reduced program length in the range of 2-3% (e.g. accumulated main and tail call sections from one of the object file reduced from 4864 to 4729 insns), reduced complexity in the range of 10-30% (e.g. accumulated sections reduced in one of the cases from 116432 to 88428 insns), and reduced stack usage in the range of 1-5% (e.g. accumulated sections from one of the object files reduced from 824 to 784b). The modification for LLVM will be incorporated in a backwards compatible way. Plan is for LLVM to have i) a target specific option to offer a possibility to explicitly enable the extension by the user (as we have with -m target specific extensions today for various CPU insns), and ii) have the kernel checked for presence of the extensions and enable them transparently when the user is selecting more aggressive options such as -march=native in a bpf target context. (Other frontends generating BPF byte code, e.g. ply can probe the kernel directly for its code generation.) [1] https://github.com/borkmann/llvm/tree/bpf-insnsSigned-off-by:
-
David S. Miller authored
Willem de Bruijn says: ==================== net: zerocopy fixes Fix two issues introduced in the msg_zerocopy patchset. ==================== Signed-off-by: -
Willem de Bruijn authored
Do not use uarg->zerocopy outside msg_zerocopy. In other paths the field is not explicitly initialized and aliases another field. Those paths have only one reference so do not need this intermediate variable. Call uarg->callback directly. Fixes: 1f8b977a ("sock: enable MSG_ZEROCOPY") Signed-off-by:
Willem de Bruijn <willemb@google.com> Signed-off-by:
-
