kernel/git/next/linux-next.git/drivers/char, branch master

Merge branch 'headers' of git://git.infradead.org/users/willy/pagecache.git

2026-09-07T13:49:19+00:00

# Conflicts: # net/ceph/osd_client.c

Merge branch 'linux-next' of https://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost.git

2026-09-07T13:47:54+00:00

Merge branch 'for-next-tpm' of https://git.kernel.org/pub/scm/linux/kernel/git/jarkko/linux-tpmdd.git

2026-09-07T13:27:35+00:00

Merge branch 'master' of https://git.kernel.org/pub/scm/linux/kernel/git/herbert/cryptodev-2.6.git

2026-09-07T12:26:33+00:00

Merge https://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm.git mm-unstable into for-next

2026-09-07T07:49:10+00:00

Signed-off-by: David Hildenbrand (Arm)

mm: move drivers/char/mem.c to mm/char-mem.c

2026-09-06T03:22:28+00:00

Patch series "mm: make MAP_PRIVATE-/dev/zero mappings truly anonymous". Historically anonymous memory was obtained in linux by MAP_PRIVATE-mapping /dev/zero. The canonical way of doing these now is mmap() specifying MAP_PRIVATE | MAP_ANON, but we must continue to support the legacy means of obtaining these mappings. As-is these mappings are an unusual edge-case - they satisfy vma_is_anonymous() but have non-NULL vma->vm_file, and their page offset is the offset into the /dev/zero file. Commit 93c0c8dc87f6 ("mm/rmap: use anon pgoff to track MAP_PRIVATE file-backed anon folios") causes all other anonymous folios to be tracked by their anon index (vma->vm_start >> PAGE_SHIFT at the point of first fault), leaving MAP_PRIVATE-/dev/zero as the outlier. This series remedies the situation by making MAP_PRIVATE-/dev/zero mappings truly anonymous with !vma->vm_file and correct anonymous page offset. It starts by bringing the memory character driver into mm/ - this file implements /dev/zero, /dev/mem among other things and is already (as clearly indicated by its name) within the remit of memory management. By doing this, the file_is_dev_zero() function can be provided, internal to mm, which allows for positive identification of these mappings. Using this, first prevent any other mappings from mapping memory anonymously, then make these mappings truly anonymous and eliminate all code in the kernel that previously had to account for these strange beasts. Finally, it adds userland VMA tests to assert the behaviour and selftests to assert expected merge behaviour. This patch (of 6): The memory character driver implements several mm-specific features and is always compiled into the kernel, so move it to mm/ where it belongs. Among other things the driver implements /dev/mem which provides raw access to physical memory, and /dev/zero which either allows mapping of a shmem region (if mapped with MAP_SHARED) or, uniquely, anonymous memory (if mapped MAP_PRIVATE). This change lays the foundations to allow MAP_PRIVATE-/dev/zero to be mapped precisely the same as anonymous memory is mapped as currently it is an edge case within mm. Also update a couple of comments that reference 'drivers/char/mem.c' to reference 'mm/char-mem.c'. Link: https://lore.kernel.org/20260902-map-private-dev-zero-v1-0-a578c730cec7@kernel.org Link: https://lore.kernel.org/20260902-map-private-dev-zero-v1-1-a578c730cec7@kernel.org Signed-off-by: Lorenzo Stoakes (ARM) Acked-by: Mike Rapoport (Microsoft) Cc: Arnd Bergmann Cc: Baolin Wang Cc: David Hildenbrand Cc: Greg Kroah-Hartman Cc: Hugh Dickins Cc: Jan Kara Cc: Jann Horn Cc: Liam R. Howlett Cc: Matthew Wilcox (Oracle) Cc: Michal Hocko Cc: Pedro Falcato Cc: Suren Baghdasaryan Cc: Vlastimil Babka Signed-off-by: Andrew Morton

virtio_console: allocate the port_buffer with the caller's gfp

2026-09-05T17:28:39+00:00

put_chars() runs from the hvc console write path with preemption disabled, so it asks alloc_buf() for GFP_ATOMIC. Only the data buffer gets it: the struct port_buffer itself keeps the GFP_KERNEL default, so the allocation can enter direct reclaim and sleep. A write to /dev/kmsg on a CONFIG_DEBUG_ATOMIC_SLEEP kernel splats: BUG: sleeping function called from invalid context at ./include/linux/sched/mm.h:320 in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 1, name: virtme-ng-init preempt_count: 1, expected: 0 Preemption disabled at: [] vprintk_emit+0x17d/0x510 Call Trace: dump_stack_lvl+0x69/0xa0 __might_resched+0x37a/0x4d0 __kmalloc_cache_noprof+0x94/0x5f0 put_chars+0x209/0x3e0 hvc_console_print+0x234/0x640 console_flush_all+0x4fc/0x950 console_unlock+0xbf/0x1b0 vprintk_emit+0x312/0x510 devkmsg_emit+0xba/0x110 devkmsg_write+0x21b/0x2e0 vfs_write+0x4dc/0x9d0 ksys_write+0x108/0x1e0 do_syscall_64+0xfa/0x460 Pass gfp on to that allocation too. Fixes: fc220d6be3c7 ("virtio_console: refactor __send_to_port() buffer ownership") Signed-off-by: Breno Leitao Acked-by: Sungho Bae Tested-by: Florian Westphal Link: https://patch.msgid.link/20260810-serial-v1-1-abbe51602c13@debian.org Signed-off-by: Greg Kroah-Hartman

virtio_console: fix race between hvc put_chars and virtqueue teardown on freeze

2026-09-04T21:06:04+00:00

With no_console_suspend enabled, hvc console output can continue while virtio_console is freezing. In that window, put_chars can still enqueue buffers to the output virtqueue while virtcons_freeze is tearing queues down, triggering a BUG_ON in virtqueue_detach_unused_buf_split: BUG_ON(vq->vq.num_free != vq->split.vring.num) Add a pm_freezing flag to ports_device. Set it via smp_store_release() at the start of virtcons_freeze(); put_chars() and __send_to_port() drop output while the flag is set, checked via smp_load_acquire(). The check in __send_to_port() is placed under outvq_lock, making it atomic with remove_port_data() which also acquires outvq_lock. Once remove_port_data() returns for a given port, no concurrent __send_to_port() can add buffers before remove_vqs() tears down the vq. After setting pm_freezing, acquire and release outvq_lock for each port (protected by ports_lock to prevent list manipulation races) before calling virtio_reset_device(). A TX thread that already passed the pm_freezing check may still hold outvq_lock while spinning for host acknowledgment; the drain loop ensures all such threads have completed before the device is reset. Clear pm_freezing in virtcons_restore() only after all port->out_vq pointers have been reassigned to the newly allocated virtqueues, preventing TX paths from dereferencing freed vqs during restore. Link: https://sashiko.dev/#/patchset/20260519162242.7324-1-baver.bae%40gmail.com Signed-off-by: Sungho Bae Signed-off-by: Michael S. Tsirkin Message-ID: <20260603183757.21587-5-baver.bae@gmail.com>

virtio_console: fix control queue race during restore

2026-09-04T21:06:04+00:00

In virtcons_restore(), after virtio_device_ready() sets DRIVER_OK, the device becomes active. If the control receive queue (c_ivq) is populated immediately, the host can instantly deliver pending control messages (e.g., VIRTIO_CONSOLE_PORT_REMOVE). This triggers the control_work_handler(), which can modify the portdev->ports list concurrently with the unprotected list_for_each_entry loop in virtcons_restore(), leading to list corruption or Use-After-Free. Fix this by deferring the population of the control receive queue (fill_queue for c_ivq) until after the list iteration is complete. This ensures the host cannot inject control messages during the vulnerable window. Signed-off-by: Sungho Bae Signed-off-by: Michael S. Tsirkin Message-ID: <20260603183757.21587-4-baver.bae@gmail.com>

virtio_console: fix hot-unplug races in TX paths

2026-09-04T21:06:04+00:00

When a port is hot-unplugged, unplug_port() nullifies port->portdev. However, concurrent TX paths (__send_to_port, put_chars) could read a stale pointer or encounter a NULL pointer dereference. Add READ_ONCE(port->portdev) and NULL checks in the TX paths. In __send_to_port(), move the out_vq assignment inside the outvq_lock and check portdev under the lock. Correspondingly, update unplug_port() to NULL out port->portdev while holding the outvq_lock to serialize with __send_to_port(). In put_chars(), return count instead of 0 on unplug to prevent the hvc layer from spinning in an infinite retry loop. Signed-off-by: Sungho Bae Signed-off-by: Michael S. Tsirkin Message-ID: <20260603183757.21587-3-baver.bae@gmail.com>