kernel/git/next/linux-next.git/ipc, branch master

Merge branch 'fs-next' of linux-next

2026-07-07T11:54:18+00:00

ipc: only destroy orphaned shm segments on sysctl write

2026-07-07T00:43:26+00:00

proc_ipc_dointvec_minmax_orphans() currently calls shm_destroy_orphaned() whenever shm_rmid_forced is set, including on sysctl reads. Reading /proc/sys/kernel/shm_rmid_forced should not take shm_ids rwsem for write and walk all segments. Only run the cleanup when the sysctl is written and the forced RMID policy is enabled. When shm_rmid_forced=1, monitoring tools that read /proc/sys/kernel/shm_rmid_forced trigger the cleanup on every read. Link: https://lore.kernel.org/all/?q=only+destroy+orphaned+shm+segments+on+sysctl+write Link: https://lore.kernel.org/tencent_738A8BC6E9EA205F555E4B0DAA154D4F8E0A@qq.com Signed-off-by: Jianlin Shi Cc: "Eric W. Biederman" Cc: Davidlohr Bueso Signed-off-by: Andrew Morton

Merge branch 'ipc-7.3.misc' into vfs.all

2026-07-02T08:00:12+00:00

Signed-off-by: Christian Brauner

Remove excl arg to ->create inode_operation

2026-07-02T07:06:55+00:00

The only time that 'false' is passed as the 'excl' arg to the ->create inode_operation is in lookup_open() when ->atomic_open is not provided by the parent directory. *all* directory inode_operations which do not have ->atomic_open completely ignore the 'excl' arg. Therefore we don't need the 'excl' arg. Those few ->create operations which pay attention to the arg are only ever called with a value of 'true'. We remove that arg and change all ->create operations to behave as those thhe arg were 'true'. Signed-off-by: NeilBrown Link: https://patch.msgid.link/178290671516.27465.15984496764174914338@noble.neil.brown.name Reviewed-by: Jori Koolstra Reviewed-by: Jan Kara Signed-off-by: Christian Brauner (Amutable)

mqueue: reject mq_notify with signo 0

2026-06-29T08:29:28+00:00

valid_signal(0) is true; __do_notify() skips signo 0 anyway. Signed-off-by: Yi Xie Link: https://patch.msgid.link/20260603020936.54508-1-xieyi@kylinos.cn Signed-off-by: Christian Brauner (Amutable)

Merge tag 'kernel-7.2-rc1.misc' of git://git.kernel.org/pub/scm/linux/kernel/git/vfs/vfs

2026-06-14T21:35:50+00:00

Pull misc kernel updates from Christian Brauner: "Fixes - rhashtable: give each instance its own lockdep class syzbot reported a circular locking dependency between ht->mutex and fs_reclaim via the simple_xattrs rhashtable being torn down during inode eviction. The predicted deadlock cannot occur: rhashtable_free_and_destroy() cancels the deferred worker before taking ht->mutex and acquisitions on distinct rhashtables are on distinct mutexes. Lockdep flags a cycle anyway because every ht->mutex in the kernel shared the single static lockdep class from rhashtable_init_noprof(). The lockdep key is lifted to a per-call-site static key so every rhashtable instance gets its own class. - selftests/clone3: fix misuse of the libcap library interface in the cap_checkpoint_restore test and remove unused variables - selftests/pid_namespace: compute the pid_max test limits dynamically instead of hardcoding values below the kernel-enforced minimum of PIDS_PER_CPU_MIN * num_possible_cpus() which made the tests fail on machines with many possible CPUs - selftests: fix the Makefile TARGETS entry for nsfs which wasn't adjusted when the tests moved under filesystems/ Cleanups - ipc/sem.c: use unsigned int for nsops to match the declaration in syscalls.h" * tag 'kernel-7.2-rc1.misc' of git://git.kernel.org/pub/scm/linux/kernel/git/vfs/vfs: selftests/clone3: remove unused variables selftests/clone3: fix libcap interface usage ipc/sem.c: use unsigned int for nsops selftests: Fix Makefile target for nsfs rhashtable: give each instance its own lockdep class selftests/pid_namespace: compute pid_max test limits dynamically

ipc/shm: serialize orphan cleanup with shm_nattch updates

2026-06-03T23:25:49+00:00

shm_destroy_orphaned() walks the shm idr under shm_ids(ns).rwsem, but that does not serialize all fields tested by shm_may_destroy(). In particular, shm_nattch is updated while holding shm_perm.lock, and attach paths can do that without holding the rwsem. Do not decide that an orphaned segment is unused before taking the object lock. Move the shm_may_destroy() check under shm_perm.lock, matching the other destroy paths, and unlock the segment when it no longer qualifies for removal. Link: https://lore.kernel.org/9d97cc1031de2d0bace0edf3a668818aa2f4eca6.1777410234.git.zylzyl2333@gmail.com Fixes: 4c677e2eefdb ("shm: optimize locking and ipc_namespace getting") Reported-by: Yuan Tan Reported-by: Yifan Wu Reported-by: Juefei Pu Reported-by: Xin Liu Signed-off-by: Yilin Zhu Signed-off-by: Ren Wei Cc: Christian Brauner Cc: Jeongjun Park Cc: Kees Cook Cc: Liam Howlett Cc: Lorenzo Stoakes Cc: Serge Hallyn Cc: Vasiliy Kulikov Cc: Davidlohr Bueso Cc: Oleg Nesterov Cc: Serge Hallyn Cc: Signed-off-by: Andrew Morton

ipc/sem.c: use unsigned int for nsops

2026-05-27T12:10:25+00:00

Use unsigned int instead of unsigned for nsops parameter, to match declaration in syscalls.h. Signed-off-by: Yi Xie Link: https://patch.msgid.link/20260525004220.19277-1-xieyi@kylinos.cn Signed-off-by: Christian Brauner (Amutable)

ipc: limit next_id allocation to the valid ID range

2026-05-22T02:06:11+00:00

The checkpoint/restore sysctl path can request the next SysV IPC id through ids->next_id. ipc_idr_alloc() currently forwards that request to idr_alloc() with an open-ended upper bound. If the valid tail of the SysV IPC id space is full, the allocation can spill beyond ipc_mni. The returned SysV IPC id still uses the normal index encoding, so later lookup and removal can target the wrong slot. This leaves the real IDR entry behind and breaks the IDR state for the object. The bug is in ipc_idr_alloc() in the checkpoint/restore path. 1. ids->next_id is passed to: idr_alloc(&ids->ipcs_idr, new, ipcid_to_idx(next_id), 0, ...) 2. The zero upper bound makes the allocation effectively open-ended. Once the valid SysV IPC tail is occupied, idr_alloc() can spill past ipc_mni and allocate an entry beyond the valid IPC id range. 3. The new object id is still encoded with the narrower SysV IPC index width: new->id = (new->seq << ipcmni_seq_shift()) + idx 4. Later removal goes through ipc_rmid(), which uses: ipcid_to_idx(ipcp->id) That truncates the real IDR index. An object actually stored at a high index can then be removed as if it lived at a low in-range index. 5. For shared memory, shm_destroy() frees the current object anyway, but the real high IDR slot is left behind as a dangling pointer. 6. A subsequent walk of /proc/sysvipc/shm reaches the stale IDR entry and dereferences freed memory. Prevent this by bounding the requested allocation to ipc_mni so the checkpoint/restore path fails once the valid range is exhausted. Link: https://lore.kernel.org/cover.1778336914.git.linpu5433@gmail.com Link: https://lore.kernel.org/2eebe949bfa7d1f6e13b5be6a92c64c850ce9d45.1778336914.git.linpu5433@gmail.com Fixes: 03f595668017 ("ipc: add sysctl to specify desired next object id") Signed-off-by: Linpu Yu Signed-off-by: Ren Wei Reported-by: Yuan Tan Reported-by: Yifan Wu Reported-by: Juefei Pu Reported-by: Xin Liu Cc: Kees Cook Cc: Stanislav Kinsbursky Cc: Davidlohr Bueso Cc: Signed-off-by: Andrew Morton

Convert 'alloc_obj' family to use the new default GFP_KERNEL argument

2026-02-22T01:09:51+00:00

This was done entirely with mindless brute force, using git grep -l '\