- 24 Oct, 2017 40 commits
-
-
Yotam Gigi authored
Make the spectrum_mr_tcam.c include the spectrum_mr_tcam.h header file. Cleans up sparse warning: symbol 'mlxsw_sp_mr_tcam_ops' was not declared. Should it be static? Fixes: 0e14c777 ("mlxsw: spectrum: Add the multicast routing hardware logic") Signed-off-by:
Yotam Gigi <yotamg@mellanox.com> Signed-off-by:
Jiri Pirko <jiri@mellanox.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Yotam Gigi authored
The function is only used internally in spectrum_mr.c and is not declared in the header file, thus make it static. Cleans up sparse warning: symbol 'mlxsw_sp_mr_dev_vif_lookup' was not declared. Should it be static? Fixes: c011ec1b ("mlxsw: spectrum: Add the multicast routing offloading logic") Signed-off-by:
-
Yotam Gigi authored
Fix various endianness issues in comparisons and assignments. The fix is entirely cosmetic as all the values fixed are endianness-agnostic. Cleans up sparse warnings: spectrum_mr.c:156:49: warning: restricted __be32 degrades to integer spectrum_mr.c:206:26: warning: restricted __be32 degrades to integer spectrum_mr.c:212:31: warning: incorrect type in assignment (different base types) spectrum_mr.c:212:31: expected restricted __be32 [usertype] addr4 spectrum_mr.c:212:31: got unsigned int spectrum_mr.c:214:32: warning: incorrect type in assignment (different base types) spectrum_mr.c:214:32: expected restricted __be32 [usertype] addr4 spectrum_mr.c:214:32: got unsigned int spectrum_mr.c:461:16: warning: restricted __be32 degrades to integer spectrum_mr.c:461:49: warning: restricted __be32 degrades to integer Fixes: c011ec1b ("mlxsw: spectrum: Add the multicast routing offloading logic") Signed-off-by:
-
Arkadi Sharshevsky authored
During the dump the per netlink packet entry counter should be zeroed out when new packet is created. Fixes: 190d38a5 ("mlxsw: spectrum_dpipe: Add support for adjacency table dump") Signed-off-by:
Arkadi Sharshevsky <arkadis@mellanox.com> Reported-by:
David Ahern <dsahern@gmail.com> Signed-off-by:
-
Or Gerlitz authored
Prior to commit b3f55bdd, the networking core doesn't wire an in-place actions list the when the low level driver is called to offload the flow, but all low level drivers do that (call tcf_exts_to_list()) in their offloading "add" logic. Now, the in-place list is set in the core which goes over the list in a loop, but also by the hw driver when their offloading code is invoked indirectly: cls_xxx add flow -> tc_setup_cb_call -> tc_exts_setup_cb_egdev_call -> hw driver which messes up the core list instance upon driver return. Fix that by avoiding in-place list on the net core code that deals with adding flows. Fixes: b3f55bdd ('net: sched: introduce per-egress action device callbacks') Signed-off-by:
Or Gerlitz <ogerlitz@mellanox.com> Acked-by:
-
Veerasenareddy Burru authored
Pass date and time information to NIC at the time of loading firmware and periodically update the host time to NIC firmware. This is to make NIC firmware use the same time reference as Host, so that it is easy to correlate logs from firmware and host for debugging. Signed-off-by:
Veerasenareddy Burru <veerasenareddy.burru@cavium.com> Signed-off-by:
Felix Manlunas <felix.manlunas@cavium.com> Signed-off-by:
-
Wei Wang authored
In rt6_select(), fn->leaf could be pointing to net->ipv6.ip6_null_entry. In this case, we should directly return instead of trying to carry on with the rest of the process. If not, we could crash at: spin_lock_bh(&leaf->rt6i_table->rt6_lock); because net->ipv6.ip6_null_entry does not have rt6i_table set. Syzkaller recently reported following issue on net-next: Use struct sctp_sack_info instead kasan: CONFIG_KASAN_INLINE enabled kasan: GPF could be caused by NULL-ptr deref or user memory access general protection fault: 0000 [#1] SMP KASAN Dumping ftrace buffer: (ftrace buffer empty) Modules linked in: sctp: [Deprecated]: syz-executor4 (pid 26496) Use of struct sctp_assoc_value in delayed_ack socket option. Use struct sctp_sack_info instead CPU: 1 PID: 26523 Comm: syz-executor6 Not tainted 4.14.0-rc4+ #85 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 task: ffff8801d147e3c0 task.stack: ffff8801a4328000 RIP: 0010:debug_spin_lock_before kernel/locking/spinlock_debug.c:83 [inline] RIP: 0010:do_raw_spin_lock+0x23/0x1e0 kernel/locking/spinlock_debug.c:112 RSP: 0018:ffff8801a432ed70 EFLAGS: 00010207 RAX: dffffc0000000000 RBX: 0000000000000018 RCX: 0000000000000000 RDX: 0000000000000003 RSI: 0000000000000000 RDI: 000000000000001c RBP: ffff8801a432ed90 R08: 0000000000000001 R09: 0000000000000000 R10: 0000000000000000 R11: ffffffff8482b279 R12: ffff8801ce2ff3a0 sctp: [Deprecated]: syz-executor1 (pid 26546) Use of int in maxseg socket option. Use struct sctp_assoc_value instead R13: dffffc0000000000 R14: ffff8801d971e000 R15: ffff8801ce2ff0d8 FS: 00007f56e82f5700(0000) GS:ffff8801db300000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000001ddbc22000 CR3: 00000001a4a04000 CR4: 00000000001406e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: __raw_spin_lock_bh include/linux/spinlock_api_smp.h:136 [inline] _raw_spin_lock_bh+0x39/0x40 kernel/locking/spinlock.c:175 spin_lock_bh include/linux/spinlock.h:321 [inline] rt6_select net/ipv6/route.c:786 [inline] ip6_pol_route+0x1be3/0x3bd0 net/ipv6/route.c:1650 sctp: [Deprecated]: syz-executor1 (pid 26576) Use of int in maxseg socket option. Use struct sctp_assoc_value instead TCP: request_sock_TCPv6: Possible SYN flooding on port 20002. Sending cookies. Check SNMP counters. ip6_pol_route_output+0x4c/0x60 net/ipv6/route.c:1843 fib6_rule_lookup+0x9e/0x2a0 net/ipv6/ip6_fib.c:309 ip6_route_output_flags+0x1f1/0x2b0 net/ipv6/route.c:1871 ip6_route_output include/net/ip6_route.h:80 [inline] ip6_dst_lookup_tail+0x4ea/0x970 net/ipv6/ip6_output.c:953 ip6_dst_lookup_flow+0xc8/0x270 net/ipv6/ip6_output.c:1076 sctp_v6_get_dst+0x675/0x1c30 net/sctp/ipv6.c:274 sctp_transport_route+0xa8/0x430 net/sctp/transport.c:287 sctp_assoc_add_peer+0x4fe/0x1100 net/sctp/associola.c:656 __sctp_connect+0x251/0xc80 net/sctp/socket.c:1187 sctp_connect+0xb4/0xf0 net/sctp/socket.c:4209 inet_dgram_connect+0x16b/0x1f0 net/ipv4/af_inet.c:541 SYSC_connect+0x20a/0x480 net/socket.c:1642 SyS_connect+0x24/0x30 net/socket.c:1623 entry_SYSCALL_64_fastpath+0x1f/0xbe Fixes: 66f5d6ce ("ipv6: replace rwlock with rcu and spinlock in fib6_table") Signed-off-by:
Wei Wang <weiwan@google.com> Acked-by:
Eric Dumazet <edumazet@google.com> Acked-by:
Martin KaFai Lau <kafai@fb.com> Signed-off-by:
-
Christoph Paasch authored
We already allow to enable TFO without a cookie by using the fastopen-sysctl and setting it to TFO_SERVER_COOKIE_NOT_REQD (or TFO_CLIENT_NO_COOKIE). This is safe to do in certain environments where we know that there isn't a malicous host (aka., data-centers) or when the application-protocol already provides an authentication mechanism in the first flight of data. A server however might be providing multiple services or talking to both sides (public Internet and data-center). So, this server would want to enable cookie-less TFO for certain services and/or for connections that go to the data-center. This patch exposes a socket-option and a per-route attribute to enable such fine-grained configurations. Signed-off-by:
Christoph Paasch <cpaasch@apple.com> Reviewed-by:
Yuchung Cheng <ycheng@google.com> Signed-off-by:
-
Tim Hansen authored
Mark hlist node in sk rcu iterator as protected by the rcu. hlist_next_rcu accomplishes this and silences the warnings sparse throws. Found with make C=1 net/ipv4/udp.o on linux-next tag next-20171009. Signed-off-by:
Tim Hansen <devtimhansen@gmail.com> Signed-off-by:
-
Gustavo A. R. Silva authored
Use BUG_ON instead of if condition followed by BUG in tcp_time_wait. This issue was detected with the help of Coccinelle. Signed-off-by:
Gustavo A. R. Silva <garsilva@embeddedor.com> Signed-off-by:
-
Gustavo A. R. Silva authored
Use BUG_ON instead of if condition followed by BUG in icmp_timestamp. This issue was detected with the help of Coccinelle. Signed-off-by:
-
Jesper Dangaard Brouer authored
As pointed out by Michael, commit 1c601d82 ("bpf: cpumap xdp_buff to skb conversion and allocation") contains a classical example of the potential lost wake-up problem. We need to recheck the condition __ptr_ring_empty() after changing current->state to TASK_INTERRUPTIBLE, this avoids a race between wake_up_process() and schedule(). After this, a race with wake_up_process() will simply change the state to TASK_RUNNING, and the schedule() call not really put us to sleep. Fixes: 1c601d82 ("bpf: cpumap xdp_buff to skb conversion and allocation") Reported-by:
"Michael S. Tsirkin" <mst@redhat.com> Signed-off-by:
Jesper Dangaard Brouer <brouer@redhat.com> Signed-off-by:
-
Gustavo A. R. Silva authored
In preparation to enabling -Wimplicit-fallthrough, mark switch cases where we are expecting to fall through. Notice that in this particular case I placed the "fall through" comment on its own line, which is what GCC is expecting to find. Signed-off-by:
-
Gustavo A. R. Silva authored
In preparation to enabling -Wimplicit-fallthrough, mark switch cases where we are expecting to fall through. Signed-off-by:
-
David S. Miller authored
Eric Dumazet says: ==================== ipv6: addrconf: hash improvements and cleanups Remove unecessary BH blocking, and bring IPv6 addrconf to modern world, with per netns hash perturbation and decent hash size. ==================== Signed-off-by: -
Eric Dumazet authored
rcu_read_lock() is enough here, no need to block BH. Signed-off-by:
-
Eric Dumazet authored
Table is really RCU protected, no need to block BH Signed-off-by:
-
Eric Dumazet authored
rcu_read_lock() is enough here, no need to block BH. Signed-off-by:
-
Eric Dumazet authored
rcu_read_lock() is enough here, as inet6_ifa_finish_destroy() uses kfree_rcu() Signed-off-by:
-
Eric Dumazet authored
Bring IPv6 in par with IPv4 : - Use net_hash_mix() to spread addresses a bit more. - Use 256 slots hash table instead of 16 Signed-off-by:
-
Eric Dumazet authored
ipv6_add_addr_hash() can compute the hash value outside of locked section and pass it to ipv6_chk_same_addr(). Signed-off-by:
-
Eric Dumazet authored
ipv6_chk_same_addr() is only used by ipv6_add_addr_hash(), so moving it avoids a forward declaration. Signed-off-by:
-
David S. Miller authored
Jakub Kicinski says: ==================== nfp: bpf: stack support in offload This series brings stack support for offload. We use the LMEM (Local memory) register file as memory to store the stack. Since this is a register file we need to do appropriate shifts on unaligned accesses. Verifier's state tracking helps us with that. LMEM can't be accessed directly, so we add support for setting pointer registers through which one can read/write LMEM. This set does not support accessing the stack when the alignment is not known. This can be added later (most likely using the byte_align instructions). There is also a number of optimizations which have been left out: - in more complex non aligned accesses, double shift and rotation can save us a cycle. This, however, leads to code explosion since all access sizes have to be coded separately; - since setting LM pointers costs around 5 cycles, we should be tracking their values to make sure we don't move them when they're already set correctly for earlier access; - in case of 8 byte access aligned to 4 bytes and crossing 32 byte boundary but not crossing a 64 byte boundary we don't have to increment the pointer, but this seems like a pretty rare case to justify the added complexity. ==================== Signed-off-by: -
Jakub Kicinski authored
Loading 64bit constants require up to 4 load immediates, since we can only load 16 bits at a time. If the 32bit halves of the 64bit constant are the same, however, we can save a cycle by doing a register move instead of two loads of 16 bits. Note that we don't optimize the normal ALU64 load because even though it's a 64 bit load the upper half of the register is a coming from sign extension so we can load it in one cycle anyway. Signed-off-by:
Jakub Kicinski <jakub.kicinski@netronome.com> Reviewed-by:
Quentin Monnet <quentin.monnet@netronome.com> Signed-off-by:
-
Jakub Kicinski authored
If stack pointer has a different value on different paths but the alignment to words (4B) remains the same, we can set a new LMEM access pointer to the calculated value and access whichever word it's pointing to. Signed-off-by:
-
Jakub Kicinski authored
To access beyond 64th byte of the stack we need to set a new stack pointer register (LMEM is accessed indirectly through those pointers). Add a function for encoding local CSR access instruction. Use stack pointer number 3. Note that stack pointer registers allow us to index into 32 bytes of LMEM (with shift operations i.e. when operands are restricted). This means if access is crossing 32 byte boundary we must not use offsetting, we have to set the pointer to the exact address and move it with post-increments. We depend on the datapath placing the stack base address in GPR A22 for our use. Signed-off-by:
-
Jakub Kicinski authored
As long as the verifier tells us the stack offset exactly we can render the LMEM reads quite easily. Simply make sure that the offset is constant for a given instruction and add it to the instruction's offset. Signed-off-by:
-
Jakub Kicinski authored
When we are performing unaligned stack accesses in the 32-64B window we have to do a read-modify-write cycle. E.g. for reading 8 bytes from address 17: 0: tmp = stack[16] 1: gprLo = tmp >> 8 2: tmp = stack[20] 3: gprLo |= tmp << 24 4: tmp = stack[20] 5: gprHi = tmp >> 8 6: tmp = stack[24] 7: gprHi |= tmp << 24 The load on line 4 is unnecessary, because tmp already contains data from stack[20]. For write we can optimize both loads and writebacks away. Signed-off-by:
-
Jakub Kicinski authored
Add simple stack read support, similar to write in every aspect, but data flowing the other way. Note that unlike write which can be done in smaller than word quantities, if registers are loaded with less-than-word of stack contents - the values have to be zero extended. Signed-off-by:
-
Jakub Kicinski authored
Stack is implemented by the LMEM register file. Unaligned accesses to LMEM are not allowed. Accesses also have to be 4B wide. To support stack we need to make sure offsets of pointers are known at translation time (for now) and perform correct load/mask/shift operations. Since we can access first 64B of LMEM without much effort support only stacks not bigger than 64B. Following commits will extend the possible sizes beyond that. Signed-off-by:
-
Jakub Kicinski authored
nfp_bpf_check_ptr() mostly looks at the pointer register. Add a temporary variable to shorten the code. While at it make sure we print error messages if translation fails to help users identify the problem (to be carried in ext_ack in due course). Signed-off-by:
-
Jakub Kicinski authored
The need to emitting a few nops will become more common soon as we add stack and map support. Add a helper. This allows for code to be shorter but also may be handy for marking the nops with a "reason" to ease applying optimizations. Signed-off-by:
-
David S. Miller authored
Jakub Kicinski says: ==================== tools: bpftool: Add JSON output to bpftool Quentin says: This series introduces support for JSON output to all bpftool commands. It adds option parsing, and several options are created: * -j, --json Switch to JSON output. * -p, --pretty Switch to JSON and print it in a human-friendly fashion. * -h, --help Print generic help message. * -V, --version Print version number. This code uses a "json_writer", which is a copy of the one written by Stephen Hemminger in iproute2. --- I don't know if there is an easy way to share the code for json_write without copying the file, so I am very open to suggestions on this matter. ==================== Acked-by:
Alexei Starovoitov <ast@kernel.org> Signed-off-by:
-
Quentin Monnet authored
Update the documentation to provide help about JSON output generation, and add an example in bpftool-prog manual page. Also reintroduce an example that was left aside when the tool was moved from GitHub to the kernel sources, in order to show how to mount the bpffs file system (to pin programs) inside the bpftool-prog manual page. Signed-off-by:
Daniel Borkmann <daniel@iogearbox.net> Signed-off-by:
-
Quentin Monnet authored
Make the look-and-feel of the manual pages somewhat closer to other manual pages, such as the ones from the utilities from iproute2, by highlighting more keywords. Signed-off-by:
-
Quentin Monnet authored
As all commands can now return JSON output (possibly just a "null" value), output of `bpftool --json batch file FILE` should also be fully JSON compliant. Signed-off-by:
-
Quentin Monnet authored
Turn err() and info() macros into functions. In order to avoid naming conflicts with variables in the code, rename them as p_err() and p_info() respectively. The behavior of these functions is similar to the one of the macros for plain output. However, when JSON output is requested, these macros return a JSON-formatted "error" object instead of printing a message to stderr. To handle error messages correctly with JSON, a modification was brought to their behavior nonetheless: the functions now append a end-of-line character at the end of the message. This way, we can remove end-of-line characters at the end of the argument strings, and not have them in the JSON output. All error messages are formatted to hold in a single call to p_err(), in order to produce a single JSON field. Signed-off-by:
-
Quentin Monnet authored
`bpftool batch file FILE` takes FILE as an argument and executes all the bpftool commands it finds inside (or stops if an error occurs). To obtain a consistent JSON output, create a root JSON array, then for each command create a new object containing two fields: one with the command arguments, the other with the output (which is the JSON object that the command would have produced, if called on its own). Signed-off-by:
-
Quentin Monnet authored
Reuse the json_writer API introduced in an earlier commit to make bpftool able to generate JSON output on `bpftool map { show | dump | lookup | getnext }` commands. Remaining commands produce no output. Some functions have been spit into plain-output and JSON versions in order to remain readable. Outputs for sample maps have been successfully tested against a JSON validator. Signed-off-by: -
Quentin Monnet authored
Add a new printing function to dump translated eBPF instructions as JSON. As for plain output, opcodes are printed only on request (when `opcodes` is provided on the command line). The disassembled output is generated by the same code that is used by the kernel verifier. Example output: $ bpftool --json --pretty prog dump xlated id 1 [{ "disasm": "(bf) r6 = r1" },{ "disasm": "(61) r7 = *(u32 *)(r6 +16)" },{ "disasm": "(95) exit" } ] $ bpftool --json --pretty prog dump xlated id 1 opcodes [{ "disasm": "(bf) r6 = r1", "opcodes": { "code": "0xbf", "src_reg": "0x1", "dst_reg": "0x6", "off": ["0x00","0x00" ], "imm": ["0x00","0x00","0x00","0x00" ] } },{ "disasm": "(61) r7 = *(u32 *)(r6 +16)", "opcodes": { "code": "0x61", "src_reg": "0x6", "dst_reg": "0x7", "off": ["0x10","0x00" ], "imm": ["0x00","0x00","0x00","0x00" ] } },{ "disasm": "(95) exit", "opcodes": { "code": "0x95", "src_reg": "0x0", "dst_reg": "0x0", "off": ["0x00","0x00" ], "imm": ["0x00","0x00","0x00","0x00" ] } } ] Signed-off-by:
-
