- 22 Sep, 2021 40 commits
-
-
Michael Chan authored
[ Upstream commit 1b2b9183 ] If error recovery is already enabled, bnxt_timer() will periodically check the heartbeat register and the reset counter. If we get an error recovery async. notification from the firmware (e.g. change in primary/secondary role), we will immediately read and update the heartbeat register and the reset counter. If the timer for the next health check expires soon after this, we may read the heartbeat register again in quick succession and find that it hasn't changed. This will trigger error recovery unintentionally. The likelihood is small because we also reset fw_health->tmr_counter which will reset the interval for the next health check. But the update is not protected and bnxt_timer() can miss the update and perform the health check without waiting for the full interval. Fix it by only reading the heartbeat register and reset counter in bnxt_async_event_process() if error recovery is trasitioning to the enabled state. Also add proper memory barriers so that when enabling for the first time, bnxt_timer() will see the tmr_counter interval and perform the health check after the full interval has elapsed. Fixes: 7e914027 ("bnxt_en: Enable health monitoring.") Reviewed-by:
Edwin Peer <edwin.peer@broadcom.com> Signed-off-by:
Michael Chan <michael.chan@broadcom.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Michael Chan authored
[ Upstream commit 6fdab8a3 ] The current asic.rev is incomplete and does not include the metal revision. Add the metal revision and decode the complete asic revision into the more common and readable form (A0, B0, etc). Fixes: 7154917a ("bnxt_en: Refactor bnxt_dl_info_get().") Reviewed-by:
Somnath Kotur <somnath.kotur@broadcom.com> Signed-off-by:
-
Edwin Peer authored
[ Upstream commit 1656db67 ] The FW_PSID version components are 8 bits wide, not 4. Fixes: db28b6c7 ("bnxt_en: Fix devlink info's stored fw.psid version format.") Signed-off-by:
-
Rafał Miłecki authored
[ Upstream commit 63f8428b ] Broadcom's b53 switches have one IMP (Inband Management Port) that needs to be programmed using its own designed register. IMP port may be different than CPU port - especially on devices with multiple CPU ports. For that reason it's required to explicitly note IMP port index and check for it when choosing a register to use. This commit fixes BCM5301x support. Those switches use CPU port 5 while their IMP port is 8. Before this patch b53 was trying to program port 5 with B53_PORT_OVERRIDE_CTRL instead of B53_GMII_PORT_OVERRIDE_CTRL(5). It may be possible to also replace "cpu_port" usages with dsa_is_cpu_port() but that is out of the scope of thix BCM5301x fix. Fixes: 967dd82f ("net: dsa: b53: Add support for Broadcom RoboSwitch") Signed-off-by:
Rafał Miłecki <rafal@milecki.pl> Signed-off-by:
-
Willem de Bruijn authored
[ Upstream commit 8a0ed250 ] The GRE tunnel device can pull existing outer headers in ipge_xmit. This is a rare path, apparently unique to this device. The below commit ensured that pulling does not move skb->data beyond csum_start. But it has a false positive if ip_summed is not CHECKSUM_PARTIAL and thus csum_start is irrelevant. Refine to exclude this. At the same time simplify and strengthen the test. Simplify, by moving the check next to the offending pull, making it more self documenting and removing an unnecessary branch from other code paths. Strengthen, by also ensuring that the transport header is correct and therefore the inner headers will be after skb_reset_inner_headers. The transport header is set to csum_start in skb_partial_csum_set. Link: https://lore.kernel.org/netdev/YS+h%2FtqCJJiQei+W@shredder/ Fixes: 1d011c48 ("ip_gre: add validation for csum_start") Reported-by:
Ido Schimmel <idosch@idosch.org> Suggested-by:
Alexander Duyck <alexander.duyck@gmail.com> Signed-off-by:
Willem de Bruijn <willemb@google.com> Reviewed-by:
Alexander Duyck <alexanderduyck@fb.com> Signed-off-by:
-
Christophe JAILLET authored
[ Upstream commit 45010c08 ] A firmware is requested but never released in this function. This leads to a memory leak in the normal execution path. Add the missing 'release_firmware()' call. Also introduce a temp variable (new_len) in order to keep the value of 'pnvm->size' after the firmware has been released. Fixes: cdda18fb ("iwlwifi: pnvm: move file loading code to a separate function") Signed-off-by:
Christophe JAILLET <christophe.jaillet@wanadoo.fr> Reviewed-by:
Dan Carpenter <dan.carpenter@oracle.com> Acked-by:
Luca Coelho <luca@coelho.fi> Signed-off-by:
Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/1b5d80f54c1dbf85710fd285243932943b498fe7.1630614969.git.christophe.jaillet@wanadoo.fr Signed-off-by:
-
Dror Moshe authored
[ Upstream commit b05c1d14 ] Move code that generates the pnvm file name to a separate function, so that it can be reused. Signed-off-by:
Dror Moshe <drorx.moshe@intel.com> Signed-off-by:
Luca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20210826224715.7d2dd18c75a2.I3652584755b9ab44909ddcd09ff4d80c6690a1ad@changeid Signed-off-by:
-
Dinghao Liu authored
[ Upstream commit 9ddbc2a0 ] Previous commit 68233c58 removes the qlcnic_rom_lock() in qlcnic_pinit_from_rom(), but remains its corresponding unlock function, which is odd. I'm not very sure whether the lock is missing, or the unlock is redundant. This bug is suggested by a static analysis tool, please advise. Fixes: 68233c58 ("qlcnic: updated reset sequence") Signed-off-by:
Dinghao Liu <dinghao.liu@zju.edu.cn> Signed-off-by:
-
Eric Dumazet authored
[ Upstream commit c7c5e6ff ] syzbot found that forcing a big quantum attribute would crash hosts fast, essentially using this: tc qd replace dev eth0 root fq_codel quantum 4294967295 This is because fq_codel_dequeue() would have to loop ~2^31 times in : if (flow->deficit <= 0) { flow->deficit += q->quantum; list_move_tail(&flow->flowchain, &q->old_flows); goto begin; } SFQ max quantum is 2^19 (half a megabyte) Lets adopt a max quantum of one megabyte for FQ_CODEL. Fixes: 4b549a2e ("fq_codel: Fair Queue Codel AQM") Signed-off-by:
Eric Dumazet <edumazet@google.com> Reported-by:
syzbot <syzkaller@googlegroups.com> Signed-off-by:
-
Benjamin Hesmans authored
[ Upstream commit 730affed ] Bug reported by KASAN: BUG: KASAN: use-after-scope in inet6_ehashfn (net/ipv6/inet6_hashtables.c:40) Call Trace: (...) inet6_ehashfn (net/ipv6/inet6_hashtables.c:40) (...) nf_sk_lookup_slow_v6 (net/ipv6/netfilter/nf_socket_ipv6.c:91 net/ipv6/netfilter/nf_socket_ipv6.c:146) It seems that this bug has already been fixed by Eric Dumazet in the past in: commit 78296c97 ("netfilter: xt_socket: fix a stack corruption bug") But a variant of the same issue has been introduced in commit d64d80a2 ("netfilter: x_tables: don't extract flow keys on early demuxed sks in socket match") `daddr` and `saddr` potentially hold a reference to ipv6_var that is no longer in scope when the call to `nf_socket_get_sock_v6` is made. Fixes: d64d80a2 ("netfilter: x_tables: don't extract flow keys on early demuxed sks in socket match") Acked-by:
Matthieu Baerts <matthieu.baerts@tessares.net> Signed-off-by:
Benjamin Hesmans <benjamin.hesmans@tessares.net> Reviewed-by:
Florian Westphal <fw@strlen.de> Signed-off-by:
Pablo Neira Ayuso <pablo@netfilter.org> Signed-off-by:
-
Mat Martineau authored
[ Upstream commit 340fa666 ] Recent changes exposed a bug where specifically-timed requests to the path manager netlink API could trigger a divide-by-zero in __tcp_select_window(), as syzkaller does: divide error: 0000 [#1] SMP KASAN NOPTI CPU: 0 PID: 9667 Comm: syz-executor.0 Not tainted 5.14.0-rc6+ #3 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014 RIP: 0010:__tcp_select_window+0x509/0xa60 net/ipv4/tcp_output.c:3016 Code: 44 89 ff e8 c9 29 e9 fd 45 39 e7 0f 8d 20 ff ff ff e8 db 28 e9 fd 44 89 e3 e9 13 ff ff ff e8 ce 28 e9 fd 44 89 e0 44 89 e3 99 <f7> 7c 24 04 29 d3 e9 fc fe ff ff e8 b7 28 e9 fd 44 89 f1 48 89 ea RSP: 0018:ffff888031ccf020 EFLAGS: 00010216 RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000040000 RDX: 0000000000000000 RSI: ffff88811532c080 RDI: 0000000000000002 RBP: 0000000000000000 R08: ffffffff835807c2 R09: 0000000000000000 R10: 0000000000000004 R11: ffffed1020b92441 R12: 0000000000000000 R13: 1ffff11006399e08 R14: 0000000000000000 R15: 0000000000000000 FS: 00007fa4c8344700(0000) GS:ffff88811ae00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000001b2f424000 CR3: 000000003e4e2003 CR4: 0000000000770ef0 PKRU: 55555554 Call Trace: tcp_select_window net/ipv4/tcp_output.c:264 [inline] __tcp_transmit_skb+0xc00/0x37a0 net/ipv4/tcp_output.c:1351 __tcp_send_ack.part.0+0x3ec/0x760 net/ipv4/tcp_output.c:3972 __tcp_send_ack net/ipv4/tcp_output.c:3978 [inline] tcp_send_ack+0x7d/0xa0 net/ipv4/tcp_output.c:3978 mptcp_pm_nl_addr_send_ack+0x1ab/0x380 net/mptcp/pm_netlink.c:654 mptcp_pm_remove_addr+0x161/0x200 net/mptcp/pm.c:58 mptcp_nl_remove_id_zero_address+0x197/0x460 net/mptcp/pm_netlink.c:1328 mptcp_nl_cmd_del_addr+0x98b/0xd40 net/mptcp/pm_netlink.c:1359 genl_family_rcv_msg_doit.isra.0+0x225/0x340 net/netlink/genetlink.c:731 genl_family_rcv_msg net/netlink/genetlink.c:775 [inline] genl_rcv_msg+0x341/0x5b0 net/netlink/genetlink.c:792 netlink_rcv_skb+0x148/0x430 net/netlink/af_netlink.c:2504 genl_rcv+0x24/0x40 net/netlink/genetlink.c:803 netlink_unicast_kernel net/netlink/af_netlink.c:1314 [inline] netlink_unicast+0x537/0x750 net/netlink/af_netlink.c:1340 netlink_sendmsg+0x846/0xd80 net/netlink/af_netlink.c:1929 sock_sendmsg_nosec net/socket.c:704 [inline] sock_sendmsg+0x14e/0x190 net/socket.c:724 ____sys_sendmsg+0x709/0x870 net/socket.c:2403 ___sys_sendmsg+0xff/0x170 net/socket.c:2457 __sys_sendmsg+0xe5/0x1b0 net/socket.c:2486 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x38/0x90 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x44/0xae mptcp_pm_nl_addr_send_ack() was attempting to send a TCP ACK on the first subflow in the MPTCP socket's connection list without validating that the subflow was in a suitable connection state. To address this, always validate subflow state when sending extra ACKs on subflows for address advertisement or subflow priority change. Fixes: 84dfe367 ("mptcp: send out dedicated ADD_ADDR packet") Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/229 Co-developed-by:
Paolo Abeni <pabeni@redhat.com> Signed-off-by:
Mat Martineau <mathew.j.martineau@linux.intel.com> Acked-by:
Geliang Tang <geliangtang@gmail.com> Signed-off-by:
-
Rafał Miłecki authored
[ Upstream commit d12e1c46 ] Setting DSA_MAX_PORTS caused DSA to call b53 callbacks (e.g. b53_disable_port() during dsa_register_switch()) for invalid (non-existent) ports. That made b53 modify unrelated registers and is one of reasons for a broken BCM5301x support. This problem exists for years but DSA_MAX_PORTS usage has changed few times. It seems the most accurate to reference commit dropping dsa_switch_alloc() in the Fixes tag. Fixes: 7e99e347 ("net: dsa: remove dsa_switch_alloc helper") Signed-off-by:
-
Rafał Miłecki authored
[ Upstream commit cdb067d3 ] It isn't true that CPU port is always the last one. Switches BCM5301x have 9 ports (port 6 being inactive) and they use port 5 as CPU by default (depending on design some other may be CPU ports too). A more reliable way of determining number of ports is to check for the last set bit in the "enabled_ports" bitfield. This fixes b53 internal state, it will allow providing accurate info to the DSA and is required to fix BCM5301x support. Fixes: 967dd82f ("net: dsa: b53: Add support for Broadcom RoboSwitch") Signed-off-by:
Florian Fainelli <f.fainelli@gmail.com> Signed-off-by:
-
Ziyang Xuan authored
[ Upstream commit ecdc28de ] If the network devices connected to the system beyond HSO_MAX_NET_DEVICES. add_net_device() in hso_create_net_device() will be failed for the network_table is full. It will lead to business failure which rely on network_table, for example, hso_suspend() and hso_resume(). It will also lead to memory leak because resource release process can not search the hso_device object from network_table in hso_free_interface(). Add failure handler for add_net_device() in hso_create_net_device() to solve the above problems. Fixes: 72dc1c09 ("HSO: add option hso driver") Signed-off-by:
Ziyang Xuan <william.xuanziyang@huawei.com> Signed-off-by:
-
Matthieu Baerts authored
[ Upstream commit bfd862a7 ] '$cin' and '$sin' variables are local to a function: they are then not available from the cleanup trap. Instead, we need to use '$large' and '$small' that are not local and defined just before setting the trap. Without this patch, running this script in a loop might cause a: write: No space left on device issue. Fixes: 1a418cb8 ("mptcp: simult flow self-tests") Acked-by:
Jakub Kicinski <kuba@kernel.org> Signed-off-by:
-
Paolo Abeni authored
[ Upstream commit 1094c6fe ] Florian noted that if mptcp_alloc_tx_skb() allocation fails in __mptcp_push_pending(), we can end-up invoking mptcp_push_release()/tcp_push() with a zero mss, causing a divide by 0 error. This change addresses the issue refactoring the skb allocation code checking if skb collapsing will happen for sure and doing the skb allocation only after such check. Skb allocation will now happen only after the call to tcp_send_mss() which correctly initializes mss_now. As side bonuses we now fill the skb tx cache only when needed, and this also clean-up a bit the output path. v1 -> v2: - use lockdep_assert_held_once() - Jakub - fix indentation - Jakub Reported-by:
-
James Clark authored
[ Upstream commit 8af52e69 ] Currently the clean target when using O= isn't cleaning the feature detect output. This is because O= and OUTPUT= are set to canonical paths. For example in tools/perf/Makefile: FULL_O := $(shell cd $(PWD); readlink -f $(O) || echo $(O)) This means that OUTPUT ends in a / and most usages prepend it to a file without adding an extra /. This line that was changed adds an extra / before the 'feature' folder but not to the end, resulting in a clean command like this: rm -f /tmp/build//featuretest-all.bin ... After the change the clean command looks like this: rm -f /tmp/build/feature/test-all.bin ... Fixes: 762323eb ("perf build: Move feature cleanup under tools/build") Signed-off-by:
James Clark <james.clark@arm.com> Acked-by:
Jiri Olsa <jolsa@kernel.org> Link: http://lore.kernel.org/lkml/20210816130705.1331868-1-james.clark@arm.com Signed-off-by:
Arnaldo Carvalho de Melo <acme@redhat.com> Signed-off-by:
-
Linus Walleij authored
[ Upstream commit 0e90dfa7 ] I noticed that only port 0 worked on the RTL8366RB since we started to use custom tags. It turns out that the format of egress custom tags is actually different from ingress custom tags. While the lower bits just contain the port number in ingress tags, egress tags need to indicate destination port by setting the bit for the corresponding port. It was working on port 0 because port 0 added 0x00 as port number in the lower bits, and if you do this the packet appears at all ports, including the intended port. Ooops. Fix this and all ports work again. Use the define for shifting the "type A" into place while we're at it. Tested on the D-Link DIR-685 by sending traffic to each of the ports in turn. It works. Fixes: 86dd9868 ("net: dsa: tag_rtl4_a: Support also egress tags") Cc: DENG Qingfang <dqfext@gmail.com> Cc: Mauri Sandberg <sandberg@mailfence.com> Signed-off-by:
Linus Walleij <linus.walleij@linaro.org> Reviewed-by:
-
Ming Lei authored
[ Upstream commit 7db30437 ] In case of buffered reading from block device, when short read happens, we should retry to read more, otherwise the IO will be completed partially, for example, the following fio expects to read 2MB, but it can only read 1M or less bytes: fio --name=onessd --filename=/dev/nvme0n1 --filesize=2M \ --rw=randread --bs=2M --direct=0 --overwrite=0 --numjobs=1 \ --iodepth=1 --time_based=0 --runtime=2 --ioengine=io_uring \ --registerfiles --fixedbufs --gtod_reduce=1 --group_reporting Fix the issue by allowing short read retry for block device, which sets FMODE_BUF_RASYNC really. Fixes: 9a173346 ("io_uring: fix short read retries for non-reg files") Cc: Pavel Begunkov <asml.silence@gmail.com> Signed-off-by:
Ming Lei <ming.lei@redhat.com> Reviewed-by:
Pavel Begunkov <asml.silence@gmail.com> Link: https://lore.kernel.org/r/20210821150751.1290434-1-ming.lei@redhat.com Signed-off-by:
Jens Axboe <axboe@kernel.dk> Signed-off-by:
-
Christophe JAILLET authored
[ Upstream commit 889a1b3f ] If an error occurs after a 'gpiochip_add_data()' call it must be undone by a corresponding 'gpiochip_remove()' as already done in the remove function. To simplify the code a fix a leak in the error handling path of the probe, use the managed version instead (i.e. 'devm_gpiochip_add_data()') Fixes: 698b8eea ("gpio/mpc8xxx: change irq handler from chained to normal") Signed-off-by:
Bartosz Golaszewski <bgolaszewski@baylibre.com> Signed-off-by:
-
Christophe JAILLET authored
[ Upstream commit 7d658893 ] Commit 76c47d14 ("gpio: mpc8xxx: Add ACPI support") has switched to a managed version when dealing with 'mpc8xxx_gc->regs'. So the corresponding 'iounmap()' call in the error handling path and in the remove should be removed to avoid a double unmap. This also allows some simplification in the probe. All the error handling paths related to managed resources can be direct returns and a NULL check in what remains in the error handling path can be removed. Fixes: 76c47d14 ("gpio: mpc8xxx: Add ACPI support") Signed-off-by:
-
Christophe JAILLET authored
[ Upstream commit 555bda42 ] Commit 698b8eea ("gpio/mpc8xxx: change irq handler from chained to normal") has introduced a new 'goto err;' at the very end of the function, but has not updated the error handling path accordingly. Add the now missing 'irq_domain_remove()' call which balances a previous 'irq_domain_create_linear() call. Fixes: 698b8eea ("gpio/mpc8xxx: change irq handler from chained to normal") Signed-off-by:
-
Arnaldo Carvalho de Melo authored
[ Upstream commit edf7b4a2 ] The build on fedora:35 and fedora:rawhide with clang is failing with: 49 41.00 fedora:35 : FAIL clang version 13.0.0 (Fedora 13.0.0~rc1-1.fc35) bench/inject-buildid.c:351:6: error: variable 'len' set but not used [-Werror,-Wunused-but-set-variable] u64 len = 0; ^ 1 error generated. make[3]: *** [/git/perf-5.14.0-rc7/tools/build/Makefile.build:139: bench] Error 2 50 41.11 fedora:rawhide : FAIL clang version 13.0.0 (Fedora 13.0.0~rc1-1.fc35) bench/inject-buildid.c:351:6: error: variable 'len' set but not used [-Werror,-Wunused-but-set-variable] u64 len = 0; ^ 1 error generated. make[3]: *** [/git/perf-5.14.0-rc7/tools/build/Makefile.build:139: bench] Error 2 That 'len' variable is not used at all, so just make sure all the synthesize_RECORD() routines return ssize_t to propagate the writen() return, as it may fail, ditch the 'ret' var and bail out if those routines fail. Fixes: 0bf02a0d ("perf bench: Add build-id injection benchmark") Acked-by:
Namhyung Kim <namhyung@kernel.org> Link: http://lore.kernel.org/lkml/CAM9d7cgEZNSor+B+7Y2C+QYGme_v5aH0Zn0RLfxoQ+Fy83EHrg@mail.gmail.com Signed-off-by:
-
Li Huafei authored
[ Upstream commit cdf32b44 ] When setting LIBUNWIND_DIR, we first set FEATURE_CHECK_LDFLAGS-libunwind-{aarch64,x86} = -L$(LIBUNWIND_DIR)/lib. <committer note> This happens a bit before, the overwritting, in: libunwind_arch_set_flags = $(eval $(libunwind_arch_set_flags_code)) define libunwind_arch_set_flags_code FEATURE_CHECK_CFLAGS-libunwind-$(1) = -I$(LIBUNWIND_DIR)/include FEATURE_CHECK_LDFLAGS-libunwind-$(1) = -L$(LIBUNWIND_DIR)/lib endef ifdef LIBUNWIND_DIR LIBUNWIND_CFLAGS = -I$(LIBUNWIND_DIR)/include LIBUNWIND_LDFLAGS = -L$(LIBUNWIND_DIR)/lib LIBUNWIND_ARCHS = x86 x86_64 arm aarch64 debug-frame-arm debug-frame-aarch64 $(foreach libunwind_arch,$(LIBUNWIND_ARCHS),$(call libunwind_arch_set_flags,$(libunwind_arch))) endif Look at that 'foreach' on all the LIBUNWIND_ARCHS. </> After commit 5c4d7c82 ("perf unwind: Do not put libunwind-{x86,aarch64} in FEATURE_TESTS_BASIC"), FEATURE_CHECK_LDFLAGS-libunwind-{x86,aarch64} is overwritten. As a result, the remote libunwind libraries cannot be searched from $(LIBUNWIND_DIR)/lib directory during feature check tests. Fix it with variable appending. Before this patch: perf$ make VF=1 LIBUNWIND_DIR=/opt/libunwind_aarch64 BUILD: Doing 'make -j16' parallel build <SNIP> ... ... libopencsd: [ OFF ] ... libunwind-x86: [ OFF ] ... libunwind-x86_64: [ OFF ] ... libunwind-arm: [ OFF ] ... libunwind-aarch64: [ OFF ] ... libunwind-debug-frame: [ OFF ] ... libunwind-debug-frame-arm: [ OFF ] ... libunwind-debug-frame-aarch64: [ OFF ] ... cxx: [ OFF ] <SNIP> perf$ cat ../build/feature/test-libunwind-aarch64.make.output /usr/bin/ld: cannot find -lunwind-aarch64 /usr/bin/ld: cannot find -lunwind-aarch64 collect2: error: ld returned 1 exit status After this patch: perf$ make VF=1 LIBUNWIND_DIR=/opt/libunwind_aarch64 BUILD: Doing 'make -j16' parallel build <SNIP> ... libopencsd: [ OFF ] ... libunwind-x86: [ OFF ] ... libunwind-x86_64: [ OFF ] ... libunwind-arm: [ OFF ] ... libunwind-aarch64: [ on ] ... libunwind-debug-frame: [ OFF ] ... libunwind-debug-frame-arm: [ OFF ] ... libunwind-debug-frame-aarch64: [ OFF ] ... cxx: [ OFF ] <SNIP> perf$ cat ../build/feature/test-libunwind-aarch64.make.output perf$ ldd ./perf linux-vdso.so.1 (0x00007ffdf07da000) libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f30953dc000) librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f30951d4000) libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f3094e36000) libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f3094c32000) libelf.so.1 => /usr/lib/x86_64-linux-gnu/libelf.so.1 (0x00007f3094a18000) libdw.so.1 => /usr/lib/x86_64-linux-gnu/libdw.so.1 (0x00007f30947cc000) libunwind-x86_64.so.8 => /usr/lib/x86_64-linux-gnu/libunwind-x86_64.so.8 (0x00007f30945ad000) libunwind.so.8 => /usr/lib/x86_64-linux-gnu/libunwind.so.8 (0x00007f3094392000) liblzma.so.5 => /lib/x86_64-linux-gnu/liblzma.so.5 (0x00007f309416c000) libunwind-aarch64.so.8 => not found libslang.so.2 => /lib/x86_64-linux-gnu/libslang.so.2 (0x00007f3093c8a000) libpython2.7.so.1.0 => /usr/local/lib/libpython2.7.so.1.0 (0x00007f309386b000) libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f309364e000) libnuma.so.1 => /usr/lib/x86_64-linux-gnu/libnuma.so.1 (0x00007f3093443000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f3093052000) /lib64/ld-linux-x86-64.so.2 (0x00007f3096097000) libbz2.so.1.0 => /lib/x86_64-linux-gnu/libbz2.so.1.0 (0x00007f3092e42000) libutil.so.1 => /lib/x86_64-linux-gnu/libutil.so.1 (0x00007f3092c3f000) Fixes: 5c4d7c82 ("perf unwind: Do not put libunwind-{x86,aarch64} in FEATURE_TESTS_BASIC") Signed-off-by:
Li Huafei <lihuafei1@huawei.com> Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com> Cc: He Kuang <hekuang@huawei.com> Cc: Jiri Olsa <jolsa@redhat.com> Cc: Mark Rutland <mark.rutland@arm.com> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Zhang Jinhao <zhangjinhao2@huawei.com> Link: http://lore.kernel.org/lkml/20210823134340.60955-1-lihuafei1@huawei.com Signed-off-by:
-
Arnaldo Carvalho de Melo authored
[ Upstream commit 261f4911 ] Acaict, perf_home_perfconfig() is supposed to cache the result of home_perfconfig, which returns the default location of perfconfig for the user, given the HOME environment variable. However, the current implementation calls home_perfconfig every time perf_home_perfconfig() is called (so no caching is actually performed), replacing the previous pointer, thus also causing a memory leak. This patch adds a check of whether either config or failed is set and, in that case, directly returns config without calling home_perfconfig at each invocation. Fixes: f5f03e19 ("perf config: Add perf_home_perfconfig function") Signed-off-by:
Riccardo Mancini <rickyman7@gmail.com> Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com> Cc: Ian Rogers <irogers@google.com> Cc: Jin Yao <yao.jin@linux.intel.com> Cc: Jiri Olsa <jolsa@redhat.com> Cc: Mark Rutland <mark.rutland@arm.com> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Song Liu <song@kernel.org> Link: http://lore.kernel.org/lkml/20210820130817.740536-1-rickyman7@gmail.com [ Removed needless double check for the 'failed' variable ] Signed-off-by:
-
Randy Dunlap authored
[ Upstream commit 6b5ff040 ] 0day bot reports a build error: ERROR: modpost: "clear_user_page" [drivers/media/v4l2-core/videobuf-dma-sg.ko] undefined! so export it in arch/arc/ to fix the build error. In most ARCHes, clear_user_page() is a macro. OTOH, in a few ARCHes it is a function and needs to be exported. PowerPC exported it in 2004. It looks like nds32 and nios2 still need to have it exported. Fixes: 4102b533 ("ARC: [mm] Aliasing VIPT dcache support 2/4") Signed-off-by:
Randy Dunlap <rdunlap@infradead.org> Reported-by:
kernel test robot <lkp@intel.com> Cc: Guenter Roeck <linux@roeck-us.net> Cc: linux-snps-arc@lists.infradead.org Signed-off-by:
Vineet Gupta <vgupta@kernel.org> Signed-off-by:
-
Christophe JAILLET authored
[ Upstream commit 6b430c75 ] A successful 'init_rs_non_canonical()' call should be balanced by a corresponding 'free_rs()' call in the error handling path of the probe, as already done in the remove function. Update the error handling path accordingly. Fixes: 8c61b7a7 ("[MTD] [NAND] Use rslib for CAFÉ ECC") Signed-off-by:
Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/linux-mtd/fd313d3fb787458bcc73189e349f481133a2cdc9.1629532640.git.christophe.jaillet@wanadoo.fr Signed-off-by:
-
Curtis Klein authored
[ Upstream commit c7b178da ] watchdog_hrtimer_pretimeout_stop needs the watchdog device to have a valid pointer to the watchdog core data to stop the pretimeout hrtimer. Therefore it needs to be called before the pointers are cleared in watchdog_cdev_unregister. Fixes: 7b7d2fdc ("watchdog: Add hrtimer-based pretimeout feature") Reported-by:
Colin Ian King <colin.king@canonical.com> Signed-off-by:
Curtis Klein <curtis.klein@hpe.com> Reviewed-by:
Guenter Roeck <linux@roeck-us.net> Link: https://lore.kernel.org/r/1624429583-5720-1-git-send-email-curtis.klein@hpe.com Signed-off-by:
Wim Van Sebroeck <wim@linux-watchdog.org> Signed-off-by:
-
Andy Shevchenko authored
[ Upstream commit 817f9916 ] The CONFIG_PCI=y case got a new parameter long time ago. Sync the stub as well. [bhelgaas: add parameter names] Fixes: 725522b5 ("PCI: add the sysfs driver name to all modules") Link: https://lore.kernel.org/r/20210813153619.89574-1-andriy.shevchenko@linux.intel.com Reported-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by:
Bjorn Helgaas <bhelgaas@google.com> Signed-off-by:
-
Jakub Kicinski authored
[ Upstream commit ff3a52ab ] Since 39850ed5 ("PCI/PTM: Save/restore Precision Time Measurement Capability for suspend/resume"), devices that have PTM capability but don't enable it see this message on calls to pci_save_state(): no suspend buffer for PTM Drop the message, it's perfectly fine not to use a capability. Fixes: 39850ed5 ("PCI/PTM: Save/restore Precision Time Measurement Capability for suspend/resume") Link: https://lore.kernel.org/r/20210811185955.3112534-1-kuba@kernel.org Signed-off-by:
David E. Box <david.e.box@linux.intel.com> Signed-off-by:
-
Oliver Upton authored
[ Upstream commit 6826c684 ] The CPU_ON PSCI call takes a payload that KVM uses to configure a destination vCPU to run. This payload is non-architectural state and not exposed through any existing UAPI. Effectively, we have a race between CPU_ON and userspace saving/restoring a guest: if the target vCPU isn't ran again before the VMM saves its state, the requested PC and context ID are lost. When restored, the target vCPU will be runnable and start executing at its old PC. We can avoid this race by making sure the reset payload is serviced before userspace can access a vCPU's state. Fixes: 358b28f0 ("arm/arm64: KVM: Allow a VCPU to fully reset itself") Signed-off-by:
Oliver Upton <oupton@google.com> Signed-off-by:
Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20210818202133.1106786-3-oupton@google.com Signed-off-by:
-
Oliver Upton authored
[ Upstream commit 6654f9df ] KVM correctly serializes writes to a vCPU's reset state, however since we do not take the KVM lock on the read side it is entirely possible to read state from two different reset requests. Cure the race for now by taking the KVM lock when reading the reset_state structure. Fixes: 358b28f0 ("arm/arm64: KVM: Allow a VCPU to fully reset itself") Signed-off-by:
-
Zhihao Cheng authored
[ Upstream commit a89d69a4 ] Since 2431c4f5 ("mtd: Implement mtd_{read,write}() as wrappers around mtd_{read,write}_oob()") don't allow _write|_read and _write_oob|_read_oob existing at the same time, we should check the existence of callbacks "_read and _write" from subdev's master device (We can trust master device since it has been registered) before assigning, otherwise following warning occurs while making concatenated device: WARNING: CPU: 2 PID: 6728 at drivers/mtd/mtdcore.c:595 add_mtd_device+0x7f/0x7b0 Fixes: 2431c4f5 ("mtd: Implement mtd_{read,write}() around ...") Signed-off-by:
Zhihao Cheng <chengzhihao1@huawei.com> Signed-off-by:
-
Zhihao Cheng authored
[ Upstream commit f9e109a2 ] Since commit 46b5889c("mtd: implement proper partition handling") applied, mtd partition device won't hold some callback functions, such as _block_isbad, _block_markbad, etc. Besides, function mtd_block_isbad() will get mtd device's master mtd device, then invokes master mtd device's callback function. So, following process may result mtd_block_isbad() always return 0, even though mtd device has bad blocks: 1. Split a mtd device into 3 partitions: PA, PB, PC [ Each mtd partition device won't has callback function _block_isbad(). ] 2. Concatenate PA and PB as a new mtd device PN [ mtd_concat_create() finds out each subdev has no callback function _block_isbad(), so PN won't be assigned callback function concat_block_isbad(). ] Then, mtd_block_isbad() checks "!master->_block_isbad" is true, will always return 0. Reproducer: // reproduce.c static int __init init_diy_module(void) { struct mtd_info *mtd[2]; struct mtd_info *mtd_combine = NULL; mtd[0] = get_mtd_device_nm("NAND simulator partition 0"); if (!mtd[0]) { pr_err("cannot find mtd1\n"); return -EINVAL; } mtd[1] = get_mtd_device_nm("NAND simulator partition 1"); if (!mtd[1]) { pr_err("cannot find mtd2\n"); return -EINVAL; } put_mtd_device(mtd[0]); put_mtd_device(mtd[1]); mtd_combine = mtd_concat_create(mtd, 2, "Combine mtd"); if (mtd_combine == NULL) { pr_err("combine failed\n"); return -EINVAL; } mtd_device_register(mtd_combine, NULL, 0); pr_info("Combine success\n"); return 0; } 1. ID="0x20,0xac,0x00,0x15" 2. modprobe nandsim id_bytes=$ID parts=50,100 badblocks=100 3. insmod reproduce.ko 4. flash_erase /dev/mtd3 0 0 libmtd: error!: MEMERASE64 ioctl failed for eraseblock 100 (mtd3) error 5 (Input/output error) // Should be "flash_erase: Skipping bad block at 00c80000" Fixes: 46b5889c ("mtd: implement proper partition handling") Signed-off-by:
-
Masami Hiramatsu authored
[ Upstream commit 6fe7c745 ] Fixes a build error when CONFIG_HIST_TRIGGERS=n with boot-time tracing. Since the trigger_process_regex() is defined only when CONFIG_HIST_TRIGGERS=y, if it is disabled, the 'actions' event option also must be disabled. Link: https://lkml.kernel.org/r/162856123376.203126.582144262622247352.stgit@devnote2 Fixes: 81a59555 ("tracing/boot: Add per-event settings") Signed-off-by:
Masami Hiramatsu <mhiramat@kernel.org> Signed-off-by:
Steven Rostedt (VMware) <rostedt@goodmis.org> Signed-off-by:
-
Matthias Schiffer authored
[ Upstream commit a946506c ] The driver was registering IRQ 0 when no IRQ was set. This leads to warnings with newer kernels. Clear the resource flags, so no resource is registered at all in this case. Fixes: 2f17dd34 ("mfd: tqmx86: IO controller with I2C, Wachdog and GPIO") Signed-off-by:
Matthias Schiffer <matthias.schiffer@ew.tq-group.com> Reviewed-by:
Andrew Lunn <andrew@lunn.ch> Signed-off-by:
Lee Jones <lee.jones@linaro.org> Signed-off-by:
-
Dan Carpenter authored
[ Upstream commit 7eb6ea41 ] pci_dev_str_match_path() is often called with a spinlock held so the allocation has to be atomic. The call tree is: pci_specified_resource_alignment() <-- takes spin_lock(); pci_dev_str_match() pci_dev_str_match_path() Fixes: 45db3370 ("PCI: Allow specifying devices using a base bus and path of devfns") Link: https://lore.kernel.org/r/20210812070004.GC31863@kili Signed-off-by:
Logan Gunthorpe <logang@deltatee.com> Signed-off-by:
-
Anshuman Khandual authored
[ Upstream commit 5e5df957 ] Even though ID_AA64MMFR0.PARANGE reports 52 bit PA size support, it cannot be enabled as guest IPA size on 4K or 16K page size configurations. Hence kvm_ipa_limit must be restricted to 48 bits. This change achieves required IPA capping. Before the commit c9b69a0c ("KVM: arm64: Don't constrain maximum IPA size based on host configuration"), the problem here would have been just latent via PHYS_MASK_SHIFT (which earlier in turn capped kvm_ipa_limit), which remains capped at 48 bits on 4K and 16K configs. Cc: Marc Zyngier <maz@kernel.org> Cc: James Morse <james.morse@arm.com> Cc: Alexandru Elisei <alexandru.elisei@arm.com> Cc: Suzuki K Poulose <suzuki.poulose@arm.com> Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: Will Deacon <will@kernel.org> Cc: linux-arm-kernel@lists.infradead.org Cc: kvmarm@lists.cs.columbia.edu Cc: linux-kernel@vger.kernel.org Fixes: c9b69a0c ("KVM: arm64: Don't constrain maximum IPA size based on host configuration") Signed-off-by:
Anshuman Khandual <anshuman.khandual@arm.com> Signed-off-by:
-
Pavel Skripkin authored
[ Upstream commit e3245a7b ] Syzbot hit use-after-free in nf_tables_dump_sets. The problem was in missing lock protection for nft_ct_pcpu_template_refcnt. Before commit f102d66b ("netfilter: nf_tables: use dedicated mutex to guard transactions") all transactions were serialized by global mutex, but then global mutex was changed to local per netnamespace commit_mutex. This change causes use-after-free bug, when 2 netnamespaces concurently changing nft_ct_pcpu_template_refcnt without proper locking. Fix it by adding nft_ct_pcpu_mutex and protect all nft_ct_pcpu_template_refcnt changes with it. Fixes: f102d66b ("netfilter: nf_tables: use dedicated mutex to guard transactions") Reported-and-tested-by: syzbot+649e339fa6658ee623d3@syzkaller.appspotmail.com Signed-off-by:
Pavel Skripkin <paskripkin@gmail.com> Acked-by:
-
Rob Herring authored
[ Upstream commit aeaea896 ] In commit 7ef1c871 ("PCI: iproc: Use pci_parse_request_of_pci_ranges()"), calling devm_request_pci_bus_resources() was dropped from the common iProc probe code, but is still needed for BCMA bus probing. Without it, there will be lots of warnings like this: pci 0000:00:00.0: BAR 8: no space for [mem size 0x00c00000] pci 0000:00:00.0: BAR 8: failed to assign [mem size 0x00c00000] Add back calling devm_request_pci_bus_resources() and adding the resources to pci_host_bridge.windows for BCMA bus probe. Link: https://lore.kernel.org/r/20210803215656.3803204-2-robh@kernel.org Fixes: 7ef1c871 ("PCI: iproc: Use pci_parse_request_of_pci_ranges()") Reported-by:
Rafał Miłecki <zajec5@gmail.com> Tested-by:
Rob Herring <robh@kernel.org> Signed-off-by:
Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Cc: Srinath Mannam <srinath.mannam@broadcom.com> Cc: Roman Bacik <roman.bacik@broadcom.com> Cc: Bharat Gooty <bharat.gooty@broadcom.com> Cc: Abhishek Shah <abhishek.shah@broadcom.com> Cc: Jitendra Bhivare <jitendra.bhivare@broadcom.com> Cc: Ray Jui <ray.jui@broadcom.com> Cc: Florian Fainelli <f.fainelli@gmail.com> Cc: BCM Kernel Feedback <bcm-kernel-feedback-list@broadcom.com> Cc: Scott Branden <sbranden@broadcom.com> Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Cc: "Krzysztof Wilczyński" <kw@linux.com> Cc: Bjorn Helgaas <bhelgaas@google.com> Signed-off-by:
-
