Waveshare dsi 2609 - #6
Closed
EngineerWill wants to merge 5647 commits into
Closed
EngineerWill wants to merge 5647 commits into
EngineerWill wants to merge 5647 commits into
Conversation
commit f18e877 upstream. If preparation of the first subrequest fails, netfs_unbuffered_write() exits its loop before ret is initialized. The empty-iterator check can do the same. For synchronous writes, netfs_unbuffered_write_iter_locked() may then return an unrelated error instead of wreq->error. This is reachable through CIFS if cifs_prepare_write() fails to reopen the file or obtain credits. Initialize ret to 0 so the caller returns wreq->error if no data was written, or the number of bytes already written otherwise. Found with Clang's -Wconditional-uninitialized. Fixes: a0b4c7a ("netfs: Fix unbuffered/DIO writes to dispatch subrequests in strict sequence") Cc: stable@vger.kernel.org Signed-off-by: Karl Mehltretter <kmehltretter@gmail.com> Signed-off-by: David Howells <dhowells@redhat.com> Link: https://patch.msgid.link/20260827134304.2075713-2-dhowells@redhat.com Acked-by: Paulo Alcantara <pc@manguebit.org> Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 2c018cc upstream. nf_log_syslog and nfnetlink_log unregister their per-network namespace operations before unregistering their global logger backends. This leaves a window where a sysctl or netlink writer can rebind the still- registered logger after the per-net pre-exit callback cleared the old selection. The race looks like this: CPU 0 CPU 1 ---- ---- unregister_pernet_subsys() nf_log_unset(net, logger) net->nf.nf_loggers[pf] = NULL lock nf_log_mutex find logger in loggers[][] net->nf.nf_loggers[pf] = logger unlock nf_log_mutex nf_log_unregister(logger) lock nf_log_mutex loggers[pf][type] = NULL unlock nf_log_mutex synchronize_rcu() module exit returns module core frees backend memory Later, a sysctl read or packet logging operation can dereference the stale per-net logger pointer. Fix this by unregistering the global logger backends before tearing down per-net state. Once the global registrations are gone, later writers can no longer rebind the logger. unregister_pernet_subsys() already waits for an RCU grace period after the pre-exit callback clears the per-net selection, while nf_log_unregister() continues to cover readers of the global logger table. Apply this ordering fix to both nf_log backends that combine per-net teardown with global logger registration. Fixes: 5b023fc ("netfilter: enable per netns support for nf_loggers") Cc: stable@vger.kernel.org Signed-off-by: Chengfeng Ye <nicoyip.dev@gmail.com> Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 7a099b3 upstream. NLM_F_DUMP_FILTERED is only set on data elements in the conntrack dump. But when everything is filtered out it is confusing for the user space, since the flag is not reported anymore and it looks like the table was empty, which may or may not be the case. 'answer_flags' were introduced precisely for this use case, and the conntrack dump should set the flag in there in case the filtering was applied. This is important, for example, to be able to tell if the filters are supported or not by the kernel without modifying the kernel state. With the proper reporting of NLM_F_DUMP_FILTERED on NLMSG_DONE, an application in user space can just try and dump with an arbitrary filter without worrying that there could be no matching entry. The reported flag will signal that the filtering was applied and therefore supported. Fixes: cb8aa9a ("netfilter: ctnetlink: add kernel side filtering for dump") Cc: stable@vger.kernel.org Signed-off-by: Ilya Maximets <i.maximets@ovn.org> Reviewed-by: Florian Westphal <fw@strlen.de> Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 4d470be upstream. Route unsupported provisioned features through the common error path after vdpa_alloc_device() so the allocated device and adapter pointer are released consistently. Fixes: 46fc091 ("vDPA/ifcvf: implement features provisioning") Cc: stable@vger.kernel.org # v6.3+ Signed-off-by: Xiong Weimin <xiongweimin@kylinos.cn> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Message-ID: <178589471294.1556376.4816776800128323034@kylinos.cn> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit e847542 upstream. Unwind IRQs already requested by snet_request_irqs() before returning a VQ IRQ request error so a later DRIVER_OK retry starts from a clean state. The IRQs are requested and freed while the PCI device remains bound, so the driver cannot wait for devres cleanup at detach time. Fixes: 51a8f9d ("virtio: vdpa: new SolidNET DPU driver.") Cc: stable@vger.kernel.org # v6.3+ Signed-off-by: Xiong Weimin <xiongweimin@kylinos.cn> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Message-ID: <178589471328.1556376.15570536900532373521@kylinos.cn> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 4f73462 upstream. When building in a kernel tree prior to commit b055f4c ("sorttable: Move ELF parsing into scripts/elf-parse.[ch]") with clang-23 or newer, which implements a new warning under -Wunused-but-set-variable for static global variable, there is a warning from sorttable because long_size is unused when MCOUNT_SORT_ENABLED is not set: scripts/sorttable.c:452:12: error: variable 'long_size' set but not used [-Werror,-Wunused-but-set-global] 452 | static int long_size; | ^ Mark long_size as __maybe_unused to avoid inserting more ugly #ifdef directives while insuring the warning does not reappear, as the aforementioned change does not alter the uses of long_size, so it appears to be coincidence that the warning disappears after this refactoring. Cc: stable@vger.kernel.org Signed-off-by: Nathan Chancellor <nathan@kernel.org> Tested-by: Nicolas Schier <n.schier@fritz.com> Link: https://patch.msgid.link/20260831-sorttable-long_size-unused-but-set-global-v1-1-8a96b88697e5@kernel.org Signed-off-by: Nicolas Schier <nsc@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 5ab5483 upstream. In autofs_fill_super(), we create a new inode using autofs_new_ino(), however, if we fail to create root_inode, (that is, root_inode failure path), we return -ENOMEM without freeing the new inode(ino) that we created causing a memory leak. Fix this by adding autofs_free_ino() to free the inode we created in root_inode failure path before returning ENOMEM. Reported-by: syzbot+df1db6e034b3953e19f5@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=df1db6e034b3953e19f5 Fixes: 66917f8 ("autofs: add: new_inode check in autofs_fill_super()") Cc: stable@vger.kernel.org Signed-off-by: Jeffin Philip <jeffinphilip14@gmail.com> Link: https://patch.msgid.link/20260903081048.132524-1-jeffinphilip14@gmail.com Signed-off-by: Ian Kent <raven@themaw.net> Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 617d0d8 upstream. The pool-resize path frees each stream's old decoder before allocating its replacement. If an allocation fails after some streams have already been replaced, the failed stream is put back on the list with state == NULL. z_erofs_lzma_max_dictsize is still advanced as if the whole pool had been resized. An existing LZMA mount can select the broken stream and pass NULL to xz_dec_microlzma_reset(). A retry at the same size also skip another resize attempt. Since the global maximum was advanced, thus, the invalid state is left unrepaired. Allocate each replacement before freeing the old decoder, temporarily retaining one old decoder during allocation. Stop at the first failure and advance z_erofs_lzma_max_dictsize only after all streams satisfy the request. Record each stream's dictionary capacity so retries can skip streams already enlarged before a partial failure. Fixes: 622cead ("erofs: lzma compression support") Cc: stable@vger.kernel.org Signed-off-by: Nikhil Gurudasani <nikhilgurudasani314@gmail.com> Reviewed-by: Gao Xiang <xiang@kernel.org> Signed-off-by: Gao Xiang <xiang@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit a0a34a4 upstream. FBIOGETCMAP takes a shallow snapshot of info->cmap and performs the usercopy after dropping info->lock. vfb_remove() frees the colormap immediately after unregistering the framebuffer, even when an open file still holds a reference to fb_info. A concurrent driver unbind can therefore free the colormap while the ioctl copies it to userspace. KASAN reports: BUG: KASAN: slab-use-after-free in _copy_to_user Read of size 512 by task poc/125 _copy_to_user (./include/linux/instrumented.h:129 ./include/linux/uaccess.h:201 lib/usercopy.c:24) fb_cmap_to_user (./include/linux/uaccess.h:230 drivers/video/fbdev/core/fbcmap.c:211) do_fb_ioctl (drivers/video/fbdev/core/fb_chrdev.c:114) Allocated by task 1: fb_alloc_cmap_gfp (./include/linux/slab.h:973 ./include/linux/slab.h:1290 drivers/video/fbdev/core/fbcmap.c:108) vfb_probe (drivers/video/fbdev/vfb.c:459) Freed by task 124: fb_dealloc_cmap (drivers/video/fbdev/core/fbcmap.c:151) vfb_remove (drivers/video/fbdev/vfb.c:489) unregister_framebuffer() drops the registration reference, and fbdev calls fb_destroy after the last put_fb_info(). Move the registered framebuffer's cleanup into an fb_destroy callback so its colormap and screen buffer stay alive until all file references have been released. Fixes: 5e266e2 ("vfb: fix memory leaks in removal path") Reported-by: co+c25629c98ba36ebe@bugs.sh Cc: stable@kernel.org Closes: https://lore.kernel.org/linux-fbdev/f2Kf9GYn1lKR5S1dbvGVtykMxK1RlgP5z8sW@bugs.sh/ Assisted-by: Codex:gpt-5 Signed-off-by: Weiming Shi <bestswngs@gmail.com> Link: https://lore.kernel.org/linux-fbdev/f2Kf9GYn1lKR5S1dbvGVtykMxK1RlgP5z8sW@bugs.sh/ Signed-off-by: Helge Deller <deller@gmx.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit b824476 upstream. fqdir_pre_exit() flushes the skbs from incomplete queues without changing their completion state. A fragment which found a queue before high_thresh was cleared can then acquire the queue lock and reuse stale reassembly metadata. A queue concurrently killed after fqdir->dead is set can instead become INET_FRAG_COMPLETE|INET_FRAG_HASH_DEAD while still holding its old skbs; skipping it because it is complete leaves those references behind until asynchronous fqdir teardown. For IPv6, stale metadata can make ip6_frag_reasm() use the old nhoffset with a new skb and access memory out of bounds. The resulting heap corruption can be leveraged for local privilege escalation when unprivileged network namespaces are available. Unflushed fragments can also keep conntrack references alive after the conntrack per-net cleanup point. Kill each incomplete queue, then flush every queue still owned by the dying rhashtable. HASH_DEAD identifies that ownership, while complete queues without it are already owned by another destroy path and must be left alone. Releasing a timer reference removed by inet_frag_kill() is deferred to inet_frag_putn(), after the queue lock is dropped. KASAN report: BUG: KASAN: slab-out-of-bounds in ipv6_frag_rcv (net/ipv6/reassembly.c:289 (discriminator 2) net/ipv6/reassembly.c:229 (discriminator 2) net/ipv6/reassembly.c:391 (discriminator 2)) Write of size 1 at addr ff110001039c6e00 by task poc/771 Call Trace: ? ipv6_frag_rcv (net/ipv6/reassembly.c:289 (discriminator 2) net/ipv6/reassembly.c:229 (discriminator 2) net/ipv6/reassembly.c:391 (discriminator 2)) ipv6_frag_rcv (net/ipv6/reassembly.c:289 (discriminator 2) net/ipv6/reassembly.c:229 (discriminator 2) net/ipv6/reassembly.c:391 (discriminator 2)) ip6_protocol_deliver_rcu (net/ipv6/ip6_input.c:479 (discriminator 5)) ip6_input_finish (net/ipv6/ip6_input.c:534) ipv6_rcv (include/net/dst.h:480 (discriminator 3) net/ipv6/ip6_input.c:119 (discriminator 3) net/ipv6/ip6_input.c:109 (discriminator 3) include/linux/netfilter.h:325 (discriminator 3) include/linux/netfilter.h:319 (discriminator 3) net/ipv6/ip6_input.c:351 (discriminator 3)) packet_sendmsg (net/packet/af_packet.c:3110 net/packet/af_packet.c:3142) __x64_sys_sendmmsg (net/socket.c:2883 net/socket.c:2880 net/socket.c:2880) The buggy address belongs to the object at ff110001039c6b40 which belongs to the cache skbuff_small_head of size 704 The buggy address is located 0 bytes to the right of allocated 704-byte region [ff110001039c6b40, ff110001039c6e00) BUG: KASAN: slab-out-of-bounds in ip6_protocol_deliver_rcu (net/ipv6/ip6_input.c:423 (discriminator 1)) Read of size 1 at addr ff110001039c6e08 by task poc/771 Call Trace: ? ip6_protocol_deliver_rcu (net/ipv6/ip6_input.c:423 (discriminator 1)) ip6_protocol_deliver_rcu (net/ipv6/ip6_input.c:423 (discriminator 1)) ip6_input_finish (net/ipv6/ip6_input.c:534) ipv6_rcv (include/net/dst.h:480 (discriminator 3) net/ipv6/ip6_input.c:119 (discriminator 3) net/ipv6/ip6_input.c:109 (discriminator 3) include/linux/netfilter.h:325 (discriminator 3) include/linux/netfilter.h:319 (discriminator 3) net/ipv6/ip6_input.c:351 (discriminator 3)) packet_sendmsg (net/packet/af_packet.c:3110 net/packet/af_packet.c:3142) __x64_sys_sendmmsg (net/socket.c:2883 net/socket.c:2880 net/socket.c:2880) packet_sendmsg (net/packet/af_packet.c:2959 net/packet/af_packet.c:3053 net/packet/af_packet.c:3142) __x64_sys_sendmmsg (net/socket.c:2883 net/socket.c:2880 net/socket.c:2880) The buggy address belongs to the object at ff110001039c6b40 which belongs to the cache skbuff_small_head of size 704 The buggy address is located 8 bytes to the right of allocated 704-byte region [ff110001039c6b40, ff110001039c6e00) Fixes: 006a503 ("inet: frags: flush pending skbs in fqdir_pre_exit()") Cc: stable@vger.kernel.org Reported-by: Kimi Security Team <bug-report@moonshot.ai> Tested-by: Weiming Shi <shiweiming@moonshot.ai> Reviewed-by: Eric Dumazet <edumazet@google.com> Signed-off-by: Yilin Zhang <yilinzhang@moonshot.ai> Link: https://patch.msgid.link/20260904162800.1095662-1-yilinzhang@moonshot.ai Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit bf79662 upstream. TUNSETLINK allows a TUN device to change its link-layer type to ARPHRD_IEEE802154 without initializing ieee802154_ptr. lowpan_newlink() checks only the device type before dereferencing the pointer, so an RTM_NEWLINK request can trigger a NULL pointer dereference. Reject devices without ieee802154_ptr along with devices of the wrong type. Fixes: 51e0e5d ("ieee802154: 6lowpan: remove multiple lowpan per wpan support") Cc: stable@vger.kernel.org Reported-by: Vega <vega@nebusec.ai> Signed-off-by: Zhiling Zou <zhilinz@nebusec.ai> Link: https://lore.kernel.org/0b715da69bd15a86ddc47dad5cf12da648211050.1787997209.git.zhilinz@nebusec.ai Signed-off-by: Stefan Schmidt <stefan@datenfreihafen.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit ff5891b upstream. The FIFOP interrupt handler queues cc2520_fifop_irqwork. On removal, cc2520_remove() only flushes the work. The devm-managed FIFOP IRQ remains active until after ->remove() returns and can queue the work again after that flush, allowing it to run after the private data is released. Disable the work with disable_work_sync() instead of flushing it, so the handler can no longer queue it once removal begins. Destroy the buffer mutex last, since the worker and the stop callback invoked through ieee802154_unregister_hw() both take it. Found by an in-house static analysis tool. Fixes: 0da6bc8 ("ieee802154: cc2520: adds driver for TI CC2520 radio") Cc: stable@vger.kernel.org # v6.10+ Suggested-by: Miquel Raynal <miquel.raynal@bootlin.com> Reviewed-by: Miquel Raynal <miquel.raynal@bootlin.com> Assisted-by: Codex:gpt-5.6 Signed-off-by: Fan Wu <fanwu01@zju.edu.cn> Link: https://lore.kernel.org/20260812061714.175966-1-fanwu01@zju.edu.cn Signed-off-by: Stefan Schmidt <stefan@datenfreihafen.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 979d5b8 upstream. hwsim_update_pib() does an unserialized read-swap-free of phy->pib: pib_old = rtnl_dereference(phy->pib); ... rcu_assign_pointer(phy->pib, pib); kfree_rcu(pib_old, rcu); It assumes the RTNL is held, but ->set_channel is not always called under it: the mac802154 scan worker changes channels via drv_set_channel() without the RTNL. Such an update can race an RTNL-held one on the same phy; both read the same pib_old and both kfree_rcu() it, double-freeing the object. With SLUB percpu sheaves batching kfree_rcu(), this surfaces as a KASAN invalid-free in rcu_free_sheaf(). struct hwsim_phy has no lock for pib. Add one and make the swap atomic with rcu_replace_pointer() under it, dropping the misleading rtnl_dereference(). Reported-by: syzbot+60332fd095f8bb2946ad@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=60332fd095f8bb2946ad Fixes: f25da51 ("ieee802154: hwsim: add replacement for fakelb") Signed-off-by: David Carlier <devnexen@gmail.com> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/20260709221858.158063-1-devnexen@gmail.com Signed-off-by: Stefan Schmidt <stefan@datenfreihafen.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit efdfb1e upstream. fib_empty_table() probes every table ID from 1 until it finds a free one. IPv4 tables are stored in a 256-bucket hash table, so a dense set of IDs makes each probe walk a growing hash chain while RTNL is held. Automatic table assignment ("ip rule ... table 0") is an IPv4-only legacy path. Bound the automatically allocated ID to 4096 so the RTNL hold stays bounded, without changing lookups of explicitly specified table IDs. This changes user-visible behavior. A table-0 rule previously received the lowest free ID in 1..RT_TABLE_MAX (0xFFFFFFFF). After this patch the search stops at 4096 and the rule add fails with ENOBUFS if that range is fully occupied. Explicit table IDs above 4096 remain usable. The automatic path is unused in practice: it is IPv4-only, not documented by ip-rule, uncovered by kernel selftests, and both NetworkManager and systemd refuse table 0. Fixes: b801f54 ("[NET]: Increate RT_TABLE_MAX to 2^32") Cc: stable@vger.kernel.org Reported-by: Vega <vega@nebusec.ai> Suggested-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: Zihan Xi <zihanx@nebusec.ai> Reviewed-by: Ido Schimmel <idosch@nvidia.com> Reviewed-by: Petr Vorel <pvorel@suse.cz> Link: https://patch.msgid.link/6f2f2a7a136aee005512a2e1ac8ede62ac8c7bb6.1788258884.git.zihanx@nebusec.ai Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 8d6cd18 upstream. ipv6_flowlabel_get() allocates an ipv6_fl_socklist entry for every successful GET. The recheck path for a compatible existing flowlabel links another lease without applying any lease admission check. Repeated GET requests for one shareable label can therefore grow a socket's lease list without bound. Reject a new unprivileged lease once the socket already holds FL_MAX_PER_SOCK leases. Check this on the shared recheck path so reuse of a globally interned label, including the fl_intern() collision path, is covered as well. New-label admission remains under the existing mem_check() policy. Use capable(CAP_NET_ADMIN) rather than ns_capable(), matching mem_check(). An unprivileged user must not bypass the cap by creating a user namespace and a netns where they have CAP_NET_ADMIN, which would still consume host memory. Check the capability only when the socket reaches the limit, so successful unprivileged GET requests below the cap do not generate a capability audit. Do the admission check before updating linger and expires so a rejected GET does not refresh the shared label, matching the existing socket-list allocation failure path. Fixes: 1da177e ("Linux-2.6.12-rc2") Cc: stable@vger.kernel.org Reported-by: Vega <vega@nebusec.ai> Suggested-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: Zhiling Zou <zhilinz@nebusec.ai> Reviewed-by: Eric Dumazet <edumazet@google.com> Reviewed-by: Ido Schimmel <idosch@nvidia.com> Link: https://patch.msgid.link/83f8535972ff6e3741548476a1d50dec24c758be.1788415194.git.zhilinz@nebusec.ai Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 74cb397 upstream. IPVS sync receivers validate protocol states before creating or updating a connection. For connection templates, however, they only log states outside the template state range and still store the value in the connection. A template can be returned by ordinary connection lookup. TCP and SCTP then use the invalid state as an index into their transition tables. Reject invalid template states in both sync protocol versions before looking up or modifying a connection. The version 1 path handles both IPv4 and IPv6 records. Fixes: 2754114 ("ipvs: add assured state for conn templates") Cc: stable@vger.kernel.org Assisted-by: Codex:gpt-5.6-sol Signed-off-by: Kyle Zeng <kylebot@openai.com> Acked-by: Julian Anastasov <ja@ssi.bg> Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 2f37fba upstream. The RX softirq producer ieee802154_subif_frame() queues received beacon and MAC-command frames onto local->rx_beacon_list / rx_mac_cmd_list and schedules a process-context worker, storing a raw mac_pkt->sdata (and skb->dev == sdata->dev) with neither a reference nor any locking: - the lists have no lock: the softirq producer list_add_tail()s while the mac_wq worker list_del()s, so sibling interfaces on the same phy corrupt the list; - the workers dereference the interface after it may have been freed. mac802154_rx_mac_cmd_worker() touches mac_pkt->sdata directly, and mac802154_rx_beacon_worker() -> mac802154_process_beacon() dereferences skb->dev (== sdata->dev). Removing an interface frees its sdata (netdev_priv) while a queued frame still points at it, so a later worker run is a use-after-free. Reproduced under KASAN by flooding a victim interface with MAC command frames and removing it (the beacon path is the same class via skb->dev): BUG: KASAN: slab-use-after-free in mac802154_rx_mac_cmd_worker+0x463/0x630 [mac802154] Read of size 4 at addr ffff888002f9ea18 by task kworker/u8:1/31 Workqueue: phy0-mac-cmds mac802154_rx_mac_cmd_worker [mac802154] Call Trace: mac802154_rx_mac_cmd_worker+0x463/0x630 [mac802154] process_one_work+0x611/0xe80 worker_thread+0x52e/0xdc0 kthread+0x30c/0x630 ret_from_fork+0x2fd/0x3e0 Fix both lists together: - add local->rx_lock and take it around every list access: the softirq producer (plain spin_lock, softirq context) and the workers and flush (spin_lock_bh, process context); - pin the interface for the lifetime of a queued frame with netdev_hold()/netdev_put(), so the worker can safely dereference sdata / skb->dev even while the interface is being removed; - dequeue under the lock at the head and loop-drain the whole list in the workers (they previously processed one frame per run and relied on a later enqueue to drain the rest); - drop not-yet-started frames of an interface before it is unregistered, from ieee802154_if_remove() (after the RCU grace period) and from the ieee802154_remove_interfaces() loop -- the latter is the whole-phy teardown path, which does not go through ieee802154_if_remove(). An in-flight worker that already dequeued a frame keeps its own netdev reference; unregister_netdevice() then waits it out in netdev_run_todo(), which runs at rtnl_unlock() (rtnl released) and after the interface has been closed, so it does not pin rtnl. A worker blocked in an association TX only delays that one interface's unregister (the usual "waiting for %s to become free"), it does not hold rtnl. netdev_hold() is used for this reason instead of a cancel_work_sync() under rtnl, which would block on the worker's unbounded MLME TX wait via ieee802154_sync_queue(). The mac-command worker additionally skips processing for a stopped interface (ieee802154_sdata_running()), avoiding a needless association response during teardown. Fixes: 57588c7 ("mac802154: Handle passive scanning") Cc: stable@vger.kernel.org Signed-off-by: Ibrahim Hashimov <security@auditcode.ai> Assisted-by: AuditCode-AI:2026.07 Reviewed-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/20260725135154.99876-1-security@auditcode.ai Signed-off-by: Stefan Schmidt <stefan@datenfreihafen.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 1144454 upstream. Set irqfd->producer only after kvmppc_set_passthru_irq() succeeds to avoid leaving a dangling pointer on failure. The bypass manager does not register a failed producer, so the pointer is never cleared. Fixes: c57875f ("KVM: PPC: Book3S HV: Enable IRQ bypass") Suggested-by: Sean Christopherson <seanjc@google.com> Cc: stable@vger.kernel.org Signed-off-by: leixiang <leixiang@kylinos.cn> Reviewed-by: Amit Machhiwal <amachhiw@linux.ibm.com> Reviewed-by: Vaibhav Jain <vaibhav@linux.ibm.com> Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com> Link: https://patch.msgid.link/20260709055755.31297-1-leixiang@kylinos.cn Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
…PE_RFX commit 20db657 upstream. When using a 5-level translation table via ZPCI_TABLE_TYPE_RFX get_rso_from_iova() returns NULL when the region-first entry is invalid. Yet in get_rto_from_iova() the region-second origin rso is not checked to be non-NULL before accessing rso[rsx] leading to a NULL pointer dereference instead of a NULL return when iova_to_phys() is called on a unmapped IOVA. Fix this by adding the missing NULL check. Cc: stable@vger.kernel.org Fixes: 8124407 ("iommu/s390: allow larger region tables") Signed-off-by: Niklas Schnelle <schnelle@linux.ibm.com> Reviewed-by: Benjamin Block <bblock@linux.ibm.com> Reviewed-by: Matthew Rosato <mjrosato@linux.ibm.com> Reviewed-by: Farhan Ali <alifm@linux.ibm.com> Signed-off-by: Joerg Roedel <joerg.roedel@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 74f27fc upstream. When HiperSockets interfaces on the same VCHID span different OS families, reads of the sysfs attributes bridge_role and bridge_state fail with -EPERM if bridge port ownership belongs to another OS family. As a result, userspace tools such as 'lszdev -ii' cannot retrieve bridge_role and bridge_state, even though firmware returns valid bridge port data for QUERY_BRIDGE_PORTS requests. The firmware reports IPA_RC_SBP_IQD_OS_MISMATCH (0x0010) to indicate that bridge port ownership belongs to a different OS family. For QUERY_BRIDGE_PORTS operations, firmware still returns valid bridge port data (role=none, state=inactive) together with a primary return code of 0x0000 (success). Allow QUERY_BRIDGE_PORTS requests to return the bridge port data provided by the firmware despite OS_MISMATCH. To make the OS family mismatch visible to userspace, represent the firmware-reported role "none" as "none (OS family mismatch)" while preserving the reported bridge_state. The behavior for non-QUERY bridge port commands is unchanged; SET operations continue to return -EPERM when another OS family owns the bridge port. This restores readability of bridge_role and bridge_state. Fixes: 1b05cf6 ("qeth: Include error message for "OS Mismatch"") Cc: stable@vger.kernel.org Suggested-by: Halil Pasic <pasic@linux.ibm.com> Reviewed-by: Alexandra Winter <wintera@linux.ibm.com> Signed-off-by: Nagamani PV <nagamani@linux.ibm.com> Link: https://patch.msgid.link/20260901155344.3561483-1-nagamani@linux.ibm.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 15fa028 upstream. The return codes from skcipher_walk_virt() were not properly checked before entering the processing loops in ecb_aes_crypt() and ctr_aes_crypt(). If skcipher_walk_virt() fails, the walk structure may be in an undefined state, and attempting to process data could lead to incorrect behavior or accessing uninitialized memory. Add proper return code checking to ensure correct handling of the walk initialization and walk advance and eventually return to the caller with that return code. Fixes: 7988fb2 ("crypto: s390/aes - convert to skcipher API") Signed-off-by: Harald Freudenberger <freude@linux.ibm.com> Reviewed-by: Holger Dengler <dengler@linux.ibm.com> Cc: stable@vger.kernel.org # 5.5+ Signed-off-by: Heiko Carstens <hca@linux.ibm.com> Signed-off-by: Vasily Gorbik <gor@linux.ibm.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit d1c44a7 upstream. The AES CTR implementation used a mutex to lock one page of exclusive memory for fast CTR processing. Unfortunately a mutex is not save to use in atomic or interrupt context. So use a binary semaphore instead which is save to use in such environments. Furthermore rework the code to get rid of conditional locking. So restructure the AES CRT code by extracting the main loop into a separate function and just give in information about the (locked) page can be used or not (is not locked). Fixes: 7988fb2 ("crypto: s390/aes - convert to skcipher API") Suggested-by: Heiko Carstens <hca@linux.ibm.com> Signed-off-by: Harald Freudenberger <freude@linux.ibm.com> Reviewed-by: Holger Dengler <dengler@linux.ibm.com> Cc: stable@vger.kernel.org # 5.5+ Signed-off-by: Heiko Carstens <hca@linux.ibm.com> Signed-off-by: Vasily Gorbik <gor@linux.ibm.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
…lgorithm commit 8b7c3b6 upstream. In function ctr_aes_crypt() there is a buffer used to process remaining bytes < AES_BLOCK_SIZE. This buffer was not scrubbed and thus could lead to expose of unwanted data. When the buffer is used explicitly scrub it at the end of the code block to avoid exposure of maybe sensitive data. In a similar way the function gcm_aes_crypt() hat an error path where the CPACF param block was not scrubbed. Instead of return early now these error paths go to end of function where explicit scrubbing is done. Similar with the buffers which are part of the gcm_sg_walk structs from the variables gw_in and gw_out. Fixes: d07f951 ("crypto: s390/aes - Fix buffer overread in CTR mode") Signed-off-by: Harald Freudenberger <freude@linux.ibm.com> Reviewed-by: Holger Dengler <dengler@linux.ibm.com> Cc: stable@vger.kernel.org # 6.8+ Signed-off-by: Heiko Carstens <hca@linux.ibm.com> Signed-off-by: Vasily Gorbik <gor@linux.ibm.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 5b97b96 upstream. The 4 algorithms implemented in paes_s390 never had any cra_flags set. So add code which sets the cra_flag to CRYPTO_ALG_ASYNC and CRYPTO_ALG_NO_FALLBACK. Fixes: 4ccd065 ("crypto: ahash - Add support for drivers with no fallback") Signed-off-by: Harald Freudenberger <freude@linux.ibm.com> Reviewed-by: Holger Dengler <dengler@linux.ibm.com> Cc: stable@vger.kernel.org # 6.17+ Signed-off-by: Heiko Carstens <hca@linux.ibm.com> Signed-off-by: Vasily Gorbik <gor@linux.ibm.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
…pto engine commit 3301483 upstream. When a request is transferred to the engine via crypto_transfer_hash_request_to_engine() there are two return codes signaling a successful transfer: EINPROGRESS and EBUSY. However the correct handling of EBUSY was missing and has been added as a return code indicating a successful transfer to the crypto engine. Fixes: cbbc675 ("crypto: s390 - New s390 specific protected key hash phmac") Signed-off-by: Harald Freudenberger <freude@linux.ibm.com> Reviewed-by: Holger Dengler <dengler@linux.ibm.com> Cc: stable@vger.kernel.org # 6.17+ Signed-off-by: Heiko Carstens <hca@linux.ibm.com> Signed-off-by: Vasily Gorbik <gor@linux.ibm.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 19a218b upstream. In function ctr_paes_do_crypt() there is a buffer used to process remaining bytes < AES_BLOCK_SIZE. This buffer was not scrubbed and thus could lead to expose of unwanted data. Rework the code to explicitly scrub the buffer at the end of the function to avoid exposure of maybe sensitive data. In function __xts_2keys_prep_param() change the existing scrub to clean the whole param block instead of just the key field. Fixes: 6cd87cb ("s390/crypto: Rework protected key AES for true asynch support") Signed-off-by: Harald Freudenberger <freude@linux.ibm.com> Reviewed-by: Holger Dengler <dengler@linux.ibm.com> Cc: stable@vger.kernel.org # 6.16+ Signed-off-by: Heiko Carstens <hca@linux.ibm.com> Signed-off-by: Vasily Gorbik <gor@linux.ibm.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit ac14813 upstream. When crypto_finalize_hash_request() or crypto_finalize_skcipher_request() explicitly completes a request, the do_one_request callback must return 0 to indicate successful handling. Returning a negative error code causes the crypto engine to assume the driver failed to take ownership and triggers a second completion via crypto_request_complete(), resulting in a double completion. This pattern occurs in paes_s390.c 4 times and once in phmac_s390.c. Fixed in phmac_do_one_request() and all four paes do_one_request callbacks (ecb, cbc, ctr, xts) by returning 0 after explicit finalization instead of propagating the error code. Fixes: 6cd87cb ("s390/crypto: Rework protected key AES for true asynch support") Signed-off-by: Harald Freudenberger <freude@linux.ibm.com> Reviewed-by: Holger Dengler <dengler@linux.ibm.com> Cc: stable@vger.kernel.org # 6.16+ Signed-off-by: Heiko Carstens <hca@linux.ibm.com> Signed-off-by: Vasily Gorbik <gor@linux.ibm.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 7a08507 upstream. When hardware persistently returns -EBUSY after exhausting retries, the error propagates to crypto_finalize_*_request(). The crypto API's completion wrapper treats -EBUSY as a queueing status and swallows it, preventing the completion callback from firing. This causes callers using crypto_wait_req() to block indefinitely. Translate persistent -EBUSY to -EIO after retry exhaustion to ensure proper error propagation and callback invocation. Fixes: 6cd87cb ("s390/crypto: Rework protected key AES for true asynch support") Signed-off-by: Harald Freudenberger <freude@linux.ibm.com> Reviewed-by: Holger Dengler <dengler@linux.ibm.com> Cc: stable@vger.kernel.org # 6.16+ Signed-off-by: Heiko Carstens <hca@linux.ibm.com> Signed-off-by: Vasily Gorbik <gor@linux.ibm.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 6809da6 upstream. The available-counter mask was a single unsigned long, but iteration uses RISCV_MAX_COUNTERS, which is 64. On RV32 that reads past the object. Filling with an unsigned-long bit at index 32 and above is also wrong. Use DECLARE_BITMAP and set_bit/bitmap helpers. Walk each bitmap word into CFG_MATCH when checking events, when allocating an index, and when stopping all counters. Set the counter base to i times BITS_PER_LONG. Share the CFG_MATCH ecall through a small helper so the 32-bit argument split is not duplicated. On qemu-system-riscv32 the probe bitmap has bits above XLEN set, so the first word alone is not enough. Fixes: e999143 ("RISC-V: Add perf platform driver based on SBI PMU extension") Assisted-by: DeepSeek:deepseek-v3 Signed-off-by: Xixin Liu <liuxixin@kylinos.cn> Link: https://patch.msgid.link/prpmask02cmap.v2.1786434000.git.liuxixin@kylinos.cn Cc: stable@kernel.org [pjw@kernel.org: updated to apply; fixed checkpatch.pl issues] Signed-off-by: Paul Walmsley <pjw@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 6693171 upstream. Overflow status and restart masks are u64, but bits were built with BIT(). On RV32 that is an unsigned long shift, so indices >= 32 truncate or wrap and corrupt the mask. Use BIT_ULL() for those u64 bitops. Fixes: a862521 ("drivers/perf: riscv: Implement SBI PMU snapshot function") Assisted-by: DeepSeek:deepseek-v3 Signed-off-by: Xixin Liu <liuxixin@kylinos.cn> Link: https://patch.msgid.link/prpmask01bitul.v2.1786434000.git.liuxixin@kylinos.cn Cc: stable@vger.kernel.org [pjw@kernel.org: updated to apply] Signed-off-by: Paul Walmsley <pjw@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
…iptors [ Upstream commit 4939889 ] In id_mode_to_cifs_acl(), aclflag was initialized to CIFS_ACL_DACL by default. This forced the client to request setting the DACL even when only an ownership (chown) or group (chgrp) change was being performed. Let build_sec_desc() do the proper flag calculation by initializing aclflag to 0. build_sec_desc() sets the appropriate bits (CIFS_ACL_OWNER, CIFS_ACL_GROUP, or CIFS_ACL_DACL) depending on what actually changed. During ownership transfer, CIFS_ACL_DACL is only set if replace_sids_and_copy_aces() actually replaces the SIDs inside any of the DACL's ACEs. If build_sec_desc() results in aclflag being 0 (meaning no changes were mapped), exit early to avoid sending an empty security descriptor update to the server. Signed-off-by: Ralph Boehme <slow@samba.org> Signed-off-by: Steve French <stfrench@microsoft.com> Stable-dep-of: d050451 ("smb: client: fail DACL rewrite when the new DACL exceeds 64K") Signed-off-by: Sasha Levin <sashal@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[ Upstream commit d050451 ] replace_sids_and_copy_aces() and set_chmod_dacl() accumulate the size of the DACL they build in a u16. That accumulator can wrap. validate_dacl() caps num_aces at (dacl_size - sizeof(struct smb_acl)) / 20, i.e. 3276 for a maximally sized DACL, while each rewritten ACE can grow to sizeof(struct smb_ace) (76 bytes) once its SID is replaced with one carrying SID_MAX_SUB_AUTHORITIES sub-authorities. The worst case is therefore sizeof(struct smb_acl) + 3276 * 76 = 248984 bytes, far beyond what a u16 can hold. A wraparound is reached with 863 ACEs. After the wraparound, ndacl_ptr->size becomes meaningless and the offset will point anywhere in the ACE array. As a result, we will see corruption of the DACL, which then gets sent to the server. This is not an out-of-bounds write as the allocation now covers the worst-case expansion, so writes will always go into the buffer. Adjust the code to use a u32 internally and return -EOVERFLOW in the overflow case. The operation must be refused, because a DACL can only hold 2^16-1 bytes on the wire and larger DACLs cannot be represented. set_chmod_dacl() carries the same pattern and is fixed the same way. It only wraps once the source DACL comes within roughly 380 bytes of the 64K ceiling, but the failure mode is identical. Suggested-by: Namjae Jeon <linkinjeon@kernel.org> Cc: stable@vger.kernel.org Fixes: f506550 ("cifs: Retain old ACEs when converting between mode bits and ACL.") Assisted-by: Kiro:claude-opus-5 Signed-off-by: Bjoern Doebel <doebel@amazon.de> Reviewed-by: Namjae Jeon <linkinjeon@kernel.org> Signed-off-by: Paulo Alcantara <pc@manguebit.org> Signed-off-by: Sasha Levin <sashal@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[ Upstream commit 4fc3a43 ] Use atomic_t for cifs_sb_info::mnt_cifs_flags as it's currently accessed locklessly and may be changed concurrently in mount/remount and reconnect paths. Signed-off-by: Paulo Alcantara (Red Hat) <pc@manguebit.org> Reviewed-by: David Howells <dhowells@redhat.com> Cc: linux-cifs@vger.kernel.org Signed-off-by: Steve French <stfrench@microsoft.com> [Backport to 6.18: retain the atomic mount-flag conversion while keeping this branch's existing function interfaces and locations. Implement cifs_sb_flags as a single-evaluation macro with the upstream unsigned return type; do not add functions or import the generic CIFS_SB helpers, inode-state changes, reconnect helpers, or oplock refactors. Convert the existing readers, including the legacy cache macros, to the accessor. Use atomic bit operations at existing update sites, including reset_cifs_unix_caps in connect.c, and publish the remount flag snapshot with atomic_set. Keep smb3_update_mnt_flags returning void. This supplies the accessor required by cd2b2b5 (smb: client: fix WSL reparse point uid/gid override), whose patch applies without changes.] [ sashal: Reduced backport -- upstream 4fc3a43 touches 27 file(s), this backport carries 25. Not backported here: fs/smb/client/cifs_unicode.h fs/smb/client/fs_context.h This note is generated from the file lists only; see the resolution record for the reasoning. ] Stable-dep-of: cd2b2b5 ("smb: client: fix WSL reparse point uid/gid override") Signed-off-by: Sasha Levin <sashal@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[ Upstream commit c06da4b ] At the moment the TTM code has a few places which exibit sub-optimal patterns regarding local variable usage: * Having a local with some object cached but not always using it. * Having a local for a single use object member access. * Failed opportunities to use a local to cache a pointer. Lets tidy this a little bit and apply some more consistency. It is mostly for consistency and redability but I have also checked that there are not negative code generation effects. In fact there are more positives: add/remove: 0/0 grow/shrink: 3/9 up/down: 12/-175 (-163) Function old new delta ttm_pool_restore_and_alloc 415 423 +8 ttm_bo_vunmap 147 149 +2 ttm_bo_evict 521 523 +2 ttm_bo_vm_fault_reserved 972 970 -2 ttm_bo_vm_dummy_page 155 152 -3 ttm_bo_vm_fault 203 196 -7 ttm_bo_populate 158 150 -8 ttm_bo_move_memcpy 600 592 -8 ttm_bo_kmap 667 644 -23 ttm_bo_shrink 333 305 -28 ttm_bo_release 750 720 -30 ttm_bo_swapout_cb 691 625 -66 Total: Before=42717, After=42554, chg -0.38% Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com> Reviewed-by: Thadeu Lima de Souza Cascardo <cascardo@igalia.com> Link: https://lore.kernel.org/r/20250919131530.91247-5-tvrtko.ursulin@igalia.com Acked-by: Christian König <christian.koenig@amd.com> Signed-off-by: Tvrtko Ursulin <tursulin@ursulin.net> [tursulin: fixup conflict in ttm_bo_move_pipeline_evict] Stable-dep-of: 941ac10 ("drm/ttm: Drop tt->restore after successful restore") Signed-off-by: Sasha Levin <sashal@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[ Upstream commit 941ac10 ] ttm_pool_restore_and_alloc() can successfully complete the restore process via ttm_pool_restore_commit(), but tt->restore is not dropped afterward. As a result, subsequent backup/restore flows observe what appears to be a completed restore, while in reality shmem handles are still installed in tt->pages, leading to the stack trace below. Fix this by freeing and dropping tt->restore in ttm_pool_restore_and_alloc() upon successful completion of the restore. 20545 [ 309.784531] RIP: 0010:sg_alloc_append_table_from_pages+0x38c/0x490 20547 [ 309.809570] RSP: 0018:ffffc9000623b838 EFLAGS: 00010206 20548 [ 309.814827] RAX: 0000000000001000 RBX: ffff88816e42a160 RCX: 0000000000000000 20549 [ 309.821986] RDX: 0000000000002000 RSI: 0000000000000003 RDI: 0000000000001000 20550 [ 309.829147] RBP: ffff88816e42a168 R08: 0000000000000002 R09: 000000007ffff000 20551 [ 309.836310] R10: ffffc9000623b928 R11: 0000000000000000 R12: 000000007ffff000 20552 [ 309.843471] R13: ffff88815ba5a100 R14: 0000000000000000 R15: 0000000000000001 20553 [ 309.850634] FS: 00007f9ff305e700(0000) GS:ffff888276c94000(0000) knlGS:0000000000000000 20554 [ 309.858749] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 20555 [ 309.864519] CR2: 00007f9fca701000 CR3: 00000001565e2005 CR4: 0000000008f70ef0 20556 [ 309.871678] PKRU: 55555558 20557 [ 309.874403] Call Trace: 20558 [ 309.876866] <TASK> 20559 [ 309.878988] sg_alloc_table_from_pages_segment+0x60/0x100 20560 [ 309.884415] ? ttm_resource_manager_usage+0x36/0x60 [ttm] 20561 [ 309.889845] ? xe_tt_map_sg+0x7d/0xd0 [xe] 20562 [ 309.894045] xe_tt_map_sg+0x7d/0xd0 [xe] 20563 [ 309.898037] xe_bo_move+0x927/0xaa0 [xe] 20564 [ 309.902029] ttm_bo_handle_move_mem+0xba/0x170 [ttm] 20565 [ 309.907022] ttm_bo_validate+0xbe/0x190 [ttm] 20566 [ 309.911405] xe_bo_validate+0x9a/0x120 [xe] 20567 [ 309.915663] xe_gpuvm_validate+0xd9/0x140 [xe] 20568 [ 309.920206] drm_gpuvm_validate+0x2f0/0x5b0 [drm_gpuvm] 20569 [ 309.925459] ? drm_exec_lock_obj+0x63/0x210 [drm_exec] 20570 [ 309.930627] xe_vm_validate_rebind+0x46/0xb0 [xe] 20571 [ 309.935428] xe_exec_fn+0x20/0x40 [xe] 20572 [ 309.939249] drm_gpuvm_exec_lock+0x78/0xc0 [drm_gpuvm] 20573 [ 309.944410] xe_validation_exec_lock+0x5a/0xa0 [xe] 20574 [ 309.949385] xe_exec_ioctl+0x806/0xc30 [xe] 20575 [ 309.953639] ? ttwu_queue_wakelist+0xd9/0xf0 20576 [ 309.957935] ? __pfx_xe_exec_fn+0x10/0x10 [xe] 20577 [ 309.962449] ? __wake_up_common+0x73/0xa0 20578 [ 309.966482] ? __pfx_xe_exec_ioctl+0x10/0x10 [xe] 20579 [ 309.971263] drm_ioctl_kernel+0xa3/0x100 20580 [ 309.975209] drm_ioctl+0x213/0x440 20581 [ 309.978637] ? __pfx_xe_exec_ioctl+0x10/0x10 [xe] 20582 [ 309.983415] xe_drm_ioctl+0x67/0xd0 [xe] 20583 [ 309.987408] __x64_sys_ioctl+0x7f/0xd0 Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com> Cc: Christian Koenig <christian.koenig@amd.com> Cc: Huang Rui <ray.huang@amd.com> Cc: Matthew Auld <matthew.auld@intel.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Maxime Ripard <mripard@kernel.org> Cc: Thomas Zimmermann <tzimmermann@suse.de> Cc: David Airlie <airlied@gmail.com> Cc: Simona Vetter <simona@ffwll.ch> Cc: dri-devel@lists.freedesktop.org Cc: linux-kernel@vger.kernel.org Cc: stable@vger.kernel.org Fixes: b63d715 ("drm/ttm/pool, drm/ttm/tt: Provide a helper to shrink pages") Signed-off-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Link: https://patch.msgid.link/20260617015531.1164189-1-matthew.brost@intel.com Signed-off-by: Sasha Levin <sashal@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 91d7e9d upstream. When allocating a lot of buffers and putting the TTM under memory pressure, during swapout, it might crash the system with the stack trace below. It turns out that ttm_bo_swapout_cb might replace bo->resource when it moves it to system cached. When commit c06da4b ("drm/ttm: Tidy usage of local variables a little bit") used a local variable for bo->resource, it used the freed resource later in the function, leading to a UAF. Move back to using bo->resource in all cases in that function instead of a local variable. [ 604.814275] BUG: kernel NULL pointer dereference, address: 0000000000000000 [ 604.814284] #PF: supervisor read access in kernel mode [ 604.814288] #PF: error_code(0x0000) - not-present page [ 604.814291] PGD 0 P4D 0 [ 604.814296] Oops: Oops: 0000 [#1] SMP NOPTI [ 604.814303] CPU: 2 UID: 0 PID: 4408 Comm: vulkan Tainted: G W 7.0.0-rc2-00001-gc50a051e6aca raspberrypi#21 PREEMPT(full) aef6eb0c02036a7c8a5e62e0c84a30c2be90688d [ 604.814309] Tainted: [W]=WARN [ 604.814311] Hardware name: Valve Jupiter/Jupiter, BIOS F7A0133 08/05/2024 [ 604.814314] RIP: 0010:ttm_resource_move_to_lru_tail+0x100/0x160 [ttm] [ 604.814329] Code: 5b 5d e9 83 b4 1b cb 48 63 d2 48 c1 e0 04 48 8b 4e 40 48 8d 7e 40 48 8b ac d3 d8 00 00 00 48 89 c3 48 8d 54 05 68 48 8b 46 48 <48> 3b 38 0f 85 b3 3b 00 00 48 3b 79 08 0f 85 a9 3b 00 00 48 89 41 [ 604.814332] RSP: 0018:ffffcfe54e3d7578 EFLAGS: 00010256 [ 604.814336] RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffff8cf09eced300 [ 604.814339] RDX: 0000000000000068 RSI: ffff8cf1d4c1fc00 RDI: ffff8cf1d4c1fc40 [ 604.814341] RBP: 0000000000000000 R08: ffff8cf09eced300 R09: 0000000000000000 [ 604.814344] R10: 0000000000000000 R11: 0000000000000016 R12: ffff8cf1d4c1fc00 [ 604.814346] R13: 0000000000000400 R14: ffff8cf096289c00 R15: ffff8cf084c8f688 [ 604.814349] FS: 00007f00531b7780(0000) GS:ffff8cf4217a0000(0000) knlGS:0000000000000000 [ 604.814352] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 604.814355] CR2: 0000000000000000 CR3: 000000018e3df000 CR4: 0000000000350ef0 [ 604.814358] Call Trace: [ 604.814362] <TASK> [ 604.814368] ttm_bo_swapout_cb+0x24c/0x280 [ttm a469cf7fcb6737fdcf3fb5cdbcc8b1ca41f3e302] [ 604.814380] ttm_lru_walk_for_evict+0xac/0x1d0 [ttm a469cf7fcb6737fdcf3fb5cdbcc8b1ca41f3e302] [ 604.814394] ttm_bo_swapout+0x5b/0x80 [ttm a469cf7fcb6737fdcf3fb5cdbcc8b1ca41f3e302] [ 604.814405] ttm_global_swapout+0x63/0x100 [ttm a469cf7fcb6737fdcf3fb5cdbcc8b1ca41f3e302] [ 604.814415] ttm_tt_populate+0x82/0x130 [ttm a469cf7fcb6737fdcf3fb5cdbcc8b1ca41f3e302] [ 604.814424] ttm_bo_populate+0x37/0xa0 [ttm a469cf7fcb6737fdcf3fb5cdbcc8b1ca41f3e302] [ 604.814433] ttm_bo_handle_move_mem+0x157/0x170 [ttm a469cf7fcb6737fdcf3fb5cdbcc8b1ca41f3e302] [ 604.814443] ttm_bo_validate+0xd9/0x180 [ttm a469cf7fcb6737fdcf3fb5cdbcc8b1ca41f3e302] [ 604.814453] ttm_bo_init_reserved+0xa0/0x1b0 [ttm a469cf7fcb6737fdcf3fb5cdbcc8b1ca41f3e302] [ 604.814461] ? srso_return_thunk+0x5/0x5f [ 604.814469] amdgpu_bo_create+0x1f5/0x500 [amdgpu 361516226706227f4403914dbfdd3f90996136ca] [ 604.814855] ? __pfx_amdgpu_bo_user_destroy+0x10/0x10 [amdgpu 361516226706227f4403914dbfdd3f90996136ca] [ 604.815182] amdgpu_bo_create_user+0x3d/0x70 [amdgpu 361516226706227f4403914dbfdd3f90996136ca] [ 604.815504] amdgpu_gem_create_ioctl+0x16c/0x3b0 [amdgpu 361516226706227f4403914dbfdd3f90996136ca] [ 604.815830] ? __pfx_amdgpu_bo_user_destroy+0x10/0x10 [amdgpu 361516226706227f4403914dbfdd3f90996136ca] [ 604.816155] ? __pfx_amdgpu_gem_create_ioctl+0x10/0x10 [amdgpu 361516226706227f4403914dbfdd3f90996136ca] [ 604.816478] drm_ioctl_kernel+0xae/0x100 [ 604.816486] drm_ioctl+0x283/0x510 [ 604.816491] ? __pfx_amdgpu_gem_create_ioctl+0x10/0x10 [amdgpu 361516226706227f4403914dbfdd3f90996136ca] [ 604.816819] amdgpu_drm_ioctl+0x4a/0x80 [amdgpu 361516226706227f4403914dbfdd3f90996136ca] [ 604.817135] __x64_sys_ioctl+0x96/0xe0 [ 604.817142] do_syscall_64+0x11b/0x7e0 [ 604.817148] ? srso_return_thunk+0x5/0x5f [ 604.817152] ? srso_return_thunk+0x5/0x5f [ 604.817156] ? walk_system_ram_range+0xb0/0x110 [ 604.817161] ? srso_return_thunk+0x5/0x5f [ 604.817165] ? __pte_offset_map+0x1b/0xb0 [ 604.817170] ? srso_return_thunk+0x5/0x5f [ 604.817174] ? pte_offset_map_lock+0x87/0xf0 [ 604.817179] ? srso_return_thunk+0x5/0x5f [ 604.817183] ? insert_pfn+0x9f/0x1f0 [ 604.817188] ? srso_return_thunk+0x5/0x5f [ 604.817192] ? vmf_insert_pfn_prot+0x97/0x190 [ 604.817197] ? srso_return_thunk+0x5/0x5f [ 604.817201] ? ttm_bo_vm_fault_reserved+0x1a6/0x3f0 [ttm a469cf7fcb6737fdcf3fb5cdbcc8b1ca41f3e302] [ 604.817213] ? srso_return_thunk+0x5/0x5f [ 604.817217] ? amdgpu_gem_fault+0xe2/0x100 [amdgpu 361516226706227f4403914dbfdd3f90996136ca] [ 604.817542] ? srso_return_thunk+0x5/0x5f [ 604.817546] ? __do_fault+0x33/0x180 [ 604.817550] ? srso_return_thunk+0x5/0x5f [ 604.817554] ? do_fault+0x178/0x610 [ 604.817559] ? srso_return_thunk+0x5/0x5f [ 604.817562] ? __handle_mm_fault+0x9be/0x1120 [ 604.817567] ? srso_return_thunk+0x5/0x5f [ 604.817574] ? srso_return_thunk+0x5/0x5f [ 604.817578] ? count_memcg_events+0xc4/0x160 [ 604.817583] ? srso_return_thunk+0x5/0x5f [ 604.817587] ? handle_mm_fault+0x1d7/0x2e0 [ 604.817593] ? srso_return_thunk+0x5/0x5f [ 604.817596] ? do_user_addr_fault+0x173/0x660 [ 604.817602] ? srso_return_thunk+0x5/0x5f [ 604.817607] entry_SYSCALL_64_after_hwframe+0x76/0x7e [ 604.817612] RIP: 0033:0x7f00532cef4d [ 604.817617] Code: 04 25 28 00 00 00 48 89 45 c8 31 c0 48 8d 45 10 c7 45 b0 10 00 00 00 48 89 45 b8 48 8d 45 d0 48 89 45 c0 b8 10 00 00 00 0f 05 <89> c2 3d 00 f0 ff ff 77 1a 48 8b 45 c8 64 48 2b 04 25 28 00 00 00 [ 604.817620] RSP: 002b:00007ffd69ab0650 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 [ 604.817624] RAX: ffffffffffffffda RBX: 00007ffd69ab07d0 RCX: 00007f00532cef4d [ 604.817627] RDX: 00007ffd69ab0700 RSI: 00000000c0206440 RDI: 0000000000000005 [ 604.817629] RBP: 00007ffd69ab06a0 R08: 00007f00533a0ac0 R09: 0000000000000000 [ 604.817632] R10: 00007ffd69ab07c0 R11: 0000000000000246 R12: 00007ffd69ab0700 [ 604.817634] R13: 00000000c0206440 R14: 0000000000000005 R15: 0000000000000243 [ 604.817642] </TASK> Cc: Tvrtko Ursulin <tvrtko.ursulin@igalia.com> Cc: Christian König <christian.koenig@amd.com> Fixes: c06da4b ("drm/ttm: Tidy usage of local variables a little bit") Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@igalia.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com> Signed-off-by: Tvrtko Ursulin <tursulin@ursulin.net> Link: https://lore.kernel.org/r/20260304-ttm_bo_res_uaf-v1-1-43f20125b67f@igalia.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 1bb5c32 upstream. Add two checks for devm_kasprintf() errors in create_misc_rmi_device(), returning -ENOMEM if the function failed. Assisted-by: gkh_clanker_t1000 CC: Arnd Bergmann <arnd@arndb.de> CC: Greg Kroah-Hartman <gregkh@linuxfoundation.org> CC: Naveen Krishna Chatradhi <naveenkrishna.chatradhi@amd.com> CC: Akshay Gupta <Akshay.Gupta@amd.com> Signed-off-by: Griffin Kroah-Hartman <griffin@kroah.com> Link: https://patch.msgid.link/20260709132052.211683-1-griffin@kroah.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 7da514d upstream. It turns out that commit 5fce676 ("x86/mm/pat: Don't gate cpa_lock on debug_pagealloc_enabled()") was a little too quick to remove the debug_pagealloc exception for cpa_lock. Notably __kernel_map_pages() is used by the page-allocator from any context the page-allocator itself is used, which violates the cpa_lock rules. Re-instate the exception, except make it specific to the __kernel_map_pages() such that any other cpa() usage is still fully serialized by cpa_lock. Also note that since cpa() should not be used on memory that isn't allocated, the page-allocator locking and cpa are infact mutually exclusive and all cpa usage in fully serialized. Add a comment explaining this and other 'funnies' surrounding DEBUG_PAGEALLOC, including how pgd_lock is not affected and the TLB trickery. Fixes: 5fce676 ("x86/mm/pat: Don't gate cpa_lock on debug_pagealloc_enabled()") Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Link: https://patch.msgid.link/20260729111119.604452135@infradead.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 6cafe51 upstream. This allow separating the stale logic invocation and the retrans scheduler, and will simplify the next patch. It's also a cleaner design as the retrans scheduler has currently too many side effects. As a possible downside, the retrans work will now traverse the subflows list additional times; that does not matter much, as this is slowpath. While at it, pick more accurate names for the involved helpers and explicitly note that the per subflow stale data is under msk socket lock protection. The scheduler and the stale logic may observe different subflow statues, as no subflow lock is acquired. This is intentional and not harmful, worst case leading to slower retransmissions. Signed-off-by: Paolo Abeni <pabeni@redhat.com> Reviewed-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Link: https://patch.msgid.link/20260807-net-next-mptcp-oooq-pruning-v3-2-dbc1eb853cc3@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org> Stable-dep-of: 2b0f561 ("mptcp: avoid unneeded actions on subflow reset") Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 2b0f561 upstream. Once in a blue moon, the mptcp receive path can recursively call mptcp_data_ready() via state change under unlucky error conditions, and then try to hold the data lock again. Break the recursion loop explicitly checking for the exceptional condition. Add a new flag instead of using an existing one like 'closing', to exit early in subflow_state_change(), and explicitly flush the RX queue at reset time. This avoids unneeded processing to check for available data -- calling get_mapping_status() and more on a dying subflow -- but also in error reporting and worker scheduling. Note that we must consume the currently peeked skb before invoking mptcp_dss_corruption to avoid consuming it again after the eventual reset has freed it. Fixes: e32d262 ("mptcp: handle consistently DSS corruption") Cc: stable@vger.kernel.org Reported-by: Xinyang Ge <xinyang@anthropic.com> Signed-off-by: Paolo Abeni <pabeni@redhat.com> Reviewed-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Link: https://patch.msgid.link/20260917-net-mptcp-misc-fixes-7-3-rc4-v2-1-0cf5c72667c8@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 42064de upstream. The mptcp scheduler may race with subflow sockets state change: data transmission on the selected socket may fail and a later release could try to use mss_now reset to 0 for a divide operation. Address the issue by explicitly checking for the critical scenario. Fixes: c886d70 ("mptcp: do not queue data on closed subflows") Cc: stable@vger.kernel.org Reported-by: Shardul Bankar <shardul.b@mpiricsoftware.com> Reported-by: Xinyang Ge <xinyang@anthropic.com> Closes: https://lore.kernel.org/20260525194828.1137119-1-shardul.b@mpiricsoftware.com Signed-off-by: Paolo Abeni <pabeni@redhat.com> Reviewed-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Link: https://patch.msgid.link/20260917-net-mptcp-misc-fixes-7-3-rc4-v2-2-0cf5c72667c8@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit f3ef033 upstream. If __subflow_push_pending() errors out we should avoid updating the copied byte counters, to avoid mismatch push call later on. Fixes: 0fa1b37 ("mptcp: use get_send wrapper") Cc: stable@vger.kernel.org Signed-off-by: Paolo Abeni <pabeni@redhat.com> Reviewed-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Link: https://patch.msgid.link/20260917-net-mptcp-misc-fixes-7-3-rc4-v2-3-0cf5c72667c8@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Link: https://lore.kernel.org/r/20260917151551.901433442@linuxfoundation.org Tested-by: Brett A C Sheffield <bacs@librecast.net> Tested-by: Florian Fainelli <florian.fainelli@broadcom.com> Tested-by: Pavel Machek (CIP) <pavel@nabladev.com> Tested-by: Peter Schneider <pschneider1968@googlemail.com> Tested-by: Ron Economos <re@w6rz.net> Tested-by: Barry K. Nathan <barryn@pobox.com> Tested-by: Miguel Ojeda <ojeda@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
vc4 provided no get_scanout_buffer(), so drm_panic_register() skipped every plane and nothing was drawn when the kernel panicked - and with CONFIG_DRM_PANIC_DEBUG the dri/N/drm_panic_plane_x files never appeared either. Framebuffers are drm_gem_dma objects, so the generic DMA helper does the job: it hands the panic handler the already mapped CPU address, without vmapping in panic context. Imported dmabufs and non-linear modifiers are rejected by the helper, so a compositor's buffers are still skipped, but the fbdev console - the case that matters when the machine dies - works. Only the primary planes get it, as every other user of drm_fb_dma_get_scanout_buffer() does, which costs a second copy of the helper funcs per generation. Tested on a Pi 500: one plane per CRTC registers, and a panic (as well as the debugfs trigger) paints the panic screen, including the full backtrace with drm.panic_screen=kmsg. Signed-off-by: Dom Cobley <popcornmix@gmail.com>
This reverts commit a3c61d6.
This reverts commit 10214ef.
Newer versions of the DesignWare I2C block support the detection of stuck signals, and a mechanism to recover from them. Add the required software support to the driver. This change was prompted by the observation that reading a single byte from register 0 of a VEML7700 seems to cause it to issue an ACK too early, and the controller to complain about losing arbitration. There is a suspicion that this may be a more widespread problem, but at least this patch prevents the bus from locking up. See: raspberrypi#6057 Signed-off-by: Phil Elwell <phil@raspberrypi.com>
Prior to this change, every stream start was subject to a 1 second delay to allow for the microphone circuitry to settle, even if a microphone is not being used. This blocking delay, as well as being pointless for non- capture applications, can be problematic for synchronous use-cases such as alsa_recover() in PipeWire. Add a dedicated widget to handle the microphone delay, and link it into the microphone routes. See: raspberrypi#7525 Signed-off-by: Phil Elwell <phil@raspberrypi.com>
A panic often leaves whatever was on screen in place(*), so anyone
without a serial console sees a machine that simply stops. With
DRM_PANIC_SCREEN="kmsg" the tail of the kernel log, backtrace included,
is painted over the display, which a user can photograph and attach to
a bug report.
(*) In testing a panic did show from a framebuffer console, but not from
desktop (labwc) or other userspace owner of the DRM display (e.g. kodi).
Cost, measured with the option on and off:
vmlinux no change - DRM is a module in every config,
and fbcon already selects FONT_SUPPORT
drm.ko (arm64) +8873 bytes
drm.ko (arm, bcmrpi) +8048 bytes
That is drm_panic.o plus the drm_draw.o it selects. Nothing grows per
device or per plane: drm_mode_config.panic_lock and
drm_plane.kmsg_panic are unconditional struct members already. The only
addition to normal operation is one raw_spin_lock_irqsave()/unlock pair
per atomic commit, around the plane state swap in
drm_atomic_helper_swap_state(); the rest runs only from the panic
handler.
The panic screen is not guaranteed to appear, which is worth knowing
before relying on it. drm_fb_dma_get_scanout_buffer() only accepts a
linear, CPU-mapped buffer that was not imported from another device, so
a client scanning out a tiled or SAND buffer - Kodi playing video, say
- gets no panic screen at all, and it fails silently.
Tested on a Pi 500: a panic is displayed on the fbdev console,
over the kodi gui (if video is not playing) and on a labwc desktop.
With current settings the systemd watchdog reboots us after 30s.
Signed-off-by: Dom Cobley <popcornmix@gmail.com>
vc4_write_ppf() treated anything on channel 1 as being subsampled 2x in the axis being programmed: it halved the source coordinate, applied a 1/4 chroma-pixel centring offset instead of 1/2, and scaled the chroma siting by 17 bits rather than 16. That only holds for 4:2:0. For 4:2:2 the chroma plane is full height - src_h[1] == src_h[0], and the vertical PPF is force-enabled so that unity-scaled planes render at all - and for 4:4:4 the chroma plane is full resolution in both axes. In those cases the chroma phase came out at half the luma phase, displacing chroma by a quarter of a pixel against the luma. Take the subsampling for the axis being programmed from the format and derive the phase from it, rather than from the channel number. The calculation is now done in luma pixels throughout and converted to the channel's pixels at the end, which for 4:2:0 gives a bit-identical phase to before. Fixes: ac69c01 ("drm/vc4: plane: Handle fractional coordinates using the phase field") Signed-off-by: Dom Cobley <popcornmix@gmail.com>
Chroma siting describes where the chroma samples sit relative to the luma samples, so it only says anything on an axis that is actually subsampled. On a full-resolution axis - vertically for 4:2:2, both axes for 4:4:4 - the chroma is by definition cosited with the luma, but the property was applied there regardless, shifting the chroma away from the luma. Fixes: b7fcc0d ("vc4/drm:plane: Make use of chroma siting parameter") Signed-off-by: Dom Cobley <popcornmix@gmail.com>
vc4_write_ppf() starts the phase at
(src_x - siting - 1/2) / subsample
but output pixel r samples the source at (r + 1/2) * scale - 1/2, so
the initial phase also needs half a destination pixel's worth of
source:
(src_x - siting - 1/2) / subsample + scale/2
Without it everything the PPF touches is displaced by half a
destination pixel's worth of source. For 4:2:0 chroma composited 1:1
that is 0.25 chroma pixels, i.e. half a luma line, and since the luma
at 1:1 goes through SCALING_NONE rather than the PPF, the chroma ends
up half a line adrift of the luma it belongs to.
Measured on a Pi 5 by compositing a synthetic 4:2:0 frame 1:1 and
capturing it through the writeback connector: with cosited chroma and
CHROMA_SITING_V=0 the chroma came back 0.371 luma rows early (0.378
rows on the horizontal axis), against a luma control that measured
0.000. The siting properties themselves scale correctly at -1.00 luma
pixels per unit.
Fixes: ac69c01 ("drm/vc4: plane: Handle fractional coordinates using the phase field")
Signed-off-by: Dom Cobley <popcornmix@gmail.com>
The chroma siting properties defaulted to (0, 0), placing the chroma
samples on the top-left luma sample. MPEG-2, H.264 and HEVC 4:2:0 are
horizontally cosited but vertically interstitial, so the default left
typical video content half a luma line out unless userspace knew about
this property - which is downstream-only - and set it.
Default to (0, 0x8000) instead, which is right for the common case.
This is only an improvement once the PPF phase is right. Measured on a
Pi 5 by compositing a synthetic 4:2:0 frame 1:1 and capturing it
through the writeback connector, PSNR against an ideal reference,
whole frame:
SITING_V=0 SITING_V=0.5
before the scale/2 fix 21.01 dB 20.67 dB
after 20.21 dB 21.20 dB
Before that fix the pipeline sampled chroma 0.38 luma rows early, which
a siting of 0 partly cancelled and 0.5 made worse - so this change on
its own would have been a regression.
Signed-off-by: Dom Cobley <popcornmix@gmail.com>
The PPF is a 4-tap filter with 64 phases. Only 8 key phases are stored -
32 coefficients, indexed tap * 8 + phase - and the hardware linearly
interpolates the other 56 from them. The key phases sit at 0, 1/8, ...,
7/8 of a source pixel.
The Mitchell-Netravali table was tabulated at (p + 1/2) / 8 instead:
1/16, 3/16, ..., 15/16. Every stored phase, and therefore every
interpolated one, was half a key phase - 1/16 of a source pixel - late.
For 4:2:0 chroma composited 1:1 that is an eighth of a luma line, on
both axes, and it does not respond to CHROMA_SITING because the siting
moves the requested phase and this moved the realised one.
It was tabulated that way because vc4_hvs_upload_linear_kernel() only
took the first 16 coefficients and mirrored them, which requires
f(p) + f(7 - p) == 1, and (p + 1/2) / 8 is the only spacing that gives
that. The hardware stores all 32 coefficients and has no such
requirement, so write all 32 and put the key phases where they belong.
The nearest-neighbour kernel is unchanged: the new macro emits exactly
the dwords the old mirroring did for a symmetric table.
While at it the coefficients are rounded so that every phase sums to
exactly 256 and is within 0.63 counts of the ideal kernel. Phases 0 and
7 were out by up to 5.7 counts and summed to 247, and SCALER_PPF_AGC
fixes a bad sum by rewriting the largest coefficient, so those two
phases had their dominant tap inflated from 227 to 236 and smoothed
noticeably less than the other six.
Measured on a Pi 5 through the writeback connector, chroma sampling
offset against the source's own siting, in luma pixels:
vertical horizontal
old table +0.125 +0.123
this table +0.011 +0.021
luma control 0.000 0.000
The old table's own centroids predicted +0.129 and this one's 0.000.
4:2:2 vertical chroma, which the old table put at +0.037, now measures
0.000. PSNR of an interstitially-sited 4:2:0 test frame against its
ideal now peaks with CHROMA_SITING_V at 0.5, where it should; with the
old table the peak was at 0.625.
Fixes: 21af94c ("drm/vc4: Add support for scaling of display planes.")
Signed-off-by: Dom Cobley <popcornmix@gmail.com>
Copy the led-modes DT property from the Broadcom PHYs, with a translation table to equivalent settings for this PHY. Signed-off-by: Phil Elwell <phil@raspberrypi.com>
Add a led-modes property as an instruction to other PHYs to accept Broadcom-compatible configuration. The default values are the same as the defaults in the Broadcom driver. Signed-off-by: Phil Elwell <phil@raspberrypi.com>
…CD (E) The automatic panel detection introduced in a previous merge turned out to be unfriendly for customer use after some hands-on testing. Remove the extra detection and rotation handling and keep only the default landscape configuration. Expose the 10.1inch E panel as explicit 4-lane (60fps) and 2-lane (30fps) variants instead. Signed-off-by: Goodwill <646689853@qq.com>
…10.1inch E variants The automatic detection overlay parameter turned out to be unfriendly for customer use. Replace it with explicit 10_1_inchE_4lane and 10_1_inchE_2lane parameters matching the new driver compatible strings, keeping only the default landscape orientation. Signed-off-by: Goodwill <646689853@qq.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
20 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Reverts the automatic panel detection previously added for the
Waveshare 10.1inch DSI LCD (E) and replaces it with two explicit
overlay parameters:
10_1_inchE_4lane— 1920x1200 @ 60fps, 4 DSI lanes10_1_inchE_2lane— 1920x1200 @ 30fps, 2 DSI lanesWhy
After the auto-detection support was merged, several people tested it
and found the behaviour unfriendly for end customers:
unexpected mode/rotation depending on the panel controller state,
requiring manual intervention;
This change removes the auto-detect code path (I2C reads, rotation
handling and the portrait 1200x1920 modes) and keeps only the default
landscape orientation. The panel variant is now chosen explicitly via
the overlay parameter, and the driver writes the desired refresh rate
to register 0xd0 accordingly.
Commits
drm/panel: panel-waveshare-dsi: Drop auto-detection on 10.1inch DSI LCD (E)— driver side: remove
ws_panel_auto_detect(),ws_panel_i2c_read()and the portrait modes; add
ws_panel_10_1_e_4lane/2lane_dataand afps_reg_valfield instruct ws_panel_data.dts: overlays: vc4-kms-dsi-waveshare-panel: Replace auto_detect with 10.1inch E variants— overlay/README side: replace the
auto_detectparameter with10_1_inchE_4lane/10_1_inchE_2lane.The
auto_detectoverlay parameter is removed. Users currently booting withmust switch to
10_1_inchE_4lane(60fps panels) or10_1_inchE_2lane(30fps panels) after upgrading.
Testing
Tested on Raspberry Pi 5 with the Waveshare 10.1inch DSI LCD (E):
Notes
waveshare,10.1inch-e-{4,2}lane-panel)are not yet documented in the DT bindings; a follow-up PR will add
them together with the other undocumented Waveshare panel compatibles.