summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2021-03-26hwrng: intel - Fix included header from 'asmTian Tao
This commit fixes the checkpatch warning: WARNING: Use #include <linux/io.h> instead of <asm/io.h> 34: FILE: drivers/char/hw_random/intel-rng.c:34: Signed-off-by: Tian Tao <tiantao6@hisilicon.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2021-03-26Merge branch 'ecc'Herbert Xu
This pulls in the NIST P384/256/192 x509 changes.
2021-03-26x509: Add OID for NIST P384 and extend parser for itSaulo Alessandre
Prepare the x509 parser to accept NIST P384 certificates and add the OID for ansip384r1, which is the identifier for NIST P384. Summary of changes: * crypto/asymmetric_keys/x509_cert_parser.c - prepare x509 parser to load NIST P384 * include/linux/oid_registry.h - add OID_ansip384r1 Signed-off-by: Saulo Alessandre <saulo.alessandre@tse.jus.br> Tested-by: Stefan Berger <stefanb@linux.ibm.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2021-03-26ima: Support EC keys for signature verificationStefan Berger
Add support for IMA signature verification for EC keys. Since SHA type of hashes can be used by RSA and ECDSA signature schemes we need to look at the key and derive from the key which signature scheme to use. Since this can be applied to all types of keys, we change the selection of the encoding type to be driven by the key's signature scheme rather than by the hash type. Cc: Dmitry Kasatkin <dmitry.kasatkin@gmail.com> Cc: linux-integrity@vger.kernel.org Cc: David Howells <dhowells@redhat.com> Cc: keyrings@vger.kernel.org Signed-off-by: Stefan Berger <stefanb@linux.ibm.com> Reviewed-by: Vitaly Chikunov <vt@altlinux.org> Reviewed-by: Tianjia Zhang <tianjia.zhang@linux.alibaba.com> Acked-by: Mimi Zohar <zohar@linux.ibm.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2021-03-26x509: Add support for parsing x509 certs with ECDSA keysStefan Berger
Add support for parsing of x509 certificates that contain ECDSA keys, such as NIST P256, that have been signed by a CA using any of the current SHA hash algorithms. Cc: David Howells <dhowells@redhat.com> Cc: keyrings@vger.kernel.org Signed-off-by: Stefan Berger <stefanb@linux.ibm.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2021-03-26x509: Detect sm2 keys by their parameters OIDStefan Berger
Detect whether a key is an sm2 type of key by its OID in the parameters array rather than assuming that everything under OID_id_ecPublicKey is sm2, which is not the case. Cc: David Howells <dhowells@redhat.com> Cc: keyrings@vger.kernel.org Signed-off-by: Stefan Berger <stefanb@linux.ibm.com> Reviewed-by: Tianjia Zhang <tianjia.zhang@linux.alibaba.com> Tested-by: Tianjia Zhang <tianjia.zhang@linux.alibaba.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2021-03-26crypto: ecdsa - Register NIST P384 and extend test suiteSaulo Alessandre
Register NIST P384 as an akcipher and extend the testmgr with NIST P384-specific test vectors. Summary of changes: * crypto/ecdsa.c - add ecdsa_nist_p384_init_tfm - register and unregister P384 tfm * crypto/testmgr.c - add test vector for P384 on vector of tests * crypto/testmgr.h - add test vector params for P384(sha1, sha224, sha256, sha384 and sha512) Signed-off-by: Saulo Alessandre <saulo.alessandre@tse.jus.br> Tested-by: Stefan Berger <stefanb@linux.ibm.com> Acked-by: Jarkko Sakkinen <jarkko@kernel.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2021-03-26crypto: ecc - Add math to support fast NIST P384Saulo Alessandre
Add the math needed for NIST P384 and adapt certain functions' parameters so that the ecc_curve is passed to vli_mmod_fast. This allows to identify the curve by its name prefix and the appropriate function for fast mmod calculation can be used. Summary of changes: * crypto/ecc.c - add vli_mmod_fast_384 - change some routines to pass ecc_curve forward until vli_mmod_fast * crypto/ecc.h - add ECC_CURVE_NIST_P384_DIGITS - change ECC_MAX_DIGITS to P384 size Signed-off-by: Saulo Alessandre <saulo.alessandre@tse.jus.br> Tested-by: Stefan Berger <stefanb@linux.ibm.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2021-03-26crypto: ecc - Add NIST P384 curve parametersSaulo Alessandre
Add the parameters for the NIST P384 curve and define a new curve ID for it. Make the curve available in ecc_get_curve. Summary of changes: * crypto/ecc_curve_defs.h - add nist_p384 params * include/crypto/ecdh.h - add ECC_CURVE_NIST_P384 * crypto/ecc.c - change ecc_get_curve to accept nist_p384 Signed-off-by: Saulo Alessandre <saulo.alessandre@tse.jus.br> Tested-by: Stefan Berger <stefanb@linux.ibm.com> Acked-by: Jarkko Sakkinen <jarkko@kernel.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2021-03-26crypto: ecdsa - Add support for ECDSA signature verificationStefan Berger
Add support for parsing the parameters of a NIST P256 or NIST P192 key. Enable signature verification using these keys. The new module is enabled with CONFIG_ECDSA: Elliptic Curve Digital Signature Algorithm (NIST P192, P256 etc.) is A NIST cryptographic standard algorithm. Only signature verification is implemented. Cc: Herbert Xu <herbert@gondor.apana.org.au> Cc: "David S. Miller" <davem@davemloft.net> Cc: linux-crypto@vger.kernel.org Signed-off-by: Stefan Berger <stefanb@linux.ibm.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2021-03-26oid_registry: Add OIDs for ECDSA with SHA224/256/384/512Stefan Berger
Add OIDs for ECDSA with SHA224/256/384/512. Signed-off-by: Stefan Berger <stefanb@linux.ibm.com> Acked-by: Jarkko Sakkinen <jarkko@kernel.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2021-03-26drivers: gpu: drm: xen_drm_front_drm_info is declared twiceWan Jiabing
struct xen_drm_front_drm_info has been declared. Remove the duplicate. Signed-off-by: Wan Jiabing <wanjiabing@vivo.com> Reviewed-by: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com> Signed-off-by: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210325061901.851273-1-wanjiabing@vivo.com
2021-03-26gpu/xen: Fix a use after free in xen_drm_drv_initLv Yunlong
In function displback_changed, has the call chain displback_connect(front_info)->xen_drm_drv_init(front_info). We can see that drm_info is assigned to front_info->drm_info and drm_info is freed in fail branch in xen_drm_drv_init(). Later displback_disconnect(front_info) is called and it calls xen_drm_drv_fini(front_info) cause a use after free by drm_info = front_info->drm_info statement. My patch has done two things. First fixes the fail label which drm_info = kzalloc() failed and still free the drm_info. Second sets front_info->drm_info to NULL to avoid uaf. Signed-off-by: Lv Yunlong <lyl2019@mail.ustc.edu.cn> Reviewed-by: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com> Signed-off-by: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210323014656.10068-1-lyl2019@mail.ustc.edu.cn
2021-03-25libbpf: Fix bail out from 'ringbuf_process_ring()' on errorPedro Tammela
The current code bails out with negative and positive returns. If the callback returns a positive return code, 'ring_buffer__consume()' and 'ring_buffer__poll()' will return a spurious number of records consumed, but mostly important will continue the processing loop. This patch makes positive returns from the callback a no-op. Fixes: bf99c936f947 ("libbpf: Add BPF ring buffer support") Signed-off-by: Pedro Tammela <pctammela@mojatatu.com> Signed-off-by: Andrii Nakryiko <andrii@kernel.org> Link: https://lore.kernel.org/bpf/20210325150115.138750-1-pctammela@mojatatu.com
2021-03-26Merge tag 'drm-msm-fixes-2021-02-25' of ↵Dave Airlie
https://gitlab.freedesktop.org/drm/msm into drm-fixes - pll fixes - shutdown hook fix - runtime resume fix - clear_oob fix - kms locking fix - display aux retry fix Signed-off-by: Dave Airlie <airlied@redhat.com> From: Rob Clark <robdclark@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/CAF6AEGvmiMKRms_NVavD=NA_jbuexZUcqqL35ke7umqpp-TxMw@mail.gmail.com
2021-03-25Merge branch '40GbE' of ↵David S. Miller
git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/net-queue Tony Nguyen says: ==================== Intel Wired LAN Driver Updates 2021-03-25 This series contains updates to virtchnl header file and i40e driver. Norbert removes added padding from virtchnl RSS structures as this causes issues when iterating over the arrays. Mateusz adds Asym_Pause as supported to allow these settings to be set as the hardware supports it. Eryk fixes an issue where encountering a VF reset alongside releasing VFs could cause a call trace. Arkadiusz moves TC setup before resource setup as previously it was possible to enter with a null q_vector causing a kernel oops. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
2021-03-25sch_red: fix off-by-one checks in red_check_params()Eric Dumazet
This fixes following syzbot report: UBSAN: shift-out-of-bounds in ./include/net/red.h:237:23 shift exponent 32 is too large for 32-bit type 'unsigned int' CPU: 1 PID: 8418 Comm: syz-executor170 Not tainted 5.12.0-rc4-next-20210324-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:79 [inline] dump_stack+0x141/0x1d7 lib/dump_stack.c:120 ubsan_epilogue+0xb/0x5a lib/ubsan.c:148 __ubsan_handle_shift_out_of_bounds.cold+0xb1/0x181 lib/ubsan.c:327 red_set_parms include/net/red.h:237 [inline] choke_change.cold+0x3c/0xc8 net/sched/sch_choke.c:414 qdisc_create+0x475/0x12f0 net/sched/sch_api.c:1247 tc_modify_qdisc+0x4c8/0x1a50 net/sched/sch_api.c:1663 rtnetlink_rcv_msg+0x44e/0xad0 net/core/rtnetlink.c:5553 netlink_rcv_skb+0x153/0x420 net/netlink/af_netlink.c:2502 netlink_unicast_kernel net/netlink/af_netlink.c:1312 [inline] netlink_unicast+0x533/0x7d0 net/netlink/af_netlink.c:1338 netlink_sendmsg+0x856/0xd90 net/netlink/af_netlink.c:1927 sock_sendmsg_nosec net/socket.c:654 [inline] sock_sendmsg+0xcf/0x120 net/socket.c:674 ____sys_sendmsg+0x6e8/0x810 net/socket.c:2350 ___sys_sendmsg+0xf3/0x170 net/socket.c:2404 __sys_sendmsg+0xe5/0x1b0 net/socket.c:2433 do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46 entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x43f039 Code: 28 c3 e8 2a 14 00 00 66 2e 0f 1f 84 00 00 00 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 c0 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007ffdfa725168 EFLAGS: 00000246 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 0000000000400488 RCX: 000000000043f039 RDX: 0000000000000000 RSI: 0000000020000040 RDI: 0000000000000004 RBP: 0000000000403020 R08: 0000000000400488 R09: 0000000000400488 R10: 0000000000400488 R11: 0000000000000246 R12: 00000000004030b0 R13: 0000000000000000 R14: 00000000004ac018 R15: 0000000000400488 Fixes: 8afa10cbe281 ("net_sched: red: Avoid illegal values") Signed-off-by: Eric Dumazet <edumazet@google.com> Reported-by: syzbot <syzkaller@googlegroups.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-03-25Merge branch 'tunnel-shinfo'David S. Miller
Antoine Tenart says: ==================== net: do not modify the shared tunnel info when PMTU triggers an ICMP reply The series fixes an issue were a shared ip_tunnel_info is modified when PMTU triggers an ICMP reply in vxlan and geneve, making following packets in that flow to have a wrong destination address if the flow isn't updated. A detailled information is given in each of the two commits. This was tested manually with OVS and I ran the PTMU selftests with kmemleak enabled (all OK, none was skipped). ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
2021-03-25geneve: do not modify the shared tunnel info when PMTU triggers an ICMP replyAntoine Tenart
When the interface is part of a bridge or an Open vSwitch port and a packet exceed a PMTU estimate, an ICMP reply is sent to the sender. When using the external mode (collect metadata) the source and destination addresses are reversed, so that Open vSwitch can match the packet against an existing (reverse) flow. But inverting the source and destination addresses in the shared ip_tunnel_info will make following packets of the flow to use a wrong destination address (packets will be tunnelled to itself), if the flow isn't updated. Which happens with Open vSwitch, until the flow times out. Fixes this by uncloning the skb's ip_tunnel_info before inverting its source and destination addresses, so that the modification will only be made for the PTMU packet, not the following ones. Fixes: c1a800e88dbf ("geneve: Support for PMTU discovery on directly bridged links") Tested-by: Eelco Chaudron <echaudro@redhat.com> Reviewed-by: Eelco Chaudron <echaudro@redhat.com> Signed-off-by: Antoine Tenart <atenart@kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-03-25vxlan: do not modify the shared tunnel info when PMTU triggers an ICMP replyAntoine Tenart
When the interface is part of a bridge or an Open vSwitch port and a packet exceed a PMTU estimate, an ICMP reply is sent to the sender. When using the external mode (collect metadata) the source and destination addresses are reversed, so that Open vSwitch can match the packet against an existing (reverse) flow. But inverting the source and destination addresses in the shared ip_tunnel_info will make following packets of the flow to use a wrong destination address (packets will be tunnelled to itself), if the flow isn't updated. Which happens with Open vSwitch, until the flow times out. Fixes this by uncloning the skb's ip_tunnel_info before inverting its source and destination addresses, so that the modification will only be made for the PTMU packet, not the following ones. Fixes: fc68c99577cc ("vxlan: Support for PMTU discovery on directly bridged links") Tested-by: Eelco Chaudron <echaudro@redhat.com> Reviewed-by: Eelco Chaudron <echaudro@redhat.com> Signed-off-by: Antoine Tenart <atenart@kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-03-25Merge branch 'nfc-fixes'David S. Miller
Xiaoming Ni says: ==================== nfc: fix Resource leakage and endless loop fix Resource leakage and endless loop in net/nfc/llcp_sock.c, reported by "kiyin(尹亮)". Link: https://www.openwall.com/lists/oss-security/2020/11/01/1 ==================== math: Export mul_u64_u64_div_u64 Fixes: f51d7bf1dbe5 ("ptp_qoriq: fix overflow in ptp_qoriq_adjfine() u64 calcalation") Signed-off-by: David S. Miller <davem@davemloft.net>
2021-03-25nfc: Avoid endless loops caused by repeated llcp_sock_connect()Xiaoming Ni
When sock_wait_state() returns -EINPROGRESS, "sk->sk_state" is LLCP_CONNECTING. In this case, llcp_sock_connect() is repeatedly invoked, nfc_llcp_sock_link() will add sk to local->connecting_sockets twice. sk->sk_node->next will point to itself, that will make an endless loop and hang-up the system. To fix it, check whether sk->sk_state is LLCP_CONNECTING in llcp_sock_connect() to avoid repeated invoking. Fixes: b4011239a08e ("NFC: llcp: Fix non blocking sockets connections") Reported-by: "kiyin(尹亮)" <kiyin@tencent.com> Link: https://www.openwall.com/lists/oss-security/2020/11/01/1 Cc: <stable@vger.kernel.org> #v3.11 Signed-off-by: Xiaoming Ni <nixiaoming@huawei.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-03-25nfc: fix memory leak in llcp_sock_connect()Xiaoming Ni
In llcp_sock_connect(), use kmemdup to allocate memory for "llcp_sock->service_name". The memory is not released in the sock_unlink label of the subsequent failure branch. As a result, memory leakage occurs. fix CVE-2020-25672 Fixes: d646960f7986 ("NFC: Initial LLCP support") Reported-by: "kiyin(尹亮)" <kiyin@tencent.com> Link: https://www.openwall.com/lists/oss-security/2020/11/01/1 Cc: <stable@vger.kernel.org> #v3.3 Signed-off-by: Xiaoming Ni <nixiaoming@huawei.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-03-25nfc: fix refcount leak in llcp_sock_connect()Xiaoming Ni
nfc_llcp_local_get() is invoked in llcp_sock_connect(), but nfc_llcp_local_put() is not invoked in subsequent failure branches. As a result, refcount leakage occurs. To fix it, add calling nfc_llcp_local_put(). fix CVE-2020-25671 Fixes: c7aa12252f51 ("NFC: Take a reference on the LLCP local pointer when creating a socket") Reported-by: "kiyin(尹亮)" <kiyin@tencent.com> Link: https://www.openwall.com/lists/oss-security/2020/11/01/1 Cc: <stable@vger.kernel.org> #v3.6 Signed-off-by: Xiaoming Ni <nixiaoming@huawei.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-03-25nfc: fix refcount leak in llcp_sock_bind()Xiaoming Ni
nfc_llcp_local_get() is invoked in llcp_sock_bind(), but nfc_llcp_local_put() is not invoked in subsequent failure branches. As a result, refcount leakage occurs. To fix it, add calling nfc_llcp_local_put(). fix CVE-2020-25670 Fixes: c7aa12252f51 ("NFC: Take a reference on the LLCP local pointer when creating a socket") Reported-by: "kiyin(尹亮)" <kiyin@tencent.com> Link: https://www.openwall.com/lists/oss-security/2020/11/01/1 Cc: <stable@vger.kernel.org> #v3.6 Signed-off-by: Xiaoming Ni <nixiaoming@huawei.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-03-25amd-xgbe: Update DMA coherency valuesShyam Sundar S K
Based on the IOMMU configuration, the current cache control settings can result in possible coherency issues. The hardware team has recommended new settings for the PCI device path to eliminate the issue. Fixes: 6f595959c095 ("amd-xgbe: Adjust register settings to improve performance") Signed-off-by: Shyam Sundar S K <Shyam-sundar.S-k@amd.com> Acked-by: Tom Lendacky <thomas.lendacky@amd.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-03-25net: dsa: lantiq_gswip: Let GSWIP automatically set the xMII clockMartin Blumenstingl
The xMII interface clock depends on the PHY interface (MII, RMII, RGMII) as well as the current link speed. Explicitly configure the GSWIP to automatically select the appropriate xMII interface clock. This fixes an issue seen by some users where ports using an external RMII or RGMII PHY were deaf (no RX or TX traffic could be seen). Most likely this is due to an "invalid" xMII clock being selected either by the bootloader or hardware-defaults. Fixes: 14fceff4771e51 ("net: dsa: Add Lantiq / Intel DSA driver for vrx200") Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-03-25dt-bindings: net: micrel-ksz90x1.txt: correct documentationDinh Nguyen
Correct the Micrel phy documentation for the ksz9021 and ksz9031 phys for how the phy skews are set. Signed-off-by: Dinh Nguyen <dinguyen@kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-03-25net: axienet: allow setups without MDIODaniel Mack
In setups with fixed-link settings there is no mdio node in DTS. axienet_probe() already handles that gracefully but lp->mii_bus is then NULL. Fix code that tries to blindly grab the MDIO lock by introducing two helper functions that make the locking conditional. Signed-off-by: Daniel Mack <daniel@zonque.org> Reviewed-by: Radhey Shyam Pandey <radhey.shyam.pandey@xilinx.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-03-25net: dsa: only unset VLAN filtering when last port leaves last VLAN-aware bridgeVladimir Oltean
DSA is aware of switches with global VLAN filtering since the blamed commit, but it makes a bad decision when multiple bridges are spanning the same switch: ip link add br0 type bridge vlan_filtering 1 ip link add br1 type bridge vlan_filtering 1 ip link set swp2 master br0 ip link set swp3 master br0 ip link set swp4 master br1 ip link set swp5 master br1 ip link set swp5 nomaster ip link set swp4 nomaster [138665.939930] sja1105 spi0.1: port 3: dsa_core: VLAN filtering is a global setting [138665.947514] DSA: failed to notify DSA_NOTIFIER_BRIDGE_LEAVE When all ports leave br1, DSA blindly attempts to disable VLAN filtering on the switch, ignoring the fact that br0 still exists and is VLAN-aware too. It fails while doing that. This patch checks whether any port exists at all and is under a VLAN-aware bridge. Fixes: d371b7c92d19 ("net: dsa: Unset vlan_filtering when ports leave the bridge") Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Tested-by: Florian Fainelli <f.fainelli@gmail.com> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Reviewed-by: Kurt Kanzenbach <kurt@linutronix.de> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-03-25Merge tag 'integrity-v5.12-fix' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/zohar/linux-integrity Pull integrity fix from Mimi Zohar: "Just one patch to address a NULL ptr dereferencing when there is a mismatch between the user enabled LSMs and IMA/EVM" * tag 'integrity-v5.12-fix' of git://git.kernel.org/pub/scm/linux/kernel/git/zohar/linux-integrity: integrity: double check iint_cache was initialized
2021-03-25hostfs: fix memory handling in follow_link()Al Viro
1) argument should not be freed in any case - the caller already has it as ->s_fs_info (and uses it a lot afterwards) 2) allocate readlink buffer with kmalloc() - the caller has no way to tell if it's got that (on absolute symlink) or a result of kasprintf(). Sure, for SLAB and SLUB kfree() works on results of kmem_cache_alloc(), but that's not documented anywhere, might change in the future *and* is already not true for SLOB. Fixes: 52b209f7b848 ("get rid of hostfs_read_inode()") Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2021-03-25Merge tag 'for-5.12-rc4-tag' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux Pull btrfs fixes from David Sterba: "Fixes for issues that have some user visibility and are simple enough for this time of development cycle: - a few fixes for rescue= mount option, adding more checks for missing trees - fix sleeping in atomic context on qgroup deletion - fix subvolume deletion on mount - fix build with M= syntax - fix checksum mismatch error message for direct io" * tag 'for-5.12-rc4-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux: btrfs: fix check_data_csum() error message for direct I/O btrfs: fix sleep while in non-sleep context during qgroup removal btrfs: fix subvolume/snapshot deletion not triggered on mount btrfs: fix build when using M=fs/btrfs btrfs: do not initialize dev replace for bad dev root btrfs: initialize device::fs_info always btrfs: do not initialize dev stats if we have no dev_root btrfs: zoned: remove outdated WARN_ON in direct IO
2021-03-25tools/turbostat: Unmark non-kernel-doc commentRandy Dunlap
Do not mark a comment as kernel-doc notation when it is not meant to be in kernel-doc notation. Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Signed-off-by: Borislav Petkov <bp@suse.de> Link: https://lkml.kernel.org/r/20210325201333.16792-1-rdunlap@infradead.org
2021-03-25s390/vdso: fix initializing and updating of vdso_dataHeiko Carstens
Li Wang reported that clock_gettime(CLOCK_MONOTONIC_RAW, ...) returns incorrect values when time is provided via vdso instead of system call: vdso_ts_nsec = 4484351380985507, vdso_ts.tv_sec = 4484351, vdso_ts.tv_nsec = 380985507 sys_ts_nsec = 1446923235377, sys_ts.tv_sec = 1446, sys_ts.tv_nsec = 923235377 Within the s390 specific vdso function __arch_get_hw_counter() reads tod clock steering values from the arch_data member of the passed in vdso_data structure. Problem is that only for the CS_HRES_COARSE vdso_data arch_data is initialized and gets updated. The CS_RAW specific vdso_data does not contain any valid tod_clock_steering information, which explains the different values. Fix this by initializing and updating all vdso_datas. Reported-by: Li Wang <liwang@redhat.com> Tested-by: Li Wang <liwang@redhat.com> Fixes: 1ba2d6c0fd4e ("s390/vdso: simplify __arch_get_hw_counter()") Link: https://lore.kernel.org/linux-s390/YFnxr1ZlMIOIqjfq@osiris Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2021-03-25s390/vdso: fix tod_steering_delta typeHeiko Carstens
The s390 specific vdso function __arch_get_hw_counter() is supposed to consider tod clock steering. If a tod clock steering event happens and the tod clock is set to a new value __arch_get_hw_counter() will not return the real tod clock value but slowly drift it from the old delta until the returned value finally matches the real tod clock value again. Unfortunately the type of tod_steering_delta unsigned while it is supposed to be signed. It depends on if tod_steering_delta is negative or positive in which direction the vdso code drifts the clock value. Worst case is now that instead of drifting the clock slowly it will jump into the opposite direction by a factor of two. Fix this by simply making tod_steering_delta signed. Fixes: 4bff8cb54502 ("s390: convert to GENERIC_VDSO") Cc: <stable@vger.kernel.org> # 5.10 Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2021-03-25s390/vdso: copy tod_steering_delta value to vdso_data pageHeiko Carstens
When converting the vdso assembler code to C it was forgotten to actually copy the tod_steering_delta value to vdso_data page. Which in turn means that tod clock steering will not work correctly. Fix this by simply copying the value whenever it is updated. Fixes: 4bff8cb54502 ("s390: convert to GENERIC_VDSO") Cc: <stable@vger.kernel.org> # 5.10 Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2021-03-26Merge tag 'amd-drm-fixes-5.12-2021-03-24' of ↵Dave Airlie
https://gitlab.freedesktop.org/agd5f/linux into drm-fixes amd-drm-fixes-5.12-2021-03-24: amdgpu: - S0ix fixes - Add PCI ID - Polaris PCIe DPM fix - Display fix for high refresh rate monitors Signed-off-by: Dave Airlie <airlied@redhat.com> From: Alex Deucher <alexander.deucher@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210324210630.3949-1-alexander.deucher@amd.com
2021-03-26Merge branch 'linux-5.12' of git://github.com/skeggsb/linux into drm-fixesDave Airlie
- cursor size fix Signed-off-by: Dave Airlie <airlied@redhat.com> From: Ben Skeggs <skeggsb@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/CACAvsv7js90N_PYc8JncQA9Hu0yjbg+vPw109FKxJ538nZ=fag@mail.gmail.com
2021-03-26Merge tag 'drm-intel-fixes-2021-03-25-1' of ↵Dave Airlie
git://anongit.freedesktop.org/drm/drm-intel into drm-fixes - DisplayPort LTTPR fixes around link training and limiting it according to supported spec version. (Imre) - Fix enabled_planes bitmask to really represent only logically enabled planes (Ville). - Fix DSS CTL registers for ICL DSI transcoders (Jani) - Fix the GT fence revocation runtime PM logic. (Imre) Signed-off-by: Dave Airlie <airlied@redhat.com> From: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/YFxYdrjqeUtSu+3p@intel.com
2021-03-26Merge tag 'drm-misc-fixes-2021-03-25' of ↵Dave Airlie
git://anongit.freedesktop.org/drm/drm-misc into drm-fixes drm-misc-fixes for v5.12: - Use FOLL_FORCE and FOLL_LONGTERM in etnaviv Signed-off-by: Dave Airlie <airlied@redhat.com> From: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/72d4c9ce-6709-4e0f-a715-79fdcebb48e7@linux.intel.com
2021-03-25i40e: Fix oops at i40e_rebuild()Arkadiusz Kubalewski
Setup TC before the i40e_setup_pf_switch() call. Memory must be initialized for all the queues before using its resources. Previously it could be possible that a call: xdp_rxq_info_reg(&rx_ring->xdp_rxq, rx_ring->netdev, rx_ring->queue_index, rx_ring->q_vector->napi.napi_id); was made with q_vector being null. Oops could show up with the following sequence: - no driver loaded - FW LLDP agent is on (flag disable-fw-lldp:off) - link is up - DCB configured with number of Traffic Classes that will not divide completely the default number of queues (usually cpu cores) - driver load - set private flag: disable-fw-lldp:on Fixes: 4b208eaa8078 ("i40e: Add init and default config of software based DCB") Fixes: b02e5a0ebb17 ("xsk: Propagate napi_id to XDP socket Rx path") Signed-off-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com> Signed-off-by: Arkadiusz Kubalewski <arkadiusz.kubalewski@intel.com> Tested-by: Tony Brelinski <tonyx.brelinski@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2021-03-25i40e: Fix kernel oops when i40e driver removes VF'sEryk Rybak
Fix the reason of kernel oops when i40e driver removed VFs. Added new __I40E_VFS_RELEASING state to signalize releasing process by PF, that it makes possible to exit of reset VF procedure. Without this patch, it is possible to suspend the VFs reset by releasing VFs resources procedure. Retrying the reset after the timeout works on the freed VF memory causing a kernel oops. Fixes: d43d60e5eb95 ("i40e: ensure reset occurs when disabling VF") Signed-off-by: Eryk Rybak <eryk.roch.rybak@intel.com> Signed-off-by: Grzegorz Szczurek <grzegorzx.szczurek@intel.com> Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com> Tested-by: Konrad Jankowski <konrad0.jankowski@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2021-03-25io_uring: maintain CQE order of a failed linkPavel Begunkov
Arguably we want CQEs of linked requests be in a strict order of submission as it always was. Now if init of a request fails its CQE may be posted before all prior linked requests including the head of the link. Fix it by failing it last. Fixes: de59bc104c24f ("io_uring: fail links more in io_submit_sqe()") Signed-off-by: Pavel Begunkov <asml.silence@gmail.com> Link: https://lore.kernel.org/r/b7a96b05832e7ab23ad55f84092a2548c4a888b0.1616699075.git.asml.silence@gmail.com Signed-off-by: Jens Axboe <axboe@kernel.dk>
2021-03-25iio: acpi_als: Add trigger supportGwendal Grignou
As some firmware does not notify on illuminance changes, add a trigger to be able to query light via software (sysfs-trigger or hrtrigger). Add a hardware trigger set as the default trigger to maintain backward compatibility. Check iio_info reports the sensor as buffer capable: iio:device0: acpi-als (buffer capable) To test, check we can get data on demand on an Intel based chromebook: IIO_DEV="iio:device0" echo 1 > iio_sysfs_trigger/add_trigger cat trigger2/name > ${IIO_DEV}/trigger/current_trigger for i in ${IIO_DEV}/scan_elements/*_en ${IIO_DEV}/buffer/enable ; do echo 1 > $i done od -x /dev/${IIO_DEV} & echo 1 > trigger2/trigger_now Signed-off-by: Gwendal Grignou <gwendal@chromium.org> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Link: https://lore.kernel.org/r/20210317074012.2336454-4-gwendal@chromium.org Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-03-25iio: acpi_als: Add local variable dev in probeGwendal Grignou
Use dev = &device->dev in probe routine for clarity. Signed-off-by: Gwendal Grignou <gwendal@chromium.org> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Link: https://lore.kernel.org/r/20210317074012.2336454-3-gwendal@chromium.org Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-03-25iio: acpi_als: Add timestamp channelGwendal Grignou
Add timestamp channel in list of channel, to allow retrieving timestamps when events are produced. Signed-off-by: Gwendal Grignou <gwendal@chromium.org> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Link: https://lore.kernel.org/r/20210317074012.2336454-2-gwendal@chromium.org Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-03-25iio: adc: ad7292: Modify the bool initialization assignmentGuoqing Chi
A bool initializer is best assigned to false rather than 0. Signed-off-by: Guoqing Chi <chiguoqing@yulong.com> Reviewed-by: Marcelo Schmitt <marcelo.schmitt1@gmail.com> Link: https://lore.kernel.org/r/20210319062706.5135-1-chi962464zy@163.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-03-25iio: cros: unify hw fifo attributes without API changesGwendal Grignou
Commit 2e2366c2d141 ("iio: cros_ec: unify hw fifo attributes into the core file") should be reverted as it set buffer extended attributes at the wrong place. However, to revert it will requires to revert more commits: commit 165aea80e2e2 ("iio: cros_ec: use devm_iio_triggered_buffer_setup_ext()") commit 21232b4456ba ("iio: buffer: remove iio_buffer_set_attrs() helper")). and we would still have conflict with more recent development. commit ee708e6baacd ("iio: buffer: introduce support for attaching more IIO buffers") Instead, this commit reverts the first 2 commits without re-adding iio_buffer_set_attrs() and set the buffer extended attributes at the right place: 1. Instead of adding has_fw_fifo, deduct it from the configuration: - EC must support FIFO (EC_FEATURE_MOTION_SENSE_FIFO) set. - sensors send data a regular interval (accelerometer, gyro, magnetomer, barometer, light sensor). - "Legacy accelerometer" is only present on EC without FIFO, so we don't need to set buffer attributes. 2. devm_iio_triggered_buffer_setup_ext() does not need to be called when EC does not support FIFO, as there is no FIFO to manage. 3. Use devm_iio_triggered_buffer_setup_ext() when EC has a FIFO to specify the buffer extended attributes. Fixes: 2e2366c2d141 ("iio: cros_ec: unify hw fifo attributes into the core file") Fixes: 165aea80e2e2 ("iio: cros_ec: use devm_iio_triggered_buffer_setup_ext()") Signed-off-by: Gwendal Grignou <gwendal@chromium.org> Reviewed-by: Alexandru Ardelean <ardeleanalex@gmail.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Link: https://lore.kernel.org/r/20210318184857.2679181-1-gwendal@chromium.org Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-03-25iio: kfifo: add devm_iio_triggered_buffer_setup_ext variantAlexandru Ardelean
This is similar to the {devm_}iio_triggered_buffer_setup_ext variants added via commit 5164c7889857 ("iio: triggered-buffer: add {devm_}iio_triggered_buffer_setup_ext variants"). These can be used to pass extra buffer attributes to the buffer object. This is a bit of temporary mechanism (hopefully) so that drivers that want to allocate a kfifo buffer with extra buffer attributes, don't need to include 'buffer_impl.h' directly. This can also become an API function (in it's own right, unfortunately), but it may be a little less bad vs drivers having to include 'buffer_impl.h'. So, far the drivers that want to pass buffer attributes, all have to do with some HW FIFO attributes, so there may be a chance of unifying them into IIO core somehow (as some standard API). But, until that happens, we just need to let them register their HW FIFO attributes directly (without having to let them include 'buffer_impl.h' directly). Signed-off-by: Alexandru Ardelean <aardelean@deviqon.com> Link: https://lore.kernel.org/r/20210311091042.22417-1-aardelean@deviqon.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
generated by cgit (git 2.34.1) at 2025-09-21 20:06:57 +0000