- 12 Aug, 2020 7 commits
-
-
Eric Dumazet authored
We must accept an empty mask in store_rps_map(), or we are not able to disable RPS on a queue. Fixes: 07bbecb3 ("net: Restrict receive packets queuing to housekeeping CPUs") Signed-off-by:
Eric Dumazet <edumazet@google.com> Reported-by:
Maciej Żenczykowski <maze@google.com> Cc: Alex Belits <abelits@marvell.com> Cc: Nitesh Narayan Lal <nitesh@redhat.com> Cc: Peter Zijlstra (Intel) <peterz@infradead.org> Reviewed-by:
Peter Zijlstra (Intel) <peterz@infradead.org> Acked-by:
Nitesh Narayan Lal <nitesh@redhat.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
David S. Miller authored
Jonathan McDowell says: ==================== net: stmmac: Fix multicast filter on IPQ806x This pair of patches are the result of discovering a failure to correctly receive IPv6 multicast packets on such a device (in particular DHCPv6 requests and RA solicitations). Putting the device into promiscuous mode, or allmulti, both resulted in such packets correctly being received. Examination of the vendor driver (nss-gmac from the qsdk) shows that it does not enable the multicast filter and instead falls back to allmulti. Extend the base dwmac1000 driver to fall back when there's no suitable hardware filter, and update the ipq806x platform to request this. ==================== Signed-off-by: -
Jonathan McDowell authored
The IPQ806x does not appear to have a functional multicast ethernet address filter. This was observed as a failure to correctly receive IPv6 packets on a LAN to the all stations address. Checking the vendor driver shows that it does not attempt to enable the multicast filter and instead falls back to receiving all multicast packets, internally setting ALLMULTI. Use the new fallback support in the dwmac1000 driver to correctly achieve the same with the mainline IPQ806x driver. Confirmed to fix IPv6 functionality on an RB3011 router. Cc: stable@vger.kernel.org Signed-off-by:
Jonathan McDowell <noodles@earth.li> Signed-off-by:
-
Jonathan McDowell authored
If we don't have a hardware multicast filter available then instead of silently failing to listen for the requested ethernet broadcast addresses fall back to receiving all multicast packets, in a similar fashion to other drivers with no multicast filter. Cc: stable@vger.kernel.org Signed-off-by:
-
Johannes Berg authored
With certain configurations, a 64-bit ARCH=um errors out here with an unknown csum_ipv6_magic() function. Include the right header file to always have it. Signed-off-by:
Johannes Berg <johannes.berg@intel.com> Signed-off-by:
-
Stefano Garzarella authored
syzbot reported this issue where in the vsock_poll() we find the socket state at TCP_ESTABLISHED, but 'transport' is null: general protection fault, probably for non-canonical address 0xdffffc0000000012: 0000 [#1] PREEMPT SMP KASAN KASAN: null-ptr-deref in range [0x0000000000000090-0x0000000000000097] CPU: 0 PID: 8227 Comm: syz-executor.2 Not tainted 5.8.0-rc7-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:vsock_poll+0x75a/0x8e0 net/vmw_vsock/af_vsock.c:1038 Call Trace: sock_poll+0x159/0x460 net/socket.c:1266 vfs_poll include/linux/poll.h:90 [inline] do_pollfd fs/select.c:869 [inline] do_poll fs/select.c:917 [inline] do_sys_poll+0x607/0xd40 fs/select.c:1011 __do_sys_poll fs/select.c:1069 [inline] __se_sys_poll fs/select.c:1057 [inline] __x64_sys_poll+0x18c/0x440 fs/select.c:1057 do_syscall_64+0x60/0xe0 arch/x86/entry/common.c:384 entry_SYSCALL_64_after_hwframe+0x44/0xa9 This issue can happen if the TCP_ESTABLISHED state is set after we read the vsk->transport in the vsock_poll(). We could put barriers to synchronize, but this can only happen during connection setup, so we can simply check that 'transport' is valid. Fixes: c0cfa2d8 ("vsock: add multi-transports support") Reported-and-tested-by: syzbot+a61bac2fcc1a7c6623fe@syzkaller.appspotmail.com Signed-off-by:
Stefano Garzarella <sgarzare@redhat.com> Reviewed-by:
Jorgen Hansen <jhansen@vmware.com> Signed-off-by:
-
Edward Cree authored
The handling of the RXQ/TXQ size granularity design-params had two problems: it had a 64-bit divide that didn't build on 32-bit platforms, and it could divide by zero if the NIC supplied 0 as the value of the design-param. Fix both by checking for 0 and for a granularity bigger than our min-size; if the granularity <= EFX_MIN_DMAQ_SIZE then it fits in 32 bits, so we can cast it to u32 for the divide. Reported-by:
kernel test robot <lkp@intel.com> Signed-off-by:
Edward Cree <ecree@solarflare.com> Reviewed-by:
Guenter Roeck <linux@roeck-us.net> Signed-off-by:
-
- 11 Aug, 2020 11 commits
-
-
David S. Miller authored
Tim Froidcoeur says: ==================== net: initialize fastreuse on inet_inherit_port In the case of TPROXY, bind_conflict optimizations for SO_REUSEADDR or SO_REUSEPORT are broken, possibly resulting in O(n) instead of O(1) bind behaviour or in the incorrect reuse of a bind. the kernel keeps track for each bind_bucket if all sockets in the bind_bucket support SO_REUSEADDR or SO_REUSEPORT in two fastreuse flags. These flags allow skipping the costly bind_conflict check when possible (meaning when all sockets have the proper SO_REUSE option). For every socket added to a bind_bucket, these flags need to be updated. As soon as a socket that does not support reuse is added, the flag is set to false and will never go back to true, unless the bind_bucket is deleted. Note that there is no mechanism to re-evaluate these flags when a socket is removed (this might make sense when removing a socket that would not allow reuse; this leaves room for a future patch). For this optimization to work, it is mandatory that these flags are properly initialized and updated. When a child socket is created from a listen socket in __inet_inherit_port, the TPROXY case could create a new bind bucket without properly initializing these flags, thus preventing the optimization to work. Alternatively, a socket not allowing reuse could be added to an existing bind bucket without updating the flags, causing bind_conflict to never be called as it should. Patch 1/2 refactors the fastreuse update code in inet_csk_get_port into a small helper function, making the actual fix tiny and easier to understand. Patch 2/2 calls this new helper when __inet_inherit_port decides to create a new bind_bucket or use a different bind_bucket than the one of the listen socket. v4: - rebase on latest linux/net master branch v3: - remove company disclaimer from automatic signature v2: - remove unnecessary cast ==================== Signed-off-by: -
Tim Froidcoeur authored
In the case of TPROXY, bind_conflict optimizations for SO_REUSEADDR or SO_REUSEPORT are broken, possibly resulting in O(n) instead of O(1) bind behaviour or in the incorrect reuse of a bind. the kernel keeps track for each bind_bucket if all sockets in the bind_bucket support SO_REUSEADDR or SO_REUSEPORT in two fastreuse flags. These flags allow skipping the costly bind_conflict check when possible (meaning when all sockets have the proper SO_REUSE option). For every socket added to a bind_bucket, these flags need to be updated. As soon as a socket that does not support reuse is added, the flag is set to false and will never go back to true, unless the bind_bucket is deleted. Note that there is no mechanism to re-evaluate these flags when a socket is removed (this might make sense when removing a socket that would not allow reuse; this leaves room for a future patch). For this optimization to work, it is mandatory that these flags are properly initialized and updated. When a child socket is created from a listen socket in __inet_inherit_port, the TPROXY case could create a new bind bucket without properly initializing these flags, thus preventing the optimization to work. Alternatively, a socket not allowing reuse could be added to an existing bind bucket without updating the flags, causing bind_conflict to never be called as it should. Call inet_csk_update_fastreuse when __inet_inherit_port decides to create a new bind_bucket or use a different bind_bucket than the one of the listen socket. Fixes: 093d2823 ("tproxy: fix hash locking issue when using port redirection in __inet_inherit_port()") Acked-by:
Matthieu Baerts <matthieu.baerts@tessares.net> Signed-off-by:
Tim Froidcoeur <tim.froidcoeur@tessares.net> Signed-off-by:
-
Tim Froidcoeur authored
Refactor the fastreuse update code in inet_csk_get_port into a small helper function that can be called from other places. Acked-by:
-
Marek Behún authored
Commit c3e302ed ("net: phy: marvell10g: fix temperature sensor on 2110") added a check for PHY ID via phydev->drv->phy_id in a function which is called by devres at a time when phydev->drv is already set to null by phy_remove function. This null pointer dereference can be triggered via SFP subsystem with a SFP module containing this Marvell PHY. When the SFP interface is put down, the SFP subsystem removes the PHY. Fixes: c3e302ed ("net: phy: marvell10g: fix temperature sensor on 2110") Signed-off-by:
Marek Behún <marek.behun@nic.cz> Cc: Maxime Chevallier <maxime.chevallier@bootlin.com> Cc: Andrew Lunn <andrew@lunn.ch> Cc: Baruch Siach <baruch@tkos.co.il> Cc: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by:
-
Miaohe Lin authored
If we failed to assign proto idx, we free the twsk_slab_name but forget to free the twsk_slab. Add a helper function tw_prot_cleanup() to free these together and also use this helper function in proto_unregister(). Fixes: b45ce321 ("sock: fix potential memory leak in proto_register()") Signed-off-by:
Miaohe Lin <linmiaohe@huawei.com> Signed-off-by:
-
Wang Hai authored
Fix the missing clk_disable_unprepare() before return from emac_clks_phase1_init() in the error handling case. Fixes: b9b17deb ("net: emac: emac gigabit ethernet controller driver") Reported-by:
Hulk Robot <hulkci@huawei.com> Signed-off-by:
Wang Hai <wanghai38@huawei.com> Acked-by:
Timur Tabi <timur@kernel.org> Signed-off-by:
-
Xu Wang authored
A multiplication for the size determination of a memory allocation indicated that an array data structure should be processed. Thus use the corresponding function "devm_kcalloc". Signed-off-by:
Xu Wang <vulab@iscas.ac.cn> Acked-by:
Shannon Nelson <snelson@pensando.io> Signed-off-by:
-
Qingyu Li authored
When creating a raw AF_NFC socket, CAP_NET_RAW needs to be checked first. Signed-off-by:
Qingyu Li <ieatmuttonchuan@gmail.com> Signed-off-by:
-
Luo bin authored
fix the compile warnings of 'strncpy' output truncated before terminating nul copying N bytes from a string of the same length Signed-off-by:
Luo bin <luobin9@huawei.com> Reported-by:
-
Xie He authored
1. Added a skb->len check This driver expects upper layers to include a pseudo header of 1 byte when passing down a skb for transmission. This driver will read this 1-byte header. This patch added a skb->len check before reading the header to make sure the header exists. 2. Added needed_headroom When this driver transmits data, first this driver will remove a pseudo header of 1 byte, then the lapb module will prepend the LAPB header of 2 or 3 bytes. So the value of needed_headroom in this driver should be 3 - 1. Cc: Willem de Bruijn <willemdebruijn.kernel@gmail.com> Cc: Martin Schiller <ms@dev.tdt.de> Signed-off-by:
Xie He <xie.he.0141@gmail.com> Acked-by:
Willem de Bruijn <willemb@google.com> Signed-off-by:
-
Ira Weiny authored
When MSG_OOB is specified to tls_device_sendpage() the mapped page is never unmapped. Hold off mapping the page until after the flags are checked and the page is actually needed. Fixes: e8f69799 ("net/tls: Add generic NIC offload infrastructure") Signed-off-by:
Ira Weiny <ira.weiny@intel.com> Reviewed-by:
Jakub Kicinski <kuba@kernel.org> Signed-off-by:
-
- 10 Aug, 2020 5 commits
-
-
Jakub Kicinski authored
When ur_load_imm_any() is inlined into jeq_imm(), it's possible for the compiler to deduce a case where _val can only have the value of -1 at compile time. Specifically, /* struct bpf_insn: _s32 imm */ u64 imm = insn->imm; /* sign extend */ if (imm >> 32) { /* non-zero only if insn->imm is negative */ /* inlined from ur_load_imm_any */ u32 __imm = imm >> 32; /* therefore, always 0xffffffff */ if (__builtin_constant_p(__imm) && __imm > 255) compiletime_assert_XXX() This can result in tripping a BUILD_BUG_ON() in __BF_FIELD_CHECK() that checks that a given value is representable in one byte (interpreted as unsigned). FIELD_FIT() should return true or false at runtime for whether a value can fit for not. Don't break the build over a value that's too large for the mask. We'd prefer to keep the inlining and compiler optimizations though we know this case will always return false. Cc: stable@vger.kernel.org Fixes: 1697599e ("bitfield.h: add FIELD_FIT() helper") Link: https://lore.kernel.org/kernel-hardening/CAK7LNASvb0UDJ0U5wkYYRzTAdnEs64HjXpEUL7d=V0CXiAXcNw@mail.gmail.com/Reported-by:Masahiro Yamada <masahiroy@kernel.org> Debugged-by:
Sami Tolvanen <samitolvanen@google.com> Signed-off-by:
Nick Desaulniers <ndesaulniers@google.com> Signed-off-by:
-
Jason Baron authored
When TFO keys are read back on big endian systems either via the global sysctl interface or via getsockopt() using TCP_FASTOPEN_KEY, the values don't match what was written. For example, on s390x: # echo "1-2-3-4" > /proc/sys/net/ipv4/tcp_fastopen_key # cat /proc/sys/net/ipv4/tcp_fastopen_key 02000000-01000000-04000000-03000000 Instead of: # cat /proc/sys/net/ipv4/tcp_fastopen_key 00000001-00000002-00000003-00000004 Fix this by converting to the correct endianness on read. This was reported by Colin Ian King when running the 'tcp_fastopen_backup_key' net selftest on s390x, which depends on the read value matching what was written. I've confirmed that the test now passes on big and little endian systems. Signed-off-by:
Jason Baron <jbaron@akamai.com> Fixes: 438ac880 ("net: fastopen: robustness and endianness fixes for SipHash") Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Eric Dumazet <edumazet@google.com> Reported-and-tested-by:
Colin Ian King <colin.king@canonical.com> Signed-off-by:
-
Jakub Kicinski authored
I'm not doing much work on the NFP driver any more. Signed-off-by:
-
Ronak Doshi authored
Commit dacce2be ("vmxnet3: add geneve and vxlan tunnel offload support") added support for encapsulation offload. However, while calculating tcp hdr length, it does not take into account if the packet is encapsulated or not. This patch fixes this issue by using correct reference for inner tcp header. Fixes: dacce2be ("vmxnet3: add geneve and vxlan tunnel offload support") Signed-off-by:
Ronak Doshi <doshir@vmware.com> Acked-by:
Guolin Yang <gyang@vmware.com> Signed-off-by:
-
Christoph Hellwig authored
This reverts commits 6d04fe15 and a31edb20. It turns out the idea to share a single pointer for both kernel and user space address causes various kinds of problems. So use the slightly less optimal version that uses an extra bit, but which is guaranteed to be safe everywhere. Fixes: 6d04fe15 ("net: optimize the sockptr_t for unified kernel/user address spaces") Reported-by:
John Stultz <john.stultz@linaro.org> Signed-off-by:
Christoph Hellwig <hch@lst.de> Signed-off-by:
-
- 08 Aug, 2020 12 commits
-
-
Miaohe Lin authored
Convert the uses of fallthrough comments to fallthrough macro. Signed-off-by:
-
Miaohe Lin authored
Use helper function ip_is_fragment() to check ip fragment. Signed-off-by:
-
Miaohe Lin authored
The out_fs jump label has nothing to do but goto out. Signed-off-by:
-
Miaohe Lin authored
We should fput() file iff FDPUT_FPUT is set. So we should set fput_needed accordingly. Fixes: 00e188ef ("sockfd_lookup_light(): switch to fdget^W^Waway from fget_light") Signed-off-by:
-
Miaohe Lin authored
Use helper function fdput() to fput() the file iff FDPUT_FPUT is set. Signed-off-by:
-
Johan Hovold authored
A recent commit introduced a late error path in phy_device_create() which fails to release the device name allocated by dev_set_name(). Fixes: 13d0ab67 ("net: phy: check return code when requesting PHY driver module") Cc: Heiner Kallweit <hkallweit1@gmail.com> Signed-off-by:
Johan Hovold <johan@kernel.org> Signed-off-by:
-
Rouven Czerwinski authored
Trying to use ktls on a system with 32-bit userspace and 64-bit kernel results in a EOPNOTSUPP message during sendmsg: setsockopt(3, SOL_TLS, TLS_TX, …, 40) = 0 sendmsg(3, …, msg_flags=0}, 0) = -1 EOPNOTSUPP (Operation not supported) The tls_sw implementation does strict flag checking and does not allow the MSG_CMSG_COMPAT flag, which is set if the message comes in through the compat syscall. This patch adds MSG_CMSG_COMPAT to the flag check to allow the usage of the TLS SW implementation on systems using the compat syscall path. Note that the same check is present in the sendmsg path for the TLS device implementation, however the flag hasn't been added there for lack of testing hardware. Signed-off-by:
Rouven Czerwinski <r.czerwinski@pengutronix.de> Signed-off-by:
-
git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpfDavid S. Miller authored
Daniel Borkmann says: ==================== pull-request: bpf 2020-08-08 The following pull-request contains BPF updates for your *net* tree. We've added 11 non-merge commits during the last 2 day(s) which contain a total of 24 files changed, 216 insertions(+), 135 deletions(-). The main changes are: 1) Fix UAPI for BPF map iterator before it gets frozen to allow for more extensions/customization in future, from Yonghong Song. 2) Fix selftests build to undo verbose build output, from Andrii Nakryiko. 3) Fix inlining compilation error on bpf_do_trace_printk() due to variable argument lists, from Stanislav Fomichev. 4) Fix an uninitialized pointer warning at btf__parse_raw() in libbpf, from Daniel T. Lee. 5) Fix several compilation warnings in selftests with regards to ignoring return value, from Jianlin Lv. 6) Fix interruptions by switching off timeout for BPF tests, from Jiri Benc. ==================== Signed-off-by: -
Paolo Abeni authored
With commit b93df08c ("mptcp: explicitly track the fully established status"), the status of unaccepted mptcp closed in mptcp_sock_destruct() changes from TCP_SYN_RECV to TCP_ESTABLISHED. As a result mptcp_sock_destruct() does not perform the proper cleanup and inet_sock_destruct() will later emit a warn. Address the issue updating the condition tested in mptcp_sock_destruct(). Also update the related comment. Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/66Reported-and-tested-by:
Christoph Paasch <cpaasch@apple.com> Fixes: b93df08c ("mptcp: explicitly track the fully established status") Signed-off-by:
Paolo Abeni <pabeni@redhat.com> Reviewed-by:
-
Paolo Abeni authored
During diag self-tests we introduce long wait in the mptcp test program to give the script enough time to access the sockets dump. Such wait is introduced after shutting down one sockets end. Since commit 43b54c6e ("mptcp: Use full MPTCP-level disconnect state machine") if both sides shutdown the socket is correctly transitioned into CLOSED status. As a side effect some sockets are not dumped via the diag interface, because the socket state (CLOSED) does not match the default filter, and this cause self-tests instability. Address the issue moving the above mentioned wait before shutting down the socket. Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/68 Fixes: df62f2ec ("selftests/mptcp: add diag interface tests") Tested-and-acked-by:
-
Paolo Abeni authored
Since commit df62f2ec ("selftests/mptcp: add diag interface tests") the MPTCP selftests relies on the MPTCP diag interface which is enabled by a specific kconfig knob: be sure to include it. Fixes: df62f2ec ("selftests/mptcp: add diag interface tests") Signed-off-by:
-
Thierry Reding authored
Query the USB device's device tree node when looking for a MAC address. The struct device embedded into the struct net_device does not have a device tree node attached at all. The reason why this went unnoticed is because the system where this was tested was one of the few development units that had its OTP programmed, as opposed to production systems where the MAC address is stored in a separate EEPROM and is passed via device tree by the firmware. Reported-by:
EJ Hsu <ejh@nvidia.com> Fixes: acb6d377 ("r8152: Use MAC address from device tree if available") Signed-off-by:
Thierry Reding <treding@nvidia.com> Reviewed-by:
-
- 07 Aug, 2020 4 commits
-
-
Randy Dunlap authored
Drop repeated words in kernel/bpf/: {has, the} Signed-off-by:Randy Dunlap <rdunlap@infradead.org> Signed-off-by:
Daniel Borkmann <daniel@iogearbox.net> Link: https://lore.kernel.org/bpf/20200807033141.10437-1-rdunlap@infradead.org
-
Andrii Nakryiko authored
99aacebe ("selftests: do not use .ONESHELL") removed .ONESHELL, which changes how Makefile "silences" multi-command target recipes. selftests/bpf's Makefile relied (a somewhat unknowingly) on .ONESHELL behavior of silencing all commands within the recipe if the first command contains @ symbol. Removing .ONESHELL exposed this hack. This patch fixes the issue by explicitly silencing each command with $(Q). Also explicitly define fallback rule for building *.o from *.c, instead of relying on non-silent inherited rule. This was causing a non-silent output for bench.o object file. Fixes: 92f7440e ("selftests/bpf: More succinct Makefile output") Signed-off-by:
Andrii Nakryiko <andriin@fb.com> Signed-off-by:
-
Alan Maguire authored
The BPF helper bpf_trace_printk() no longer uses trace_printk(); it is now triggers a dedicated trace event. Hence the described warning is no longer present, so remove the discussion of it as it may confuse people. Fixes: ac5a72ea ("bpf: Use dedicated bpf_trace_printk event instead of trace_printk()") Signed-off-by:
Alan Maguire <alan.maguire@oracle.com> Signed-off-by:
-
Xie He authored
1. Added a skb->len check This driver expects upper layers to include a pseudo header of 1 byte when passing down a skb for transmission. This driver will read this 1-byte header. This patch added a skb->len check before reading the header to make sure the header exists. 2. Changed to use needed_headroom instead of hard_header_len to request necessary headroom to be allocated In net/packet/af_packet.c, the function packet_snd first reserves a headroom of length (dev->hard_header_len + dev->needed_headroom). Then if the socket is a SOCK_DGRAM socket, it calls dev_hard_header, which calls dev->header_ops->create, to create the link layer header. If the socket is a SOCK_RAW socket, it "un-reserves" a headroom of length (dev->hard_header_len), and assumes the user to provide the appropriate link layer header. So according to the logic of af_packet.c, dev->hard_header_len should be the length of the header that would be created by dev->header_ops->create. However, this driver doesn't provide dev->header_ops, so logically dev->hard_header_len should be 0. So we should use dev->needed_headroom instead of dev->hard_header_len to request necessary headroom to be allocated. This change fixes kernel panic when this driver is used with AF_PACKET SOCK_RAW sockets. Call stack when panic: [ 168.399197] skbuff: skb_under_panic: text:ffffffff819d95fb len:20 put:14 head:ffff8882704c0a00 data:ffff8882704c09fd tail:0x11 end:0xc0 dev:veth0 ... [ 168.399255] Call Trace: [ 168.399259] skb_push.cold+0x14/0x24 [ 168.399262] eth_header+0x2b/0xc0 [ 168.399267] lapbeth_data_transmit+0x9a/0xb0 [lapbether] [ 168.399275] lapb_data_transmit+0x22/0x2c [lapb] [ 168.399277] lapb_transmit_buffer+0x71/0xb0 [lapb] [ 168.399279] lapb_kick+0xe3/0x1c0 [lapb] [ 168.399281] lapb_data_request+0x76/0xc0 [lapb] [ 168.399283] lapbeth_xmit+0x56/0x90 [lapbether] [ 168.399286] dev_hard_start_xmit+0x91/0x1f0 [ 168.399289] ? irq_init_percpu_irqstack+0xc0/0x100 [ 168.399291] __dev_queue_xmit+0x721/0x8e0 [ 168.399295] ? packet_parse_headers.isra.0+0xd2/0x110 [ 168.399297] dev_queue_xmit+0x10/0x20 [ 168.399298] packet_sendmsg+0xbf0/0x19b0 ...... Cc: Willem de Bruijn <willemdebruijn.kernel@gmail.com> Cc: Martin Schiller <ms@dev.tdt.de> Cc: Brian Norris <briannorris@chromium.org> Signed-off-by:
-
- 06 Aug, 2020 1 commit
-
-
Jianlin Lv authored
Clang compiler version: 12.0.0 The following warning appears during the selftests/bpf compilation: prog_tests/send_signal.c:51:3: warning: ignoring return value of ‘write’, declared with attribute warn_unused_result [-Wunused-result] 51 | write(pipe_c2p[1], buf, 1); | ^~~~~~~~~~~~~~~~~~~~~~~~~~ prog_tests/send_signal.c:54:3: warning: ignoring return value of ‘read’, declared with attribute warn_unused_result [-Wunused-result] 54 | read(pipe_p2c[0], buf, 1); | ^~~~~~~~~~~~~~~~~~~~~~~~~ ...... prog_tests/stacktrace_build_id_nmi.c:13:2: warning: ignoring return value of ‘fscanf’,declared with attribute warn_unused_result [-Wunused-resul] 13 | fscanf(f, "%llu", &sample_freq); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ test_tcpnotify_user.c:133:2: warning:ignoring return value of ‘system’, declared with attribute warn_unused_result [-Wunused-result] 133 | system(test_script); | ^~~~~~~~~~~~~~~~~~~ test_tcpnotify_user.c:138:2: warning:ignoring return value of ‘system’, declared with attribute warn_unused_result [-Wunused-result] 138 | system(test_script); | ^~~~~~~~~~~~~~~~~~~ test_tcpnotify_user.c:143:2: warning:ignoring return value of ‘system’, declared with attribute warn_unused_result [-Wunused-result] 143 | system(test_script); | ^~~~~~~~~~~~~~~~~~~ Add code that fix compilation warning about ignoring return value and handles any errors; Check return value of library`s API make the code more secure. Signed-off-by:Jianlin Lv <Jianlin.Lv@arm.com> Signed-off-by:
Alexei Starovoitov <ast@kernel.org> Link: https://lore.kernel.org/bpf/20200806104224.95306-1-Jianlin.Lv@arm.com
-
