03 May, 2017
10 commits
-
We should call ipxitf_put() if the copy_to_user() fails.
Reported-by: 李强
Signed-off-by: Dan Carpenter
Signed-off-by: David S. Miller -
Jump is now the only one using value action opcode. This is going to
change soon. So introduce helpers to work with this. Convert TC_ACT_JUMP.This also fixes the TC_ACT_JUMP check, which is incorrectly done as a
bit check, not a value check.Fixes: e0ee84ded796 ("net sched actions: Complete the JUMPX opcode")
Signed-off-by: Jiri Pirko
Acked-by: Jamal Hadi Salim
Signed-off-by: David S. Miller -
Sudarsana Reddy Kalluru says:
====================
qed*: PTP bug fixes.The series addresses couple of issues in the PTP implementation.
====================Signed-off-by: David S. Miller
-
PTP hardware filter configuration performed by the driver for a given
user requested config is not correct for some of the PTP modes.
Following changes are needed for PTP config-filter implementation.
1. NIG_REG_TX_PTP_EN register - Bits 0/1/2 respectively enables
TimeSync/"V1 frame format support"/"V2 frame format support" on
the TX side. Set the associated bits based on the user request.
2. ptp4l application fails to operate in Peer Delay mode. Following
changes are needed to fix this,
a. Driver should enable (set to 0) DA #1-related bits for IPv4,
IPv6 and MAC destination addresses in these registers:
NIG_REG_TX_LLH_PTP_RULE_MASK
NIG_REG_LLH_PTP_RULE_MASK
b. NIG_REG_LLH_PTP_PARAM_MASK/NIG_REG_TX_LLH_PTP_PARAM_MASK should
be set to 0x0 in all modes.Signed-off-by: Sudarsana Reddy Kalluru
Signed-off-by: Yuval Mintz
Signed-off-by: David S. Miller -
PTP Tx timestamping data structures are not protected against the
concurrent access in the Tx paths. Protecting the same using atomic
bit locks.Signed-off-by: Sudarsana Reddy Kalluru
Signed-off-by: Yuval Mintz
Signed-off-by: David S. Miller -
The IOT2000 is industrial controller platform, derived from the Intel
Galileo Gen2 board. The variant IOT2020 comes with one LAN port, the
IOT2040 has two of them. They can be told apart based on the board asset
tag in the DMI table.Based on patch by Sascha Weisenberger.
Signed-off-by: Jan Kiszka
Signed-off-by: Sascha Weisenberger
Reviewed-by: Andy Shevchenko
Signed-off-by: David S. Miller -
hns_get_sset_count() returns HNS_NET_STATS_CNT and the data space allocated
is not enough for ethtool_get_strings(), which will cause random memory
corruption.When SLAB and DEBUG_SLAB are both enabled, memory corruptions like the
the following can be observed without this patch:
[ 43.115200] Slab corruption (Not tainted): Acpi-ParseExt start=ffff801fb0b69030, len=80
[ 43.115206] Redzone: 0x9f911029d006462/0x5f78745f31657070.
[ 43.115208] Last user: [](0x5f7272655f746b70)
[ 43.115214] 010: 70 70 65 31 5f 74 78 5f 70 6b 74 00 6b 6b 6b 6b ppe1_tx_pkt.kkkk
[ 43.115217] 030: 70 70 65 31 5f 74 78 5f 70 6b 74 5f 6f 6b 00 6b ppe1_tx_pkt_ok.k
[ 43.115218] Next obj: start=ffff801fb0b69098, len=80
[ 43.115220] Redzone: 0x706d655f6f666966/0x9f911029d74e35b.
[ 43.115229] Last user: [](acpi_os_release_object+0x28/0x38)
[ 43.115231] 000: 74 79 00 6b 6b 6b 6b 6b 70 70 65 31 5f 74 78 5f ty.kkkkkppe1_tx_
[ 43.115232] 010: 70 6b 74 5f 65 72 72 5f 63 73 75 6d 5f 66 61 69 pkt_err_csum_faiSigned-off-by: Timmy Li
Signed-off-by: David S. Miller -
Be careful when comparing tcp_time_stamp to some u32 quantity,
otherwise result can be surprising.Fixes: 7c106d7e782b ("[TCP]: TCP Low Priority congestion control")
Signed-off-by: Eric Dumazet
Signed-off-by: David S. Miller -
When the instruction right before the branch destination is
a 64 bit load immediate, we currently calculate the wrong
jump offset in the ctx->offset[] array as we only account
one instruction slot for the 64 bit load immediate although
it uses two BPF instructions. Fix it up by setting the offset
into the right slot after we incremented the index.Before (ldimm64 test 1):
[...]
00000020: 52800007 mov w7, #0x0 // #0
00000024: d2800060 mov x0, #0x3 // #3
00000028: d2800041 mov x1, #0x2 // #2
0000002c: eb01001f cmp x0, x1
00000030: 54ffff82 b.cs 0x00000020
00000034: d29fffe7 mov x7, #0xffff // #65535
00000038: f2bfffe7 movk x7, #0xffff, lsl #16
0000003c: f2dfffe7 movk x7, #0xffff, lsl #32
00000040: f2ffffe7 movk x7, #0xffff, lsl #48
00000044: d29dddc7 mov x7, #0xeeee // #61166
00000048: f2bdddc7 movk x7, #0xeeee, lsl #16
0000004c: f2ddddc7 movk x7, #0xeeee, lsl #32
00000050: f2fdddc7 movk x7, #0xeeee, lsl #48
[...]After (ldimm64 test 1):
[...]
00000020: 52800007 mov w7, #0x0 // #0
00000024: d2800060 mov x0, #0x3 // #3
00000028: d2800041 mov x1, #0x2 // #2
0000002c: eb01001f cmp x0, x1
00000030: 540000a2 b.cs 0x00000044
00000034: d29fffe7 mov x7, #0xffff // #65535
00000038: f2bfffe7 movk x7, #0xffff, lsl #16
0000003c: f2dfffe7 movk x7, #0xffff, lsl #32
00000040: f2ffffe7 movk x7, #0xffff, lsl #48
00000044: d29dddc7 mov x7, #0xeeee // #61166
00000048: f2bdddc7 movk x7, #0xeeee, lsl #16
0000004c: f2ddddc7 movk x7, #0xeeee, lsl #32
00000050: f2fdddc7 movk x7, #0xeeee, lsl #48
[...]Also, add a couple of test cases to make sure JITs pass
this test. Tested on Cavium ThunderX ARMv8. The added
test cases all pass after the fix.Fixes: 8eee539ddea0 ("arm64: bpf: fix out-of-bounds read in bpf2a64_offset()")
Reported-by: David S. Miller
Signed-off-by: Daniel Borkmann
Acked-by: Alexei Starovoitov
Cc: Xi Wang
Signed-off-by: David S. Miller -
This work adds BPF_XADD for BPF_W/BPF_DW to the arm64 JIT and therefore
completes JITing of all BPF instructions, meaning we can thus also remove
the 'notyet' label and do not need to fall back to the interpreter when
BPF_XADD is used in a program!This now also brings arm64 JIT in line with x86_64, s390x, ppc64, sparc64,
where all current eBPF features are supported.BPF_W example from test_bpf:
.u.insns_int = {
BPF_ALU32_IMM(BPF_MOV, R0, 0x12),
BPF_ST_MEM(BPF_W, R10, -40, 0x10),
BPF_STX_XADD(BPF_W, R10, R0, -40),
BPF_LDX_MEM(BPF_W, R0, R10, -40),
BPF_EXIT_INSN(),
},[...]
00000020: 52800247 mov w7, #0x12 // #18
00000024: 928004eb mov x11, #0xffffffffffffffd8 // #-40
00000028: d280020a mov x10, #0x10 // #16
0000002c: b82b6b2a str w10, [x25,x11]
// start of xadd mapping:
00000030: 928004ea mov x10, #0xffffffffffffffd8 // #-40
00000034: 8b19014a add x10, x10, x25
00000038: f9800151 prfm pstl1strm, [x10]
0000003c: 885f7d4b ldxr w11, [x10]
00000040: 0b07016b add w11, w11, w7
00000044: 880b7d4b stxr w11, w11, [x10]
00000048: 35ffffab cbnz w11, 0x0000003c
// end of xadd mapping:
[...]BPF_DW example from test_bpf:
.u.insns_int = {
BPF_ALU32_IMM(BPF_MOV, R0, 0x12),
BPF_ST_MEM(BPF_DW, R10, -40, 0x10),
BPF_STX_XADD(BPF_DW, R10, R0, -40),
BPF_LDX_MEM(BPF_DW, R0, R10, -40),
BPF_EXIT_INSN(),
},[...]
00000020: 52800247 mov w7, #0x12 // #18
00000024: 928004eb mov x11, #0xffffffffffffffd8 // #-40
00000028: d280020a mov x10, #0x10 // #16
0000002c: f82b6b2a str x10, [x25,x11]
// start of xadd mapping:
00000030: 928004ea mov x10, #0xffffffffffffffd8 // #-40
00000034: 8b19014a add x10, x10, x25
00000038: f9800151 prfm pstl1strm, [x10]
0000003c: c85f7d4b ldxr x11, [x10]
00000040: 8b07016b add x11, x11, x7
00000044: c80b7d4b stxr w11, x11, [x10]
00000048: 35ffffab cbnz w11, 0x0000003c
// end of xadd mapping:
[...]Tested on Cavium ThunderX ARMv8, test suite results after the patch:
No JIT: [ 3751.855362] test_bpf: Summary: 311 PASSED, 0 FAILED, [0/303 JIT'ed]
With JIT: [ 3573.759527] test_bpf: Summary: 311 PASSED, 0 FAILED, [303/303 JIT'ed]Signed-off-by: Daniel Borkmann
Acked-by: Alexei Starovoitov
Signed-off-by: David S. Miller
02 May, 2017
30 commits
-
I say:
====================
Fix some bpf program testing framework bugsThis series fixes two issue:
1) Accidental user pointer dereference in bpf_test_finish()
2) The packet data given to the test programs is not aligned correctly
The first issue is fixed simply because we have a kernel side copy
of the datastructure in question already. And the second bug is
a simple matter of applying NET_IP_ALIGN where needed.
====================Signed-off-by: David S. Miller
-
Make sure we apply NET_IP_ALIGN when reserving headroom for SKB
and XDP test runs, just like a real driver would.Signed-off-by: David S. Miller
Acked-by: Daniel Borkmann -
Instead, pass the kattr in which has a kernel side copy of this
data structure from userspace already.Fix based upon a suggestion from Alexei Starovoitov.
Signed-off-by: David S. Miller
Acked-by: Daniel Borkmann -
This fixes the testcase on big-endian.
Signed-off-by: David S. Miller
-
Fix kdoc parameter spelling from extact to extack.
Signed-off-by: Jakub Kicinski
Signed-off-by: David S. Miller -
Fix the following warnings triggered by 51570a5ab2b7 ("A Sample of
using socket cookie and uid for traffic monitoring"):In file included from /home/foo/net-next/samples/bpf/cookie_uid_helper_example.c:54:0:
/home/foo/net-next/samples/bpf/cookie_uid_helper_example.c: In function 'prog_load':
/home/foo/net-next/samples/bpf/cookie_uid_helper_example.c:119:27: warning: overflow in implicit constant conversion [-Woverflow]
-32 + offsetof(struct stats, uid)),
^
/home/foo/net-next/samples/bpf/libbpf.h:135:12: note: in definition of macro 'BPF_STX_MEM'
.off = OFF, \
^
/home/foo/net-next/samples/bpf/cookie_uid_helper_example.c:121:27: warning: overflow in implicit constant conversion [-Woverflow]
-32 + offsetof(struct stats, packets), 1),
^
/home/foo/net-next/samples/bpf/libbpf.h:155:12: note: in definition of macro 'BPF_ST_MEM'
.off = OFF, \
^
/home/foo/net-next/samples/bpf/cookie_uid_helper_example.c:129:27: warning: overflow in implicit constant conversion [-Woverflow]
-32 + offsetof(struct stats, bytes)),
^
/home/foo/net-next/samples/bpf/libbpf.h:135:12: note: in definition of macro 'BPF_STX_MEM'
.off = OFF, \
^
HOSTLD /home/foo/net-next/samples/bpf/per_socket_stats_exampleFixes: 51570a5ab2b7 ("A Sample of using socket cookie and uid for traffic monitoring")
Signed-off-by: Daniel Borkmann
Signed-off-by: David S. Miller -
Like other JITs, sparc64 maintains an array of instruction offsets but
stores the entries off by one. This is done because jumps to the
exit block are indexed to one past the last BPF instruction.So if we size the array by the program length, we need to record
the previous instruction in order to stay within the array bounds.This is explained in ARM JIT commit 8eee539ddea0 ("arm64: bpf: fix
out-of-bounds read in bpf2a64_offset()").But this scheme requires a little bit of careful handling when
the instruction before the branch destination is a 64-bit load
immediate. It takes up 2 BPF instruction slots.Therefore, we have to fill in the array entry for the second
half of the 64-bit load immediate instruction rather than for
the one for the beginning of that instruction.Fixes: 7a12b5031c6b ("sparc64: Add eBPF JIT.")
Signed-off-by: David S. Miller -
By using smaller datatypes this (rather large) struct shrinks considerably
(80 -> 48 bytes on x86_64).As this is embedded in other structs, this also rerduces size of several
others, e.g. cls_fl_head or nft_hash.Signed-off-by: Florian Westphal
Signed-off-by: David S. Miller -
Signed-off-by: David S. Miller
-
We do not want to include things like stdio.h and friends into
eBPF program builds. bpf_util.h is for host compiled programs,
so eBPF C-code helpers don't really belong there.Add a new bpf_endian.h as a quick fix for this for now.
Signed-off-by: David S. Miller
-
Since that change also made the nfrag function not necessary
for exports, remove it.Fixes: 89a23c8b528b ("ip6_tunnel: Fix missing tunnel encapsulation limit option")
Signed-off-by: David S. Miller -
Vivien Didelot says:
====================
net: dsa: mv88e6xxx: 802.1s and 88E6390 VTUThis patch series adds support for the VLAN Table Unit (a.k.a. the VTU)
to the 88E6390 family of Marvell Ethernet switch chips. The plumbing for
the per VLAN Spanning Tree support is added as a side effect of the
necessary refactoring.The patchset is split up so that no duplication of code is introduced.
With this patchset applied, the mv88e6xxx driver has 2 new function
pointers for the VTU GetNext and VTU Load/Purge operations (with 3
implementations), both handling programmation of 802.1q and 802.1s.On a ZII Rev C board (featuring 2 88E6390X chips) with all ports bridged
together, we obtain the following hardware VLAN configuration:# cat /sys/class/net/br0/bridge/vlan_filtering
1
# cat /sys/class/net/br0/bridge/default_pvid
42
# bridge vlan add dev lan3 vid 666
# bridge vlan show
port vlan ids
lan1 42 PVID Egress Untaggedlan1 42 PVID Egress Untagged
lan2 42 PVID Egress Untagged
lan2 42 PVID Egress Untagged
lan3 42 PVID Egress Untagged
666lan3 42 PVID Egress Untagged
666lan4 42 PVID Egress Untagged
lan4 42 PVID Egress Untagged
lan5 42 PVID Egress Untagged
lan5 42 PVID Egress Untagged
lan6 42 PVID Egress Untagged
lan6 42 PVID Egress Untagged
lan7 42 PVID Egress Untagged
lan7 42 PVID Egress Untagged
lan8 42 PVID Egress Untagged
lan8 42 PVID Egress Untagged
br0 42 PVID Egress Untagged
Below are the technical details for the different implementations.
All switch families have up to 3 dedicated VTU Data registers used to
program 802.1q and 802.1s, both using 2-bit values.On 88E6185 and 88E6352 families, port membership and state are adjacent,
while the 88E6390 family share the same bits:Bits 88E6185/88E6352 88E6390
----- ----------------- --------------------------
0-1 Port 0 membership Port 0 membership or state
2-3 Port 0 state Port 1 membership or state
4-5 Port 1 membership Port 2 membership or state
6-7 Port 1 state Port 3 membership or state
8-9 Port 2 membership Port 4 membership or state
10-11 Port 2 state Port 5 membership or state
... ... ...The 88E6185 family programs all ports membership and state in a single
VTU GetNext or Load/Purge operation.The 88E6352 family introduced an indirect Spanning Tree Unit table
(a.k.a. STU) which requires additional STU GetNext and Load/Purge
operations to read and write the ports state bits.The 88E6390 family also has an STU and requires data bits to be accessed
before and after every single VTU or STU operation.Finally, the 88E6390 family introduced a 13th bit for the VLAN ID, which
must be taken care of regardless the VTU operating mode. This means that
iterating over the VTU now starts or ends with value 8191, not 4095.Patch 1 adds a max_vid field to the chip info structure.
Patch 2 adds 802.1q and 802.1s data to the generic VTU entry structure.
Patches 3 to 10 move helpers to a dedicated file (later made static).
Patches 11 and 12 abstract handling of the STU behind VTU operations.
Patches 13 and 14 add the new function pointers for VTU operations.
Patches 15 and 18 polish the VTU code and add VTU support for 88E6390.Changes in v2:
- add Reviewed-by tags
- fix comments in 8/18
====================Signed-off-by: David S. Miller
-
The 6390 family of chips use only 2 of the 3 VTU Data registers to pack
the MemberTag and PortState VLAN data. This means that they must be
written or read before or after each VTU/STU operations.Implement this variant to add support for VTU with such chips. These
chips have a 13th bit for the VID thus set their max_vid to 8191.Signed-off-by: Vivien Didelot
Reviewed-by: Andrew Lunn
Signed-off-by: David S. Miller -
Newer chips such as the 88E6390 have a VTU Page bit in the VTU VID
register to specify a 13th bit for the VID. This can be used to support
8K VLANs.When dumping the whole VTU, all VID bits must be set to one, including
this VTU Page bit. Add support for VID greater than 4095.Signed-off-by: Vivien Didelot
Signed-off-by: David S. Miller -
Make the code which fetches or initializes a new VTU entry more concise.
This allows us the get rid of the old underscore prefix naming.Signed-off-by: Vivien Didelot
Reviewed-by: Andrew Lunn
Signed-off-by: David S. Miller -
Now that we have chip operations for VTU accesses, mark all helpers from
global1_vtu.c as static. Only the various implementations of the
GetNext, LoadPurge and Flush operations need to be exposed.Signed-off-by: Vivien Didelot
Reviewed-by: Andrew Lunn
Signed-off-by: David S. Miller -
Add a new vtu_loadpurge operation to the chip info structure to differ
the various implementations of the VTU accesses.Now that the STU handling is abstracted behind VTU operations, kill the
obsolete MV88E6XXX_FLAG_STU flag.Signed-off-by: Vivien Didelot
Reviewed-by: Andrew Lunn
Signed-off-by: David S. Miller -
Add a new vtu_getnext operation to the chip info structure to differ the
various implementations of the VTU accesses.Signed-off-by: Vivien Didelot
Reviewed-by: Andrew Lunn
Signed-off-by: David S. Miller -
Now that the code writes both VTU and STU data when loading a VTU entry,
load the corresponding STU entry at the same time.This allows us to get rid of the STU management in the
_mv88e6xxx_vtu_new helper and thus remove the separate implementations
of STU Load/Purge and STU GetNext, as well as the unused family checks.Signed-off-by: Vivien Didelot
Reviewed-by: Andrew Lunn
Signed-off-by: David S. Miller -
Now that the code reads both VTU and STU data on VTU GetNext operation,
fetch the STU entry data of a VTU entry at the same time.The STU data bits are masked with the VTU data bits and they are now all
read at the same time a VTU GetNext operation is issued.Signed-off-by: Vivien Didelot
Reviewed-by: Andrew Lunn
Signed-off-by: David S. Miller -
Extract the generic portion of code to issue an STU GetNext operation,
which will be used in other implementations.Signed-off-by: Vivien Didelot
Reviewed-by: Andrew Lunn
Signed-off-by: David S. Miller -
The code to access the VTU Data registers currently only supports the
88E6185 family and alike: 2-bit membership adjacent to 2-bit port state.Even though the 88E6352 family introduced an indirect table to program
the VLAN Spanning Tree states, the usage of the VTU Data registers
remains the same regardless the VTU or STU operation.Now that the mv88e6xxx_vtu_entry structure contains both port membership
and states data, factorize the code to access them in global1_vtu.c.Signed-off-by: Vivien Didelot
Reviewed-by: Andrew Lunn
Signed-off-by: David S. Miller -
Even though every switch model has a different way to access the VTU
Data bits, the base implementation of the VTU GetNext operation remains
the same: wait, write the first VID to iterate from, start the
operation, and read the next VID.Move this generic implementation into global1_vtu.c and abstract the
handling of the start VID (similarly to the ATU GetNext implementation),
before introducing a new chip operation for specific chips.Signed-off-by: Vivien Didelot
Signed-off-by: David S. Miller -
Add helpers to access the VTU VID register in the global1_vtu.c file.
At the same time, move mv88e6xxx_g1_vtu_vid_write at the beginning of
_mv88e6xxx_vtu_loadpurge, which adds no functional changes but makes
future patches simpler.Signed-off-by: Vivien Didelot
Reviewed-by: Andrew Lunn
Signed-off-by: David S. Miller -
Add helpers to access the VTU SID register in the global1_vtu.c file.
Signed-off-by: Vivien Didelot
Reviewed-by: Andrew Lunn
Signed-off-by: David S. Miller -
Add helpers to access the VTU FID register in the global1_vtu.c file.
Signed-off-by: Vivien Didelot
Reviewed-by: Andrew Lunn
Signed-off-by: David S. Miller -
Move the VTU flush operation to global1_vtu.c and call it from a
mv88e6xxx_vtu_setup helper, similarly to the ATU and PVT setup.Signed-off-by: Vivien Didelot
Reviewed-by: Andrew Lunn
Signed-off-by: David S. Miller -
Move the helper functions to access the Global 1 VTU Operation register
to a new global1_vtu.c file, and get rid of the old underscore prefix
naming convention. This file will be extended will all VTU/STU related
code.Signed-off-by: Vivien Didelot
Reviewed-by: Andrew Lunn
Signed-off-by: David S. Miller -
VLAN aware Marvell chips can program 802.1Q VLAN membership as well as
802.1s per VLAN Spanning Tree state using the same 3 VTU Data registers.Some chips such as 88E6185 use different Data registers offsets for
ports state and membership, and program them in a single operation.Other chips such as 88E6352 use the same register layout but program
them in distinct operations (an indirect table is used for 802.1s.)Newer chips such as 88E6390 use the same offsets for both state and
membership in distinct operations, thus require multiple data accesses.To correctly abstract this, split the "data" structure member of
mv88e6xxx_vtu_entry in two "state" and "member" members, before adding
VTU support for newer chips.Signed-off-by: Vivien Didelot
Reviewed-by: Andrew Lunn
Signed-off-by: David S. Miller -
Some chips don't have a VLAN Table Unit, most of them do have a 4K
table, some others as the 88E6390 family has a 13th bit for the VID.Add a new max_vid member to the info structure, used to check the
presence of a VTU as well as the value used to iterate from in VTU
GetNext operations.This makes the MV88E6XXX_FLAG_VTU obsolete, thus remove it.
Signed-off-by: Vivien Didelot
Reviewed-by: Andrew Lunn
Signed-off-by: David S. Miller
