aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2023-01-27spi: dw: Fix wrong FIFO level setting for long xfersSerge Semin1-1/+1
Due to using the u16 type in the min_t() macros the SPI transfer length will be cast to word before participating in the conditional statement implied by the macro. Thus if the transfer length is greater than 64KB the Tx/Rx FIFO threshold level value will be determined by the leftover of the truncated after the type-case length. In the worst case it will cause the dramatical performance drop due to the "Tx FIFO Empty" or "Rx FIFO Full" interrupts triggered on each xfer word sent/received to/from the bus. The problem can be easily fixed by specifying the unsigned int type in the min_t() macros thus preventing the possible data loss. Fixes: ea11370fffdf ("spi: dw: get TX level without an additional variable") Reported-by: Sergey Nazarov <[email protected]> Signed-off-by: Serge Semin <[email protected]> Reviewed-by: Andy Shevchenko <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]>
2023-01-27ovl: fail on invalid uid/gid mapping at copy upMiklos Szeredi1-0/+4
If st_uid/st_gid doesn't have a mapping in the mounter's user_ns, then copy-up should fail, just like it would fail if the mounter task was doing the copy using "cp -a". There's a corner case where the "cp -a" would succeed but copy up fail: if there's a mapping of the invalid uid/gid (65534 by default) in the user namespace. This is because stat(2) will return this value if the mapping doesn't exist in the current user_ns and "cp -a" will in turn be able to create a file with this uid/gid. This behavior would be inconsistent with POSIX ACL's, which return -1 for invalid uid/gid which result in a failed copy. For consistency and simplicity fail the copy of the st_uid/st_gid are invalid. Fixes: 459c7c565ac3 ("ovl: unprivieged mounts") Cc: <[email protected]> # v5.11 Signed-off-by: Miklos Szeredi <[email protected]> Reviewed-by: Christian Brauner <[email protected]> Reviewed-by: Seth Forshee <[email protected]>
2023-01-27ovl: fix tmpfile leakMiklos Szeredi1-1/+1
Missed an error cleanup. Reported-by: [email protected] Fixes: 2b1a77461f16 ("ovl: use vfs_tmpfile_open() helper") Cc: <[email protected]> # v6.1 Signed-off-by: Miklos Szeredi <[email protected]>
2023-01-27btrfs: raid56: make error_bitmap update atomicQu Wenruo1-2/+10
In the rework of raid56 code, there is very limited concurrency in the endio context. Most of the work is done inside the sectors arrays, which different bios will never touch the same sector. But there is a concurrency here for error_bitmap. Both read and write endio functions need to touch them, and we can have multiple write bios touching the same error bitmap if they all hit some errors. Here we fix the unprotected bitmap operation by going set_bit() in a loop. Since we have a very small ceiling of the sectors (at most 16 sectors), such set_bit() in a loop should be very acceptable. Fixes: 2942a50dea74 ("btrfs: raid56: introduce btrfs_raid_bio::error_bitmap") Reviewed-by: Christoph Hellwig <[email protected]> Signed-off-by: Qu Wenruo <[email protected]> Signed-off-by: David Sterba <[email protected]>
2023-01-27btrfs: send: limit number of clones and allocated memory sizeDavid Sterba1-3/+3
The arg->clone_sources_count is u64 and can trigger a warning when a huge value is passed from user space and a huge array is allocated. Limit the allocated memory to 8MiB (can be increased if needed), which in turn limits the number of clone sources to 8M / sizeof(struct clone_root) = 8M / 40 = 209715. Real world number of clones is from tens to hundreds, so this is future proof. Reported-by: [email protected] Signed-off-by: David Sterba <[email protected]>
2023-01-27io_uring: always prep_async for drain requestsDylan Yudaken1-10/+8
Drain requests all go through io_drain_req, which has a quick exit in case there is nothing pending (ie the drain is not useful). In that case it can run the issue the request immediately. However for safety it queues it through task work. The problem is that in this case the request is run asynchronously, but the async work has not been prepared through io_req_prep_async. This has not been a problem up to now, as the task work always would run before returning to userspace, and so the user would not have a chance to race with it. However - with IORING_SETUP_DEFER_TASKRUN - this is no longer the case and the work might be defered, giving userspace a chance to change data being referred to in the request. Instead _always_ prep_async for drain requests, which is simpler anyway and removes this issue. Cc: [email protected] Fixes: c0e0d6ba25f1 ("io_uring: add IORING_SETUP_DEFER_TASKRUN") Signed-off-by: Dylan Yudaken <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jens Axboe <[email protected]>
2023-01-27dma-buf: actually set signaling bit for private stub fencesDanilo Krummrich1-1/+1
In dma_fence_allocate_private_stub() set the signaling bit of the newly allocated private stub fence rather than the signaling bit of the shared dma_fence_stub. Cc: <[email protected]> # v6.1 Fixes: c85d00d4fd8b ("dma-buf: set signaling bit for the stub fence") Reviewed-by: Christian König <[email protected]> Signed-off-by: Danilo Krummrich <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-01-27tools: gpio: fix -c option of gpio-event-monIvo Borisov Shopov1-0/+1
Following line should listen for a rising edge and exit after the first one since '-c 1' is provided. # gpio-event-mon -n gpiochip1 -o 0 -r -c 1 It works with kernel 4.19 but it doesn't work with 5.10. In 5.10 the above command doesn't exit after the first rising edge it keep listening for an event forever. The '-c 1' is not taken into an account. The problem is in commit 62757c32d5db ("tools: gpio: add multi-line monitoring to gpio-event-mon"). Before this commit the iterator 'i' in monitor_device() is used for counting of the events (loops). In the case of the above command (-c 1) we should start from 0 and increment 'i' only ones and hit the 'break' statement and exit the process. But after the above commit counting doesn't start from 0, it start from 1 when we listen on one line. It is because 'i' is used from one more purpose, counting of lines (num_lines) and it isn't restore to 0 after following code for (i = 0; i < num_lines; i++) gpiotools_set_bit(&values.mask, i); Restore the initial value of the iterator to 0 in order to allow counting of loops to work for any cases. Fixes: 62757c32d5db ("tools: gpio: add multi-line monitoring to gpio-event-mon") Signed-off-by: Ivo Borisov Shopov <[email protected]> Reviewed-by: Andy Shevchenko <[email protected]> [Bartosz: tweak the commit message] Signed-off-by: Bartosz Golaszewski <[email protected]>
2023-01-27gpio: ep93xx: remove unused variableArnd Bergmann1-2/+0
This one was left behind by a previous cleanup patch: drivers/gpio/gpio-ep93xx.c: In function 'ep93xx_gpio_add_bank': drivers/gpio/gpio-ep93xx.c:366:34: error: unused variable 'ic' [-Werror=unused-variable] Fixes: 216f37366e86 ("gpio: ep93xx: Make irqchip immutable") Signed-off-by: Arnd Bergmann <[email protected]> Signed-off-by: Bartosz Golaszewski <[email protected]>
2023-01-27pinctrl: single: fix potential NULL dereferenceMaxim Korotkov1-0/+2
Added checking of pointer "function" in pcs_set_mux(). pinmux_generic_get_function() can return NULL and the pointer "function" was dereferenced without checking against NULL. Found by Linux Verification Center (linuxtesting.org) with SVACE. Fixes: 571aec4df5b7 ("pinctrl: single: Use generic pinmux helpers for managing functions") Signed-off-by: Maxim Korotkov <[email protected]> Reviewed-by: Tony Lindgren <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Linus Walleij <[email protected]>
2023-01-27pinctrl: amd: Fix debug output for debounce timeMario Limonciello1-0/+1
If one GPIO has debounce enabled but future GPIOs in the list don't have debounce the time never gets reset and shows wrong value. Signed-off-by: Mario Limonciello <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Linus Walleij <[email protected]>
2023-01-27pinctrl: aspeed: Fix confusing types in return valueJoel Stanley1-1/+1
The function signature is int, but we return a bool. Instead return a negative errno as the kerneldoc suggests. Fixes: 4d3d0e4272d8 ("pinctrl: Add core support for Aspeed SoCs") Signed-off-by: Joel Stanley <[email protected]> Reviewed-by: Andrew Jeffery <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Linus Walleij <[email protected]>
2023-01-27vdpa: ifcvf: Do proper cleanup if IFCVF init failsTanmay Bhushan1-1/+1
ifcvf_mgmt_dev leaks memory if it is not freed before returning. Call is made to correct return statement so memory does not leak. ifcvf_init_hw does not take care of this so it is needed to do it here. Signed-off-by: Tanmay Bhushan <[email protected]> Message-Id: <[email protected]> Signed-off-by: Michael S. Tsirkin <[email protected]> Acked-by: Jason Wang <[email protected]> Acked-by: Zhu Lingshan <[email protected]>
2023-01-27vhost-scsi: unbreak any layout for responseJason Wang1-4/+17
Al Viro said: """ Since "vhost/scsi: fix reuse of &vq->iov[out] in response" we have this: cmd->tvc_resp_iov = vq->iov[vc.out]; cmd->tvc_in_iovs = vc.in; combined with iov_iter_init(&iov_iter, ITER_DEST, &cmd->tvc_resp_iov, cmd->tvc_in_iovs, sizeof(v_rsp)); in vhost_scsi_complete_cmd_work(). We used to have ->tvc_resp_iov _pointing_ to vq->iov[vc.out]; back then iov_iter_init() asked to set an iovec-backed iov_iter over the tail of vq->iov[], with length being the amount of iovecs in the tail. Now we have a copy of one element of that array. Fortunately, the members following it in the containing structure are two non-NULL kernel pointers, so copy_to_iter() will not copy anything beyond the first iovec - kernel pointer is not (on the majority of architectures) going to be accepted by access_ok() in copyout() and it won't be skipped since the "length" (in reality - another non-NULL kernel pointer) won't be zero. So it's not going to give a guest-to-qemu escalation, but it's definitely a bug. Frankly, my preference would be to verify that the very first iovec is long enough to hold rsp_size. Due to the above, any users that try to give us vq->iov[vc.out].iov_len < sizeof(struct virtio_scsi_cmd_resp) would currently get a failure in vhost_scsi_complete_cmd_work() anyway. """ However, the spec doesn't say anything about the legacy descriptor layout for the respone. So this patch tries to not assume the response to reside in a single separate descriptor which is what commit 79c14141a487 ("vhost/scsi: Convert completion path to use") tries to achieve towards to ANY_LAYOUT. This is done by allocating and using dedicate resp iov in the command. To be safety, start with UIO_MAXIOV to be consistent with the limitation that we advertise to the vhost_get_vq_desc(). Testing with the hacked virtio-scsi driver that use 1 descriptor for 1 byte in the response. Reported-by: Al Viro <[email protected]> Cc: Benjamin Coddington <[email protected]> Cc: Nicholas Bellinger <[email protected]> Fixes: a77ec83a5789 ("vhost/scsi: fix reuse of &vq->iov[out] in response") Signed-off-by: Jason Wang <[email protected]> Message-Id: <[email protected]> Signed-off-by: Michael S. Tsirkin <[email protected]> Reviewed-by: Stefan Hajnoczi <[email protected]>
2023-01-27tools/virtio: fix the vringh test for virtio ring changesShunsuke Mie8-5/+45
Fix the build caused by missing kmsan_handle_dma() and is_power_of_2() that are used in drivers/virtio/virtio_ring.c. Signed-off-by: Shunsuke Mie <[email protected]> Message-Id: <[email protected]> Signed-off-by: Michael S. Tsirkin <[email protected]>
2023-01-27vhost/net: Clear the pending messages when the backend is removedEric Auger3-1/+6
When the vhost iotlb is used along with a guest virtual iommu and the guest gets rebooted, some MISS messages may have been recorded just before the reboot and spuriously executed by the virtual iommu after the reboot. As vhost does not have any explicit reset user API, VHOST_NET_SET_BACKEND looks a reasonable point where to clear the pending messages, in case the backend is removed. Export vhost_clear_msg() and call it in vhost_net_set_backend() when fd == -1. Signed-off-by: Eric Auger <[email protected]> Suggested-by: Jason Wang <[email protected]> Fixes: 6b1e6cc7855b0 ("vhost: new device IOTLB API") Message-Id: <[email protected]> Signed-off-by: Michael S. Tsirkin <[email protected]>
2023-01-27xfrm: annotate data-race around use_timeEric Dumazet2-9/+12
KCSAN reported multiple cpus can update use_time at the same time. Adds READ_ONCE()/WRITE_ONCE() annotations. Note that 32bit arches are not fully protected, but they will probably no longer be supported/used in 2106. BUG: KCSAN: data-race in __xfrm_policy_check / __xfrm_policy_check write to 0xffff88813e7ec108 of 8 bytes by interrupt on cpu 0: __xfrm_policy_check+0x6ae/0x17f0 net/xfrm/xfrm_policy.c:3664 __xfrm_policy_check2 include/net/xfrm.h:1174 [inline] xfrm_policy_check include/net/xfrm.h:1179 [inline] xfrm6_policy_check+0x2e9/0x320 include/net/xfrm.h:1189 udpv6_queue_rcv_one_skb+0x48/0xa30 net/ipv6/udp.c:703 udpv6_queue_rcv_skb+0x2d6/0x310 net/ipv6/udp.c:792 udp6_unicast_rcv_skb+0x16b/0x190 net/ipv6/udp.c:935 __udp6_lib_rcv+0x84b/0x9b0 net/ipv6/udp.c:1020 udpv6_rcv+0x4b/0x50 net/ipv6/udp.c:1133 ip6_protocol_deliver_rcu+0x99e/0x1020 net/ipv6/ip6_input.c:439 ip6_input_finish net/ipv6/ip6_input.c:484 [inline] NF_HOOK include/linux/netfilter.h:302 [inline] ip6_input+0xca/0x180 net/ipv6/ip6_input.c:493 dst_input include/net/dst.h:454 [inline] ip6_rcv_finish+0x1e9/0x2d0 net/ipv6/ip6_input.c:79 NF_HOOK include/linux/netfilter.h:302 [inline] ipv6_rcv+0x85/0x140 net/ipv6/ip6_input.c:309 __netif_receive_skb_one_core net/core/dev.c:5482 [inline] __netif_receive_skb+0x8b/0x1b0 net/core/dev.c:5596 process_backlog+0x23f/0x3b0 net/core/dev.c:5924 __napi_poll+0x65/0x390 net/core/dev.c:6485 napi_poll net/core/dev.c:6552 [inline] net_rx_action+0x37e/0x730 net/core/dev.c:6663 __do_softirq+0xf2/0x2c7 kernel/softirq.c:571 do_softirq+0xb1/0xf0 kernel/softirq.c:472 __local_bh_enable_ip+0x6f/0x80 kernel/softirq.c:396 __raw_read_unlock_bh include/linux/rwlock_api_smp.h:257 [inline] _raw_read_unlock_bh+0x17/0x20 kernel/locking/spinlock.c:284 wg_socket_send_skb_to_peer+0x107/0x120 drivers/net/wireguard/socket.c:184 wg_packet_create_data_done drivers/net/wireguard/send.c:251 [inline] wg_packet_tx_worker+0x142/0x360 drivers/net/wireguard/send.c:276 process_one_work+0x3d3/0x720 kernel/workqueue.c:2289 worker_thread+0x618/0xa70 kernel/workqueue.c:2436 kthread+0x1a9/0x1e0 kernel/kthread.c:376 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:308 write to 0xffff88813e7ec108 of 8 bytes by interrupt on cpu 1: __xfrm_policy_check+0x6ae/0x17f0 net/xfrm/xfrm_policy.c:3664 __xfrm_policy_check2 include/net/xfrm.h:1174 [inline] xfrm_policy_check include/net/xfrm.h:1179 [inline] xfrm6_policy_check+0x2e9/0x320 include/net/xfrm.h:1189 udpv6_queue_rcv_one_skb+0x48/0xa30 net/ipv6/udp.c:703 udpv6_queue_rcv_skb+0x2d6/0x310 net/ipv6/udp.c:792 udp6_unicast_rcv_skb+0x16b/0x190 net/ipv6/udp.c:935 __udp6_lib_rcv+0x84b/0x9b0 net/ipv6/udp.c:1020 udpv6_rcv+0x4b/0x50 net/ipv6/udp.c:1133 ip6_protocol_deliver_rcu+0x99e/0x1020 net/ipv6/ip6_input.c:439 ip6_input_finish net/ipv6/ip6_input.c:484 [inline] NF_HOOK include/linux/netfilter.h:302 [inline] ip6_input+0xca/0x180 net/ipv6/ip6_input.c:493 dst_input include/net/dst.h:454 [inline] ip6_rcv_finish+0x1e9/0x2d0 net/ipv6/ip6_input.c:79 NF_HOOK include/linux/netfilter.h:302 [inline] ipv6_rcv+0x85/0x140 net/ipv6/ip6_input.c:309 __netif_receive_skb_one_core net/core/dev.c:5482 [inline] __netif_receive_skb+0x8b/0x1b0 net/core/dev.c:5596 process_backlog+0x23f/0x3b0 net/core/dev.c:5924 __napi_poll+0x65/0x390 net/core/dev.c:6485 napi_poll net/core/dev.c:6552 [inline] net_rx_action+0x37e/0x730 net/core/dev.c:6663 __do_softirq+0xf2/0x2c7 kernel/softirq.c:571 do_softirq+0xb1/0xf0 kernel/softirq.c:472 __local_bh_enable_ip+0x6f/0x80 kernel/softirq.c:396 __raw_read_unlock_bh include/linux/rwlock_api_smp.h:257 [inline] _raw_read_unlock_bh+0x17/0x20 kernel/locking/spinlock.c:284 wg_socket_send_skb_to_peer+0x107/0x120 drivers/net/wireguard/socket.c:184 wg_packet_create_data_done drivers/net/wireguard/send.c:251 [inline] wg_packet_tx_worker+0x142/0x360 drivers/net/wireguard/send.c:276 process_one_work+0x3d3/0x720 kernel/workqueue.c:2289 worker_thread+0x618/0xa70 kernel/workqueue.c:2436 kthread+0x1a9/0x1e0 kernel/kthread.c:376 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:308 value changed: 0x0000000063c62d6f -> 0x0000000063c62d70 Reported by Kernel Concurrency Sanitizer on: CPU: 1 PID: 4185 Comm: kworker/1:2 Tainted: G W 6.2.0-rc4-syzkaller-00009-gd532dd102151-dirty #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/26/2022 Workqueue: wg-crypt-wg0 wg_packet_tx_worker Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Reported-by: syzbot <[email protected]> Signed-off-by: Eric Dumazet <[email protected]> Cc: Steffen Klassert <[email protected]> Cc: Arnd Bergmann <[email protected]> Acked-by: Arnd Bergmann <[email protected]> Signed-off-by: Steffen Klassert <[email protected]>
2023-01-27xfrm: consistently use time64_t in xfrm_timer_handler()Eric Dumazet1-4/+4
For some reason, blamed commit did the right thing in xfrm_policy_timer() but did not in xfrm_timer_handler() Fixes: 386c5680e2e8 ("xfrm: use time64_t for in-kernel timestamps") Signed-off-by: Eric Dumazet <[email protected]> Cc: Arnd Bergmann <[email protected]> Cc: Steffen Klassert <[email protected]> Acked-by: Arnd Bergmann <[email protected]> Signed-off-by: Steffen Klassert <[email protected]>
2023-01-27ALSA: memalloc: Workaround for Xen PVTakashi Iwai1-18/+69
We change recently the memalloc helper to use dma_alloc_noncontiguous() and the fallback to get_pages(). Although lots of issues with IOMMU (or non-IOMMU) have been addressed, but there seems still a regression on Xen PV. Interestingly, the only proper way to work is use dma_alloc_coherent(). The use of dma_alloc_coherent() for SG buffer was dropped as it's problematic on IOMMU systems. OTOH, Xen PV has a different way, and it's fine to use the dma_alloc_coherent(). This patch is a workaround for Xen PV. It consists of the following changes: - For Xen PV, use only the fallback allocation without dma_alloc_noncontiguous() - In the fallback allocation, use dma_alloc_coherent(); the DMA address from dma_alloc_coherent() is returned in get_addr ops - The DMA addresses are stored in an array; the first entry stores the number of allocated pages in lower bits, which are referred at releasing pages again Reported-by: Marek Marczykowski-Górecki <[email protected]> Tested-by: Marek Marczykowski-Górecki <[email protected]> Fixes: a8d302a0b770 ("ALSA: memalloc: Revive x86-specific WC page allocations again") Fixes: 9736a325137b ("ALSA: memalloc: Don't fall back for SG-buffer with IOMMU") Link: https://lore.kernel.org/r/[email protected] Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Takashi Iwai <[email protected]>
2023-01-26bpf: Fix the kernel crash caused by bpf_setsockopt().Kui-Feng Lee1-1/+0
The kernel crash was caused by a BPF program attached to the "lsm_cgroup/socket_sock_rcv_skb" hook, which performed a call to `bpf_setsockopt()` in order to set the TCP_NODELAY flag as an example. Flags like TCP_NODELAY can prompt the kernel to flush a socket's outgoing queue, and this hook "lsm_cgroup/socket_sock_rcv_skb" is frequently triggered by softirqs. The issue was that in certain circumstances, when `tcp_write_xmit()` was called to flush the queue, it would also allow BH (bottom-half) to run. This could lead to our program attempting to flush the same socket recursively, which caused a `skbuff` to be unlinked twice. `security_sock_rcv_skb()` is triggered by `tcp_filter()`. This occurs before the sock ownership is checked in `tcp_v4_rcv()`. Consequently, if a bpf program runs on `security_sock_rcv_skb()` while under softirq conditions, it may not possess the lock needed for `bpf_setsockopt()`, thus presenting an issue. The patch fixes this issue by ensuring that a BPF program attached to the "lsm_cgroup/socket_sock_rcv_skb" hook is not allowed to call `bpf_setsockopt()`. The differences from v1 are - changing commit log to explain holding the lock of the sock, - emphasizing that TCP_NODELAY is not the only flag, and - adding the fixes tag. v1: https://lore.kernel.org/bpf/[email protected]/ Signed-off-by: Kui-Feng Lee <[email protected]> Fixes: 9113d7e48e91 ("bpf: expose bpf_{g,s}etsockopt to lsm cgroup") Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Martin KaFai Lau <[email protected]>
2023-01-26scsi: Revert "scsi: core: map PQ=1, PDT=other values to ↵Martin K. Petersen1-4/+3
SCSI_SCAN_TARGET_PRESENT" This reverts commit 948e922fc44611ee2de0c89583ca958cb5307d36. Not all targets that return PQ=1 and PDT=0 should be ignored. While the SCSI spec is vague in this department, there appears to be a critical mass of devices which rely on devices being accessible with this combination of reported values. Fixes: 948e922fc446 ("scsi: core: map PQ=1, PDT=other values to SCSI_SCAN_TARGET_PRESENT") Link: https://lore.kernel.org/r/[email protected] Acked-by: Bart Van Assche <[email protected]> Acked-by: Martin Wilck <[email protected]> Acked-by: Hannes Reinecke <[email protected]> Signed-off-by: Martin K. Petersen <[email protected]>
2023-01-26scsi: core: Fix the scsi_device_put() might_sleep annotationBart Van Assche2-2/+2
Although most calls of scsi_device_put() happen from non-atomic context, alua_rtpg_queue() calls this function from atomic context if alua_rtpg_queue() itself is called from atomic context. alua_rtpg_queue() is always called from contexts where the caller must hold at least one reference to the scsi device in question. This means that the reference taken by alua_rtpg_queue() itself can't be the last one, and thus can be dropped without entering the code path in which scsi_device_put() might actually sleep. Hence move the might_sleep() annotation from scsi_device_put() into scsi_device_dev_release(). [1] https://lore.kernel.org/linux-scsi/[email protected]/ [2] https://lore.kernel.org/linux-scsi/[email protected]/ Note: a significant part of the above description was written by Martin Wilck. Fixes: f93ed747e2c7 ("scsi: core: Release SCSI devices synchronously") Cc: Martin Wilck <[email protected]> Cc: Steffen Maier <[email protected]> Cc: Hannes Reinecke <[email protected]> Cc: Sachin Sant <[email protected]> Cc: Benjamin Block <[email protected]> Reported-by: Steffen Maier <[email protected]> Signed-off-by: Bart Van Assche <[email protected]> Reviewed-by: Martin Wilck <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Martin K. Petersen <[email protected]>
2023-01-27Merge tag 'drm-misc-fixes-2023-01-26' of ↵Dave Airlie5-30/+76
git://anongit.freedesktop.org/drm/drm-misc into drm-fixes A fix and a preliminary patch to fix a memory leak in i915, and a use after free fix for fbdev deferred io Signed-off-by: Dave Airlie <[email protected]> From: Maxime Ripard <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/20230126104018.cbrcjxl5wefdbb2f@houat
2023-01-27amdgpu: fix build on non-DCN platforms.Dave Airlie1-2/+2
This fixes the build here locally on my 32-bit arm build. Signed-off-by: Dave Airlie <[email protected]>
2023-01-27Merge tag 'amd-drm-fixes-6.2-2023-01-25' of ↵Dave Airlie8-21/+89
https://gitlab.freedesktop.org/agd5f/linux into drm-fixes amd-drm-fixes-6.2-2023-01-25: amdgpu: - GC11.x fixes - SMU13.0.0 fix - Freesync video fix - DP MST fixes drm: - DP MST kref fix Signed-off-by: Dave Airlie <[email protected]> From: Alex Deucher <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-01-27Merge tag 'drm-intel-fixes-2023-01-26' of ↵Dave Airlie2-38/+2
git://anongit.freedesktop.org/drm/drm-intel into drm-fixes - Fix BSC default context for Meteor Lake (Lucas) - Fix selftest-scheduler's modify_type (Andi) Signed-off-by: Dave Airlie <[email protected]> From: Rodrigo Vivi <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-01-26MAINTAINERS: Move to shared PCI treeBjorn Helgaas1-4/+4
Move PCI subsystem maintenance to a shared git tree to make it easier for maintainers to collaborate. Update MAINTAINERS accordingly. No change to patch submission and patchwork tracking. Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bjorn Helgaas <[email protected]>
2023-01-26IB/IPoIB: Fix legacy IPoIB due to wrong number of queuesDragos Tatulea1-0/+8
The cited commit creates child PKEY interfaces over netlink will multiple tx and rx queues, but some devices doesn't support more than 1 tx and 1 rx queues. This causes to a crash when traffic is sent over the PKEY interface due to the parent having a single queue but the child having multiple queues. This patch fixes the number of queues to 1 for legacy IPoIB at the earliest possible point in time. BUG: kernel NULL pointer dereference, address: 000000000000036b PGD 0 P4D 0 Oops: 0000 [#1] SMP CPU: 4 PID: 209665 Comm: python3 Not tainted 6.1.0_for_upstream_min_debug_2022_12_12_17_02 #1 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 RIP: 0010:kmem_cache_alloc+0xcb/0x450 Code: ce 7e 49 8b 50 08 49 83 78 10 00 4d 8b 28 0f 84 cb 02 00 00 4d 85 ed 0f 84 c2 02 00 00 41 8b 44 24 28 48 8d 4a 01 49 8b 3c 24 <49> 8b 5c 05 00 4c 89 e8 65 48 0f c7 0f 0f 94 c0 84 c0 74 b8 41 8b RSP: 0018:ffff88822acbbab8 EFLAGS: 00010202 RAX: 0000000000000070 RBX: ffff8881c28e3e00 RCX: 00000000064f8dae RDX: 00000000064f8dad RSI: 0000000000000a20 RDI: 0000000000030d00 RBP: 0000000000000a20 R08: ffff8882f5d30d00 R09: ffff888104032f40 R10: ffff88810fade828 R11: 736f6d6570736575 R12: ffff88810081c000 R13: 00000000000002fb R14: ffffffff817fc865 R15: 0000000000000000 FS: 00007f9324ff9700(0000) GS:ffff8882f5d00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000000000036b CR3: 00000001125af004 CR4: 0000000000370ea0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> skb_clone+0x55/0xd0 ip6_finish_output2+0x3fe/0x690 ip6_finish_output+0xfa/0x310 ip6_send_skb+0x1e/0x60 udp_v6_send_skb+0x1e5/0x420 udpv6_sendmsg+0xb3c/0xe60 ? ip_mc_finish_output+0x180/0x180 ? __switch_to_asm+0x3a/0x60 ? __switch_to_asm+0x34/0x60 sock_sendmsg+0x33/0x40 __sys_sendto+0x103/0x160 ? _copy_to_user+0x21/0x30 ? kvm_clock_get_cycles+0xd/0x10 ? ktime_get_ts64+0x49/0xe0 __x64_sys_sendto+0x25/0x30 do_syscall_64+0x3d/0x90 entry_SYSCALL_64_after_hwframe+0x46/0xb0 RIP: 0033:0x7f9374f1ed14 Code: 42 41 f8 ff 44 8b 4c 24 2c 4c 8b 44 24 20 89 c5 44 8b 54 24 28 48 8b 54 24 18 b8 2c 00 00 00 48 8b 74 24 10 8b 7c 24 08 0f 05 <48> 3d 00 f0 ff ff 77 34 89 ef 48 89 44 24 08 e8 68 41 f8 ff 48 8b RSP: 002b:00007f9324ff7bd0 EFLAGS: 00000293 ORIG_RAX: 000000000000002c RAX: ffffffffffffffda RBX: 00007f9324ff7cc8 RCX: 00007f9374f1ed14 RDX: 00000000000002fb RSI: 00007f93000052f0 RDI: 0000000000000030 RBP: 0000000000000000 R08: 00007f9324ff7d40 R09: 000000000000001c R10: 0000000000000000 R11: 0000000000000293 R12: 0000000000000000 R13: 000000012a05f200 R14: 0000000000000001 R15: 00007f9374d57bdc </TASK> Fixes: dbc94a0fb817 ("IB/IPoIB: Fix queue count inconsistency for PKEY child interfaces") Signed-off-by: Dragos Tatulea <[email protected]> Link: https://lore.kernel.org/r/95eb6b74c7cf49fa46281f9d056d685c9fa11d38.1674584576.git.leon@kernel.org Signed-off-by: Leon Romanovsky <[email protected]>
2023-01-26drm/ssd130x: Init display before the SSD130X_DISPLAY_ON commandJavier Martinez Canillas1-11/+7
Commit 622113b9f11f ("drm/ssd130x: Replace simple display helpers with the atomic helpers") changed the driver to just use the atomic helpers instead of the simple KMS abstraction layer. But the commit also made a subtle change on the display power sequence and initialization order, by moving the ssd130x_power_on() call to the encoder .atomic_enable handler and the ssd130x_init() call to CRTC .reset handler. Before this change, both ssd130x_power_on() and ssd130x_init() were called in the simple display pipeline .enable handler, so the display was already initialized by the time the SSD130X_DISPLAY_ON command was sent. For some reasons, it only made the ssd130x SPI driver to fail but the I2C was still working. That is the reason why the bug was not noticed before. To revert to the old driver behavior, move the ssd130x_init() call to the encoder .atomic_enable as well. Besides fixing the panel not being turned on when using SPI, it also gets rid of the custom CRTC .reset callback. Fixes: 622113b9f11f ("drm/ssd130x: Replace simple display helpers with the atomic helpers") Signed-off-by: Javier Martinez Canillas <[email protected]> Reviewed-by: Thomas Zimmermann <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-01-26Merge tag 'nvme-6.2-2023-01-26' of git://git.infradead.org/nvme into block-6.2Jens Axboe3-11/+10
Pull NVMe fixes from Christoph: "nvme fixes for Linux 6.2 - flush initial scan_work for async probe (Keith Busch) - fix passthrough csi check (Keith Busch) - fix nvme-fc initialization order (Ross Lagerwall)" * tag 'nvme-6.2-2023-01-26' of git://git.infradead.org/nvme: nvme: fix passthrough csi check nvme-pci: flush initial scan_work for async probe nvme-fc: fix initialization order
2023-01-26Merge tag 'platform-drivers-x86-v6.2-3' of ↵Linus Torvalds9-111/+211
git://git.kernel.org/pub/scm/linux/kernel/git/pdx86/platform-drivers-x86 Pull x86 platform driver fixes from Hans de Goede: - Fix false positive apple_gmux backlight detection on older iGPU only MacBook models - Various other small fixes and hardware-id additions * tag 'platform-drivers-x86-v6.2-3' of git://git.kernel.org/pub/scm/linux/kernel/git/pdx86/platform-drivers-x86: platform/x86: thinkpad_acpi: Fix profile modes on Intel platforms ACPI: video: Fix apple gmux detection platform/x86: apple-gmux: Add apple_gmux_detect() helper platform/x86: apple-gmux: Move port defines to apple-gmux.h platform/x86: hp-wmi: Fix cast to smaller integer type warning platform/x86/amd: pmc: Add a module parameter to disable workarounds platform/x86/amd: pmc: Disable IRQ1 wakeup for RN/CZN platform/x86: asus-wmi: Fix kbd_dock_devid tablet-switch reporting platform/x86: gigabyte-wmi: add support for B450M DS3H WIFI-CF platform/x86: hp-wmi: Handle Omen Key event platform/x86: dell-wmi: Add a keymap for KEY_MUTE in type 0x0010 table
2023-01-26Merge tag 'net-6.2-rc6' of ↵Linus Torvalds38-400/+535
git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net Pull networking fixes from Paolo Abeni: "Including fixes from netfilter. Current release - regressions: - sched: sch_taprio: do not schedule in taprio_reset() Previous releases - regressions: - core: fix UaF in netns ops registration error path - ipv4: prevent potential spectre v1 gadgets - ipv6: fix reachability confirmation with proxy_ndp - netfilter: fix for the set rbtree - eth: fec: use page_pool_put_full_page when freeing rx buffers - eth: iavf: fix temporary deadlock and failure to set MAC address Previous releases - always broken: - netlink: prevent potential spectre v1 gadgets - netfilter: fixes for SCTP connection tracking - mctp: struct sock lifetime fixes - eth: ravb: fix possible hang if RIS2_QFF1 happen - eth: tg3: resolve deadlock in tg3_reset_task() during EEH Misc: - Mat stepped out as MPTCP co-maintainer" * tag 'net-6.2-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net: (40 commits) net: mdio-mux-meson-g12a: force internal PHY off on mux switch docs: networking: Fix bridge documentation URL tsnep: Fix TX queue stop/wake for multiple queues net/tg3: resolve deadlock in tg3_reset_task() during EEH net: mctp: mark socks as dead on unhash, prevent re-add net: mctp: hold key reference when looking up a general key net: mctp: move expiry timer delete to unhash net: mctp: add an explicit reference from a mctp_sk_key to sock net: ravb: Fix possible hang if RIS2_QFF1 happen net: ravb: Fix lack of register setting after system resumed for Gen3 net/x25: Fix to not accept on connected socket ice: move devlink port creation/deletion sctp: fail if no bound addresses can be used for a given scope net/sched: sch_taprio: do not schedule in taprio_reset() Revert "Merge branch 'ethtool-mac-merge'" netrom: Fix use-after-free of a listening socket. netfilter: conntrack: unify established states for SCTP paths Revert "netfilter: conntrack: add sctp DATA_SENT state" netfilter: conntrack: fix bug in for_each_sctp_chunk netfilter: conntrack: fix vtag checks for ABORT/SHUTDOWN_COMPLETE ...
2023-01-26treewide: fix up files incorrectly marked executableLinus Torvalds3-0/+0
I'm not exactly clear on what strange workflow causes people to do it, but clearly occasionally some files end up being committed as executable even though they clearly aren't. This is a reprise of commit 90fda63fa115 ("treewide: fix up files incorrectly marked executable"), just with a different set of files (but with the same trivial shell scripting). So apparently we need to re-do this every five years or so, and Joe needs to just keep reminding me to do so ;) Reported-by: Joe Perches <[email protected]> Fixes: 523375c943e5 ("drm/vmwgfx: Port vmwgfx to arm64") Fixes: 5c439937775d ("ASoC: codecs: add support for ES8326") Signed-off-by: Linus Torvalds <[email protected]>
2023-01-26ASoC: cs42l56: fix DT probeArnd Bergmann1-6/+0
While looking through legacy platform data users, I noticed that the DT probing never uses data from the DT properties, as the platform_data structure gets overwritten directly after it is initialized. There have never been any boards defining the platform_data in the mainline kernel either, so this driver so far only worked with patched kernels or with the default values. For the benefit of possible downstream users, fix the DT probe by no longer overwriting the data. Signed-off-by: Arnd Bergmann <[email protected]> Acked-by: Charles Keepax <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]>
2023-01-26block: ublk: move ublk_chr_class destroying after devices are removedMing Lei1-4/+3
The 'ublk_chr_class' is needed when deleting ublk char devices in ublk_exit(), so move it after devices(idle) are removed. Fixes the following warning reported by Harris, James R: [ 859.178950] sysfs group 'power' not found for kobject 'ublkc0' [ 859.178962] WARNING: CPU: 3 PID: 1109 at fs/sysfs/group.c:278 sysfs_remove_group+0x9c/0xb0 Reported-by: "Harris, James R" <[email protected]> Fixes: 71f28f3136af ("ublk_drv: add io_uring based userspace block driver") Link: https://lore.kernel.org/linux-block/Y9JlFmSgDl3+zy3N@T590/T/#t Signed-off-by: Ming Lei <[email protected]> Tested-by: Jim Harris <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jens Axboe <[email protected]>
2023-01-26Partially revert "perf/arm-cmn: Optimise DTC counter accesses"Robin Murphy1-1/+6
It turns out the optimisation implemented by commit 4f2c3872dde5 is totally broken, since all the places that consume hw->dtcs_used for events other than cycle count are still not expecting it to be sparsely populated, and fail to read all the relevant DTC counters correctly if so. If implemented correctly, the optimisation potentially saves up to 3 register reads per event update, which is reasonably significant for events targeting a single node, but still not worth a massive amount of additional code complexity overall. Getting it right within the current design looks a fair bit more involved than it was ever intended to be, so let's just make a functional revert which restores the old behaviour while still backporting easily. Fixes: 4f2c3872dde5 ("perf/arm-cmn: Optimise DTC counter accesses") Reported-by: Ilkka Koskinen <[email protected]> Signed-off-by: Robin Murphy <[email protected]> Link: https://lore.kernel.org/r/b41bb4ed7283c3d8400ce5cf5e6ec94915e6750f.1674498637.git.robin.murphy@arm.com Signed-off-by: Will Deacon <[email protected]>
2023-01-26pinctrl: mediatek: Fix the drive register definition of some PinsGuodong Liu1-2/+2
The drive adjustment register definition of gpio13 and gpio81 is wrong: "the start address for the range" of gpio18 is corrected to 0x000, "the start bit for the first register within the range" of gpio81 is corrected to 24. Fixes: 6cf5e9ef362a ("pinctrl: add pinctrl driver on mt8195") Signed-off-by: Guodong Liu <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Linus Walleij <[email protected]>
2023-01-26drm/vc4: hdmi: make CEC adapter name uniqueHans Verkuil1-1/+2
The bcm2711 has two HDMI outputs, each with their own CEC adapter. The CEC adapter name has to be unique, but it is currently hardcoded to "vc4" for both outputs. Change this to use the card_name from the variant information in order to make the adapter name unique. Signed-off-by: Hans Verkuil <[email protected]> Fixes: 15b4511a4af6 ("drm/vc4: add HDMI CEC support") Signed-off-by: Maxime Ripard <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-01-26ARM: dts: imx7d-smegw01: Fix USB host over-current polarityFabio Estevam1-1/+2
Currently, when resetting the USB modem via AT commands, the modem is no longer re-connected. This problem is caused by the incorrect description of the USB_OTG2_OC pad. It should have pull-up enabled, hysteresis enabled and the property 'over-current-active-low' should be passed. With this change, the USB modem can be successfully re-connected after a reset. Cc: [email protected] Fixes: 9ac0ae97e349 ("ARM: dts: imx7d-smegw01: Add support for i.MX7D SMEGW01 board") Signed-off-by: Fabio Estevam <[email protected]> Signed-off-by: Shawn Guo <[email protected]>
2023-01-26arm64: dts: imx8mm-verdin: Do not power down eth-phyPhilippe Schenker1-0/+1
Currently if suspending using either freeze or memory state, the fec driver tries to power down the phy which leads to crash of the kernel and non-responsible kernel with the following call trace: [ 24.839889 ] Call trace: [ 24.839892 ] phy_error+0x18/0x60 [ 24.839898 ] kszphy_handle_interrupt+0x6c/0x80 [ 24.839903 ] phy_interrupt+0x20/0x2c [ 24.839909 ] irq_thread_fn+0x30/0xa0 [ 24.839919 ] irq_thread+0x178/0x2c0 [ 24.839925 ] kthread+0x154/0x160 [ 24.839932 ] ret_from_fork+0x10/0x20 Since there is currently no functionality in the phy subsystem to power down phys let's just disable the feature of powering-down the ethernet phy. Fixes: 6a57f224f734 ("arm64: dts: freescale: add initial support for verdin imx8m mini") Signed-off-by: Philippe Schenker <[email protected]> Signed-off-by: Shawn Guo <[email protected]>
2023-01-26MAINTAINERS: match freescale ARM64 DT directory in i.MX entryAhmad Fatoum1-0/+3
The majority of device trees in arch/arm64/boot/dts/freescale/ are built around i.MX SoCs with the rest being for Layerscape. Yet, calling get_maintainers.pl -f on this directory will not match the MAINTAINERS entry, because the directory name doesn't contain the substring "imx". Add an explicit file match for the directory and exclude the Layerscape specific files. This ensures To/Cc is not only generated from git history, but takes e.g. the R: entries into account as well. Signed-off-by: Ahmad Fatoum <[email protected]> Signed-off-by: Shawn Guo <[email protected]>
2023-01-25net: mdio-mux-meson-g12a: force internal PHY off on mux switchJerome Brunet1-7/+16
Force the internal PHY off then on when switching to the internal path. This fixes problems where the PHY ID is not properly set. Fixes: 7090425104db ("net: phy: add amlogic g12a mdio mux support") Suggested-by: Qi Duan <[email protected]> Co-developed-by: Heiner Kallweit <[email protected]> Signed-off-by: Heiner Kallweit <[email protected]> Signed-off-by: Jerome Brunet <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
2023-01-25docs: networking: Fix bridge documentation URLIvan Vecera1-1/+1
Current documentation URL [1] is no longer valid. [1] https://www.linuxfoundation.org/collaborate/workgroups/networking/bridge Signed-off-by: Ivan Vecera <[email protected]> Reviewed-by: Pavan Chebbi <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
2023-01-25tsnep: Fix TX queue stop/wake for multiple queuesGerhard Engleder1-6/+9
netif_stop_queue() and netif_wake_queue() act on TX queue 0. This is ok as long as only a single TX queue is supported. But support for multiple TX queues was introduced with 762031375d5c and I missed to adapt stop and wake of TX queues. Use netif_stop_subqueue() and netif_tx_wake_queue() to act on specific TX queue. Fixes: 762031375d5c ("tsnep: Support multiple TX/RX queue pairs") Signed-off-by: Gerhard Engleder <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
2023-01-25net/tg3: resolve deadlock in tg3_reset_task() during EEHDavid Christensen1-4/+4
During EEH error injection testing, a deadlock was encountered in the tg3 driver when tg3_io_error_detected() was attempting to cancel outstanding reset tasks: crash> foreach UN bt ... PID: 159 TASK: c0000000067c6000 CPU: 8 COMMAND: "eehd" ... #5 [c00000000681f990] __cancel_work_timer at c00000000019fd18 #6 [c00000000681fa30] tg3_io_error_detected at c00800000295f098 [tg3] #7 [c00000000681faf0] eeh_report_error at c00000000004e25c ... PID: 290 TASK: c000000036e5f800 CPU: 6 COMMAND: "kworker/6:1" ... #4 [c00000003721fbc0] rtnl_lock at c000000000c940d8 #5 [c00000003721fbe0] tg3_reset_task at c008000002969358 [tg3] #6 [c00000003721fc60] process_one_work at c00000000019e5c4 ... PID: 296 TASK: c000000037a65800 CPU: 21 COMMAND: "kworker/21:1" ... #4 [c000000037247bc0] rtnl_lock at c000000000c940d8 #5 [c000000037247be0] tg3_reset_task at c008000002969358 [tg3] #6 [c000000037247c60] process_one_work at c00000000019e5c4 ... PID: 655 TASK: c000000036f49000 CPU: 16 COMMAND: "kworker/16:2" ...:1 #4 [c0000000373ebbc0] rtnl_lock at c000000000c940d8 #5 [c0000000373ebbe0] tg3_reset_task at c008000002969358 [tg3] #6 [c0000000373ebc60] process_one_work at c00000000019e5c4 ... Code inspection shows that both tg3_io_error_detected() and tg3_reset_task() attempt to acquire the RTNL lock at the beginning of their code blocks. If tg3_reset_task() should happen to execute between the times when tg3_io_error_deteced() acquires the RTNL lock and tg3_reset_task_cancel() is called, a deadlock will occur. Moving tg3_reset_task_cancel() call earlier within the code block, prior to acquiring RTNL, prevents this from happening, but also exposes another deadlock issue where tg3_reset_task() may execute AFTER tg3_io_error_detected() has executed: crash> foreach UN bt PID: 159 TASK: c0000000067d2000 CPU: 9 COMMAND: "eehd" ... #4 [c000000006867a60] rtnl_lock at c000000000c940d8 #5 [c000000006867a80] tg3_io_slot_reset at c0080000026c2ea8 [tg3] #6 [c000000006867b00] eeh_report_reset at c00000000004de88 ... PID: 363 TASK: c000000037564000 CPU: 6 COMMAND: "kworker/6:1" ... #3 [c000000036c1bb70] msleep at c000000000259e6c #4 [c000000036c1bba0] napi_disable at c000000000c6b848 #5 [c000000036c1bbe0] tg3_reset_task at c0080000026d942c [tg3] #6 [c000000036c1bc60] process_one_work at c00000000019e5c4 ... This issue can be avoided by aborting tg3_reset_task() if EEH error recovery is already in progress. Fixes: db84bf43ef23 ("tg3: tg3_reset_task() needs to use rtnl_lock to synchronize") Signed-off-by: David Christensen <[email protected]> Reviewed-by: Pavan Chebbi <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
2023-01-26arm64: dts: imx8mm: Fix pad control for UART1_DTE_RXPierluigi Passaro1-1/+1
According section     8.2.5.313 Select Input Register (IOMUXC_UART1_RXD_SELECT_INPUT) of      i.MX 8M Mini Applications Processor Reference Manual, Rev. 3, 11/2020 the required setting for this specific pin configuration is "1" Signed-off-by: Pierluigi Passaro <[email protected]> Reviewed-by: Fabio Estevam <[email protected]> Fixes: c1c9d41319c3 ("dt-bindings: imx: Add pinctrl binding doc for imx8mm") Signed-off-by: Shawn Guo <[email protected]>
2023-01-25ksmbd: downgrade ndr version error message to debugNamjae Jeon1-4/+4
When user switch samba to ksmbd, The following message flood is coming when accessing files. Samba seems to changs dos attribute version to v5. This patch downgrade ndr version error message to debug. $ dmesg ... [68971.766914] ksmbd: v5 version is not supported [68971.779808] ksmbd: v5 version is not supported [68971.871544] ksmbd: v5 version is not supported [68971.910135] ksmbd: v5 version is not supported ... Cc: [email protected] Fixes: e2f34481b24d ("cifsd: add server-side procedures for SMB3") Signed-off-by: Namjae Jeon <[email protected]> Signed-off-by: Steve French <[email protected]>
2023-01-25ksmbd: limit pdu length size according to connection statusNamjae Jeon2-4/+18
Stream protocol length will never be larger than 16KB until session setup. After session setup, the size of requests will not be larger than 16KB + SMB2 MAX WRITE size. This patch limits these invalidly oversized requests and closes the connection immediately. Fixes: 0626e6641f6b ("cifsd: add server handler for central processing and tranport layers") Cc: [email protected] Reported-by: [email protected] # ZDI-CAN-18259 Signed-off-by: Namjae Jeon <[email protected]> Signed-off-by: Steve French <[email protected]>
2023-01-25clk: ingenic: jz4760: Update M/N/OD calculation algorithmPaul Cercueil1-10/+8
The previous algorithm was pretty broken. - The inner loop had a '(m > m_max)' condition, and the value of 'm' would increase in each iteration; - Each iteration would actually multiply 'm' by two, so it is not needed to re-compute the whole equation at each iteration; - It would loop until (m & 1) == 0, which means it would loop at most once. - The outer loop would divide the 'n' value by two at the end of each iteration. This meant that for a 12 MHz parent clock and a 1.2 GHz requested clock, it would first try n=12, then n=6, then n=3, then n=1, none of which would work; the only valid value is n=2 in this case. Simplify this algorithm with a single for loop, which decrements 'n' after each iteration, addressing all of the above problems. Fixes: bdbfc029374f ("clk: ingenic: Add support for the JZ4760") Cc: <[email protected]> Signed-off-by: Paul Cercueil <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Stephen Boyd <[email protected]>
2023-01-25cxl/pmem: Fix nvdimm unregistration when cxl_pmem driver is absentDan Williams3-39/+28
The cxl_pmem.ko module houses the driver for both cxl_nvdimm_bridge objects and cxl_nvdimm objects. When the core creates a cxl_nvdimm it arranges for it to be autoremoved when the bridge goes down. However, if the bridge never initialized because the cxl_pmem.ko module never loaded, it sets up a the following crash scenario: BUG: kernel NULL pointer dereference, address: 0000000000000478 [..] RIP: 0010:cxl_nvdimm_probe+0x99/0x140 [cxl_pmem] [..] Call Trace: <TASK> cxl_bus_probe+0x17/0x50 [cxl_core] really_probe+0xde/0x380 __driver_probe_device+0x78/0x170 driver_probe_device+0x1f/0x90 __driver_attach+0xd2/0x1c0 bus_for_each_dev+0x79/0xc0 bus_add_driver+0x1b1/0x200 driver_register+0x89/0xe0 cxl_pmem_init+0x50/0xff0 [cxl_pmem] It turns out the recent rework to simplify nvdimm probing obviated the need to unregister cxl_nvdimm objects at cxl_nvdimm_bridge ->remove() time. Leave the cxl_nvdimm device registered until the hosting cxl_memdev departs. The alternative is that the cxl_memdev needs to be reattached whenever the cxl_nvdimm_bridge attach state cycles, which is awkward and unnecessary. The only requirement is to make sure that when the cxl_nvdimm_bridge goes away any dependent cxl_nvdimm objects are shutdown. Handle that in unregister_nvdimm_bus(). With these registration entanglements removed there is no longer a need to pre-load the cxl_pmem module in cxl_acpi. Fixes: cb9cfff82f6a ("cxl/acpi: Simplify cxl_nvdimm_bridge probing") Reported-by: Gregory Price <[email protected]> Debugged-by: Jonathan Cameron <[email protected]> Tested-by: Jonathan Cameron <[email protected]> Reviewed-by: Jonathan Cameron <[email protected]> Reviewed-by: Dave Jiang <[email protected]> Link: https://lore.kernel.org/r/167426077263.3955046.9695309346988027311.stgit@dwillia2-xfh.jf.intel.com Signed-off-by: Dan Williams <[email protected]>
Powered by cgit, Gruvboxed by Blaster4385.