mirror of https://gitee.com/openkylin/linux.git
967889 Commits
Author | SHA1 | Message | Date |
---|---|---|---|
Maor Dickman | 219b3267ca |
net/mlx5e: Fix check if netdev is bond slave
Bond events handler uses bond_slave_get_rtnl to check if net device
is bond slave. bond_slave_get_rtnl return the rcu rx_handler pointer
from the netdev which exists for bond slaves but also exists for
devices that are attached to linux bridge so using it as indication
for bond slave is wrong.
Fix by using netif_is_lag_port instead.
Fixes:
|
|
Huy Nguyen | 6248ce991f |
net/mlx5e: Fix IPsec packet drop by mlx5e_tc_update_skb
Both TC and IPsec crypto offload use metadata_regB to store
private information. Since TC does not use bit 31 of regB, IPsec
will use bit 31 as the IPsec packet marker. The IPsec's regB usage
is changed to:
Bit31: IPsec marker
Bit30-24: IPsec syndrome
Bit23-0: IPsec obj id
Fixes:
|
|
Huy Nguyen | 5cfb540ef2 |
net/mlx5e: Set IPsec WAs only in IP's non checksum partial case.
The IP's checksum partial still requires L4 csum flag on Ethernet WQE.
Make the IPsec WAs only for the IP's non checksum partial case
(for example icmd packet)
Fixes:
|
|
Maxim Mikityanskiy | ea63609857 |
net/mlx5e: Fix refcount leak on kTLS RX resync
On resync, the driver calls inet_lookup_established
(__inet6_lookup_established) that increases sk_refcnt of the socket. To
decrease it, the driver set skb->destructor to sock_edemux. However, it
didn't work well, because the TCP stack also sets this destructor for
early demux, and the refcount gets decreased only once, while increased
two times (in mlx5e and in the TCP stack). It leads to a socket leak, a
TLS context leak, which in the end leads to calling tls_dev_del twice:
on socket close and on driver unload, which in turn leads to a crash.
This commit fixes the refcount leak by calling sock_gen_put right away
after using the socket, thus fixing all the subsequent issues.
Fixes:
|
|
Linus Torvalds | 111e91a6df |
- fix system call exit path; avoid return to user space with
any TIF/CIF/PIF set - fix file permission for cpum_sfb_size parameter - another small defconfig update -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEECMNfWEw3SLnmiLkZIg7DeRspbsIFAl+0EOoACgkQIg7DeRsp bsIh5g/+LuitpduJRvbyb9Km1A+CSflhC7USScBnyO0n2MRlo1c4M2rRIoUtOVD4 ktOV03CcKAjahw3umIx9euHkqYo5qgUVkSgx9q23R0GMf3iSXwh4wKKpe/YAuiad qsAunpD6xRtKm2xqnnSGYiZ8gKDRw7N+nZBWNrZa74I/thcNZbq1d7TBmrTJrkYL EH8JxTvPohNpjtDYOwVh8XcKPl1tT3R7N9/bmudTiOtGQtDWCsOjg4XisAc10ovw thCmr1t32SBifdhk6HE7AQrA73EpazDQlAUZlPVb+E7JJypp5gUDSkJO1wZ+TkhW WJgIgJGzeyJ9iqLQQcnwdxQW91spKr/gYw9yy5gZDZ1uvCclqdfKo/sha1N+xX3F j67+h/LEOGV3d02mBlDi6+4fnjHbnyWhDUivi3Atp7PHmWGd1qTPjLqZ3NsXZrLT 8sTX6c77g8YqzC++Q2goXPDmToxqcT1LCPpAVSNYY3BdAsOgvMJSlFVia1If5SAv 6MU8MUWTORBqh7c/hB0Ka+cVJUxtZ6Pt/HESM9qONhTEmAqNfeWvPgsSSlLytl39 PS9RDL6vw29rsOvu9kLEaISRl1G31RaLRYLdIZ4HyTl+8m+skQ3VAmursEnLrTnb oRFBuNp6Y5jPGWkqXhE6t7z3ozzRNZERXA1AEqM2VozKHOXYtiI= =TVeJ -----END PGP SIGNATURE----- Merge tag 's390-5.10-4' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux Pull s390 fixes from Heiko Carstens: - fix system call exit path; avoid return to user space with any TIF/CIF/PIF set - fix file permission for cpum_sfb_size parameter - another small defconfig update * tag 's390-5.10-4' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux: s390/cpum_sf.c: fix file permission for cpum_sfb_size s390: update defconfigs s390: fix system call exit path |
|
Linus Torvalds | ed129cd75a |
- fix bug preventing booting on several platforms
- fix for build error, when modules need has_transparent_hugepage - fix for memleak in alchemy clk setup -----BEGIN PGP SIGNATURE----- iQJOBAABCAA4FiEEbt46xwy6kEcDOXoUeZbBVTGwZHAFAl+0DxIaHHRzYm9nZW5k QGFscGhhLmZyYW5rZW4uZGUACgkQeZbBVTGwZHAJARAAo9kPj9P488PlKjw168SJ neNK00OmtW8D6grnXIHnj/lYzJ1ul+dgbfEiKYMKrBibwc9jxdqeBjR+aLbADs0H 8u4Z3+dLRNzCqnxd4EYwP53+WdICrlNN9c7H+AjvWP4aMzZLNQW2fAQi+7hGR8p7 gvR+7CZyBHtVns92IGrMPEm1CBVrP/PrKxU6TRi3GYxxf7jCGYMHRI/bwXkBSGhg mzxeCtygnDKivUcLv2FqFQ6BmSbPbxZVqQNKkBCqEyEIvYmvNkmUMuqf36NYOtBp dXloYV5px9FjEqBhfyRYeO3xElyphCm4fYWV4+Bvf60w4m3c33peezg8ltJxqFAu zFZk6NhfgZrRRJTGTfJ3juisagmtLzGx5rcK/JJGmcvW3975cwMlEtd545JGrECW Lq3GZLwROc8hEh8dydrf3jGjP3+Ty2emO6rjYQrDqoWAhu4IqpLIb7s58IWzVlYv z7KejBo1bTuSGar6sHREmEGCPzlrJp4ebq6niD4j57Yk9gzp0BoTd+JogE/EaCz/ P92OV/Log/hgKhFB0sI3Mtl2OOF3KIPq1IFfeu8731yMq9muOVZMhTOS03LRySFl yyxVFn+uI00oE5A7Vw4ETEdiw1lbBjD4rC6HLQK36RhlZR5vGGL8rIejXRuKJCZY F5yTub6Y6KDbKpBCjAkDros= =5NkQ -----END PGP SIGNATURE----- Merge tag 'mips_fixes_5.10_1' of git://git.kernel.org/pub/scm/linux/kernel/git/mips/linux Pull MIPS fixes from Thomas Bogendoerfer: - fix bug preventing booting on several platforms - fix for build error, when modules need has_transparent_hugepage - fix for memleak in alchemy clk setup * tag 'mips_fixes_5.10_1' of git://git.kernel.org/pub/scm/linux/kernel/git/mips/linux: MIPS: Alchemy: Fix memleak in alchemy_clk_setup_cpu MIPS: kernel: Fix for_each_memblock conversion MIPS: export has_transparent_hugepage() for modules |
|
Ryan Sharpelletti | 1b9e2a8c99 |
tcp: only postpone PROBE_RTT if RTT is < current min_rtt estimate
During loss recovery, retransmitted packets are forced to use TCP
timestamps to calculate the RTT samples, which have a millisecond
granularity. BBR is designed using a microsecond granularity. As a
result, multiple RTT samples could be truncated to the same RTT value
during loss recovery. This is problematic, as BBR will not enter
PROBE_RTT if the RTT sample is <= the current min_rtt sample, meaning
that if there are persistent losses, PROBE_RTT will constantly be
pushed off and potentially never re-entered. This patch makes sure
that BBR enters PROBE_RTT by checking if RTT sample is < the current
min_rtt sample, rather than <=.
The Netflix transport/TCP team discovered this bug in the Linux TCP
BBR code during lab tests.
Fixes:
|
|
Joel Stanley | 3d5179458d |
net: ftgmac100: Fix crash when removing driver
When removing the driver we would hit BUG_ON(!list_empty(&dev->ptype_specific))
in net/core/dev.c due to still having the NC-SI packet handler
registered.
# echo 1e660000.ethernet > /sys/bus/platform/drivers/ftgmac100/unbind
------------[ cut here ]------------
kernel BUG at net/core/dev.c:10254!
Internal error: Oops - BUG: 0 [#1] SMP ARM
CPU: 0 PID: 115 Comm: sh Not tainted 5.10.0-rc3-next-20201111-00007-g02e0365710c4 #46
Hardware name: Generic DT based system
PC is at netdev_run_todo+0x314/0x394
LR is at cpumask_next+0x20/0x24
pc : [<806f5830>] lr : [<80863cb0>] psr: 80000153
sp : 855bbd58 ip : 00000001 fp : 855bbdac
r10: 80c03d00 r9 : 80c06228 r8 : 81158c54
r7 : 00000000 r6 : 80c05dec r5 : 80c05d18 r4 : 813b9280
r3 : 813b9054 r2 : 8122c470 r1 : 00000002 r0 : 00000002
Flags: Nzcv IRQs on FIQs off Mode SVC_32 ISA ARM Segment none
Control: 00c5387d Table: 85514008 DAC: 00000051
Process sh (pid: 115, stack limit = 0x7cb5703d)
...
Backtrace:
[<806f551c>] (netdev_run_todo) from [<80707eec>] (rtnl_unlock+0x18/0x1c)
r10:00000051 r9:854ed710 r8:81158c54 r7:80c76bb0 r6:81158c10 r5:8115b410
r4:813b9000
[<80707ed4>] (rtnl_unlock) from [<806f5db8>] (unregister_netdev+0x2c/0x30)
[<806f5d8c>] (unregister_netdev) from [<805a8180>] (ftgmac100_remove+0x20/0xa8)
r5:8115b410 r4:813b9000
[<805a8160>] (ftgmac100_remove) from [<805355e4>] (platform_drv_remove+0x34/0x4c)
Fixes:
|
|
Zhang Changzhong | 7b027c249d |
net: b44: fix error return code in b44_init_one()
Fix to return a negative error code from the error handling
case instead of 0, as done elsewhere in this function.
Fixes:
|
|
Linus Torvalds | be1dd6692a |
perf tools updates for v5.10: 3rd batch.
- Fix file corruption due to event deletion in 'perf inject'. - Update arch/x86/lib/mem{cpy,set}_64.S copies used in 'perf bench mem memcpy', silencing perf build warning. - Avoid an msan warning in a copied stack in 'perf test'. - Correct tracepoint field name "flags" in ARM's CS-ETM hardware tracing 'perf test' entry. - Update branch sample pattern for cs-etm to cope with excluding guest in userspace counting. - Don't free "lock_seq_stat" if read_count isn't zero in 'perf lock'. Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com> Test results: The first ones are container based builds of tools/perf with and without libelf support. Where clang is available, it is also used to build perf with/without libelf, and building with LIBCLANGLLVM=1 (built-in clang) with gcc and clang when clang and its devel libraries are installed. The objtool and samples/bpf/ builds are disabled now that I'm switching from using the sources in a local volume to fetching them from a http server to build it inside the container, to make it easier to build in a container cluster. Those will come back later. Several are cross builds, the ones with -x-ARCH and the android one, and those may not have all the features built, due to lack of multi-arch devel packages, available and being used so far on just a few, like debian:experimental-x-{arm64,mipsel}. The 'perf test' one will perform a variety of tests exercising tools/perf/util/, tools/lib/{bpf,traceevent,etc}, as well as run perf commands with a variety of command line event specifications to then intercept the sys_perf_event syscall to check that the perf_event_attr fields are set up as expected, among a variety of other unit tests. Then there is the 'make -C tools/perf build-test' ones, that build tools/perf/ with a variety of feature sets, exercising the build with an incomplete set of features as well as with a complete one. It is planned to have it run on each of the containers mentioned above, using some container orchestration infrastructure. Get in contact if interested in helping having this in place. $ grep "model name" -m1 /proc/cpuinfo model name: AMD Ryzen 9 3900X 12-Core Processor $ export PERF_TARBALL=http://192.168.86.5/perf/perf-5.10.0-rc3.tar.xz $ dm 1 71.39 alpine:3.4 : Ok gcc (Alpine 5.3.0) 5.3.0, clang version 3.8.0 (tags/RELEASE_380/final) 2 70.77 alpine:3.5 : Ok gcc (Alpine 6.2.1) 6.2.1 20160822, clang version 3.8.1 (tags/RELEASE_381/final) 3 73.70 alpine:3.6 : Ok gcc (Alpine 6.3.0) 6.3.0, clang version 4.0.0 (tags/RELEASE_400/final) 4 82.24 alpine:3.7 : Ok gcc (Alpine 6.4.0) 6.4.0, Alpine clang version 5.0.0 (tags/RELEASE_500/final) (based on LLVM 5.0.0) 5 82.21 alpine:3.8 : Ok gcc (Alpine 6.4.0) 6.4.0, Alpine clang version 5.0.1 (tags/RELEASE_501/final) (based on LLVM 5.0.1) 6 84.79 alpine:3.9 : Ok gcc (Alpine 8.3.0) 8.3.0, Alpine clang version 5.0.1 (tags/RELEASE_502/final) (based on LLVM 5.0.1) 7 106.15 alpine:3.10 : Ok gcc (Alpine 8.3.0) 8.3.0, Alpine clang version 8.0.0 (tags/RELEASE_800/final) (based on LLVM 8.0.0) 8 120.21 alpine:3.11 : Ok gcc (Alpine 9.3.0) 9.3.0, Alpine clang version 9.0.0 (https://git.alpinelinux.org/aports f7f0d2c2b8bcd6a5843401a9a702029556492689) (based on LLVM 9.0.0) 9 111.49 alpine:3.12 : Ok gcc (Alpine 9.3.0) 9.3.0, Alpine clang version 10.0.0 (https://gitlab.alpinelinux.org/alpine/aports.git 7445adce501f8473efdb93b17b5eaf2f1445ed4c) 10 119.72 alpine:edge : Ok gcc (Alpine 10.2.0) 10.2.0, Alpine clang version 10.0.1 11 70.03 alt:p8 : Ok x86_64-alt-linux-gcc (GCC) 5.3.1 20151207 (ALT p8 5.3.1-alt3.M80P.1), clang version 3.8.0 (tags/RELEASE_380/final) 12 86.89 alt:p9 : Ok x86_64-alt-linux-gcc (GCC) 8.4.1 20200305 (ALT p9 8.4.1-alt0.p9.1), clang version 10.0.0 13 84.45 alt:sisyphus : Ok x86_64-alt-linux-gcc (GCC) 9.3.1 20200518 (ALT Sisyphus 9.3.1-alt1), clang version 10.0.1 14 67.56 amazonlinux:1 : Ok gcc (GCC) 7.2.1 20170915 (Red Hat 7.2.1-2), clang version 3.6.2 (tags/RELEASE_362/final) 15 101.57 amazonlinux:2 : Ok gcc (GCC) 7.3.1 20180712 (Red Hat 7.3.1-9), clang version 7.0.1 (Amazon Linux 2 7.0.1-1.amzn2.0.2) 16 22.59 android-ndk:r12b-arm : Ok arm-linux-androideabi-gcc (GCC) 4.9.x 20150123 (prerelease) 17 22.50 android-ndk:r15c-arm : Ok arm-linux-androideabi-gcc (GCC) 4.9.x 20150123 (prerelease) 18 12.05 centos:6 : FAIL gcc (GCC) 4.4.7 20120313 (Red Hat 4.4.7-23) Ancient gcc get this wrong: /git/linux/tools/lib/bpf/libbpf.h:203: error: wrong number of arguments specified for 'deprecated' attribute But when using NO_LIBBPF we should not hit this, changes for that to happen will land in 5.11 as they require more surgery than advisable for this late in 5.10 rc. 19 32.72 centos:7 : Ok gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-44) 20 118.02 centos:8 : Ok gcc (GCC) 8.3.1 20191121 (Red Hat 8.3.1-5), clang version 9.0.1 (Red Hat 9.0.1-2.module_el8.2.0+309+0c7b6b03) 21 62.52 clearlinux:latest : Ok gcc (Clear Linux OS for Intel Architecture) 10.2.1 20201105 releases/gcc-10.2.0-465-g2b4cba9a30, clang version 10.0.1 22 78.48 debian:8 : Ok gcc (Debian 4.9.2-10+deb8u2) 4.9.2, Debian clang version 3.5.0-10 (tags/RELEASE_350/final) (based on LLVM 3.5.0) 23 79.18 debian:9 : Ok gcc (Debian 6.3.0-18+deb9u1) 6.3.0 20170516, clang version 3.8.1-24 (tags/RELEASE_381/final) 24 76.33 debian:10 : Ok gcc (Debian 8.3.0-6) 8.3.0, clang version 7.0.1-8+deb10u2 (tags/RELEASE_701/final) 25 93.16 debian:experimental : Ok gcc (Debian 10.2.0-16) 10.2.0, Debian clang version 11.0.0-4 26 30.47 debian:experimental-x-mips64 : Ok mips64-linux-gnuabi64-gcc (Debian 9.3.0-8) 9.3.0 27 31.23 fedora:20 : Ok gcc (GCC) 4.8.3 20140911 (Red Hat 4.8.3-7) 28 31.77 fedora:22 : Ok gcc (GCC) 5.3.1 20160406 (Red Hat 5.3.1-6), clang version 3.5.0 (tags/RELEASE_350/final) 29 70.66 fedora:23 : Ok gcc (GCC) 5.3.1 20160406 (Red Hat 5.3.1-6), clang version 3.7.0 (tags/RELEASE_370/final) 30 82.84 fedora:24 : Ok gcc (GCC) 6.3.1 20161221 (Red Hat 6.3.1-1), clang version 3.8.1 (tags/RELEASE_381/final) 31 25.41 fedora:24-x-ARC-uClibc : Ok arc-linux-gcc (ARCompact ISA Linux uClibc toolchain 2017.09-rc2) 7.1.1 20170710 32 84.37 fedora:25 : Ok gcc (GCC) 6.4.1 20170727 (Red Hat 6.4.1-1), clang version 3.9.1 (tags/RELEASE_391/final) 33 96.38 fedora:26 : Ok gcc (GCC) 7.3.1 20180130 (Red Hat 7.3.1-2), clang version 4.0.1 (tags/RELEASE_401/final) 34 97.16 fedora:27 : Ok gcc (GCC) 7.3.1 20180712 (Red Hat 7.3.1-6), clang version 5.0.2 (tags/RELEASE_502/final) 35 107.89 fedora:28 : Ok gcc (GCC) 8.3.1 20190223 (Red Hat 8.3.1-2), clang version 6.0.1 (tags/RELEASE_601/final) 36 113.43 fedora:29 : Ok gcc (GCC) 8.3.1 20190223 (Red Hat 8.3.1-2), clang version 7.0.1 (Fedora 7.0.1-6.fc29) 37 117.85 fedora:30 : Ok gcc (GCC) 9.3.1 20200408 (Red Hat 9.3.1-2), clang version 8.0.0 (Fedora 8.0.0-3.fc30) 38 25.36 fedora:30-x-ARC-uClibc : Ok arc-linux-gcc (ARCv2 ISA Linux uClibc toolchain 2019.03-rc1) 8.3.1 20190225 39 116.54 fedora:31 : Ok gcc (GCC) 9.3.1 20200408 (Red Hat 9.3.1-2), clang version 9.0.1 (Fedora 9.0.1-4.fc31) 40 98.36 fedora:32 : Ok gcc (GCC) 10.2.1 20201016 (Red Hat 10.2.1-6), clang version 10.0.1 (Fedora 10.0.1-3.fc32) 41 97.72 fedora:33 : Ok gcc (GCC) 10.2.1 20201005 (Red Hat 10.2.1-5), clang version 11.0.0 (Fedora 11.0.0-1.fc33) 42 98.60 fedora:rawhide : Ok gcc (GCC) 10.2.1 20201112 (Red Hat 10.2.1-8), clang version 11.0.0 (Fedora 11.0.0-2.fc34) 43 35.00 gentoo-stage3-amd64:latest : Ok gcc (Gentoo 9.3.0-r1 p3) 9.3.0 44 70.27 mageia:5 : Ok gcc (GCC) 4.9.2, clang version 3.5.2 (tags/RELEASE_352/final) 45 86.27 mageia:6 : Ok gcc (Mageia 5.5.0-1.mga6) 5.5.0, clang version 3.9.1 (tags/RELEASE_391/final) 46 103.63 manjaro:latest : Ok gcc (GCC) 10.2.0, clang version 10.0.1 47 228.99 openmandriva:cooker : Ok gcc (GCC) 10.2.0 20200723 (OpenMandriva), OpenMandriva 11.0.0-1 clang version 11.0.0 (/builddir/build/BUILD/llvm-project-llvmorg-11.0.0/clang 63e22714ac938c6b537bd958f70680d3331a2030) 48 120.44 opensuse:15.0 : Ok gcc (SUSE Linux) 7.4.1 20190905 [gcc-7-branch revision 275407], clang version 5.0.1 (tags/RELEASE_501/final 312548) 49 127.26 opensuse:15.1 : Ok gcc (SUSE Linux) 7.5.0, clang version 7.0.1 (tags/RELEASE_701/final 349238) 50 117.76 opensuse:15.2 : Ok gcc (SUSE Linux) 7.5.0, clang version 9.0.1 51 114.96 opensuse:42.3 : Ok gcc (SUSE Linux) 4.8.5, clang version 3.8.0 (tags/RELEASE_380/final 262553) 52 110.55 opensuse:tumbleweed : Ok gcc (SUSE Linux) 10.2.1 20200825 [revision c0746a1beb1ba073c7981eb09f55b3d993b32e5c], clang version 10.0.1 53 11.81 oraclelinux:6 : FAIL gcc (GCC) 4.4.7 20120313 (Red Hat 4.4.7-23.0.1) See explanation for centos:6 54 32.31 oraclelinux:7 : Ok gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-44.0.3) 55 116.81 oraclelinux:8 : Ok gcc (GCC) 8.3.1 20191121 (Red Hat 8.3.1-5.0.3), clang version 9.0.1 (Red Hat 9.0.1-2.0.1.module+el8.2.0+5599+9ed9ef6d) 56 28.44 ubuntu:12.04 : Ok gcc (Ubuntu/Linaro 4.6.3-1ubuntu5) 4.6.3, Ubuntu clang version 3.0-6ubuntu3 (tags/RELEASE_30/final) (based on LLVM 3.0) 57 31.16 ubuntu:14.04 : Ok gcc (Ubuntu 4.8.4-2ubuntu1~14.04.4) 4.8.4 58 79.71 ubuntu:16.04 : Ok gcc (Ubuntu 5.4.0-6ubuntu1~16.04.12) 5.4.0 20160609, clang version 3.8.0-2ubuntu4 (tags/RELEASE_380/final) 59 27.05 ubuntu:16.04-x-arm : Ok arm-linux-gnueabihf-gcc (Ubuntu/Linaro 5.4.0-6ubuntu1~16.04.9) 5.4.0 20160609 60 27.14 ubuntu:16.04-x-arm64 : Ok aarch64-linux-gnu-gcc (Ubuntu/Linaro 5.4.0-6ubuntu1~16.04.9) 5.4.0 20160609 61 25.89 ubuntu:16.04-x-powerpc : Ok powerpc-linux-gnu-gcc (Ubuntu 5.4.0-6ubuntu1~16.04.9) 5.4.0 20160609 62 26.39 ubuntu:16.04-x-powerpc64 : Ok powerpc64-linux-gnu-gcc (Ubuntu/IBM 5.4.0-6ubuntu1~16.04.9) 5.4.0 20160609 63 26.32 ubuntu:16.04-x-powerpc64el : Ok powerpc64le-linux-gnu-gcc (Ubuntu/IBM 5.4.0-6ubuntu1~16.04.9) 5.4.0 20160609 64 25.61 ubuntu:16.04-x-s390 : Ok s390x-linux-gnu-gcc (Ubuntu 5.4.0-6ubuntu1~16.04.9) 5.4.0 20160609 65 91.53 ubuntu:18.04 : Ok gcc (Ubuntu 7.5.0-3ubuntu1~18.04) 7.5.0, clang version 6.0.0-1ubuntu2 (tags/RELEASE_600/final) 66 28.76 ubuntu:18.04-x-arm : Ok arm-linux-gnueabihf-gcc (Ubuntu/Linaro 7.5.0-3ubuntu1~18.04) 7.5.0 67 27.64 ubuntu:18.04-x-arm64 : Ok aarch64-linux-gnu-gcc (Ubuntu/Linaro 7.5.0-3ubuntu1~18.04) 7.5.0 68 22.90 ubuntu:18.04-x-m68k : Ok m68k-linux-gnu-gcc (Ubuntu 7.5.0-3ubuntu1~18.04) 7.5.0 69 27.23 ubuntu:18.04-x-powerpc : Ok powerpc-linux-gnu-gcc (Ubuntu 7.5.0-3ubuntu1~18.04) 7.5.0 70 29.56 ubuntu:18.04-x-powerpc64 : Ok powerpc64-linux-gnu-gcc (Ubuntu 7.5.0-3ubuntu1~18.04) 7.5.0 71 29.76 ubuntu:18.04-x-powerpc64el : Ok powerpc64le-linux-gnu-gcc (Ubuntu 7.5.0-3ubuntu1~18.04) 7.5.0 72 161.85 ubuntu:18.04-x-riscv64 : Ok riscv64-linux-gnu-gcc (Ubuntu 7.5.0-3ubuntu1~18.04) 7.5.0 73 25.41 ubuntu:18.04-x-s390 : Ok s390x-linux-gnu-gcc (Ubuntu 7.5.0-3ubuntu1~18.04) 7.5.0 74 27.77 ubuntu:18.04-x-sh4 : Ok sh4-linux-gnu-gcc (Ubuntu 7.5.0-3ubuntu1~18.04) 7.5.0 75 25.38 ubuntu:18.04-x-sparc64 : Ok sparc64-linux-gnu-gcc (Ubuntu 7.5.0-3ubuntu1~18.04) 7.5.0 76 71.37 ubuntu:19.10 : Ok gcc (Ubuntu 9.2.1-9ubuntu2) 9.2.1 20191008, clang version 8.0.1-3build1 (tags/RELEASE_801/final) 77 27.53 ubuntu:19.10-x-alpha : Ok alpha-linux-gnu-gcc (Ubuntu 9.2.1-9ubuntu1) 9.2.1 20191008 78 24.90 ubuntu:19.10-x-hppa : Ok hppa-linux-gnu-gcc (Ubuntu 9.2.1-9ubuntu1) 9.2.1 20191008 79 75.35 ubuntu:20.04 : Ok gcc (Ubuntu 9.3.0-17ubuntu1~20.04) 9.3.0, clang version 10.0.0-4ubuntu1 80 31.41 ubuntu:20.04-x-powerpc64el : Ok powerpc64le-linux-gnu-gcc (Ubuntu 10.2.0-5ubuntu1~20.04) 10.2.0 81 76.36 ubuntu:20.10 : Ok gcc (Ubuntu 10.2.0-13ubuntu1) 10.2.0, Ubuntu clang version 11.0.0-2 $ # uname -a Linux quaco 5.8.14-200.fc32.x86_64 #1 SMP Wed Oct 7 14:47:56 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux # git log --oneline -1 |
|
Zhang Changzhong | cb47d16ea2 |
qed: fix error return code in qed_iwarp_ll2_start()
Fix to return a negative error code from the error handling case instead of 0, as done elsewhere in this function. Fixes: |
|
Linus Torvalds | 9dacf44c38 |
Merge branch 'urgent-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu
Pull RCU fix from Paul McKenney: "A single commit that fixes a bug that was introduced a couple of merge windows ago, but which rather more recently converged to an agreed-upon fix. The bug is that interrupts can be incorrectly enabled while holding an irq-disabled spinlock. This can of course result in self-deadlocks. The bug is a bit difficult to trigger. It requires that a preempted task be blocking a preemptible-RCU grace period long enough to trigger an RCU CPU stall warning. In addition, an interrupt must occur at just the right time, and that interrupt's handler must acquire that same irq-disabled spinlock. Still, a deadlock is a deadlock. Furthermore, we do now have a fix, and that fix survives kernel test robot, -next, and rcutorture testing. It has also been verified by Sebastian as fixing the bug. Therefore..." * 'urgent-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu: rcu: Don't invoke try_invoke_on_locked_down_task() with irqs disabled |
|
Xiongfeng Wang | 6654b57866 |
drm/sun4i: dw-hdmi: fix error return code in sun8i_dw_hdmi_bind()
Fix to return a negative error code from the error handling case instead
of 0 in function sun8i_dw_hdmi_bind().
Fixes:
|
|
Lukas Wunner |
04a9cd51d3
|
spi: npcm-fiu: Don't leak SPI master in probe error path
If the calls to of_match_device(), of_alias_get_id(),
devm_ioremap_resource(), devm_regmap_init_mmio() or devm_clk_get()
fail on probe of the NPCM FIU SPI driver, the spi_controller struct is
erroneously not freed.
Fix by switching over to the new devm_spi_alloc_master() helper.
Fixes:
|
|
Serge Semin |
a41b0ad07b
|
spi: dw: Set transfer handler before unmasking the IRQs
It turns out the IRQs most like can be unmasked before the controller is enabled with no problematic consequences. The manual doesn't explicitly state that, but the examples perform the controller initialization procedure in that order. So the commit |
|
Laurent Pinchart | dc293f2106 |
xtensa: uaccess: Add missing __user to strncpy_from_user() prototype
When adding __user annotations in commit
|
|
Joakim Tjernlund | 54a2a3898f |
ALSA: usb-audio: Add delay quirk for all Logitech USB devices
Found one more Logitech device, BCC950 ConferenceCam, which needs the same delay here. This makes 3 out of 3 devices I have tried. Therefore, add a delay for all Logitech devices as it does not hurt. Signed-off-by: Joakim Tjernlund <joakim.tjernlund@infinera.com> Cc: <stable@vger.kernel.org> # 4.19.y, 5.4.y Link: https://lore.kernel.org/r/20201117122803.24310-1-joakim.tjernlund@infinera.com Signed-off-by: Takashi Iwai <tiwai@suse.de> |
|
Rafael J. Wysocki | 14c620cf2e |
Merge branch 'cpufreq/arm/fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/vireshk/pm
Pull cpufreq-arm fixes for 5.10-rc5 from Viresh Kumar: "- tegra186: Fix ->get() callback. - arm/scmi: Add dummy clock provider to fix failure." * 'cpufreq/arm/fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/vireshk/pm: cpufreq: scmi: Fix OPP addition failure with a dummy clock provider cpufreq: tegra186: Fix get frequency callback |
|
Sami Tolvanen | ebd19fc372 |
perf/x86: fix sysfs type mismatches
This change switches rapl to use PMU_FORMAT_ATTR, and fixes two other macros to use device_attribute instead of kobj_attribute to avoid callback type mismatches that trip indirect call checking with Clang's Control-Flow Integrity (CFI). Reported-by: Sedat Dilek <sedat.dilek@gmail.com> Signed-off-by: Sami Tolvanen <samitolvanen@google.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Reviewed-by: Kees Cook <keescook@chromium.org> Link: https://lkml.kernel.org/r/20201113183126.1239404-1-samitolvanen@google.com |
|
Boqun Feng | 43be4388e9 |
lockdep: Put graph lock/unlock under lock_recursion protection
A warning was hit when running xfstests/generic/068 in a Hyper-V guest: [...] ------------[ cut here ]------------ [...] DEBUG_LOCKS_WARN_ON(lockdep_hardirqs_enabled()) [...] WARNING: CPU: 2 PID: 1350 at kernel/locking/lockdep.c:5280 check_flags.part.0+0x165/0x170 [...] ... [...] Workqueue: events pwq_unbound_release_workfn [...] RIP: 0010:check_flags.part.0+0x165/0x170 [...] ... [...] Call Trace: [...] lock_is_held_type+0x72/0x150 [...] ? lock_acquire+0x16e/0x4a0 [...] rcu_read_lock_sched_held+0x3f/0x80 [...] __send_ipi_one+0x14d/0x1b0 [...] hv_send_ipi+0x12/0x30 [...] __pv_queued_spin_unlock_slowpath+0xd1/0x110 [...] __raw_callee_save___pv_queued_spin_unlock_slowpath+0x11/0x20 [...] .slowpath+0x9/0xe [...] lockdep_unregister_key+0x128/0x180 [...] pwq_unbound_release_workfn+0xbb/0xf0 [...] process_one_work+0x227/0x5c0 [...] worker_thread+0x55/0x3c0 [...] ? process_one_work+0x5c0/0x5c0 [...] kthread+0x153/0x170 [...] ? __kthread_bind_mask+0x60/0x60 [...] ret_from_fork+0x1f/0x30 The cause of the problem is we have call chain lockdep_unregister_key() -> <irq disabled by raw_local_irq_save()> lockdep_unlock() -> arch_spin_unlock() -> __pv_queued_spin_unlock_slowpath() -> pv_kick() -> __send_ipi_one() -> trace_hyperv_send_ipi_one(). Although this particular warning is triggered because Hyper-V has a trace point in ipi sending, but in general arch_spin_unlock() may call another function having a trace point in it, so put the arch_spin_lock() and arch_spin_unlock() after lock_recursion protection to fix this problem and avoid similiar problems. Signed-off-by: Boqun Feng <boqun.feng@gmail.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Link: https://lkml.kernel.org/r/20201113110512.1056501-1-boqun.feng@gmail.com |
|
Juri Lelli | 2279f540ea |
sched/deadline: Fix priority inheritance with multiple scheduling classes
Glenn reported that "an application [he developed produces] a BUG in deadline.c when a SCHED_DEADLINE task contends with CFS tasks on nested PTHREAD_PRIO_INHERIT mutexes. I believe the bug is triggered when a CFS task that was boosted by a SCHED_DEADLINE task boosts another CFS task (nested priority inheritance). ------------[ cut here ]------------ kernel BUG at kernel/sched/deadline.c:1462! invalid opcode: 0000 [#1] PREEMPT SMP CPU: 12 PID: 19171 Comm: dl_boost_bug Tainted: ... Hardware name: ... RIP: 0010:enqueue_task_dl+0x335/0x910 Code: ... RSP: 0018:ffffc9000c2bbc68 EFLAGS: 00010002 RAX: 0000000000000009 RBX: ffff888c0af94c00 RCX: ffffffff81e12500 RDX: 000000000000002e RSI: ffff888c0af94c00 RDI: ffff888c10b22600 RBP: ffffc9000c2bbd08 R08: 0000000000000009 R09: 0000000000000078 R10: ffffffff81e12440 R11: ffffffff81e1236c R12: ffff888bc8932600 R13: ffff888c0af94eb8 R14: ffff888c10b22600 R15: ffff888bc8932600 FS: 00007fa58ac55700(0000) GS:ffff888c10b00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fa58b523230 CR3: 0000000bf44ab003 CR4: 00000000007606e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: ? intel_pstate_update_util_hwp+0x13/0x170 rt_mutex_setprio+0x1cc/0x4b0 task_blocks_on_rt_mutex+0x225/0x260 rt_spin_lock_slowlock_locked+0xab/0x2d0 rt_spin_lock_slowlock+0x50/0x80 hrtimer_grab_expiry_lock+0x20/0x30 hrtimer_cancel+0x13/0x30 do_nanosleep+0xa0/0x150 hrtimer_nanosleep+0xe1/0x230 ? __hrtimer_init_sleeper+0x60/0x60 __x64_sys_nanosleep+0x8d/0xa0 do_syscall_64+0x4a/0x100 entry_SYSCALL_64_after_hwframe+0x49/0xbe RIP: 0033:0x7fa58b52330d ... ---[ end trace 0000000000000002 ]— He also provided a simple reproducer creating the situation below: So the execution order of locking steps are the following (N1 and N2 are non-deadline tasks. D1 is a deadline task. M1 and M2 are mutexes that are enabled * with priority inheritance.) Time moves forward as this timeline goes down: N1 N2 D1 | | | | | | Lock(M1) | | | | | | Lock(M2) | | | | | | Lock(M2) | | | | Lock(M1) | | (!!bug triggered!) | Daniel reported a similar situation as well, by just letting ksoftirqd run with DEADLINE (and eventually block on a mutex). Problem is that boosted entities (Priority Inheritance) use static DEADLINE parameters of the top priority waiter. However, there might be cases where top waiter could be a non-DEADLINE entity that is currently boosted by a DEADLINE entity from a different lock chain (i.e., nested priority chains involving entities of non-DEADLINE classes). In this case, top waiter static DEADLINE parameters could be null (initialized to 0 at fork()) and replenish_dl_entity() would hit a BUG(). Fix this by keeping track of the original donor and using its parameters when a task is boosted. Reported-by: Glenn Elliott <glenn@aurora.tech> Reported-by: Daniel Bristot de Oliveira <bristot@redhat.com> Signed-off-by: Juri Lelli <juri.lelli@redhat.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Tested-by: Daniel Bristot de Oliveira <bristot@redhat.com> Link: https://lkml.kernel.org/r/20201117061432.517340-1-juri.lelli@redhat.com |
|
Peter Zijlstra | ec618b84f6 |
sched: Fix rq->nr_iowait ordering
schedule() ttwu()
deactivate_task(); if (p->on_rq && ...) // false
atomic_dec(&task_rq(p)->nr_iowait);
if (prev->in_iowait)
atomic_inc(&rq->nr_iowait);
Allows nr_iowait to be decremented before it gets incremented,
resulting in more dodgy IO-wait numbers than usual.
Note that because we can now do ttwu_queue_wakelist() before
p->on_cpu==0, we lose the natural ordering and have to further delay
the decrement.
Fixes:
|
|
Peter Zijlstra | f97bb5272d |
sched: Fix data-race in wakeup
Mel reported that on some ARM64 platforms loadavg goes bananas and Will tracked it down to the following race: CPU0 CPU1 schedule() prev->sched_contributes_to_load = X; deactivate_task(prev); try_to_wake_up() if (p->on_rq &&) // false if (smp_load_acquire(&p->on_cpu) && // true ttwu_queue_wakelist()) p->sched_remote_wakeup = Y; smp_store_release(prev->on_cpu, 0); where both p->sched_contributes_to_load and p->sched_remote_wakeup are in the same word, and thus the stores X and Y race (and can clobber one another's data). Whereas prior to commit |
|
Quentin Perret | 8e1ac4299a |
sched/fair: Fix overutilized update in enqueue_task_fair()
enqueue_task_fair() attempts to skip the overutilized update for new
tasks as their util_avg is not accurate yet. However, the flag we check
to do so is overwritten earlier on in the function, which makes the
condition pretty much a nop.
Fix this by saving the flag early on.
Fixes:
|
|
Zhang Qilong | ac3b57adf8 |
MIPS: Alchemy: Fix memleak in alchemy_clk_setup_cpu
If the clk_register fails, we should free h before
function returns to prevent memleak.
Fixes:
|
|
Manish Narani | d06d60d52e |
mmc: sdhci-of-arasan: Issue DLL reset explicitly
In the current implementation DLL reset will be issued for
each ITAP and OTAP setting inside ATF, this is creating issues
in some scenarios and this sequence is not inline with the TRM.
To fix the issue, DLL reset should be removed from the ATF and
host driver will request it explicitly.
This patch update host driver to explicitly request for DLL reset
before ITAP (assert DLL) and after OTAP (release DLL) settings.
Fixes:
|
|
Manish Narani | d338c6d01d |
mmc: sdhci-of-arasan: Use Mask writes for Tap delays
Mask the ITAP and OTAP delay bits before updating with the new
tap value for Versal platform.
Fixes:
|
|
Manish Narani | 9e95343293 |
mmc: sdhci-of-arasan: Allow configuring zero tap values
Allow configuring the Output and Input tap values with zero to avoid
failures in some cases (one of them is SD boot mode) where the output
and input tap values may be already set to non-zero.
Fixes:
|
|
Adrian Hunter | 60d5356610 |
mmc: sdhci-pci: Prefer SDR25 timing for High Speed mode for BYT-based Intel controllers
A UHS setting of SDR25 can give better results for High Speed mode.
This is because there is no setting corresponding to high speed. Currently
SDHCI sets no value, which means zero which is also the setting for SDR12.
There was an attempt to change this in sdhci.c but it caused problems for
some drivers, so it was reverted and the change was made to sdhci-brcmstb
in commit
|
|
Greg Kroah-Hartman | 2dde2821b5 |
First set of IIO and counter fixes for the 5.10 cycle.
IIO cros_ec - Provide defauts for max and min frequency when older machines fail to return them correctly. ingenic-adc - Fix wrong vref value for JZ4770 SoC - Fix AUX / VBAT readings when touchscreen in use by pausing touchscreen readings during a read of these channels. kxcjk1013 - Fix an issue with KIOX010A ACPI id using devices which need to run a ACPI device specific method to avoid leaving the keyboard disabled. Includes a minor precursor patch to make this fix easier to do. mt6577-auxadc - Fix an issue with dev_comp not being set resulting in a null ptr deref. st_lsm6dsx - Set a 10ms min shub slave timeout to handle fast snesors where more time is needed to set up the config than the cycles allowed. stm32-adc - Fix an issue due to a clash between an ADC configured to use IRQs and a second configured to use DMA cause by some incorrect register masking. vcnl4035 - Kconfig missing dependency Counter ti-eqep - wrong value for max_register as one beyond the end instead of the end. -----BEGIN PGP SIGNATURE----- iQJFBAABCAAvFiEEbilms4eEBlKRJoGxVIU0mcT0FogFAl+yyk8RHGppYzIzQGtl cm5lbC5vcmcACgkQVIU0mcT0FohJURAAi5xCdV2cUQoAUCi2ldlwEVaIb+yCdHzk V1mB6O9sdJTmkaJx6qopkx/Dn0Sou1G48paKlzOFznno0no0PRY4IXDZq5TdR+M+ 0WTR6TR0UwT1AIVELzhMPuW9+G1YbWdxRDBEeXOAT+HrJftZLpgU2Mk3Of8h7p0n /CAaT60wwVf13VJ9ESjr7UKqisuMIt0zsqN5lS8sXRNnIx1mCZe1DFb6v1cs3w6n G77lub5ylNxu+u6l6YTYILNZ+Sj6NCiUzxVE7R5eSpmfk0+t7bFtA6tXXekZCdvq +DxzM2vnLXmx1PwNJOd97sArLI0I94AmOwrcphKaa/HAb4akRfcPhapsNjGMny/n I8AlCDrLcFZq//dAd0mt7A676CyL1sNG8w7wu91IDfsPkfYgInNemlft5nmwokGu f+crhtKoNJjaV5n1yIXDPgXpH0s6U5Hmy+ELMLr2rw85hwpwzJF0pYd4+DqRr8aI RCogkKP2ey80RfZlDl8qRTiz/wUSmlxsujjZPAYG+1Spaj08EiT3e5Oad+NmVuKr jcehdqOFZHXML7nK2ntpuQ7UW1xY4USyxjtPJ6q6IUVEiF4wTOGhHX9ePM1y38b1 W/F4Lcq2mAQ9rxoWP+FUHuB36zMB0cZ1KXVohvlciTkdl6DSyF4eio19M5MAYqxI RolkTf2Fa4A= =QQWq -----END PGP SIGNATURE----- Merge tag 'iio-fixes-for-5.10a' of https://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio into staging-linus Jonathan writes: First set of IIO and counter fixes for the 5.10 cycle. IIO cros_ec - Provide defauts for max and min frequency when older machines fail to return them correctly. ingenic-adc - Fix wrong vref value for JZ4770 SoC - Fix AUX / VBAT readings when touchscreen in use by pausing touchscreen readings during a read of these channels. kxcjk1013 - Fix an issue with KIOX010A ACPI id using devices which need to run a ACPI device specific method to avoid leaving the keyboard disabled. Includes a minor precursor patch to make this fix easier to do. mt6577-auxadc - Fix an issue with dev_comp not being set resulting in a null ptr deref. st_lsm6dsx - Set a 10ms min shub slave timeout to handle fast snesors where more time is needed to set up the config than the cycles allowed. stm32-adc - Fix an issue due to a clash between an ADC configured to use IRQs and a second configured to use DMA cause by some incorrect register masking. vcnl4035 - Kconfig missing dependency Counter ti-eqep - wrong value for max_register as one beyond the end instead of the end. * tag 'iio-fixes-for-5.10a' of https://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio: iio: accel: kxcjk1013: Add support for KIOX010A ACPI DSM for setting tablet-mode iio: accel: kxcjk1013: Replace is_smo8500_device with an acpi_type enum iio: light: fix kconfig dependency bug for VCNL4035 iio/adc: ingenic: Fix AUX/VBAT readings when touchscreen is used iio/adc: ingenic: Fix battery VREF for JZ4770 SoC iio: imu: st_lsm6dsx: set 10ms as min shub slave timeout counter/ti-eqep: Fix regmap max_register iio: adc: stm32-adc: fix a regression when using dma and irq iio: adc: mediatek: fix unset field iio: cros_ec: Use default frequencies when EC returns invalid information |
|
Chen Yu | 1a371e67dc |
x86/microcode/intel: Check patch signature before saving microcode for early loading
Currently, scan_microcode() leverages microcode_matches() to check
if the microcode matches the CPU by comparing the family and model.
However, the processor stepping and flags of the microcode signature
should also be considered when saving a microcode patch for early
update.
Use find_matching_signature() in scan_microcode() and get rid of the
now-unused microcode_matches() which is a good cleanup in itself.
Complete the verification of the patch being saved for early loading in
save_microcode_patch() directly. This needs to be done there too because
save_mc_for_early() will call save_microcode_patch() too.
The second reason why this needs to be done is because the loader still
tries to support, at least hypothetically, mixed-steppings systems and
thus adds all patches to the cache that belong to the same CPU model
albeit with different steppings.
For example:
microcode: CPU: sig=0x906ec, pf=0x2, rev=0xd6
microcode: mc_saved[0]: sig=0x906e9, pf=0x2a, rev=0xd6, total size=0x19400, date = 2020-04-23
microcode: mc_saved[1]: sig=0x906ea, pf=0x22, rev=0xd6, total size=0x19000, date = 2020-04-27
microcode: mc_saved[2]: sig=0x906eb, pf=0x2, rev=0xd6, total size=0x19400, date = 2020-04-23
microcode: mc_saved[3]: sig=0x906ec, pf=0x22, rev=0xd6, total size=0x19000, date = 2020-04-27
microcode: mc_saved[4]: sig=0x906ed, pf=0x22, rev=0xd6, total size=0x19400, date = 2020-04-23
The patch which is being saved for early loading, however, can only be
the one which fits the CPU this runs on so do the signature verification
before saving.
[ bp: Do signature verification in save_microcode_patch()
and rewrite commit message. ]
Fixes:
|
|
Thomas Bogendoerfer | 61a2f1aecf |
MIPS: kernel: Fix for_each_memblock conversion
The loop over all memblocks works with PFNs and not physical
addresses, so we need for_each_mem_pfn_range().
Fixes:
|
|
Sudeep Holla | 8410e7f3b3 |
cpufreq: scmi: Fix OPP addition failure with a dummy clock provider
Commit |
|
Jon Hunter | e010d1d25e |
cpufreq: tegra186: Fix get frequency callback
Commit |
|
Mike Christie | f36199355c |
scsi: target: iscsi: Fix cmd abort fabric stop race
Maurizio found a race where the abort and cmd stop paths can race as follows: 1. thread1 runs iscsit_release_commands_from_conn and sets CMD_T_FABRIC_STOP. 2. thread2 runs iscsit_aborted_task and then does __iscsit_free_cmd. It then returns from the aborted_task callout and we finish target_handle_abort and do: target_handle_abort -> transport_cmd_check_stop_to_fabric -> lio_check_stop_free -> target_put_sess_cmd The cmd is now freed. 3. thread1 now finishes iscsit_release_commands_from_conn and runs iscsit_free_cmd while accessing a command we just released. In __target_check_io_state we check for CMD_T_FABRIC_STOP and set the CMD_T_ABORTED if the driver is not cleaning up the cmd because of a session shutdown. However, iscsit_release_commands_from_conn only sets the CMD_T_FABRIC_STOP and does not check to see if the abort path has claimed completion ownership of the command. This adds a check in iscsit_release_commands_from_conn so only the abort or fabric stop path cleanup the command. Link: https://lore.kernel.org/r/1605318378-9269-1-git-send-email-michael.christie@oracle.com Reported-by: Maurizio Lombardi <mlombard@redhat.com> Reviewed-by: Maurizio Lombardi <mlombard@redhat.com> Signed-off-by: Mike Christie <michael.christie@oracle.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com> |
|
Lee Duncan | fe0a8a95e7 |
scsi: libiscsi: Fix NOP race condition
iSCSI NOPs are sometimes "lost", mistakenly sent to the user-land iscsid daemon instead of handled in the kernel, as they should be, resulting in a message from the daemon like: iscsid: Got nop in, but kernel supports nop handling. This can occur because of the new forward- and back-locks, and the fact that an iSCSI NOP response can occur before processing of the NOP send is complete. This can result in "conn->ping_task" being NULL in iscsi_nop_out_rsp(), when the pointer is actually in the process of being set. To work around this, we add a new state to the "ping_task" pointer. In addition to NULL (not assigned) and a pointer (assigned), we add the state "being set", which is signaled with an INVALID pointer (using "-1"). Link: https://lore.kernel.org/r/20201106193317.16993-1-leeman.duncan@gmail.com Reviewed-by: Mike Christie <michael.christie@oracle.com> Signed-off-by: Lee Duncan <lduncan@suse.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com> |
|
Jakub Kicinski | d5bd32a876 |
Merge branch 'bnxt_en-bug-fixes'
Michael Chan says: ==================== bnxt_en: Bug fixes. This first patch fixes a module eeprom A2h addressing issue. The next 2 patches fix counter related issues. The last one skips an unsupported firmware call on the VF to avoid the error log. ==================== Link: https://lore.kernel.org/r/1605486472-28156-1-git-send-email-michael.chan@broadcom.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> |
|
Vasundhara Volam | 0ae0a779ef |
bnxt_en: Avoid unnecessary NVM_GET_DEV_INFO cmd error log on VFs.
VFs do not have access permissions to issue NVM_GET_DEV_INFO
firmware command.
Fixes:
|
|
Michael Chan | fa97f303fa |
bnxt_en: Fix counter overflow logic.
bnxt_add_one_ctr() adds a hardware counter to a software counter and
adjusts for the hardware counter wraparound against the mask. The logic
assumes that the hardware counter is always smaller than or equal to
the mask.
This assumption is mostly correct. But in some cases if the firmware
is older and does not provide the accurate mask, the driver can use
a mask that is smaller than the actual hardware mask. This can cause
some extra carry bits to be added to the software counter, resulting in
counters that far exceed the actual value. Fix it by masking the
hardware counter with the mask passed into bnxt_add_one_ctr().
Fixes:
|
|
Michael Chan | eba93de6d3 |
bnxt_en: Free port stats during firmware reset.
Firmware is unable to retain the port counters during any kind of
fatal or non-fatal resets, so we must clear the port counters to
avoid false detection of port counter overflow.
Fixes:
|
|
Edwin Peer | 4260330b32 |
bnxt_en: read EEPROM A2h address using page 0
The module eeprom address range returned by bnxt_get_module_eeprom()
should be 256 bytes of A0h address space, the lower half of the A2h
address space, and page 0 for the upper half of the A2h address space.
Fix the firmware call by passing page_number 0 for the A2h slave address
space.
Fixes:
|
|
Alex Elder | 064c9c32b1 |
net: ipa: lock when freeing transaction
Transactions sit on one of several lists, depending on their state
(allocated, pending, complete, or polled). A spinlock protects
against concurrent access when transactions are moved between these
lists.
Transactions are also reference counted. A newly-allocated
transaction has an initial count of 1; a transaction is released in
gsi_trans_free() only if its decremented reference count reaches 0.
Releasing a transaction includes removing it from the polled (or if
unused, allocated) list, so the spinlock is acquired when we release
a transaction.
The reference count is used to allow a caller to synchronously wait
for a committed transaction to complete. In this case, the waiter
takes an extra reference to the transaction *before* committing it
(so it won't be freed), and releases its reference (calls
gsi_trans_free()) when it is done with it.
Similarly, gsi_channel_update() takes an extra reference to ensure a
transaction isn't released before the function is done operating on
it. Until the transaction is moved to the completed list (by this
function) it won't be freed, so this reference is taken "safely."
But in the quiesce path, we want to wait for the "last" transaction,
which we find in the completed or polled list. Transactions on
these lists can be freed at any time, so we (try to) prevent that
by taking the reference while holding the spinlock.
Currently gsi_trans_free() decrements a transaction's reference
count unconditionally, acquiring the lock to remove the transaction
from its list *only* when the count reaches 0. This does not
protect the quiesce path, which depends on the lock to ensure its
extra reference prevents release of the transaction.
Fix this by only dropping the last reference to a transaction
in gsi_trans_free() while holding the spinlock.
Fixes:
|
|
Vadim Fedorenko | 3fe16edf67 |
net/tls: fix corrupted data in recvmsg
If tcp socket has more data than Encrypted Handshake Message then
tls_sw_recvmsg will try to decrypt next record instead of returning
full control message to userspace as mentioned in comment. The next
message - usually Application Data - gets corrupted because it uses
zero copy for decryption that's why the data is not stored in skb
for next iteration. Revert check to not decrypt next record if
current is not Application Data.
Fixes:
|
|
Subash Abhinov Kasiviswanathan | fc70f5bf5e |
net: qualcomm: rmnet: Fix incorrect receive packet handling during cleanup
During rmnet unregistration, the real device rx_handler is first cleared
followed by the removal of rx_handler_data after the rcu synchronization.
Any packets in the receive path may observe that the rx_handler is NULL.
However, there is no check when dereferencing this value to use the
rmnet_port information.
This fixes following splat by adding the NULL check.
Unable to handle kernel NULL pointer dereference at virtual
address 000000000000000d
pc : rmnet_rx_handler+0x124/0x284
lr : rmnet_rx_handler+0x124/0x284
rmnet_rx_handler+0x124/0x284
__netif_receive_skb_core+0x758/0xd74
__netif_receive_skb+0x50/0x17c
process_backlog+0x15c/0x1b8
napi_poll+0x88/0x284
net_rx_action+0xbc/0x23c
__do_softirq+0x20c/0x48c
Fixes:
|
|
Lorenzo Bianconi | 9c79a8ab5f |
net: mvneta: fix possible memory leak in mvneta_swbm_add_rx_fragment
Recycle the page running page_pool_put_full_page() in
mvneta_swbm_add_rx_fragment routine when the last descriptor
contains just the FCS or if the received packet contains more than
MAX_SKB_FRAGS fragments
Fixes:
|
|
Wong Vee Khee | 8e5debed39 |
net: stmmac: Use rtnl_lock/unlock on netif_set_real_num_rx_queues() call
Fix an issue where dump stack is printed on suspend resume flow due to
netif_set_real_num_rx_queues() is not called with rtnl_lock held().
Fixes:
|
|
Heiner Kallweit | 7a30ecc923 |
net: bridge: add missing counters to ndo_get_stats64 callback
In br_forward.c and br_input.c fields dev->stats.tx_dropped and
dev->stats.multicast are populated, but they are ignored in
ndo_get_stats64.
Fixes:
|
|
Zhang Changzhong | 35f735c665 |
net: ethernet: ti: cpsw: fix error return code in cpsw_probe()
Fix to return a negative error code from the error handling
case instead of 0, as done elsewhere in this function.
Fixes:
|
|
Zhang Changzhong | 661710bfd5 |
net: stmmac: dwmac-intel-plat: fix error return code in intel_eth_plat_probe()
Fix to return a negative error code from the error handling
case instead of 0, as done elsewhere in this function.
Fixes:
|
|
Mark Brown |
63fa58d99a
|
Merge Intel catpt DSP fixes into asoc-5.10 |