aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2021-04-06net/mlx5: Fix placement of log_max_flow_counterRaed Salem1-3/+3
The cited commit wrongly placed log_max_flow_counter field of mlx5_ifc_flow_table_prop_layout_bits, align it to the HW spec intended placement. Fixes: 16f1c5bb3ed7 ("net/mlx5: Check device capability for maximum flow counters") Signed-off-by: Raed Salem <[email protected]> Reviewed-by: Roi Dayan <[email protected]> Signed-off-by: Saeed Mahameed <[email protected]>
2021-04-06net/mlx5: Fix HW spec violation configuring uplinkEli Cohen1-2/+3
Make sure to modify uplink port to follow only if the uplink_follow capability is set as required by the HW spec. Failure to do so causes traffic to the uplink representor net device to cease after switching to switchdev mode. Fixes: 7d0314b11cdd ("net/mlx5e: Modify uplink state on interface up/down") Signed-off-by: Eli Cohen <[email protected]> Reviewed-by: Roi Dayan <[email protected]> Signed-off-by: Saeed Mahameed <[email protected]>
2021-04-06LOOKUP_MOUNTPOINT: we are cleaning "jumped" flag too lateAl Viro1-4/+4
That (and traversals in case of umount .) should be done before complete_walk(). Either a braino or mismerge damage on queue reorders - either way, I should've spotted that much earlier. Fucked-up-by: Al Viro <[email protected]> X-Paperbag: Brown Fixes: 161aff1d93ab "LOOKUP_MOUNTPOINT: fold path_mountpointat() into path_lookupat()" Cc: [email protected] # v5.7+ Signed-off-by: Al Viro <[email protected]>
2021-04-06docs: ethtool: fix some copy-paste errorsJakub Kicinski1-5/+5
Fix incorrect documentation. Mostly referring to other objects, likely because the text was copied and not adjusted. Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2021-04-06net: tun: set tun->dev->addr_len during TUNSETLINK processingPhillip Potter1-0/+48
When changing type with TUNSETLINK ioctl command, set tun->dev->addr_len to match the appropriate type, using new tun_get_addr_len utility function which returns appropriate address length for given type. Fixes a KMSAN-found uninit-value bug reported by syzbot at: https://syzkaller.appspot.com/bug?id=0766d38c656abeace60621896d705743aeefed51 Reported-by: [email protected] Diagnosed-by: Eric Dumazet <[email protected]> Signed-off-by: Phillip Potter <[email protected]> Reviewed-by: Eric Dumazet <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2021-04-06ethtool: fix incorrect datatype in set_eee opsWong Vee Khee1-2/+2
The member 'tx_lpi_timer' is defined with __u32 datatype in the ethtool header file. Hence, we should use ethnl_update_u32() in set_eee ops. Fixes: fd77be7bd43c ("ethtool: set EEE settings with EEE_SET request") Cc: <[email protected]> # 5.10.x Cc: Michal Kubecek <[email protected]> Signed-off-by: Wong Vee Khee <[email protected]> Reviewed-by: Jakub Kicinski <[email protected]> Reviewed-by: Michal Kubecek <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2021-04-06net: hns3: clear VF down state bit before request link statusGuangbin Huang1-2/+2
Currently, the VF down state bit is cleared after VF sending link status request command. There is problem that when VF gets link status replied from PF, the down state bit may still set as 1. In this case, the link status replied from PF will be ignored and always set VF link status to down. To fix this problem, clear VF down state bit before VF requests link status. Fixes: e2cb1dec9779 ("net: hns3: Add HNS3 VF HCL(Hardware Compatibility Layer) Support") Signed-off-by: Guangbin Huang <[email protected]> Signed-off-by: Huazhong Tan <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2021-04-06Merge tag 'linux-can-fixes-for-5.12-20210406' of ↵David S. Miller1-6/+18
git://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can Marc Kleine-Budde says: ==================== pull-request: can 2021-04-06 this is a pull request of 1 patch for net/master. The patch is by me and fixes the SPI half duplex support in the mcp251x CAN driver. ==================== Signed-off-by: David S. Miller <[email protected]>
2021-04-06pcnet32: Use pci_resource_len to validate PCI resourceGuenter Roeck1-2/+3
pci_resource_start() is not a good indicator to determine if a PCI resource exists or not, since the resource may start at address 0. This is seen when trying to instantiate the driver in qemu for riscv32 or riscv64. pci 0000:00:01.0: reg 0x10: [io 0x0000-0x001f] pci 0000:00:01.0: reg 0x14: [mem 0x00000000-0x0000001f] ... pcnet32: card has no PCI IO resources, aborting Use pci_resouce_len() instead. Signed-off-by: Guenter Roeck <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2021-04-07bpf, sockmap: Fix incorrect fwd_alloc accountingJohn Fastabend1-7/+5
Incorrect accounting fwd_alloc can result in a warning when the socket is torn down, [18455.319240] WARNING: CPU: 0 PID: 24075 at net/core/stream.c:208 sk_stream_kill_queues+0x21f/0x230 [...] [18455.319543] Call Trace: [18455.319556] inet_csk_destroy_sock+0xba/0x1f0 [18455.319577] tcp_rcv_state_process+0x1b4e/0x2380 [18455.319593] ? lock_downgrade+0x3a0/0x3a0 [18455.319617] ? tcp_finish_connect+0x1e0/0x1e0 [18455.319631] ? sk_reset_timer+0x15/0x70 [18455.319646] ? tcp_schedule_loss_probe+0x1b2/0x240 [18455.319663] ? lock_release+0xb2/0x3f0 [18455.319676] ? __release_sock+0x8a/0x1b0 [18455.319690] ? lock_downgrade+0x3a0/0x3a0 [18455.319704] ? lock_release+0x3f0/0x3f0 [18455.319717] ? __tcp_close+0x2c6/0x790 [18455.319736] ? tcp_v4_do_rcv+0x168/0x370 [18455.319750] tcp_v4_do_rcv+0x168/0x370 [18455.319767] __release_sock+0xbc/0x1b0 [18455.319785] __tcp_close+0x2ee/0x790 [18455.319805] tcp_close+0x20/0x80 This currently happens because on redirect case we do skb_set_owner_r() with the original sock. This increments the fwd_alloc memory accounting on the original sock. Then on redirect we may push this into the queue of the psock we are redirecting to. When the skb is flushed from the queue we give the memory back to the original sock. The problem is if the original sock is destroyed/closed with skbs on another psocks queue then the original sock will not have a way to reclaim the memory before being destroyed. Then above warning will be thrown sockA sockB sk_psock_strp_read() sk_psock_verdict_apply() -- SK_REDIRECT -- sk_psock_skb_redirect() skb_queue_tail(psock_other->ingress_skb..) sk_close() sock_map_unref() sk_psock_put() sk_psock_drop() sk_psock_zap_ingress() At this point we have torn down our own psock, but have the outstanding skb in psock_other. Note that SK_PASS doesn't have this problem because the sk_psock_drop() logic releases the skb, its still associated with our psock. To resolve lets only account for sockets on the ingress queue that are still associated with the current socket. On the redirect case we will check memory limits per 6fa9201a89898, but will omit fwd_alloc accounting until skb is actually enqueued. When the skb is sent via skb_send_sock_locked or received with sk_psock_skb_ingress memory will be claimed on psock_other. Fixes: 6fa9201a89898 ("bpf, sockmap: Avoid returning unneeded EAGAIN when redirecting to self") Reported-by: Andrii Nakryiko <[email protected]> Signed-off-by: John Fastabend <[email protected]> Signed-off-by: Daniel Borkmann <[email protected]> Link: https://lore.kernel.org/bpf/161731444013.68884.4021114312848535993.stgit@john-XPS-13-9370
2021-04-07bpf, sockmap: Fix sk->prot unhash op resetJohn Fastabend1-1/+6
In '4da6a196f93b1' we fixed a potential unhash loop caused when a TLS socket in a sockmap was removed from the sockmap. This happened because the unhash operation on the TLS ctx continued to point at the sockmap implementation of unhash even though the psock has already been removed. The sockmap unhash handler when a psock is removed does the following, void sock_map_unhash(struct sock *sk) { void (*saved_unhash)(struct sock *sk); struct sk_psock *psock; rcu_read_lock(); psock = sk_psock(sk); if (unlikely(!psock)) { rcu_read_unlock(); if (sk->sk_prot->unhash) sk->sk_prot->unhash(sk); return; } [...] } The unlikely() case is there to handle the case where psock is detached but the proto ops have not been updated yet. But, in the above case with TLS and removed psock we never fixed sk_prot->unhash() and unhash() points back to sock_map_unhash resulting in a loop. To fix this we added this bit of code, static inline void sk_psock_restore_proto(struct sock *sk, struct sk_psock *psock) { sk->sk_prot->unhash = psock->saved_unhash; This will set the sk_prot->unhash back to its saved value. This is the correct callback for a TLS socket that has been removed from the sock_map. Unfortunately, this also overwrites the unhash pointer for all psocks. We effectively break sockmap unhash handling for any future socks. Omitting the unhash operation will leave stale entries in the map if a socket transition through unhash, but does not do close() op. To fix set unhash correctly before calling into tls_update. This way the TLS enabled socket will point to the saved unhash() handler. Fixes: 4da6a196f93b1 ("bpf: Sockmap/tls, during free we may call tcp_bpf_unhash() in loop") Reported-by: Cong Wang <[email protected]> Reported-by: Lorenz Bauer <[email protected]> Suggested-by: Cong Wang <[email protected]> Signed-off-by: John Fastabend <[email protected]> Signed-off-by: Daniel Borkmann <[email protected]> Link: https://lore.kernel.org/bpf/161731441904.68884.15593917809745631972.stgit@john-XPS-13-9370
2021-04-06tipc: increment the tmp aead refcnt before attaching itXin Long1-1/+2
Li Shuang found a NULL pointer dereference crash in her testing: [] BUG: unable to handle kernel NULL pointer dereference at 0000000000000020 [] RIP: 0010:tipc_crypto_rcv_complete+0xc8/0x7e0 [tipc] [] Call Trace: [] <IRQ> [] tipc_crypto_rcv+0x2d9/0x8f0 [tipc] [] tipc_rcv+0x2fc/0x1120 [tipc] [] tipc_udp_recv+0xc6/0x1e0 [tipc] [] udpv6_queue_rcv_one_skb+0x16a/0x460 [] udp6_unicast_rcv_skb.isra.35+0x41/0xa0 [] ip6_protocol_deliver_rcu+0x23b/0x4c0 [] ip6_input+0x3d/0xb0 [] ipv6_rcv+0x395/0x510 [] __netif_receive_skb_core+0x5fc/0xc40 This is caused by NULL returned by tipc_aead_get(), and then crashed when dereferencing it later in tipc_crypto_rcv_complete(). This might happen when tipc_crypto_rcv_complete() is called by two threads at the same time: the tmp attached by tipc_crypto_key_attach() in one thread may be released by the one attached by that in the other thread. This patch is to fix it by incrementing the tmp's refcnt before attaching it instead of calling tipc_aead_get() after attaching it. Fixes: fc1b6d6de220 ("tipc: introduce TIPC encryption & authentication") Reported-by: Li Shuang <[email protected]> Signed-off-by: Xin Long <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2021-04-06virtio_net: Do not pull payload in skb->headEric Dumazet2-8/+16
Xuan Zhuo reported that commit 3226b158e67c ("net: avoid 32 x truesize under-estimation for tiny skbs") brought a ~10% performance drop. The reason for the performance drop was that GRO was forced to chain sk_buff (using skb_shinfo(skb)->frag_list), which uses more memory but also cause packet consumers to go over a lot of overhead handling all the tiny skbs. It turns out that virtio_net page_to_skb() has a wrong strategy : It allocates skbs with GOOD_COPY_LEN (128) bytes in skb->head, then copies 128 bytes from the page, before feeding the packet to GRO stack. This was suboptimal before commit 3226b158e67c ("net: avoid 32 x truesize under-estimation for tiny skbs") because GRO was using 2 frags per MSS, meaning we were not packing MSS with 100% efficiency. Fix is to pull only the ethernet header in page_to_skb() Then, we change virtio_net_hdr_to_skb() to pull the missing headers, instead of assuming they were already pulled by callers. This fixes the performance regression, but could also allow virtio_net to accept packets with more than 128bytes of headers. Many thanks to Xuan Zhuo for his report, and his tests/help. Fixes: 3226b158e67c ("net: avoid 32 x truesize under-estimation for tiny skbs") Reported-by: Xuan Zhuo <[email protected]> Link: https://www.spinics.net/lists/netdev/msg731397.html Co-Developed-by: Xuan Zhuo <[email protected]> Signed-off-by: Xuan Zhuo <[email protected]> Signed-off-by: Eric Dumazet <[email protected]> Cc: "Michael S. Tsirkin" <[email protected]> Cc: Jason Wang <[email protected]> Cc: [email protected] Acked-by: Jason Wang <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2021-04-06net: broadcom: bcm4908enet: Fix a double free in bcm4908_enet_dma_allocLv Yunlong1-0/+1
In bcm4908_enet_dma_alloc, if callee bcm4908_dma_alloc_buf_descs() failed, it will free the ring->cpu_addr by dma_free_coherent() and return error. Then bcm4908_enet_dma_free() will be called, and free the same cpu_addr by dma_free_coherent() again. My patch set ring->cpu_addr to NULL after it is freed in bcm4908_dma_alloc_buf_descs() to avoid the double free. Fixes: 4feffeadbcb2e ("net: broadcom: bcm4908enet: add BCM4908 controller driver") Signed-off-by: Lv Yunlong <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2021-04-06Merge tag 'mvebu-fixes-5.12-1' of ↵Arnd Bergmann2-4/+6
git://git.kernel.org/pub/scm/linux/kernel/git/gclement/mvebu into arm/fixes mvebu fixes for 5.12 (part 1) 2 fixes on on turris-omnia (Armada 38x based:) - Fix storm interrupt - Enable hardware buffer management as it should be Unbreak AHCI on all Marvell Armada 7k8k / CN913x platforms * tag 'mvebu-fixes-5.12-1' of git://git.kernel.org/pub/scm/linux/kernel/git/gclement/mvebu: ARM: dts: turris-omnia: configure LED[2]/INTn pin as interrupt pin ARM: dts: turris-omnia: fix hardware buffer management Revert "arm64: dts: marvell: armada-cp110: Switch to per-port SATA interrupts" Link: https://lore.kernel.org/r/87a6qgctit.fsf@BL-laptop Signed-off-by: Arnd Bergmann <[email protected]>
2021-04-06net: mac802154: Fix general protection faultPavel Skripkin1-1/+1
syzbot found general protection fault in crypto_destroy_tfm()[1]. It was caused by wrong clean up loop in llsec_key_alloc(). If one of the tfm array members is in IS_ERR() range it will cause general protection fault in clean up function [1]. Call Trace: crypto_free_aead include/crypto/aead.h:191 [inline] [1] llsec_key_alloc net/mac802154/llsec.c:156 [inline] mac802154_llsec_key_add+0x9e0/0xcc0 net/mac802154/llsec.c:249 ieee802154_add_llsec_key+0x56/0x80 net/mac802154/cfg.c:338 rdev_add_llsec_key net/ieee802154/rdev-ops.h:260 [inline] nl802154_add_llsec_key+0x3d3/0x560 net/ieee802154/nl802154.c:1584 genl_family_rcv_msg_doit+0x228/0x320 net/netlink/genetlink.c:739 genl_family_rcv_msg net/netlink/genetlink.c:783 [inline] genl_rcv_msg+0x328/0x580 net/netlink/genetlink.c:800 netlink_rcv_skb+0x153/0x420 net/netlink/af_netlink.c:2502 genl_rcv+0x24/0x40 net/netlink/genetlink.c:811 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 Signed-off-by: Pavel Skripkin <[email protected]> Reported-by: [email protected] Acked-by: Alexander Aring <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Stefan Schmidt <[email protected]>
2021-04-06net: ieee802154: stop dump llsec params for monitorsAlexander Aring1-0/+5
This patch stops dumping llsec params for monitors which we don't support yet. Otherwise we will access llsec mib which isn't initialized for monitors. Reported-by: [email protected] Signed-off-by: Alexander Aring <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Stefan Schmidt <[email protected]>
2021-04-06net: ieee802154: forbid monitor for del llsec seclevelAlexander Aring1-0/+3
This patch forbids to del llsec seclevel for monitor interfaces which we don't support yet. Otherwise we will access llsec mib which isn't initialized for monitors. Reported-by: [email protected] Signed-off-by: Alexander Aring <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Stefan Schmidt <[email protected]>
2021-04-06i2c: exynos5: correct top kerneldocKrzysztof Kozlowski1-1/+1
The top comment is not a kerneldoc, as W=1 build reports: drivers/i2c/busses/i2c-exynos5.c:39: warning: expecting prototype for i2c(). Prototype was for HSI2C_CTL() instead Signed-off-by: Krzysztof Kozlowski <[email protected]> Signed-off-by: Wolfram Sang <[email protected]>
2021-04-06net: ieee802154: forbid monitor for add llsec seclevelAlexander Aring1-0/+3
This patch forbids to add llsec seclevel for monitor interfaces which we don't support yet. Otherwise we will access llsec mib which isn't initialized for monitors. Signed-off-by: Alexander Aring <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Stefan Schmidt <[email protected]>
2021-04-06net: ieee802154: stop dump llsec seclevels for monitorsAlexander Aring1-0/+5
This patch stops dumping llsec seclevels for monitors which we don't support yet. Otherwise we will access llsec mib which isn't initialized for monitors. Signed-off-by: Alexander Aring <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Stefan Schmidt <[email protected]>
2021-04-06net: ieee802154: forbid monitor for del llsec devkeyAlexander Aring1-0/+3
This patch forbids to del llsec devkey for monitor interfaces which we don't support yet. Otherwise we will access llsec mib which isn't initialized for monitors. Signed-off-by: Alexander Aring <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Stefan Schmidt <[email protected]>
2021-04-06net: ieee802154: forbid monitor for add llsec devkeyAlexander Aring1-0/+3
This patch forbids to add llsec devkey for monitor interfaces which we don't support yet. Otherwise we will access llsec mib which isn't initialized for monitors. Signed-off-by: Alexander Aring <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Stefan Schmidt <[email protected]>
2021-04-06net: ieee802154: stop dump llsec devkeys for monitorsAlexander Aring1-0/+5
This patch stops dumping llsec devkeys for monitors which we don't support yet. Otherwise we will access llsec mib which isn't initialized for monitors. Signed-off-by: Alexander Aring <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Stefan Schmidt <[email protected]>
2021-04-06net: ieee802154: forbid monitor for del llsec devAlexander Aring1-0/+3
This patch forbids to del llsec dev for monitor interfaces which we don't support yet. Otherwise we will access llsec mib which isn't initialized for monitors. Signed-off-by: Alexander Aring <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Stefan Schmidt <[email protected]>
2021-04-06net: ieee802154: forbid monitor for add llsec devAlexander Aring1-0/+3
This patch forbids to add llsec dev for monitor interfaces which we don't support yet. Otherwise we will access llsec mib which isn't initialized for monitors. Signed-off-by: Alexander Aring <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Stefan Schmidt <[email protected]>
2021-04-06platform/x86: intel-hid: Fix spurious wakeups caused by tablet-mode events ↵Hans de Goede1-7/+9
during suspend Some devices send (duplicate) tablet-mode events when moved around even though the mode has not changed; and they do this even when suspended. Change the tablet-mode event handling when priv->wakeup_mode is set to update the switch state in case it changed and then return immediately (without calling pm_wakeup_hard_event()) to avoid spurious wakeups. BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=212537 Fixes: 537b0dd4729e ("platform/x86: intel-hid: Add support for SW_TABLET_MODE") Signed-off-by: Hans de Goede <[email protected]> Reviewed-by: Elia Devito <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2021-04-06net: ieee802154: stop dump llsec devs for monitorsAlexander Aring1-0/+5
This patch stops dumping llsec devs for monitors which we don't support yet. Otherwise we will access llsec mib which isn't initialized for monitors. Signed-off-by: Alexander Aring <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Stefan Schmidt <[email protected]>
2021-04-06net: ieee802154: forbid monitor for del llsec keyAlexander Aring1-0/+3
This patch forbids to del llsec key for monitor interfaces which we don't support yet. Otherwise we will access llsec mib which isn't initialized for monitors. Signed-off-by: Alexander Aring <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Stefan Schmidt <[email protected]>
2021-04-06net: ieee802154: forbid monitor for add llsec keyAlexander Aring1-0/+3
This patch forbids to add llsec key for monitor interfaces which we don't support yet. Otherwise we will access llsec mib which isn't initialized for monitors. Signed-off-by: Alexander Aring <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Stefan Schmidt <[email protected]>
2021-04-06net: ieee802154: stop dump llsec keys for monitorsAlexander Aring1-0/+5
This patch stops dumping llsec keys for monitors which we don't support yet. Otherwise we will access llsec mib which isn't initialized for monitors. Signed-off-by: Alexander Aring <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Stefan Schmidt <[email protected]>
2021-04-06net: ieee802154: forbid monitor for set llsec paramsAlexander Aring1-0/+3
This patch forbids to set llsec params for monitor interfaces which we don't support yet. Reported-by: [email protected] Signed-off-by: Alexander Aring <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Stefan Schmidt <[email protected]>
2021-04-06Merge branch 'fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfsLinus Torvalds2-6/+7
Pull fs fixes from Al Viro: "Fairly old hostfs bug (in setups that are not used by anyone, apparently) + fix for this cycle regression: extra dput/mntput in LOOKUP_CACHED failure handling" * 'fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs: Make sure nd->path.mnt and nd->path.dentry are always valid pointers hostfs: fix memory handling in follow_link()
2021-04-06Make sure nd->path.mnt and nd->path.dentry are always valid pointersAl Viro1-2/+4
Initialize them in set_nameidata() and make sure that terminate_walk() clears them once the pointers become potentially invalid (i.e. we leave RCU mode or drop them in non-RCU one). Currently we have "path_init() always initializes them and nobody accesses them outside of path_init()/terminate_walk() segments", which is asking for trouble. With that change we would have nd->path.{mnt,dentry} 1) always valid - NULL or pointing to currently allocated objects. 2) non-NULL while we are successfully walking 3) NULL when we are not walking at all 4) contributing to refcounts whenever non-NULL outside of RCU mode. Fixes: 6c6ec2b0a3e0 ("fs: add support for LOOKUP_CACHED") Reported-by: [email protected] Tested-by: Christian Brauner <[email protected]> Signed-off-by: Al Viro <[email protected]>
2021-04-06drm/panel: panel-dsi-cm: disable TE for nowSebastian Reichel1-3/+9
Disable TE for Droid 4 panel, since implementation is currently broken. Also disable it for N950 panel, which is untested. Reported-by: Tony Lindgren <[email protected]> Reported-by: Tomi Valkeinen <[email protected]> Fixes: 4c1b935fea54 ("drm/omap: dsi: move TE GPIO handling into core") Signed-off-by: Sebastian Reichel <[email protected]> Tested-by: Tony Lindgren <[email protected]> Acked-by: Thierry Reding <[email protected]> Signed-off-by: Tomi Valkeinen <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2021-04-06parisc: math-emu: Few spelling fixes in the file fpu.hBhaskar Chowdhury1-29/+3
with some additional cleanups by Helge. Signed-off-by: Bhaskar Chowdhury <[email protected]> Acked-by: Randy Dunlap <[email protected]> Signed-off-by: Helge Deller <[email protected]>
2021-04-06parisc: avoid a warning on u8 cast for cmpxchg on u8 pointersGao Xiang1-1/+1
commit b344d6a83d01 ("parisc: add support for cmpxchg on u8 pointers") can generate a sparse warning ("cast truncates bits from constant value"), which has been reported several times [1] [2] [3]. The original code worked as expected, but anyway, let silence such sparse warning as what others did [4]. [1] https://lore.kernel.org/r/[email protected] [2] https://lore.kernel.org/r/[email protected] [3] https://lore.kernel.org/r/202008210829.KVwn7Xeh%[email protected] [4] https://lore.kernel.org/r/[email protected] Cc: Liam Beguin <[email protected]> Cc: Helge Deller <[email protected]> Cc: [email protected] # v5.8+ Signed-off-by: Gao Xiang <[email protected]> Signed-off-by: Helge Deller <[email protected]>
2021-04-06ALSA: hda/conexant: Apply quirk for another HP ZBook G5 modelTakashi Iwai1-0/+1
There is another HP ZBook G5 model with the PCI SSID 103c:844f that requires the same quirk for controlling the mute LED. Add the corresponding entry to the quirk table. BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=212407 Cc: <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Takashi Iwai <[email protected]>
2021-04-06can: mcp251x: fix support for half duplex SPI host controllersMarc Kleine-Budde1-6/+18
Some SPI host controllers do not support full-duplex SPI transfers. The function mcp251x_spi_trans() does a full duplex transfer. It is used in several places in the driver, where a TX half duplex transfer is sufficient. To fix support for half duplex SPI host controllers, this patch introduces a new function mcp251x_spi_write() and changes all callers that do a TX half duplex transfer to use mcp251x_spi_write(). Fixes: e0e25001d088 ("can: mcp251x: add support for half duplex controllers") Link: https://lore.kernel.org/r/[email protected] Cc: Tim Harvey <[email protected]> Tested-By: Tim Harvey <[email protected]> Reported-by: Gerhard Bertelsmann <[email protected]> Signed-off-by: Marc Kleine-Budde <[email protected]>
2021-04-06iwlwifi: mvm: fix beacon protection checksJohannes Berg1-5/+12
Unfortunately, since beacon protection isn't fully available yet, we didn't notice that there are problems with it and that the replay detection isn't working correctly. We were relying only on mac80211, since iwl_mvm_rx_crypto() exits when !ieee80211_has_protected(), which is of course true for protected (but not encrypted) management frames. Fix this to properly detect protected (but not encrypted) management frames and handle them - we continue to only care about beacons since for others everything can and will be checked in mac80211. Signed-off-by: Johannes Berg <[email protected]> Fixes: b1fdc2505abc ("iwlwifi: mvm: advertise BIGTK client support if available") Signed-off-by: Luca Coelho <[email protected]> Signed-off-by: Kalle Valo <[email protected]> Link: https://lore.kernel.org/r/iwlwifi.20210326125611.23c990843369.I09c262a8f6f9852cc8f513cdcb31a7f8f87dd8af@changeid
2021-04-06iwlwifi: mvm: rfi: don't lock mvm->mutex when sending config commandGregory Greenman2-5/+8
The mutex is already locked in iwl_mvm_mac_start. Signed-off-by: Gregory Greenman <[email protected]> Fixes: 21254908cbe9 ("iwlwifi: mvm: add RFI-M support") Signed-off-by: Luca Coelho <[email protected]> Signed-off-by: Kalle Valo <[email protected]> Link: https://lore.kernel.org/r/iwlwifi.20210326125611.703288ea058d.I82a0312389032d07c3b478bef3e938e06bfa7df6@changeid
2021-04-06iwlwifi: pcie: add support for So-F devicesLuca Coelho2-1/+26
We have a new type of device that has a different MAC ID, but is otherwise identical to So devices. Add rules to match this new ID accordingly. Signed-off-by: Luca Coelho <[email protected]> Signed-off-by: Kalle Valo <[email protected]> Link: https://lore.kernel.org/r/iwlwifi.20210326125611.4feea3560def.I2b6ef794c2073a18779dd40fb53f8c942d1ab42d@changeid
2021-04-06iwlwifi: fw: fix notification wait lockingJohannes Berg1-5/+5
Since we now call iwl_notification_wait_notify() from the NAPI poll in soft-IRQ, we get a (valid) lockdep complaint that we could get a deadlock by taking the spinlock from sleeping context and then getting the soft-IRQ that also tries to take it (in NAPI polling). Fix this by disabling soft-IRQs for this lock. Signed-off-by: Johannes Berg <[email protected]> Fixes: 25edc8f259c7 ("iwlwifi: pcie: properly implement NAPI") Signed-off-by: Luca Coelho <[email protected]> Signed-off-by: Kalle Valo <[email protected]> Link: https://lore.kernel.org/r/iwlwifi.20210326125611.c3b2e3d6b58b.Ic56f351d04674df70567bab0269cba91bdbc853c@changeid
2021-04-06iwlwifi: add support for Qu with AX201 deviceMatt Chen1-0/+1
Add this specific Samsung AX201 sku to driver so it can be detected and initialized successfully. Signed-off-by: Matt Chen <[email protected]> Signed-off-by: Luca Coelho <[email protected]> Signed-off-by: Kalle Valo <[email protected]> Link: https://lore.kernel.org/r/iwlwifi.20210326125611.30b622037714.Id9fd709cf1c8261c097bbfd7453f6476077dcafc@changeid
2021-04-06iwlwifi: pcie: properly set LTR workarounds on 22000 devicesJohannes Berg3-32/+37
As the context info gen3 code is only called for >=AX210 devices (from iwl_trans_pcie_gen2_start_fw()) the code there to set LTR on 22000 devices cannot actually do anything (22000 < AX210). Fix this by moving the LTR code to iwl_trans_pcie_gen2_start_fw() where it can handle both devices. This then requires that we kick the firmware only after that rather than doing it from the context info code. Note that this again had a dead branch in gen3 code, which I've removed here. Signed-off-by: Johannes Berg <[email protected]> Fixes: ed0022da8bd9 ("iwlwifi: pcie: set LTR on more devices") Signed-off-by: Luca Coelho <[email protected]> Signed-off-by: Kalle Valo <[email protected]> Link: https://lore.kernel.org/r/iwlwifi.20210326125611.675486178ed1.Ib61463aba6920645059e366dcdca4c4c77f0ff58@changeid
2021-04-06iwlwifi: fix 11ax disabled bit in the regulatory capability flagsLuca Coelho1-1/+1
When version 2 of the regulatory capability flags API was implemented, the flag to disable 11ax was defined as bit 13, but this was later changed and the bit remained as bit 10, like in version 1. This was never changed in the driver, so we were checking for the wrong bit in newer devices. Fix it. Signed-off-by: Luca Coelho <[email protected]> Fixes: e27c506a985c ("iwlwifi: regulatory: regulatory capabilities api change") Signed-off-by: Luca Coelho <[email protected]> Signed-off-by: Kalle Valo <[email protected]> Link: https://lore.kernel.org/r/iwlwifi.20210326125611.6d28516b59cd.Id0248d5e4662695254f49ce37b0268834ed52918@changeid
2021-04-06parisc: parisc-agp requires SBA IOMMU driverHelge Deller1-1/+1
Add a dependency to the SBA IOMMU driver to avoid: ERROR: modpost: "sba_list" [drivers/char/agp/parisc-agp.ko] undefined! Reported-by: kernel test robot <[email protected]> Cc: [email protected] Signed-off-by: Helge Deller <[email protected]>
2021-04-06parisc: Remove duplicate struct task_struct declarationWan Jiabing1-1/+0
struct task_struct is declared twice. One has been declared at 154th line. Remove the duplicate. Signed-off-by: Wan Jiabing <[email protected]> Signed-off-by: Helge Deller <[email protected]>
2021-04-05scsi: scsi_transport_srp: Don't block target in SRP_PORT_LOST stateMartin Wilck1-1/+1
rport_dev_loss_timedout() sets the rport state to SRP_PORT_LOST and the SCSI target state to SDEV_TRANSPORT_OFFLINE. If this races with srp_reconnect_work(), a warning is printed: Mar 27 18:48:07 ictm1604s01h4 kernel: dev_loss_tmo expired for SRP port-18:1 / host18. Mar 27 18:48:07 ictm1604s01h4 kernel: ------------[ cut here ]------------ Mar 27 18:48:07 ictm1604s01h4 kernel: scsi_internal_device_block(18:0:0:100) failed: ret = -22 Mar 27 18:48:07 ictm1604s01h4 kernel: Call Trace: Mar 27 18:48:07 ictm1604s01h4 kernel: ? scsi_target_unblock+0x50/0x50 [scsi_mod] Mar 27 18:48:07 ictm1604s01h4 kernel: starget_for_each_device+0x80/0xb0 [scsi_mod] Mar 27 18:48:07 ictm1604s01h4 kernel: target_block+0x24/0x30 [scsi_mod] Mar 27 18:48:07 ictm1604s01h4 kernel: device_for_each_child+0x57/0x90 Mar 27 18:48:07 ictm1604s01h4 kernel: srp_reconnect_rport+0xe4/0x230 [scsi_transport_srp] Mar 27 18:48:07 ictm1604s01h4 kernel: srp_reconnect_work+0x40/0xc0 [scsi_transport_srp] Avoid this by not trying to block targets for rports in SRP_PORT_LOST state. Link: https://lore.kernel.org/r/[email protected] Reviewed-by: Bart Van Assche <[email protected]> Signed-off-by: Martin Wilck <[email protected]> Signed-off-by: Martin K. Petersen <[email protected]>
2021-04-05scsi: target: iscsi: Fix zero tag inside a trace eventRoman Bolshakov1-2/+1
target_sequencer_start event is triggered inside target_cmd_init_cdb(). se_cmd.tag is not initialized with ITT at the moment so the event always prints zero tag. Link: https://lore.kernel.org/r/[email protected] Cc: [email protected] # 5.10+ Reviewed-by: Mike Christie <[email protected]> Signed-off-by: Roman Bolshakov <[email protected]> Signed-off-by: Martin K. Petersen <[email protected]>
Powered by cgit, Gruvboxed by Blaster4385.