- 13 May, 2019 12 commits
-
-
Corentin Labbe authored
When adding more MAC addresses to a dwmac-sun8i interface, the device goes directly in promiscuous mode. This is due to IFF_UNICAST_FLT missing flag. So since the hardware support unicast filtering, let's add IFF_UNICAST_FLT. Fixes: 9f93ac8d ("net-next: stmmac: Add dwmac-sun8i") Signed-off-by:
Corentin Labbe <clabbe@baylibre.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Grygorii Strashko authored
Fix reported build fail: ERROR: "cpsw_ale_flush_multicast" [drivers/net/ethernet/ti/keystone_netcp_ethss.ko] undefined! ERROR: "cpsw_ale_create" [drivers/net/ethernet/ti/keystone_netcp_ethss.ko] undefined! ERROR: "cpsw_ale_add_vlan" [drivers/net/ethernet/ti/keystone_netcp_ethss.ko] undefined! Fixes: 16f54164 ("net: ethernet: ti: cpsw: drop CONFIG_TI_CPSW_ALE config option") Reported-by:
kbuild test robot <lkp@intel.com> Signed-off-by:
Grygorii Strashko <grygorii.strashko@ti.com> Signed-off-by:
-
Eric Dumazet authored
Various things in eBPF really require us to disable preemption before running an eBPF program. syzbot reported : BUG: assuming atomic context at net/core/flow_dissector.c:737 in_atomic(): 0, irqs_disabled(): 0, pid: 24710, name: syz-executor.3 2 locks held by syz-executor.3/24710: #0: 00000000e81a4bf1 (&tfile->napi_mutex){+.+.}, at: tun_get_user+0x168e/0x3ff0 drivers/net/tun.c:1850 #1: 00000000254afebd (rcu_read_lock){....}, at: __skb_flow_dissect+0x1e1/0x4bb0 net/core/flow_dissector.c:822 CPU: 1 PID: 24710 Comm: syz-executor.3 Not tainted 5.1.0+ #6 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x172/0x1f0 lib/dump_stack.c:113 __cant_sleep kernel/sched/core.c:6165 [inline] __cant_sleep.cold+0xa3/0xbb kernel/sched/core.c:6142 bpf_flow_dissect+0xfe/0x390 net/core/flow_dissector.c:737 __skb_flow_dissect+0x362/0x4bb0 net/core/flow_dissector.c:853 skb_flow_dissect_flow_keys_basic include/linux/skbuff.h:1322 [inline] skb_probe_transport_header include/linux/skbuff.h:2500 [inline] skb_probe_transport_header include/linux/skbuff.h:2493 [inline] tun_get_user+0x2cfe/0x3ff0 drivers/net/tun.c:1940 tun_chr_write_iter+0xbd/0x156 drivers/net/tun.c:2037 call_write_iter include/linux/fs.h:1872 [inline] do_iter_readv_writev+0x5fd/0x900 fs/read_write.c:693 do_iter_write fs/read_write.c:970 [inline] do_iter_write+0x184/0x610 fs/read_write.c:951 vfs_writev+0x1b3/0x2f0 fs/read_write.c:1015 do_writev+0x15b/0x330 fs/read_write.c:1058 __do_sys_writev fs/read_write.c:1131 [inline] __se_sys_writev fs/read_write.c:1128 [inline] __x64_sys_writev+0x75/0xb0 fs/read_write.c:1128 do_syscall_64+0x103/0x670 arch/x86/entry/common.c:298 entry_SYSCALL_64_after_hwframe+0x49/0xbe Fixes: d58e468b ("flow_dissector: implements flow dissector BPF hook") Signed-off-by:Eric Dumazet <edumazet@google.com> Reported-by:
syzbot <syzkaller@googlegroups.com> Cc: Petar Penkov <ppenkov@google.com> Cc: Stanislav Fomichev <sdf@google.com> Signed-off-by:
-
Jarod Wilson authored
There's currently a problem with toggling arp_validate on and off with an active-backup bond. At the moment, you can start up a bond, like so: modprobe bonding mode=1 arp_interval=100 arp_validate=0 arp_ip_targets=192.168.1.1 ip link set bond0 down echo "ens4f0" > /sys/class/net/bond0/bonding/slaves echo "ens4f1" > /sys/class/net/bond0/bonding/slaves ip link set bond0 up ip addr add 192.168.1.2/24 dev bond0 Pings to 192.168.1.1 work just fine. Now turn on arp_validate: echo 1 > /sys/class/net/bond0/bonding/arp_validate Pings to 192.168.1.1 continue to work just fine. Now when you go to turn arp_validate off again, the link falls flat on it's face: echo 0 > /sys/class/net/bond0/bonding/arp_validate dmesg ... [133191.911987] bond0: Setting arp_validate to none (0) [133194.257793] bond0: bond_should_notify_peers: slave ens4f0 [133194.258031] bond0: link status definitely down for interface ens4f0, disabling it [133194.259000] bond0: making interface ens4f1 the new active one [133197.330130] bond0: link status definitely down for interface ens4f1, disabling it [133197.331191] bond0: now running without any active interface! The problem lies in bond_options.c, where passing in arp_validate=0 results in bond->recv_probe getting set to NULL. This flies directly in the face of commit 3fe68df9, which says we need to set recv_probe = bond_arp_recv, even if we're not using arp_validate. Said commit fixed this in bond_option_arp_interval_set, but missed that we can get to that same state in bond_option_arp_validate_set as well. One solution would be to universally set recv_probe = bond_arp_recv here as well, but I don't think bond_option_arp_validate_set has any business touching recv_probe at all, and that should be left to the arp_interval code, so we can just make things much tidier here. Fixes: 3fe68df9 ("bonding: always set recv_probe to bond_arp_rcv in arp monitor") CC: Jay Vosburgh <j.vosburgh@gmail.com> CC: Veaceslav Falico <vfalico@gmail.com> CC: Andy Gospodarek <andy@greyhouse.net> CC: "David S. Miller" <davem@davemloft.net> CC: netdev@vger.kernel.org Signed-off-by:
Jarod Wilson <jarod@redhat.com> Signed-off-by:
Jay Vosburgh <jay.vosburgh@canonical.com> Signed-off-by:
-
Jerome Brunet authored
The phy id chosen by Amlogic is incorrectly set in the mdio mux and does not match the phy driver. It was not detected before because DT forces the use the correct driver for the internal PHY. Fixes: 70904251 ("net: phy: add amlogic g12a mdio mux support") Reported-by:
Qi Duan <qi.duan@amlogic.com> Signed-off-by:
Jerome Brunet <jbrunet@baylibre.com> Signed-off-by:
-
Kunihiko Hayashi authored
After calling phy_select_page() and until calling phy_restore_page(), the mutex 'mdio_lock' is already locked, so the driver should use non-locked version of phy functions. Or there will be a deadlock with 'mdio_lock'. This replaces phy functions called from rtl8211e_config_init() to avoid the deadlock issue. Fixes: f81dadbc ("net: phy: realtek: Add rtl8211e rx/tx delays config") Signed-off-by:
Kunihiko Hayashi <hayashi.kunihiko@socionext.com> Reviewed-by:
Andrew Lunn <andrew@lunn.ch> Signed-off-by:
-
Thomas Bogendoerfer authored
The old MIPS implementation of dma_cache_sync() didn't use the dev argument, but commit c9eb6172 ("dma-mapping: turn dma_cache_sync into a dma_map_ops method") changed that, so we now need to set dev.parent. Signed-off-by:
Thomas Bogendoerfer <tbogendoerfer@suse.de> Signed-off-by:
-
git://git.kernel.org/pub/scm/linux/kernel/git/pablo/nfDavid S. Miller authored
Pablo Neira Ayuso says: ==================== Netfilter fixes for net The following patchset contains Netfilter fixes for net: 1) Postpone chain policy update to drop after transaction is complete, from Florian Westphal. 2) Add entry to flowtable after confirmation to fix UDP flows with packets going in one single direction. 3) Reference count leak in dst object, from Taehee Yoo. 4) Check for TTL field in flowtable datapath, from Taehee Yoo. 5) Fix h323 conntrack helper due to incorrect boundary check, from Jakub Jankowski. 6) Fix incorrect rcu dereference when fetching basechain stats, from Florian Westphal. 7) Missing error check when adding new entries to flowtable, from Taehee Yoo. 8) Use version field in nfnetlink message to honor the nfgen_family field, from Kristian Evensen. 9) Remove incorrect configuration check for CONFIG_NF_CONNTRACK_IPV6, from Subash Abhinov Kasiviswanathan. 10) Prevent dying entries from being added to the flowtable, from Taehee Yoo. 11) Don't hit WARN_ON() with malformed blob in ebtables with trailing data after last rule, reported by syzbot, patch from Florian Westphal. 12) Remove NFT_CT_TIMEOUT enumeration, never used in the kernel code. 13) Fix incorrect definition for NFT_LOGLEVEL_MAX, from Florian Westphal. This batch comes with a conflict that can be fixed with this patch: diff --cc include/uapi/linux/netfilter/nf_tables.h index 7bdb234f3d8c,f0cf7b0f4f35..505393c6e959 --- a/include/uapi/linux/netfilter/nf_tables.h +++ b/include/uapi/linux/netfilter/nf_tables.h @@@ -966,6 -966,8 +966,7 @@@ enum nft_socket_keys * @NFT_CT_DST_IP: conntrack layer 3 protocol destination (IPv4 address) * @NFT_CT_SRC_IP6: conntrack layer 3 protocol source (IPv6 address) * @NFT_CT_DST_IP6: conntrack layer 3 protocol destination (IPv6 address) - * @NFT_CT_TIMEOUT: connection tracking timeout policy assigned to conntrack + * @NFT_CT_ID: conntrack id */ enum nft_ct_keys { NFT_CT_STATE, @@@ -991,6 -993,8 +992,7 @@@ NFT_CT_DST_IP, NFT_CT_SRC_IP6, NFT_CT_DST_IP6, - NFT_CT_TIMEOUT, + NFT_CT_ID, __NFT_CT_MAX }; #define NFT_CT_MAX (__NFT_CT_MAX - 1) That replaces the unused NFT_CT_TIMEOUT definition by NFT_CT_ID. If you prefer, I can also solve this conflict here, just let me know. ==================== Signed-off-by: -
Petr Štetiar authored
of_find_device_by_node takes a reference to the embedded struct device which needs to be dropped after use. Fixes: d01f449c ("of_net: add NVMEM support to of_get_mac_address") Reported-by:
Julia Lawall <julia.lawall@lip6.fr> Signed-off-by:
Petr Štetiar <ynezz@true.cz> Reviewed-by:
-
Maxime Chevallier authored
Now that the mvpp2 driver supports classification offloading, we must add the NETIF_F_NTUPLE to the features list. Since the current code doesn't allow disabling the feature, we don't set the flag in dev->hw_features. Fixes: 90b509b3 ("net: mvpp2: cls: Add Classification offload support") Reported-by:
Jakub Kicinski <jakub.kicinski@netronome.com> Acked-by:
Maxime Chevallier <maxime.chevallier@bootlin.com> Signed-off-by:
-
git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpfDavid S. Miller authored
Daniel Borkmann says: ==================== pull-request: bpf 2019-05-13 The following pull-request contains BPF updates for your *net* tree. The main changes are: 1) Fix out of bounds backwards jumps due to a bug in dead code removal, from Daniel. 2) Fix libbpf users by detecting unsupported BTF kernel features and sanitize them before load, from Andrii. 3) Fix undefined behavior in narrow load handling of context fields, from Krzesimir. 4) Various BPF uapi header doc/man page fixes, from Quentin. 5) Misc .gitignore fixups to exclude built files, from Kelsey. ==================== Signed-off-by: -
Krzesimir Nowak authored
Commit 31fd8581 ("bpf: permits narrower load from bpf program context fields") made the verifier add AND instructions to clear the unwanted bits with a mask when doing a narrow load. The mask is computed with (1 << size * 8) - 1 where "size" is the size of the narrow load. When doing a 4 byte load of a an 8 byte field the verifier shifts the literal 1 by 32 places to the left. This results in an overflow of a signed integer, which is an undefined behavior. Typically, the computed mask was zero, so the result of the narrow load ended up being zero too. Cast the literal to long long to avoid overflows. Note that narrow load of the 4 byte fields does not have the undefined behavior, because the load size can only be either 1 or 2 bytes, so shifting 1 by 8 or 16 places will not overflow it. And reading 4 bytes would not be a narrow load of a 4 bytes field. Fixes: 31fd8581 ("bpf: permits narrower load from bpf program context fields") Reviewed-by:
Alban Crequy <alban@kinvolk.io> Reviewed-by:
Iago López Galeiras <iago@kinvolk.io> Signed-off-by:
Krzesimir Nowak <krzesimir@kinvolk.io> Cc: Yonghong Song <yhs@fb.com> Signed-off-by:
Daniel Borkmann <daniel@iogearbox.net>
-
- 12 May, 2019 14 commits
-
-
Andrii Nakryiko authored
Depending on used versions of libbpf, Clang, and kernel, it's possible to have valid BPF object files with valid BTF information, that still won't load successfully due to Clang emitting newer BTF features (e.g., BTF_KIND_FUNC, .BTF.ext's line_info/func_info, BTF_KIND_DATASEC, etc), that are not yet supported by older kernel. This patch adds detection of BTF features and sanitizes BPF object's BTF by substituting various supported BTF kinds, which have compatible layout: - BTF_KIND_FUNC -> BTF_KIND_TYPEDEF - BTF_KIND_FUNC_PROTO -> BTF_KIND_ENUM - BTF_KIND_VAR -> BTF_KIND_INT - BTF_KIND_DATASEC -> BTF_KIND_STRUCT Replacement is done in such a way as to preserve as much information as possible (names, sizes, etc) where possible without violating kernel's validation rules. v2->v3: - remove duplicate #defines from libbpf_util.h v1->v2: - add internal libbpf_internal.h w/ common stuff - switch SK storage BTF to use new libbpf__probe_raw_btf() Reported-by:
Alexei Starovoitov <ast@fb.com> Signed-off-by:
Andrii Nakryiko <andriin@fb.com> Signed-off-by:
-
Kelsey Skunberg authored
The following files are generated after building /selftests/bpf/ and should be added to .gitignore: - libbpf.pc - libbpf.so.* Signed-off-by:
Kelsey Skunberg <skunberg.kelsey@gmail.com> Signed-off-by:
-
Daniel Borkmann authored
Quentin Monnet says: ==================== Another round of fixes for the doc in the BPF UAPI header, which can be turned into a manual page. First patch is the most important, as it fixes parsing for the bpf_strtoul() helper doc. Following patches are formatting fixes (nitpicks, mostly). The last one updates the copy of the header, located under tools/. ==================== Signed-off-by: -
Quentin Monnet authored
Synchronise the bpf.h header under tools, to report the fixes and additions recently brought to the documentation for the BPF helpers. Signed-off-by:
Quentin Monnet <quentin.monnet@netronome.com> Acked-by:
-
Quentin Monnet authored
This commit brings many minor fixes to the documentation for BPF helper functions. Mostly, this is limited to formatting fixes and improvements. In particular, fix broken formatting for bpf_skb_adjust_room(). Besides formatting, replace the mention of "bpf_fullsock()" (that is not associated with any function or type exposed to the user) in the description of bpf_sk_storage_get() by "full socket". Signed-off-by:
-
Quentin Monnet authored
"Underlaying packet buffer" should be an "underlying" one, in the warning about invalidated data and data_end pointers. Through copy-and-paste, the typo occurred no fewer than 19 times in the documentation. Let's fix it. Signed-off-by:
-
Quentin Monnet authored
The script broke on parsing function prototype for bpf_strtoul(). This is because the last argument for the function is a pointer to an "unsigned long". The current version of the script only accepts "const" and "struct", but not "unsigned", at the beginning of argument types made of several words. One solution could be to add "unsigned" to the list, but the issue could come up again in the future (what about "long int"?). It turns out we do not need to have such restrictions on the words: so let's simply accept any series of words instead. Reported-by:
Yonghong Song <yhs@fb.com> Signed-off-by:
-
Daniel Borkmann authored
Add a couple of tests to make sure branch(/call) offset adjustments are correctly performed. Signed-off-by: -
Hariprasad Kelam authored
Fix below issue reported by coccicheck net/dccp/proto.c:266:5-8: Unneeded variable: "err". Return "0" on line 310 Signed-off-by:
Hariprasad Kelam <hariprasad.kelam@gmail.com> Signed-off-by:
-
David S. Miller authored
Vladimir Oltean says: ==================== Fix a bug and avoid dangerous usage patterns around DSA_SKB_CB Making DSA use the sk_buff control block was my idea during the 'Traffic-support-for-SJA1105-DSA-driver' patchset, and I had also introduced a series of macro helpers that turned out to not be so helpful: 1. DSA_SKB_ZERO() zeroizes the 48-byte skb->cb area, but due to the high performance impact in the hotpath it was only intended to be called from the timestamping path. But it turns out that not zeroizing it has uncovered the reading of an uninitialized member field of DSA_SKB_CB, so in the future just be careful about what needs initialization and remove this macro. 2. DSA_SKB_CLONE() contains a flaw in its body definition (originally put there to silence checkpatch.pl) and is unusable at this point (will only cause NPE's when used). So remove it. 3. For DSA_SKB_COPY() the same performance considerations apply as above and therefore it's best to prune this function before it reaches a stable kernel and potentially any users. ==================== Signed-off-by: -
Vladimir Oltean authored
It's best to not expose this, due to the performance hit it may cause when calling it. Fixes: b68b0dd0 ("net: dsa: Keep private info in the skb->cb") Signed-off-by:
Vladimir Oltean <olteanv@gmail.com> Reviewed-by:
-
Vladimir Oltean authored
This does not cause any bug now because it has no users, but its body contains two pointer definitions within a code block: struct sk_buff *clone = _clone; \ struct sk_buff *skb = _skb; \ When calling the macro as DSA_SKB_CLONE(clone, skb), these variables would obscure the arguments that the macro was called with, and the initializers would be a no-op instead of doing their job (undefined behavior, by the way, but GCC nicely puts NULL pointers instead). So simply remove this broken macro and leave users to simply call "DSA_SKB_CB(skb)->clone = clone" by hand when needed. There is one functional difference when doing what I just suggested above: the control block won't be transferred from the original skb into the clone. Since there's no foreseen need for the control block in the clone ATM, this is ok. Fixes: b68b0dd0 ("net: dsa: Keep private info in the skb->cb") Signed-off-by:
-
Vladimir Oltean authored
The sk_buff control block can have any contents on xmit put there by the stack, so initialization is mandatory, since we are checking its value after the actual DSA xmit (the tagger may have changed it). The DSA_SKB_ZERO() macro could have been used for this purpose, but: - Zeroizing a 48-byte memory region in the hotpath is best avoided. - It would have triggered a warning with newer compilers since __dsa_skb_cb contains a structure within a structure, and the {0} initializer was incorrect for that purpose. So simply remove the DSA_SKB_ZERO() macro and initialize the deferred_xmit variable by hand (which should be done for all further dsa_skb_cb variables which need initialization - currently none - to avoid the performance penalty). Fixes: 97a69a0d ("net: dsa: Add support for deferred xmit") Signed-off-by: -
Florian Westphal authored
should be same as NFT_LOGLEVEL_AUDIT, so use -, not +. Fixes: 7eced5ab ("netfilter: nf_tables: add NFT_LOGLEVEL_* enumeration and use it") Signed-off-by:
Florian Westphal <fw@strlen.de> Signed-off-by:
Pablo Neira Ayuso <pablo@netfilter.org>
-
- 11 May, 2019 3 commits
-
-
Heiner Kallweit authored
When adding missing callbacks I missed that one had them set already. Interesting that the compiler didn't complain. Fixes: daf3ddbe ("net: phy: realtek: add missing page operations") Signed-off-by:
Heiner Kallweit <hkallweit1@gmail.com> Signed-off-by:
-
Nicholas Mc Guire authored
sparse was unable to verify endiannes correctness due to reassignment from le32_to_cpu to the same variable - fix this warning up by providing a proper __le32 type and initializing it. This is not actually fixing any bug - rather just addressing the sparse warning. Signed-off-by:
Nicholas Mc Guire <hofrat@osadl.org> Signed-off-by:
-
Daniel Borkmann authored
systemtap folks reported the following splat recently: [ 7790.862212] WARNING: CPU: 3 PID: 26759 at arch/x86/kernel/kprobes/core.c:1022 kprobe_fault_handler+0xec/0xf0 [...] [ 7790.864113] CPU: 3 PID: 26759 Comm: sshd Not tainted 5.1.0-0.rc7.git1.1.fc31.x86_64 #1 [ 7790.864198] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS[...] [ 7790.864314] RIP: 0010:kprobe_fault_handler+0xec/0xf0 [ 7790.864375] Code: 48 8b 50 [...] [ 7790.864714] RSP: 0018:ffffc06800bdbb48 EFLAGS: 00010082 [ 7790.864812] RAX: ffff9e2b75a16320 RBX: 0000000000000000 RCX: 0000000000000000 [ 7790.865306] RDX: ffffffffffffffff RSI: 000000000000000e RDI: ffffc06800bdbbf8 [ 7790.865514] RBP: ffffc06800bdbbf8 R08: 0000000000000000 R09: 0000000000000000 [ 7790.865960] R10: 0000000000000000 R11: 0000000000000000 R12: ffffc06800bdbbf8 [ 7790.866037] R13: ffff9e2ab56a0418 R14: ffff9e2b6d0bb400 R15: ffff9e2b6d268000 [ 7790.866114] FS: 00007fde49937d80(0000) GS:ffff9e2b75a00000(0000) knlGS:0000000000000000 [ 7790.866193] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 7790.866318] CR2: 0000000000000000 CR3: 000000012f312000 CR4: 00000000000006e0 [ 7790.866419] Call Trace: [ 7790.866677] do_user_addr_fault+0x64/0x480 [ 7790.867513] do_page_fault+0x33/0x210 [ 7790.868002] async_page_fault+0x1e/0x30 [ 7790.868071] RIP: 0010: (null) [ 7790.868144] Code: Bad RIP value. [ 7790.868229] RSP: 0018:ffffc06800bdbca8 EFLAGS: 00010282 [ 7790.868362] RAX: ffff9e2b598b60f8 RBX: ffffc06800bdbe48 RCX: 0000000000000004 [ 7790.868629] RDX: 0000000000000004 RSI: ffffc06800bdbc6c RDI: ffff9e2b598b60f0 [ 7790.868834] RBP: ffffc06800bdbcf8 R08: 0000000000000000 R09: 0000000000000004 [ 7790.870432] R10: 00000000ff6f7a03 R11: 0000000000000000 R12: 0000000000000001 [ 7790.871859] R13: ffffc06800bdbcb8 R14: 0000000000000000 R15: ffff9e2acd0a5310 [ 7790.873455] ? vfs_read+0x5/0x170 [ 7790.874639] ? vfs_read+0x1/0x170 [ 7790.875834] ? trace_call_bpf+0xf6/0x260 [ 7790.877044] ? vfs_read+0x1/0x170 [ 7790.878208] ? vfs_read+0x5/0x170 [ 7790.879345] ? kprobe_perf_func+0x233/0x260 [ 7790.880503] ? vfs_read+0x1/0x170 [ 7790.881632] ? vfs_read+0x5/0x170 [ 7790.882751] ? kprobe_ftrace_handler+0x92/0xf0 [ 7790.883926] ? __vfs_read+0x30/0x30 [ 7790.885050] ? ftrace_ops_assist_func+0x94/0x100 [ 7790.886183] ? vfs_read+0x1/0x170 [ 7790.887283] ? vfs_read+0x5/0x170 [ 7790.888348] ? ksys_read+0x5a/0xe0 [ 7790.889389] ? do_syscall_64+0x5c/0xa0 [ 7790.890401] ? entry_SYSCALL_64_after_hwframe+0x49/0xbe After some debugging, turns out that the logic in 2cbd95a5 ("bpf: change parameters of call/branch offset adjustment") has a bug that is exposed after 52875a04 ("bpf: verifier: remove dead code") in that we miss some of the jump offset adjustments after code patching when we remove dead code, more concretely, upon backward jump spanning over the area that is being removed. BPF insns of a case that was hit pre 52875a04: [...] 676: (85) call bpf_perf_event_output#-47616 677: (05) goto pc-636 678: (62) *(u32 *)(r10 -64) = 0 679: (bf) r7 = r10 680: (07) r7 += -64 681: (05) goto pc-44 682: (05) goto pc-1 683: (05) goto pc-1 BPF insns afterwards: [...] 618: (85) call bpf_perf_event_output#-47616 619: (05) goto pc-638 620: (62) *(u32 *)(r10 -64) = 0 621: (bf) r7 = r10 622: (07) r7 += -64 623: (05) goto pc-44 To illustrate the bug, situation looks as follows: ____ 0 | | <-- foo: [...] 1 |____| 2 |____| <-- pos / end_new ^ 3 | | | 4 | | | len 5 |____| | (remove region) 6 | | <-- end_old v 7 | | 8 | | <-- curr (jmp foo) 9 |____| The condition curr >= end_new && curr + off + 1 < end_new in the branch delta adjustments is never hit because curr + off + 1 < end_new is compared as unsigned and therefore curr + off + 1 > end_new in unsigned realm as curr + off + 1 becomes negative since the insns are memmove()'d before the offset adjustments. Correct BPF insns after this fix: [...] 618: (85) call bpf_perf_event_output#-47216 619: (05) goto pc-578 620: (62) *(u32 *)(r10 -64) = 0 621: (bf) r7 = r10 622: (07) r7 += -64 623: (05) goto pc-44 Note that unprivileged case is not affected from this. Fixes: 52875a04 ("bpf: verifier: remove dead code") Fixes: 2cbd95a5 ("bpf: change parameters of call/branch offset adjustment") Reported-by:
Frank Ch. Eigler <fche@redhat.com> Signed-off-by:
Alexei Starovoitov <ast@kernel.org>
-
- 10 May, 2019 11 commits
-
-
Heiner Kallweit authored
Add missing page operation callbacks to few Realtek drivers. This also fixes a NPE after the referenced commit added code to the RTL8211E driver that uses phy_select_page(). Fixes: f81dadbc ("net: phy: realtek: Add rtl8211e rx/tx delays config") Signed-off-by:
Florian Fainelli <f.fainelli@gmail.com> Reported-by:
Vicente Bergas <vicencb@gmail.com> Signed-off-by:
-
David S. Miller authored
Petr Štetiar says: ==================== of_get_mac_address fixes this patch series is hopefuly the last series of the fixes which are related to the introduction of NVMEM support into of_get_mac_address. First patch is removing `nvmem-mac-address` property which was wrong idea as I've allocated the property with devm_kzalloc and then added it to DT, so then 2 entities would be refcounting the allocation. So if the driver unbinds, the buffer is freed, but DT code would be still referencing that memory. Second patch fixes some unwanted references to the Linux API in the DT bindings documentation. Patches 3-5 should hopefully make compilers and thus kbuild test robot happy. ==================== Signed-off-by: -
Petr Štetiar authored
This patch fixes following (similar) warning reported by kbuild test robot: In function ‘memcpy’, inlined from ‘smsc75xx_init_mac_address’ at drivers/net/usb/smsc75xx.c:778:3, inlined from ‘smsc75xx_bind’ at drivers/net/usb/smsc75xx.c:1501:2: ./include/linux/string.h:355:9: warning: argument 2 null where non-null expected [-Wnonnull] return __builtin_memcpy(p, q, size); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~ drivers/net/usb/smsc75xx.c: In function ‘smsc75xx_bind’: ./include/linux/string.h:355:9: note: in a call to built-in function ‘__builtin_memcpy’ I've replaced the offending memcpy with ether_addr_copy, because I'm 100% sure, that of_get_mac_address can't return NULL as it returns valid pointer or ERR_PTR encoded value, nothing else. I'm hesitant to just change IS_ERR into IS_ERR_OR_NULL check, as this would make the warning disappear also, but it would be confusing to check for impossible return value just to make a compiler happy. I'm now changing all occurencies of memcpy to ether_addr_copy after the of_get_mac_address call, as it's very likely, that we're going to get similar reports from kbuild test robot in the future. Fixes: d31a36b5 ("net: wireless: support of_get_mac_address new ERR_PTR error") Reported-by: -
Petr Štetiar authored
This patch fixes following (similar) warning reported by kbuild test robot: In function ‘memcpy’, inlined from ‘smsc75xx_init_mac_address’ at drivers/net/usb/smsc75xx.c:778:3, inlined from ‘smsc75xx_bind’ at drivers/net/usb/smsc75xx.c:1501:2: ./include/linux/string.h:355:9: warning: argument 2 null where non-null expected [-Wnonnull] return __builtin_memcpy(p, q, size); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~ drivers/net/usb/smsc75xx.c: In function ‘smsc75xx_bind’: ./include/linux/string.h:355:9: note: in a call to built-in function ‘__builtin_memcpy’ I've replaced the offending memcpy with ether_addr_copy, because I'm 100% sure, that of_get_mac_address can't return NULL as it returns valid pointer or ERR_PTR encoded value, nothing else. I'm hesitant to just change IS_ERR into IS_ERR_OR_NULL check, as this would make the warning disappear also, but it would be confusing to check for impossible return value just to make a compiler happy. I'm now changing all occurencies of memcpy to ether_addr_copy after the of_get_mac_address call, as it's very likely, that we're going to get similar reports from kbuild test robot in the future. Fixes: a51645f7 ("net: ethernet: support of_get_mac_address new ERR_PTR error") Reported-by: -
Petr Štetiar authored
This patch fixes following (similar) warning reported by kbuild test robot: In function ‘memcpy’, inlined from ‘smsc75xx_init_mac_address’ at drivers/net/usb/smsc75xx.c:778:3, inlined from ‘smsc75xx_bind’ at drivers/net/usb/smsc75xx.c:1501:2: ./include/linux/string.h:355:9: warning: argument 2 null where non-null expected [-Wnonnull] return __builtin_memcpy(p, q, size); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~ drivers/net/usb/smsc75xx.c: In function ‘smsc75xx_bind’: ./include/linux/string.h:355:9: note: in a call to built-in function ‘__builtin_memcpy’ I've replaced the offending memcpy with ether_addr_copy, because I'm 100% sure, that of_get_mac_address can't return NULL as it returns valid pointer or ERR_PTR encoded value, nothing else. I'm hesitant to just change IS_ERR into IS_ERR_OR_NULL check, as this would make the warning disappear also, but it would be confusing to check for impossible return value just to make a compiler happy. I'm now changing all occurencies of memcpy to ether_addr_copy after the of_get_mac_address call, as it's very likely, that we're going to get similar reports from kbuild test robot in the future. Fixes: ea168cdf ("powerpc: tsi108: support of_get_mac_address new ERR_PTR error") Reported-by: -
Petr Štetiar authored
In commit 687e3d55 ("dt-bindings: doc: reflect new NVMEM of_get_mac_address behaviour") I've kept or added references to Linux of_get_mac_address API which is unwanted so this patch fixes that by removing those references. Fixes: 687e3d55 ("dt-bindings: doc: reflect new NVMEM of_get_mac_address behaviour") Suggested-by:
Rob Herring <robh@kernel.org> Signed-off-by:
-
Petr Štetiar authored
In commit d01f449c ("of_net: add NVMEM support to of_get_mac_address") I've added `nvmem-mac-address` property which was wrong idea as I've allocated the property with devm_kzalloc and then added it to DT, so then 2 entities would be refcounting the allocation. So if the driver unbinds, the buffer is freed, but DT code would be still referencing that memory. I'm removing this property completely instead of fixing it, as it's not needed to have it. Fixes: d01f449c ("of_net: add NVMEM support to of_get_mac_address") Suggested-by:
-
Thomas Falcon authored
Only set the device carrier state to on after receiving an up link state indication from the underlying adapter. Likewise, if a down link indication is receieved, update the carrier state accordingly. This fix ensures that accurate carrier state is reported by the driver following a link state update by the underlying adapter. Signed-off-by:
Thomas Falcon <tlfalcon@linux.ibm.com> Signed-off-by:
-
Thomas Falcon authored
It was discovered in testing that the underlying hardware MAC address will revert to initial settings following a device reset, but the driver fails to resend the current OS MAC settings. This oversight can result in dropped packets should the scenario occur. Fix this by informing hardware of current MAC address settings following any adapter initialization or resets. Signed-off-by:
-
YueHaibing authored
Fix gcc build error: net/dsa/tag_brcm.c:211:16: error: brcm_prepend_netdev_ops undeclared here (not in a function); did you mean brcm_netdev_ops? DSA_TAG_DRIVER(brcm_prepend_netdev_ops); ^ ./include/net/dsa.h:708:10: note: in definition of macro DSA_TAG_DRIVER .ops = &__ops, \ ^~~~~ ./include/net/dsa.h:701:36: warning: dsa_tag_driver_brcm_prepend_netdev_ops defined but not used [-Wunused-variable] #define DSA_TAG_DRIVER_NAME(__ops) dsa_tag_driver ## _ ## __ops ^ ./include/net/dsa.h:707:30: note: in expansion of macro DSA_TAG_DRIVER_NAME static struct dsa_tag_driver DSA_TAG_DRIVER_NAME(__ops) = { \ ^~~~~~~~~~~~~~~~~~~ net/dsa/tag_brcm.c:211:1: note: in expansion of macro DSA_TAG_DRIVER DSA_TAG_DRIVER(brcm_prepend_netdev_ops); Like the CONFIG_NET_DSA_TAG_BRCM case, brcm_prepend_netdev_ops and DSA_TAG_PROTO_BRCM_PREPEND should be wrappeed by CONFIG_NET_DSA_TAG_BRCM_PREPEND. Reported-by:Hulk Robot <hulkci@huawei.com> Fixes: b74b70c4 ("net: dsa: Support prepended Broadcom tag") Signed-off-by:
YueHaibing <yuehaibing@huawei.com> Reviewed-by:
-
Tobin C. Harding authored
Currently error return from kobject_init_and_add() is not followed by a call to kobject_put(). This means there is a memory leak. We currently set p to NULL so that kfree() may be called on it as a noop, the code is arguably clearer if we move the kfree() up closer to where it is called (instead of after goto jump). Remove a goto label 'err1' and jump to call to kobject_put() in error return from kobject_init_and_add() fixing the memory leak. Re-name goto label 'put_back' to 'err1' now that we don't use err1, following current nomenclature (err1, err2 ...). Move call to kfree out of the error code at bottom of function up to closer to where memory was allocated. Add comment to clarify call to kfree(). Signed-off-by:
Tobin C. Harding <tobin@kernel.org> Signed-off-by:
-
