summaryrefslogtreecommitdiff
path: root/fs/dlm
AgeCommit message (Collapse)Author
11 daysdlm: wait for outstanding SRCU callbacks to complete in exit pathsZqiang
The dlm_lowcomms_exit() and dlm_midcomms_exit() iterate over the srcu protected connection and node hash tables and hand each element to call_srcu() for deferred freeing (connection_release() and midcomms_node_release()). call_srcu() is asynchronous: the callbacks are invoked only after an SRCU grace period, which may happen after the exit function has already returned. These exit functions are reached from exit_dlm() on module unload. Once they return, module teardown continues and the module text may be unloaded while call_srcu() callbacks are still pending. When such a callback finally runs, it executes freed module code and touches the static SRCU domains that are being torn down, resulting in a use-after-free. Add an srcu_barrier() after the call_srcu() loop in each exit function to wait for all outstanding callbacks of the respective SRCU domain to complete before returning. In dlm_midcomms_exit() the barrier is issued before dlm_lowcomms_exit() so that node callbacks are drained prior to tearing down the lower layer. Signed-off-by: Zqiang <qiang.zhang@linux.dev> Acked-by: Alexander Aring <aahringo@redhat.com> Signed-off-by: Alexander Aring <aahringo@redhat.com> Signed-off-by: David Teigland <teigland@redhat.com>
12 daysdlm: fix variable key length lookupAlexander Aring
Before commit 6c648035cbe7 ("dlm: switch to use rhashtable for rsbs") the rsb hashtable was dynamic key length. Accidentally it was changed to switch to static key length which can end in different results. We fixing this back to the original behaviour by adding the necessary functionality to rhashtable to handle the objects and lookups as dynamic key lengths. Fixes: 6c648035cbe7 ("dlm: switch to use rhashtable for rsbs") Signed-off-by: Alexander Aring <aahringo@redhat.com> Signed-off-by: David Teigland <teigland@redhat.com>
12 daysdlm: fix NULL pointer dereference in dlm_dump_rsb_name()Danila Chernetsov
The function dlm_dump_rsb_name() is called from receive_rcom_lookup() when a debug dump is requested via a special RCOM_LOOKUP message with rc_id == 0xFFFFFFFF. The resource name passed to dlm_dump_rsb_name() comes from the received message. There is no guarantee that an RSB with this name exists in the local hash table. dlm_search_rsb_tree() returns 0 when the RSB is found and stores a valid pointer in r. When the lookup fails, it returns -EBADR and leaves r NULL. The current error handling is inverted: if (!error) goto out; As a result, dlm_dump_rsb() is called only when the lookup fails and r is NULL, resulting in a NULL pointer dereference. Found by Linux Verification Center (linuxtesting.org) with SVACE. Fixes: 2d90354027ad ("dlm: merge toss and keep hash table lists into one list") Acked-by: Alexander Aring <aahringo@redhat.com> Signed-off-by: Danila Chernetsov <listdansp@mail.ru> Signed-off-by: Alexander Aring <aahringo@redhat.com> Signed-off-by: David Teigland <teigland@redhat.com>
12 daysdlm: validate lock modes in recovery messagesDanila Chernetsov
The DLM recovery path restores lock state from rcom_lock messages received from remote nodes. The lock modes in these messages are copied directly into the local lkb state without validating that they are within the valid DLM lock mode range. The rest of the DLM code assumes that lkb_rqmode and lkb_grmode contain valid lock modes. In particular, LVB callback handling in dlm_may_skip_callback() uses lock modes as indexes into the dlm_lvb_operations array: dlm_lvb_operations[prev_mode + 1][mode + 1] An invalid lock mode received during recovery could therefore result in an out-of-bounds read during subsequent LVB callback processing. Validate rl_rqmode and rl_grmode before storing them into the local LKB state. This preserves the lock mode invariant required by the rest of the DLM code. Found by Linux Verification Center (linuxtesting.org) with SVACE. Fixes: e7fd41792fc0 ("[DLM] The core of the DLM for GFS2/CLVM") Acked-by: Alexander Aring <aahringo@redhat.com> Signed-off-by: Danila Chernetsov <listdansp@mail.ru> Signed-off-by: Alexander Aring <aahringo@redhat.com> Signed-off-by: David Teigland <teigland@redhat.com>
12 daysdlm: fix buffer overflow from negative len in dlm_search_rsb_treeJoseph Qi
commit 080e5563f878c ("dlm: validate length in dlm_search_rsb_tree") only checks for len > DLM_RESNAME_MAXLEN, which does not catch negative values. While the input 'len' can be negative and a negative int passed to memcpy() is implicitly converted to a large size_t, causing a stack buffer overflow on the key[] array. Fix this by changing the 'len' parameter type from int to unsigned int. This ensures negative values from callers are implicitly converted to large unsigned values that are caught by the existing len > DLM_RESNAME_MAXLEN check. Acked-by: Alexander Aring <aahringo@redhat.com> Signed-off-by: Joseph Qi <joseph.qi@linux.alibaba.com> Signed-off-by: Alexander Aring <aahringo@redhat.com> Signed-off-by: David Teigland <teigland@redhat.com>
12 daysdlm: validate userspace lock resource name lengthSamuel Moelius
The DLM userspace device accepts a flexible resource name after `struct dlm_write_request`. `device_write()` bounded the total write size, but did not verify that `i.lock.namelen` was covered by the bytes actually supplied by the write. A short `DLM_USER_LOCK` request can therefore claim a full `DLM_RESNAME_MAXLEN` resource name while providing no name bytes. The request path later hashes and copies the claimed name length, reading past the `memdup_user_nul()` allocation. Reject non-conversion lock requests whose claimed resource name length exceeds the flexible name payload supplied with the write. Valid lock requests with complete names are unchanged. Track the payload length before compat conversion so 32-bit requests keep using their own request header size. Assisted-by: Codex:gpt-5.5-cyber-preview Acked-by: Alexander Aring <aahringo@redhat.com> Signed-off-by: Samuel Moelius <sam.moelius@trailofbits.com> Signed-off-by: Alexander Aring <aahringo@redhat.com> Signed-off-by: David Teigland <teigland@redhat.com>
12 daysdlm: require CAP_SYS_ADMIN for dlm-monitor deviceHaofeng Li
monitor_device_open() in fs/dlm/user.c performs only atomic_inc(&dlm_monitor_opened) and sets dlm_monitor_unused = 0; it does no capability check. monitor_device_close() does atomic_dec_and_test(&dlm_monitor_opened) and, when the count reaches zero, calls dlm_stop_lockspaces() — which stops every lockspace on the node. The miscdevice is also registered with no .mode field. Attack chain (when the device node is reachable by an unprivileged opener — see mitigation note below): 1. attacker open("/dev/dlm-monitor") with no cap check; the global counter goes 0 -> 1 2. attacker close(fd); atomic_dec_and_test reaches zero again and dlm_stop_lockspaces() runs -> every DLM lockspace on the local node is stopped. Other cluster members then observe the node losing its lockspaces (membership / recovery side effects), so the impact is not strictly local to GFS2 / OCFS2 / lvmlockd / cluster-md workloads on this node. variant: attacker holds the fd open indefinitely to suppress the intended stop when dlm_controld later closes its own fd (inverse abuse — recovery / shutdown stalls) Mitigation: devtmpfs creates /dev/dlm-monitor as 0600 root:root on a stock kernel, so unprivileged open is blocked by the node mode, not by a kernel cap check. The gap is real wherever the node is reachable (udev MODE=0666, container bind-mount, fd via SCM_RIGHTS, or any setup where dlm_controld shares its monitor fd). Reproduction (kernel 7.2.0-rc3, dlm loaded, no live lockspace): # ./exploit_h3 # as root [*] lockspace devices present: 0 [!!!] AUTH BYPASS: opened /dev/dlm-monitor, no cap check (fd=3) [VULNERABLE] monitor open auth bypass demonstrated $ setpriv --reuid 65534 --regid 65534 ./exploit_h3 [OK ] open denied: Permission denied # node 0600, not cap check The destructive close path is opt-in in the PoX (--i-know-it-stops-lockspaces); we did not drive it here. Driving the close path on a node with active lockspaces would stop them; on this throw-away node there are none, but we keep the opt-in gate so the same PoX is safe to re-run on production-like clusters. Fix: gate monitor_device_open() on capable(CAP_SYS_ADMIN) and set .mode = 0600 on monitor_device, matching the dlm_controld-only intended usage. Acked-by: Alexander Aring <aahringo@redhat.com> Signed-off-by: Haofeng Li <lihaofeng@kylinos.cn> Signed-off-by: Alexander Aring <aahringo@redhat.com> Signed-off-by: David Teigland <teigland@redhat.com>
12 daysdlm: gate dlm_plock device on CAP_SYS_ADMINHaofeng Li
fs/dlm/plock.c registers /dev/dlm_plock via a miscdevice whose file_operations has no .open callback and whose .mode field is unset. The kernel therefore performs no capability check on open, and any process that can open the node becomes an unprivileged plock daemon with full read+write access to the pending-plock queue. Attack chain (when the device node is reachable by an unprivileged opener — see mitigation note below): 1. attacker open("/dev/dlm_plock") succeeds with no cap check 2. dev_read() drains pending plock requests straight to user space, leaking dlm_plock_info fields: fsid, number (resource id / inode), start, end, owner, pid, ex, wait 3. dev_write() matches an attacker-supplied dlm_plock_info against a pending op on recv_list (matched on fsid+number+ owner+pid+start+end+ex+wait) and memcpy()'s it into the in-kernel op, including a forged .rv == 0 4. when a matched op exists, the forged result is then applied: for async ops (op->data != NULL), dlm_plock_callback() runs posix_lock_file(); for sync ops, the requester wakes and proceeds as if the cluster had granted the lock. Either way the requester ends up holding a POSIX lock without a real DLM grant, or sees attacker-chosen rv that breaks lock correctness. With no pending op on recv_list, dev_write() still returns sizeof(info) but does nothing beyond a pr_debug ("dlm dev_write no op ...") — so a syntactically accepted write does not by itself prove an applied grant. Mitigation: on a stock kernel, devtmpfs creates /dev/dlm_plock as 0600 root:root, so steps 1-4 are only reachable where the node is exposed to a less privileged principal — e.g. udev MODE=0666, container bind-mount of the node, or an fd passed via SCM_RIGHTS. The in-kernel capability gap is real regardless of node mode. Reproduction (kernel 7.2.0-rc3, dlm loaded): # ./exploit_h2 # as root [*] node /dev/dlm_plock mode=0600 uid=0 gid=0 [!!!] AUTH BYPASS: opened with no capability check (fd=3) [!!!] FORGE ACCEPTED: kernel accepted forged plock result (rv=0); pending ops are grant-forgeable [VULNERABLE] open + read-leak + grant-forge demonstrated The "FORGE ACCEPTED" line means dev_write() returned sizeof(info), i.e. the write path is reachable and the version check passed; it does not by itself mean a grant was applied. Demonstrating an actual forged grant requires a concurrent plock op on recv_list to match against. $ setpriv --reuid 65534 --regid 65534 ./exploit_h2 [OK ] open denied: Permission denied # devtmpfs 0600, not a kernel cap check Fix: add a .open callback that requires CAP_SYS_ADMIN, and set .mode = 0600 on the miscdevice so the explicit expectation matches the devtmpfs default and survives future defaults. Acked-by: Alexander Aring <aahringo@redhat.com> Signed-off-by: Haofeng Li <lihaofeng@kylinos.cn> Signed-off-by: Alexander Aring <aahringo@redhat.com> Signed-off-by: David Teigland <teigland@redhat.com>
2026-05-08dlm: init per node debugfs before add to node hashAlexander Aring
Avoiding potential issues when a node is added to the hash but the debugfs is not NULL or IS_ERR() so a potential iteration over the hash and debugfs_remove() will not fail like in dlm_midcomms_exit(). However dlm_midcomms_exit() will be called in module init/exit function and the hash should be empty anyway at those stages. We change the behavior as cleanup to avoid potential issues. Reported-by: Ginger <ginger.jzllee@gmail.com> Closes: https://lore.kernel.org/gfs2/CAGp+u1ZE7UsQ4sSUHBKQXU8x3M_jwK=ek1urSjEtd3jXQGFmVg@mail.gmail.com Signed-off-by: Alexander Aring <aahringo@redhat.com> Signed-off-by: David Teigland <teigland@redhat.com>
2026-05-08dlm: fix add msg handle in send_queue orderedAlexander Aring
In a benchmark scenario triggering a lot of requests that triggers a lot of DLM messages on the network it can be that the mh->seq is not ordered according the oldest seq number. This ordering is required by dlm_receive_ack as "before(mh->seq, seq)" will stop to check for older sequence numbers that are ordered in the tail of "node->send_queue". The side effects of not having it correct ordered regarding "before(mh->seq, seq)" are refcounting issues and use-after free. I only was able to reproduce this issue in a experimental DLM branch and a user space DLM benchmark that uses io_uring. After changing this I don't experienced any refcounting with the sending buffer issues anymore. Fixes: 489d8e559c659 ("fs: dlm: add reliable connection if reconnect") Signed-off-by: Alexander Aring <aahringo@redhat.com> Signed-off-by: David Teigland <teigland@redhat.com>
2026-05-08dlm: add usercopy whitelist to dlm_cb cacheZiyi Guo
The dlm_cb slab cache is created with kmem_cache_create(), which provides no usercopy whitelist. When a callback carries LVB data, dlm_user_add_ast() copies the LVB into the inline lvbptr[] array within the slab-allocated struct dlm_callback and redirects ua->lksb.sb_lvbptr to point to it. copy_result_to_user() then calls copy_to_user() with this pointer. With CONFIG_HARDENED_USERCOPY enabled, this triggers usercopy_abort(). Switch to kmem_cache_create_usercopy() with a whitelist covering the lvbptr field. Signed-off-by: Ziyi Guo <n7l8m4@u.northwestern.edu> Acked-by: Alexander Aring <aahringo@redhat.com> Signed-off-by: Alexander Aring <aahringo@redhat.com> Signed-off-by: David Teigland <teigland@redhat.com>
2026-05-08dlm: use hlist_for_each_entry_srcu for SRCU protected listsLi RongQing
The connection and node hash tables in DLM are protected by SRCU, but the code currently uses hlist_for_each_entry_rcu() for traversal. While this works functionally, it is semantically incorrect and triggers warnings when RCU lockdep debugging is enabled, as it expects regular RCU read-side critical sections. This patch replaces the incorrect macros with hlist_for_each_entry_srcu() and adds the appropriate lockdep expressions using srcu_read_lock_held() to ensure consistency with the underlying locking mechanism. Signed-off-by: Li RongQing <lirongqing@baidu.com> Acked-by: Alexander Aring <aahringo@redhat.com> Signed-off-by: Alexander Aring <aahringo@redhat.com> Signed-off-by: David Teigland <teigland@redhat.com>
2026-03-29ipv6: convert CONFIG_IPV6 to built-in only and clean up KconfigsFernando Fernandez Mancera
Maintaining a modular IPv6 stack offers image size savings for specific setups, this benefit is outweighed by the architectural burden it imposes on the subsystems on implementation and maintenance. Therefore, drop it. Change CONFIG_IPV6 from tristate to bool. Remove all Kconfig dependencies across the tree that explicitly checked for IPV6=m. In addition, remove MODULE_DESCRIPTION(), MODULE_ALIAS(), MODULE_AUTHOR() and MODULE_LICENSE(). This is also replacing module_init() by device_initcall(). It is not possible to use fs_initcall() as IPv4 does because that creates a race condition on IPv6 addrconf. Finally, modify the default configs from CONFIG_IPV6=m to CONFIG_IPV6=y except for m68k as according to the bloat-o-meter the image is increasing by 330KB~ and that isn't acceptable. Instead, disable IPv6 on this architecture by default. This is aligned with m68k RAM requirements and recommendations [1]. [1] http://www.linux-m68k.org/faq/ram.html Signed-off-by: Fernando Fernandez Mancera <fmancera@suse.de> Tested-by: Ricardo B. Marlière <rbm@suse.com> Acked-by: Krzysztof Kozlowski <krzk@kernel.org> # arm64 Link: https://patch.msgid.link/20260325120928.15848-2-fmancera@suse.de Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-02-21Convert 'alloc_obj' family to use the new default GFP_KERNEL argumentLinus Torvalds
This was done entirely with mindless brute force, using git grep -l '\<k[vmz]*alloc_objs*(.*, GFP_KERNEL)' | xargs sed -i 's/\(alloc_objs*(.*\), GFP_KERNEL)/\1)/' to convert the new alloc_obj() users that had a simple GFP_KERNEL argument to just drop that argument. Note that due to the extreme simplicity of the scripting, any slightly more complex cases spread over multiple lines would not be triggered: they definitely exist, but this covers the vast bulk of the cases, and the resulting diff is also then easier to check automatically. For the same reason the 'flex' versions will be done as a separate conversion. Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2026-02-21treewide: Replace kmalloc with kmalloc_obj for non-scalar typesKees Cook
This is the result of running the Coccinelle script from scripts/coccinelle/api/kmalloc_objs.cocci. The script is designed to avoid scalar types (which need careful case-by-case checking), and instead replace kmalloc-family calls that allocate struct or union object instances: Single allocations: kmalloc(sizeof(TYPE), ...) are replaced with: kmalloc_obj(TYPE, ...) Array allocations: kmalloc_array(COUNT, sizeof(TYPE), ...) are replaced with: kmalloc_objs(TYPE, COUNT, ...) Flex array allocations: kmalloc(struct_size(PTR, FAM, COUNT), ...) are replaced with: kmalloc_flex(*PTR, FAM, COUNT, ...) (where TYPE may also be *VAR) The resulting allocations no longer return "void *", instead returning "TYPE *". Signed-off-by: Kees Cook <kees@kernel.org>
2026-02-10Merge tag 'locking-core-2026-02-08' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull locking updates from Ingo Molnar: "Lock debugging: - Implement compiler-driven static analysis locking context checking, using the upcoming Clang 22 compiler's context analysis features (Marco Elver) We removed Sparse context analysis support, because prior to removal even a defconfig kernel produced 1,700+ context tracking Sparse warnings, the overwhelming majority of which are false positives. On an allmodconfig kernel the number of false positive context tracking Sparse warnings grows to over 5,200... On the plus side of the balance actual locking bugs found by Sparse context analysis is also rather ... sparse: I found only 3 such commits in the last 3 years. So the rate of false positives and the maintenance overhead is rather high and there appears to be no active policy in place to achieve a zero-warnings baseline to move the annotations & fixers to developers who introduce new code. Clang context analysis is more complete and more aggressive in trying to find bugs, at least in principle. Plus it has a different model to enabling it: it's enabled subsystem by subsystem, which results in zero warnings on all relevant kernel builds (as far as our testing managed to cover it). Which allowed us to enable it by default, similar to other compiler warnings, with the expectation that there are no warnings going forward. This enforces a zero-warnings baseline on clang-22+ builds (Which are still limited in distribution, admittedly) Hopefully the Clang approach can lead to a more maintainable zero-warnings status quo and policy, with more and more subsystems and drivers enabling the feature. Context tracking can be enabled for all kernel code via WARN_CONTEXT_ANALYSIS_ALL=y (default disabled), but this will generate a lot of false positives. ( Having said that, Sparse support could still be added back, if anyone is interested - the removal patch is still relatively straightforward to revert at this stage. ) Rust integration updates: (Alice Ryhl, Fujita Tomonori, Boqun Feng) - Add support for Atomic<i8/i16/bool> and replace most Rust native AtomicBool usages with Atomic<bool> - Clean up LockClassKey and improve its documentation - Add missing Send and Sync trait implementation for SetOnce - Make ARef Unpin as it is supposed to be - Add __rust_helper to a few Rust helpers as a preparation for helper LTO - Inline various lock related functions to avoid additional function calls WW mutexes: - Extend ww_mutex tests and other test-ww_mutex updates (John Stultz) Misc fixes and cleanups: - rcu: Mark lockdep_assert_rcu_helper() __always_inline (Arnd Bergmann) - locking/local_lock: Include more missing headers (Peter Zijlstra) - seqlock: fix scoped_seqlock_read kernel-doc (Randy Dunlap) - rust: sync: Replace `kernel::c_str!` with C-Strings (Tamir Duberstein)" * tag 'locking-core-2026-02-08' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: (90 commits) locking/rwlock: Fix write_trylock_irqsave() with CONFIG_INLINE_WRITE_TRYLOCK rcu: Mark lockdep_assert_rcu_helper() __always_inline compiler-context-analysis: Remove __assume_ctx_lock from initializers tomoyo: Use scoped init guard crypto: Use scoped init guard kcov: Use scoped init guard compiler-context-analysis: Introduce scoped init guards cleanup: Make __DEFINE_LOCK_GUARD handle commas in initializers seqlock: fix scoped_seqlock_read kernel-doc tools: Update context analysis macros in compiler_types.h rust: sync: Replace `kernel::c_str!` with C-Strings rust: sync: Inline various lock related methods rust: helpers: Move #define __rust_helper out of atomic.c rust: wait: Add __rust_helper to helpers rust: time: Add __rust_helper to helpers rust: task: Add __rust_helper to helpers rust: sync: Add __rust_helper to helpers rust: refcount: Add __rust_helper to helpers rust: rcu: Add __rust_helper to helpers rust: processor: Add __rust_helper to helpers ...
2026-02-02dlm: Avoid -Wflex-array-member-not-at-end warningGustavo A. R. Silva
-Wflex-array-member-not-at-end was introduced in GCC-14, and we are getting ready to enable it, globally. Move the conflicting declaration to the end of the corresponding structure. Notice that `struct dlm_message` is a flexible structure, this is a structure that contains a flexible-array member. Fix the following warning: fs/dlm/dlm_internal.h:609:33: warning: structure containing a flexible array member is not at the end of another structure [-Wflex-array-member-not-at-end] Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org> Signed-off-by: David Teigland <teigland@redhat.com>
2026-01-20fs/dlm/dir: remove unuse variable count_matchAlex Shi
The variable was never used after introduced. Better to comment it if we want to keep the info. fs/dlm/dir.c:65:26: error: variable 'count_match' set but not used [-Werror,-Wunused-but-set-variable] 65 | unsigned int count = 0, count_match = 0, count_bad = 0, count_add = 0; | ^ 1 error generated. Signed-off-by: Alex Shi <alexs@kernel.org> Signed-off-by: Alexander Aring <aahringo@redhat.com> Signed-off-by: David Teigland <teigland@redhat.com>
2026-01-20dlm: Constify struct configfs_item_operations and configfs_group_operationsChristophe JAILLET
'struct configfs_item_operations' and 'configfs_group_operations' are not modified in this driver. Constifying these structures moves some data to a read-only section, so increases overall security, especially when the structure holds some function pointers. On a x86_64, with allmodconfig, as an example: Before: ====== text data bss dec hex filename 29436 12952 384 42772 a714 fs/dlm/config.o After: ===== text data bss dec hex filename 30076 12312 384 42772 a714 fs/dlm/config.o Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Signed-off-by: Alexander Aring <aahringo@redhat.com> Signed-off-by: David Teigland <teigland@redhat.com>
2026-01-20fs/dlm: use list_add_tail() instead of open-coding list insertionShaurya Rane
Replace the manual list pointer manipulation in add_ordered_member() with the standard list_add_tail() helper. The original code explicitly updated ->prev and ->next pointers to insert @newlist before @tmp, which is exactly what list_add_tail(newlist, tmp) provides. Using the list macro improves readability, removes a source of potential pointer bugs, and satisfies the existing FIXME requesting conversion to the list helpers. No functional change in the ordering logic for DLM members. Signed-off-by: Shaurya Rane <ssrane_b23@ee.vjti.ac.in> Signed-off-by: Alexander Aring <aahringo@redhat.com> Signed-off-by: David Teigland <teigland@redhat.com>
2026-01-20dlm: validate length in dlm_search_rsb_treeEzrak1e
The len parameter in dlm_dump_rsb_name() is not validated and comes from network messages. When it exceeds DLM_RESNAME_MAXLEN, it can cause out-of-bounds write in dlm_search_rsb_tree(). Add length validation to prevent potential buffer overflow. Signed-off-by: Ezrak1e <ezrakiez@gmail.com> Signed-off-by: Alexander Aring <aahringo@redhat.com> Signed-off-by: David Teigland <teigland@redhat.com>
2026-01-20dlm: fix recovery pending middle conversionAlexander Aring
During a workload involving conversions between lock modes PR and CW, lock recovery can create a "conversion deadlock" state between locks that have been recovered. When this occurs, kernel warning messages are logged, e.g. "dlm: WARN: pending deadlock 1e node 0 2 1bf21" "dlm: receive_rcom_lock_args 2e middle convert gr 3 rq 2 remote 2 1e" After this occurs, the deadlocked conversions both appear on the convert queue of the resource being locked, and the conversion requests do not complete. Outside of recovery, conversions that would produce a deadlock are resolved immediately, and return -EDEADLK. The locks are not placed on the convert queue in the deadlocked state. To fix this problem, an lkb under conversion between PR/CW is rebuilt during recovery on a new master's granted queue, with the currently granted mode, rather than being rebuilt on the new master's convert queue, with the currently granted mode and the newly requested mode. The in-progress convert is then resent to the new master after recovery, so the conversion deadlock will be processed outside of the recovery context and handled as described above. Signed-off-by: Alexander Aring <aahringo@redhat.com> Signed-off-by: David Teigland <teigland@redhat.com>
2026-01-05compiler-context-analysis: Change __cond_acquires to take return valueMarco Elver
While Sparse is oblivious to the return value of conditional acquire functions, Clang's context analysis needs to know the return value which indicates successful acquisition. Add the additional argument, and convert existing uses. Notably, Clang's interpretation of the value merely relates to the use in a later conditional branch, i.e. 1 ==> context lock acquired in branch taken if condition non-zero, and 0 ==> context lock acquired in branch taken if condition is zero. Given the precise value does not matter, introduce symbolic variants to use instead of either 0 or 1, which should be more intuitive. No functional change intended. Signed-off-by: Marco Elver <elver@google.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Link: https://patch.msgid.link/20251219154418.3592607-10-elver@google.com
2025-11-04net: Convert proto callbacks from sockaddr to sockaddr_unsizedKees Cook
Convert struct proto pre_connect(), connect(), bind(), and bind_add() callback function prototypes from struct sockaddr to struct sockaddr_unsized. This does not change per-implementation use of sockaddr for passing around an arbitrarily sized sockaddr struct. Those will be addressed in future patches. Additionally removes the no longer referenced struct sockaddr from include/net/inet_common.h. No binary changes expected. Signed-off-by: Kees Cook <kees@kernel.org> Link: https://patch.msgid.link/20251104002617.2752303-5-kees@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-11-04net: Convert proto_ops connect() callbacks to use sockaddr_unsizedKees Cook
Update all struct proto_ops connect() callback function prototypes from "struct sockaddr *" to "struct sockaddr_unsized *" to avoid lying to the compiler about object sizes. Calls into struct proto handlers gain casts that will be removed in the struct proto conversion patch. No binary changes expected. Signed-off-by: Kees Cook <kees@kernel.org> Link: https://patch.msgid.link/20251104002617.2752303-3-kees@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-11-04net: Convert proto_ops bind() callbacks to use sockaddr_unsizedKees Cook
Update all struct proto_ops bind() callback function prototypes from "struct sockaddr *" to "struct sockaddr_unsized *" to avoid lying to the compiler about object sizes. Calls into struct proto handlers gain casts that will be removed in the struct proto conversion patch. No binary changes expected. Signed-off-by: Kees Cook <kees@kernel.org> Link: https://patch.msgid.link/20251104002617.2752303-2-kees@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-09-29Merge tag 'dlm-6.18' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/teigland/linux-dlm Pull dlm updates from David Teigland: "This adds a dlm_release_lockspace() flag to request that node-failure recovery be performed for the node leaving the lockspace. The implementation of this flag requires coordination with userland clustering components. It's been requested for use by GFS2" * tag 'dlm-6.18' of git://git.kernel.org/pub/scm/linux/kernel/git/teigland/linux-dlm: dlm: check for undefined release_option values dlm: handle release_option as unsigned dlm: move to rinfo for all middle conversion cases dlm: handle invalid lockspace member remove dlm: add new flag DLM_RELEASE_RECOVER for dlm_lockspace_release dlm: add new configfs entry release_recover for lockspace members dlm: add new RELEASE_RECOVER uevent attribute for release_lockspace dlm: use defines for force values in dlm_release_lockspace dlm: check for defined force value in dlm_lockspace_release
2025-09-19fs: WQ_PERCPU added to alloc_workqueue usersMarco Crivellari
Currently if a user enqueue a work item using schedule_delayed_work() the used wq is "system_wq" (per-cpu wq) while queue_delayed_work() use WORK_CPU_UNBOUND (used when a cpu is not specified). The same applies to schedule_work() that is using system_wq and queue_work(), that makes use again of WORK_CPU_UNBOUND. This lack of consistentcy cannot be addressed without refactoring the API. alloc_workqueue() treats all queues as per-CPU by default, while unbound workqueues must opt-in via WQ_UNBOUND. This default is suboptimal: most workloads benefit from unbound queues, allowing the scheduler to place worker threads where they’re needed and reducing noise when CPUs are isolated. This patch adds a new WQ_PERCPU flag to all the fs subsystem users to explicitly request the use of the per-CPU behavior. Both flags coexist for one release cycle to allow callers to transition their calls. Once migration is complete, WQ_UNBOUND can be removed and unbound will become the implicit default. With the introduction of the WQ_PERCPU flag (equivalent to !WQ_UNBOUND), any alloc_workqueue() caller that doesn’t explicitly specify WQ_UNBOUND must now use WQ_PERCPU. All existing users have been updated accordingly. Suggested-by: Tejun Heo <tj@kernel.org> Signed-off-by: Marco Crivellari <marco.crivellari@suse.com> Link: https://lore.kernel.org/20250916082906.77439-4-marco.crivellari@suse.com Signed-off-by: Christian Brauner <brauner@kernel.org>
2025-08-14dlm: check for undefined release_option valuesAlexander Aring
Checking on all undefined release_option values to return -EINVAL in case a user is providing them to dlm_release_lockspace(). Signed-off-by: Alexander Aring <aahringo@redhat.com> Signed-off-by: David Teigland <teigland@redhat.com>
2025-08-14dlm: handle release_option as unsignedAlexander Aring
Future patches will introduce a invalid argument check for undefined values. All values for release_option are positive integer values to not check on negative values as well we just change the parameter to unsigned int. Signed-off-by: Alexander Aring <aahringo@redhat.com> Signed-off-by: David Teigland <teigland@redhat.com>
2025-08-14dlm: move to rinfo for all middle conversion casesAlexander Aring
Since commit f74dacb4c8116 ("dlm: fix recovery of middle conversions") we introduced additional debugging information if we hit the middle conversion by using log_limit(). The DLM log_limit() functionality requires a DLM debug option being enabled. As this case is so rarely and excempt any potential introduced new issue with recovery we switching it to log_rinfo() ad this is ratelimited under normal DLM loglevel. Signed-off-by: Alexander Aring <aahringo@redhat.com> Signed-off-by: David Teigland <teigland@redhat.com>
2025-08-14dlm: handle invalid lockspace member removeAlexander Aring
Since commit de7b4869b4ecf ("dlm: add new configfs entry release_recover for lockspace members") we are moving lockspace members into a gone list before removing them to get additional removing attributes from configfs. There is still a very unlikely possibility when find_config_node() returns NULL, then for some reason the node wasn't marked as gone but it was removed. We will just handle this case and drop an error to observe if this case can ever happen. Reported-by: Dan Carpenter <dan.carpenter@linaro.org> Closes: https://lore.kernel.org/gfs2/aJ2Ssuh8xlsTutrA@stanley.mountain/T/#u Signed-off-by: Alexander Aring <aahringo@redhat.com> Signed-off-by: David Teigland <teigland@redhat.com>
2025-08-12dlm: add new flag DLM_RELEASE_RECOVER for dlm_lockspace_releaseAlexander Aring
When dlm_lockspace_release() is passed DLM_RELEASE_RECOVER, it tells the dlm to handle the release/leave as if the node had failed, i.e. perform recovery steps for a failed node, like recover_slot(). When DLM_RELEASE_RECOVER is set: - dlm_release_lockspace() includes RELEASE_RECOVER=1 in the OFFLINE uevent sent to userspace. - userspace/dlm_controld sends a message to all lockspace members indicating that the subsequent node removal should be handled as if the node had failed. - when dlm_controld on all nodes receives the new message, it sets the release_recover configfs entry to 1 for the node. - when the dlm/kernel next performs recovery and removes the node, it will see that release_recover has been set, and will perform recovery steps for the node as if it had failed, e.g. the recover_slot() callback is called to notify the fs. Signed-off-by: Alexander Aring <aahringo@redhat.com> Signed-off-by: David Teigland <teigland@redhat.com>
2025-08-12dlm: add new configfs entry release_recover for lockspace membersAlexander Aring
A new configfs entry is added for a lockspace member: /config/dlm/<cluster>/spaces/<space>/nodes/<node>/release_recover release_recover can be set to 1 by userspace (dlm_controld process) prior to removing the lockspace member (rmdir of the <node>). This tells the kernel to handle the removed member as if it had failed, i.e. recovery steps for a failed node should be perfomed, as opposed to the recovery steps for a node doing a controlled leave. Signed-off-by: Alexander Aring <aahringo@redhat.com> Signed-off-by: David Teigland <teigland@redhat.com>
2025-08-12dlm: add new RELEASE_RECOVER uevent attribute for release_lockspaceAlexander Aring
RELEASE_RECOVER=0|1 is passed to user space as part of the OFFLINE uevent for leaving a lockspace, and used by subsequent patches. RELEASE_RECOVER=1 tells user space that the release_lockspace/leave should be handled by the remaining lockspace members as if the leaving node had failed. Signed-off-by: Alexander Aring <aahringo@redhat.com> Signed-off-by: David Teigland <teigland@redhat.com>
2025-08-12dlm: use defines for force values in dlm_release_lockspaceAlexander Aring
Clarify the use of the force parameter by renaming it to "release_option" and adding defines (with descriptions) for each of the accepted values. Signed-off-by: Alexander Aring <aahringo@redhat.com> Signed-off-by: David Teigland <teigland@redhat.com>
2025-08-12dlm: check for defined force value in dlm_lockspace_releaseAlexander Aring
Force values over 3 are undefined, so don't treat them as 3. Signed-off-by: Alexander Aring <aahringo@redhat.com> Signed-off-by: David Teigland <teigland@redhat.com>
2025-06-08treewide, timers: Rename from_timer() to timer_container_of()Ingo Molnar
Move this API to the canonical timer_*() namespace. [ tglx: Redone against pre rc1 ] Signed-off-by: Ingo Molnar <mingo@kernel.org> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Link: https://lore.kernel.org/all/aB2X0jCKQO56WdMt@gmail.com
2025-04-30dlm: drop SCTP Kconfig dependencyAlexander Aring
DLM does not use any exported SCTP function. SCTP is registered dynamically as protocol to the kernel and can be used over the right protocol identifiers on the socket api. We drop the SCTP dependency as DLM can also be used with TCP only. Signed-off-by: Alexander Aring <aahringo@redhat.com> Reviewed-by: Heming zhao <heming.zhao@suse.com> Signed-off-by: David Teigland <teigland@redhat.com>
2025-04-30dlm: reject SCTP configuration if not enabledAlexander Aring
Reject SCTP dlm configuration if the kernel was never build with SCTP. Currently the only one known user space tool "dlm_controld" will drop an error in the logs and getting stuck. This behaviour should be fixed to deliver an error to the user or fallback to TCP. Signed-off-by: Alexander Aring <aahringo@redhat.com> Reviewed-by: Heming zhao <heming.zhao@suse.com> Signed-off-by: David Teigland <teigland@redhat.com>
2025-04-30dlm: use SHUT_RDWR for SCTP shutdownAlexander Aring
Currently SCTP shutdown() call gets stuck because there is no incoming EOF indicator on its socket. On the peer side the EOF indicator as recvmsg() returns 0 will be triggered as mechanism to flush the socket queue on the receive side. In SCTP recvmsg() function sctp_recvmsg() we can see that only if sk_shutdown has the bit RCV_SHUTDOWN set SCTP will recvmsg() will return EOF. The RCV_SHUTDOWN bit will only be set when shutdown with SHUT_RD is called. We use now SHUT_RDWR to also get a EOF indicator from recvmsg() call on the shutdown() initiator. SCTP does not support half closed sockets and the semantic of SHUT_WR is different here, it seems that calling SHUT_WR on sctp sockets keeps the socket open to have the possibility to do some specific SCTP operations on it that we don't do here. There exists still a difference in the limitations of TCP vs SCTP in case if we are required to have a half closed socket functionality. This was tried to archieve with DLM protocol changes in the past and hopefully we really don't require half closed socket functionality. Signed-off-by: Alexander Aring <aahringo@redhat.com> Tested-by: Heming zhao <heming.zhao@suse.com> Reviewed-by: Heming zhao <heming.zhao@suse.com> Signed-off-by: David Teigland <teigland@redhat.com>
2025-04-30dlm: mask sk_shutdown valueAlexander Aring
The sk->sk_shutdown value is flag value so use masking to check if RCV_SHUTDOWN is set as other possible values like SEND_SHUTDOWN can set as well. Signed-off-by: Alexander Aring <aahringo@redhat.com> Tested-by: Heming zhao <heming.zhao@suse.com> Reviewed-by: Heming zhao <heming.zhao@suse.com> Signed-off-by: David Teigland <teigland@redhat.com>
2025-03-18dlm: make tcp still work in multi-link envHeming Zhao
This patch bypasses multi-link errors in TCP mode, allowing dlm to operate on the first tcp link. Signed-off-by: Heming Zhao <heming.zhao@suse.com> Signed-off-by: David Teigland <teigland@redhat.com>
2025-02-28dlm: fix error if active rsb is not hashedAlexander Aring
If an active rsb is not hashed anymore and this could occur because we releases and acquired locks we need to signal the followed code that the lookup failed. Since the lookup was successful, but it isn't part of the rsb hash anymore we need to signal it by setting error to -EBADR as dlm_search_rsb_tree() does it. Cc: stable@vger.kernel.org Fixes: 5be323b0c64d ("dlm: move dlm_search_rsb_tree() out of lock") Signed-off-by: Alexander Aring <aahringo@redhat.com> Signed-off-by: David Teigland <teigland@redhat.com>
2025-02-28dlm: fix error if inactive rsb is not hashedAlexander Aring
If an inactive rsb is not hashed anymore and this could occur because we releases and acquired locks we need to signal the followed code that the lookup failed. Since the lookup was successful, but it isn't part of the rsb hash anymore we need to signal it by setting error to -EBADR as dlm_search_rsb_tree() does it. Cc: stable@vger.kernel.org Fixes: 01fdeca1cc2d ("dlm: use rcu to avoid an extra rsb struct lookup") Signed-off-by: Alexander Aring <aahringo@redhat.com> Signed-off-by: David Teigland <teigland@redhat.com>
2025-02-10dlm: prevent NPD when writing a positive value to event_doneThadeu Lima de Souza Cascardo
do_uevent returns the value written to event_done. In case it is a positive value, new_lockspace would undo all the work, and lockspace would not be set. __dlm_new_lockspace, however, would treat that positive value as a success due to commit 8511a2728ab8 ("dlm: fix use count with multiple joins"). Down the line, device_create_lockspace would pass that NULL lockspace to dlm_find_lockspace_local, leading to a NULL pointer dereference. Treating such positive values as successes prevents the problem. Given this has been broken for so long, this is unlikely to break userspace expectations. Fixes: 8511a2728ab8 ("dlm: fix use count with multiple joins") Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@igalia.com> Signed-off-by: David Teigland <teigland@redhat.com>
2025-02-10dlm: increase max number of links for corosync3/knetHeming Zhao
This patch increases the maximum number of links that can be used with corosync3/knet. The majority of the changes are in user space dlm_tools/dlm_controld. Signed-off-by: Heming Zhao <heming.zhao@suse.com> Signed-off-by: David Teigland <teigland@redhat.com>
2024-12-19dlm: return -ENOENT if no comm was foundAlexander Aring
Currently if no comm can be found dlm_comm_seq() returns -EEXIST which means entry already exists for a lookup it makes no sense to return -EEXIST. We change it to -ENOENT. There is no user that will evaluate the return value on a specific value so this should be fine. Signed-off-by: Alexander Aring <aahringo@redhat.com> Signed-off-by: David Teigland <teigland@redhat.com>
2024-12-19dlm: fix srcu_read_lock() return type to intAlexander Aring
The return type of srcu_read_lock() is int and not bool. Whereas we using the ret variable only to evaluate a bool type of dlm_lowcomms_con_has_addr() to check if an address is already being set. Fixes: 6f0b0b5d7ae7 ("fs: dlm: remove dlm_node_addrs lookup list") Signed-off-by: Alexander Aring <aahringo@redhat.com> Signed-off-by: David Teigland <teigland@redhat.com>
2024-12-19dlm: fix removal of rsb struct that is master and dir recordAlexander Aring
An rsb struct was not being removed in the case where it was both the master and the dir record. This case (master and dir node) was missed in the condition for doing add_scan() from deactivate_rsb(). Fixing this triggers a related WARN_ON that needs to be fixed, and requires adjusting where two del_scan() calls are made. Fixes: c217adfc8caa ("dlm: fix add_scan and del_scan usage") Signed-off-by: Alexander Aring <aahringo@redhat.com> Signed-off-by: David Teigland <teigland@redhat.com>