summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* ubifs: Configure dentry operations at dentry-creation timeGabriel Krisman Bertazi2024-02-272-1/+1
| | | | | | | | | | fscrypt now supports configuring dentry operations at dentry-creation time through the preset sb->s_d_op, instead of at lookup time. Enable this in ubifs, since the lookup-time mechanism is going away. Reviewed-by: Eric Biggers <ebiggers@google.com> Link: https://lore.kernel.org/r/20240221171412.10710-10-krisman@suse.de Signed-off-by: Gabriel Krisman Bertazi <krisman@suse.de>
* f2fs: Configure dentry operations at dentry-creation timeGabriel Krisman Bertazi2024-02-272-1/+1
| | | | | | | | | | | | | | | | This was already the case for case-insensitive before commit bb9cd9106b22 ("fscrypt: Have filesystems handle their d_ops"), but it was changed to set at lookup-time to facilitate the integration with fscrypt. But it's a problem because dentries that don't get created through ->lookup() won't have any visibility of the operations. Since fscrypt now also supports configuring dentry operations at creation-time, do it for any encrypted and/or casefold volume, simplifying the implementation across these features. Reviewed-by: Eric Biggers <ebiggers@google.com> Link: https://lore.kernel.org/r/20240221171412.10710-9-krisman@suse.de Signed-off-by: Gabriel Krisman Bertazi <krisman@suse.de>
* ext4: Configure dentry operations at dentry-creation timeGabriel Krisman Bertazi2024-02-272-1/+1
| | | | | | | | | | | | | | | | | This was already the case for case-insensitive before commit bb9cd9106b22 ("fscrypt: Have filesystems handle their d_ops"), but it was changed to set at lookup-time to facilitate the integration with fscrypt. But it's a problem because dentries that don't get created through ->lookup() won't have any visibility of the operations. Since fscrypt now also supports configuring dentry operations at creation-time, do it for any encrypted and/or casefold volume, simplifying the implementation across these features. Acked-by: Theodore Ts'o <tytso@mit.edu> Reviewed-by: Eric Biggers <ebiggers@google.com> Link: https://lore.kernel.org/r/20240221171412.10710-8-krisman@suse.de Signed-off-by: Gabriel Krisman Bertazi <krisman@suse.de>
* libfs: Add helper to choose dentry operations at mount-timeGabriel Krisman Bertazi2024-02-272-0/+29
| | | | | | | | | | | | In preparation to drop the similar helper that sets d_op at lookup time, add a version to set the right d_op filesystem-wide, through sb->s_d_op. The operations structures are shared across filesystems supporting fscrypt and/or casefolding, therefore we can keep it in common libfs code. Reviewed-by: Eric Biggers <ebiggers@google.com> Link: https://lore.kernel.org/r/20240221171412.10710-7-krisman@suse.de Signed-off-by: Gabriel Krisman Bertazi <krisman@suse.de>
* libfs: Merge encrypted_ci_dentry_ops and ci_dentry_opsGabriel Krisman Bertazi2024-02-271-28/+6
| | | | | | | | | In preparation to get case-insensitive dentry operations from sb->s_d_op again, use the same structure with and without fscrypt. Reviewed-by: Eric Biggers <ebiggers@google.com> Link: https://lore.kernel.org/r/20240221171412.10710-6-krisman@suse.de Signed-off-by: Gabriel Krisman Bertazi <krisman@suse.de>
* fscrypt: Drop d_revalidate once the key is addedGabriel Krisman Bertazi2024-02-271-7/+22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | When a key is added, existing directory dentries in the DCACHE_NOKEY_NAME form are moved by the VFS to the plaintext version. But, since they have the DCACHE_OP_REVALIDATE flag set, revalidation will be done at each lookup only to return immediately, since plaintext dentries can't go stale until eviction. This patch optimizes this case, by dropping the flag once the nokey_name dentry becomes plain-text. Note that non-directory dentries are not moved this way, so they won't be affected. Of course, this can only be done if fscrypt is the only thing requiring revalidation for a dentry. For this reason, we only disable d_revalidate if the .d_revalidate hook is fscrypt_d_revalidate itself. It is safe to do it here because when moving the dentry to the plain-text version, we are holding the d_lock. We might race with a concurrent RCU lookup but this is harmless because, at worst, we will get an extra d_revalidate on the keyed dentry, which will still find the dentry to be valid. Finally, now that we do more than just clear the DCACHE_NOKEY_NAME in fscrypt_handle_d_move, skip it entirely for plaintext dentries, to avoid extra costs. Reviewed-by: Eric Biggers <ebiggers@google.com> Link: https://lore.kernel.org/r/20240221171412.10710-5-krisman@suse.de Signed-off-by: Gabriel Krisman Bertazi <krisman@suse.de>
* fscrypt: Drop d_revalidate for valid dentries during lookupGabriel Krisman Bertazi2024-02-271-0/+22
| | | | | | | | | | | | | | | | | | | | | | | Unencrypted and encrypted-dentries where the key is available don't need to be revalidated by fscrypt, since they don't go stale from under VFS and the key cannot be removed for the encrypted case without evicting the dentry. Disable their d_revalidate hook on the first lookup, to avoid repeated revalidation later. This is done in preparation to always configuring d_op through sb->s_d_op. The only part detail is that, since the filesystem might have other features that require revalidation, we only apply this optimization if the d_revalidate handler is fscrypt_d_revalidate itself. Finally, we need to clean the dentry->flags even for unencrypted dentries, so the ->d_lock might be acquired even for them. In order to avoid doing it for filesystems that don't care about fscrypt at all, we peek ->d_flags without the lock at first, and only acquire it if we actually need to write the flag. Reviewed-by: Eric Biggers <ebiggers@google.com> Link: https://lore.kernel.org/r/20240221171412.10710-4-krisman@suse.de Signed-off-by: Gabriel Krisman Bertazi <krisman@suse.de>
* fscrypt: Factor out a helper to configure the lookup dentryGabriel Krisman Bertazi2024-02-272-10/+20
| | | | | | | | | | | Both fscrypt_prepare_lookup_partial and fscrypt_prepare_lookup will set DCACHE_NOKEY_NAME for dentries when the key is not available. Extract out a helper to set this flag in a single place, in preparation to also add the optimization that will disable ->d_revalidate if possible. Reviewed-by: Eric Biggers <ebiggers@google.com> Link: https://lore.kernel.org/r/20240221171412.10710-3-krisman@suse.de Signed-off-by: Gabriel Krisman Bertazi <krisman@suse.de>
* ovl: Always reject mounting over case-insensitive directoriesGabriel Krisman Bertazi2024-02-272-3/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | overlayfs relies on the filesystem setting DCACHE_OP_HASH or DCACHE_OP_COMPARE to reject mounting over case-insensitive directories. Since commit bb9cd9106b22 ("fscrypt: Have filesystems handle their d_ops"), we set ->d_op through a hook in ->d_lookup, which means the root dentry won't have them, causing the mount to accidentally succeed. In v6.7-rc7, the following sequence will succeed to mount, but any dentry other than the root dentry will be a "weird" dentry to ovl and fail with EREMOTE. mkfs.ext4 -O casefold lower.img mount -O loop lower.img lower mount -t overlay -o lowerdir=lower,upperdir=upper,workdir=work ovl /mnt Mounting on a subdirectory fails, as expected, because DCACHE_OP_HASH and DCACHE_OP_COMPARE are properly set by ->lookup. Fix by explicitly rejecting superblocks that allow case-insensitive dentries. Yes, this will be solved when we move d_op configuration back to ->s_d_op. Yet, we better have an explicit fix to avoid messing up again. While there, re-sort the entries to have more descriptive error messages first. Fixes: bb9cd9106b22 ("fscrypt: Have filesystems handle their d_ops") Acked-by: Amir Goldstein <amir73il@gmail.com> Reviewed-by: Eric Biggers <ebiggers@google.com> Link: https://lore.kernel.org/r/20240221171412.10710-2-krisman@suse.de Signed-off-by: Gabriel Krisman Bertazi <krisman@suse.de>
* libfs: Attempt exact-match comparison first during casefolded lookupGabriel Krisman Bertazi2024-02-271-17/+23
| | | | | | | | | | | | | | | | | | | | | | Casefolded comparisons are (obviously) way more costly than a simple memcmp. Try the case-sensitive comparison first, falling-back to the case-insensitive lookup only when needed. This allows any exact-match lookup to complete without having to walk the utf8 trie. Note that, for strict mode, generic_ci_d_compare used to reject an invalid UTF-8 string, which would now be considered valid if it exact-matches the disk-name. But, if that is the case, the filesystem is corrupt. More than that, it really doesn't matter in practice, because the name-under-lookup will have already been rejected by generic_ci_d_hash and we won't even get here. The memcmp is safe under RCU because we are operating on str/len instead of dentry->d_name directly, and the caller guarantees their consistency between each other in __d_lookup_rcu_op_compare. Link: https://lore.kernel.org/r/87ttn2sip7.fsf_-_@mailhost.krisman.be Suggested-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Gabriel Krisman Bertazi <krisman@suse.de>
* Merge tag 'exfat-for-6.8-rc1' of ↵Linus Torvalds2024-01-125-92/+335
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/linkinjeon/exfat Pull exfat updates from Namjae Jeon: - Replace the internal table lookup algorithm with the hweight library and ffs of the bitops library. - Handle the two types of stream entry, valid data size (has been written) and data size separately. It improves compatibility with two differently sized files created on Windows. * tag 'exfat-for-6.8-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/linkinjeon/exfat: exfat: do not zero the extended part exfat: change to get file size from DataLength exfat: using ffs instead of internal logic exfat: using hweight instead of internal logic
| * exfat: do not zero the extended partYuezhang Mo2024-01-082-21/+70
| | | | | | | | | | | | | | | | | | | | | | | | | | Since the read operation beyond the ValidDataLength returns zero, if we just extend the size of the file, we don't need to zero the extended part, but only change the DataLength without changing the ValidDataLength. Signed-off-by: Yuezhang Mo <Yuezhang.Mo@sony.com> Reviewed-by: Andy Wu <Andy.Wu@sony.com> Reviewed-by: Aoyama Wataru <wataru.aoyama@sony.com> Reviewed-by: Sungjong Seo <sj1557.seo@samsung.com> Signed-off-by: Namjae Jeon <linkinjeon@kernel.org>
| * exfat: change to get file size from DataLengthYuezhang Mo2024-01-084-19/+231
| | | | | | | | | | | | | | | | | | | | | | | | | | In stream extension directory entry, the ValidDataLength field describes how far into the data stream user data has been written, and the DataLength field describes the file size. Signed-off-by: Yuezhang Mo <Yuezhang.Mo@sony.com> Reviewed-by: Andy Wu <Andy.Wu@sony.com> Reviewed-by: Aoyama Wataru <wataru.aoyama@sony.com> Reviewed-by: Sungjong Seo <sj1557.seo@samsung.com> Signed-off-by: Namjae Jeon <linkinjeon@kernel.org>
| * exfat: using ffs instead of internal logicJohn Sanpe2024-01-082-28/+16
| | | | | | | | | | | | | | | | | | | | | | | | Replaced the internal table lookup algorithm with ffs of the bitops library with better performance. Use it to increase the single processing length of the exfat_find_free_bitmap function, from single-byte search to long type. Signed-off-by: John Sanpe <sanpeqf@gmail.com> Acked-by: Sungjong Seo <sj1557.seo@samsung.com> Signed-off-by: Namjae Jeon <linkinjeon@kernel.org>
| * exfat: using hweight instead of internal logicJohn Sanpe2024-01-081-27/+21
| | | | | | | | | | | | | | | | | | | | | | | | Replace the internal table lookup algorithm with the hweight library, which has instruction set acceleration capabilities. Use it to increase the length of a single calculation of the exfat_find_free_bitmap function to the long type. Signed-off-by: John Sanpe <sanpeqf@gmail.com> Acked-by: Sungjong Seo <sj1557.seo@samsung.com> Signed-off-by: Namjae Jeon <linkinjeon@kernel.org>
* | Merge tag 'pull-bcachefs-fix' of ↵Linus Torvalds2024-01-123-17/+31
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs Pull bcachefs locking fix from Al Viro: "Fix broken locking in bch2_ioctl_subvolume_destroy()" * tag 'pull-bcachefs-fix' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs: bch2_ioctl_subvolume_destroy(): fix locking new helper: user_path_locked_at()
| * | bch2_ioctl_subvolume_destroy(): fix lockingAl Viro2023-11-151-14/+17
| | | | | | | | | | | | | | | | | | | | | make it use user_path_locked_at() to get the normal directory protection for modifications, as well as stable ->d_parent and ->d_name in victim Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
| * | new helper: user_path_locked_at()Al Viro2023-11-152-3/+14
| | | | | | | | | | | | | | | | | | | | | Equivalent of kern_path_locked() taking dfd/userland name. User introduced in the next commit. Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
* | | Merge tag 'pull-simple_recursive_removal' of ↵Linus Torvalds2024-01-120-0/+0
|\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs Pull nfsctl update from Al Viro: "More simple_recursive_removal() conversions. nfsctl this time..." * tag 'pull-simple_recursive_removal' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs: nfsctl: switch to simple_recursive_removal()
| * | | nfsctl: switch to simple_recursive_removal()Al Viro2023-12-201-56/+14
| |/ / | | | | | | | | | | | | | | | | | | | | | | | | | | | Use simple_recursive_removal() in nfsd_client_rmdir() rather than open-coding it. And use less heavy-handed locking to get from nfsctl inode to its ->i_private... Reviewed-by: Jeff Layton <jlayton@redhat.com> Tested-by: Jeff Layton <jlayton@redhat.com> Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
* | | Merge tag 'rcu.release.v6.8' of https://github.com/neeraju/linuxLinus Torvalds2024-01-1220-67/+151
|\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Pull RCU updates from Neeraj Upadhyay: - Documentation and comment updates - RCU torture, locktorture updates that include cleanups; nolibc init build support for mips, ppc and rv64; testing of mid stall duration scenario and fixing fqs task creation conditions - Misc fixes, most notably restricting usage of RCU CPU stall notifiers, to confine their usage primarily to debug kernels - RCU tasks minor fixes - lockdep annotation fix for NMI-safe accesses, callback advancing/acceleration cleanup and documentation improvements * tag 'rcu.release.v6.8' of https://github.com/neeraju/linux: rcu: Force quiescent states only for ongoing grace period doc: Clarify historical disclaimers in memory-barriers.txt doc: Mention address and data dependencies in rcu_dereference.rst doc: Clarify RCU Tasks reader/updater checklist rculist.h: docs: Fix wrong function summary Documentation: RCU: Remove repeated word in comments srcu: Use try-lock lockdep annotation for NMI-safe access. srcu: Explain why callbacks invocations can't run concurrently srcu: No need to advance/accelerate if no callback enqueued srcu: Remove superfluous callbacks advancing from srcu_gp_start() rcu: Remove unused macros from rcupdate.h rcu: Restrict access to RCU CPU stall notifiers rcu-tasks: Mark RCU Tasks accesses to current->rcu_tasks_idle_cpu rcutorture: Add fqs_holdoff check before fqs_task is created rcutorture: Add mid-sized stall to TREE07 rcutorture: add nolibc init support for mips, ppc and rv64 locktorture: Increase Hamming distance between call_rcu_chain and rcu_call_chains
| | \ \
| | \ \
| | \ \
| | \ \
| | \ \
| | \ \
| *-----. \ \ Merge branches 'doc.2023.12.13a', 'torture.2023.11.23a', ↵Neeraj Upadhyay (AMD)2023-12-1415-42/+103
| |\ \ \ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | 'fixes.2023.12.13a', 'rcu-tasks.2023.12.12b' and 'srcu.2023.12.13a' into rcu-merge.2023.12.13a
| | | | | * | | srcu: Use try-lock lockdep annotation for NMI-safe access.Sebastian Andrzej Siewior2023-12-132-1/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | It is claimed that srcu_read_lock_nmisafe() NMI-safe. However it triggers a lockdep if used from NMI because lockdep expects a deadlock since nothing disables NMIs while the lock is acquired. This is because commit f0f44752f5f61 ("rcu: Annotate SRCU's update-side lockdep dependencies") annotates synchronize_srcu() as a write lock usage. This helps to detect a deadlocks such as srcu_read_lock(); synchronize_srcu(); srcu_read_unlock(); The side effect is that the lock srcu_struct now has a USED usage in normal contexts, so it conflicts with a USED_READ usage in NMI. But this shouldn't cause a real deadlock because the write lock usage from synchronize_srcu() is a fake one and only used for read/write deadlock detection. Use a try-lock annotation for srcu_read_lock_nmisafe() to avoid lockdep complains if used from NMI. Fixes: f0f44752f5f6 ("rcu: Annotate SRCU's update-side lockdep dependencies") Link: https://lore.kernel.org/r/20230927160231.XRCDDSK4@linutronix.de Reviewed-by: Boqun Feng <boqun.feng@gmail.com> Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by: Paul E. McKenney <paulmck@kernel.org> Signed-off-by: Neeraj Upadhyay (AMD) <neeraj.iitr10@gmail.com>
| | | | | * | | srcu: Explain why callbacks invocations can't run concurrentlyFrederic Weisbecker2023-12-121-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If an SRCU barrier is queued while callbacks are running and a new callbacks invocator for the same sdp were to run concurrently, the RCU barrier might execute too early. As this requirement is non-obvious, make sure to keep a record. Signed-off-by: Frederic Weisbecker <frederic@kernel.org> Reviewed-by: Joel Fernandes (Google) <joel@joelfernandes.org> Signed-off-by: Paul E. McKenney <paulmck@kernel.org> Signed-off-by: Neeraj Upadhyay (AMD) <neeraj.iitr10@gmail.com>
| | | | | * | | srcu: No need to advance/accelerate if no callback enqueuedFrederic Weisbecker2023-12-121-3/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | While in grace period start, there is nothing to accelerate and therefore no need to advance the callbacks either if no callback is to be enqueued. Spare these needless operations in this case. Signed-off-by: Frederic Weisbecker <frederic@kernel.org> Reviewed-by: Joel Fernandes (Google) <joel@joelfernandes.org> Signed-off-by: Paul E. McKenney <paulmck@kernel.org> Signed-off-by: Neeraj Upadhyay (AMD) <neeraj.iitr10@gmail.com>
| | | | | * | | srcu: Remove superfluous callbacks advancing from srcu_gp_start()Frederic Weisbecker2023-12-121-10/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Callbacks advancing on SRCU must be performed on two specific places: 1) On enqueue time in order to make room for the acceleration of the new callback. 2) On invocation time in order to move the callbacks ready to invoke. Any other callback advancing callsite is needless. Remove the remaining one in srcu_gp_start(). Co-developed-by: Yong He <zhuangel570@gmail.com> Signed-off-by: Yong He <zhuangel570@gmail.com> Co-developed-by: Joel Fernandes <joel@joelfernandes.org> Signed-off-by: Joel Fernandes <joel@joelfernandes.org> Signed-off-by: Frederic Weisbecker <frederic@kernel.org> Signed-off-by: Paul E. McKenney <paulmck@kernel.org> Co-developed-by: Neeraj Upadhyay (AMD) <neeraj.iitr10@gmail.com> Signed-off-by: Neeraj Upadhyay (AMD) <neeraj.iitr10@gmail.com>
| | | | * | | | rcu-tasks: Mark RCU Tasks accesses to current->rcu_tasks_idle_cpuPaul E. McKenney2023-12-121-2/+2
| | | | |/ / / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The task_struct structure's ->rcu_tasks_idle_cpu can be concurrently read and written from the RCU Tasks grace-period kthread and from the CPU on which the task_struct structure's task is running. This commit therefore marks the accesses appropriately. Reported-by: Boqun Feng <boqun.feng@gmail.com> Signed-off-by: Paul E. McKenney <paulmck@kernel.org> Reviewed-by: Joel Fernandes (Google) <joel@joelfernandes.org> Signed-off-by: Neeraj Upadhyay (AMD) <neeraj.iitr10@gmail.com>
| | | * | | | rcu: Force quiescent states only for ongoing grace periodZqiang2023-12-141-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If an rcutorture test scenario creates an fqs_task kthread, it will periodically invoke rcu_force_quiescent_state() in order to start force-quiescent-state (FQS) operations. However, an FQS operation will be started even if there is no RCU grace period in progress. Although testing FQS operations startup when there is no grace period in progress is necessary, it need not happen all that often. This commit therefore causes rcu_force_quiescent_state() to take an early exit if there is no grace period in progress. Note that there will still be attempts to start an FQS scan in the absence of a grace period because the grace period might end right after the rcu_force_quiescent_state() function's check. In actual testing, this happens about once every ten minutes, which should provide adequate testing. Signed-off-by: Zqiang <qiang.zhang1211@gmail.com> Reviewed-by: Joel Fernandes (Google) <joel@joelfernandes.org> Signed-off-by: Paul E. McKenney <paulmck@kernel.org> Signed-off-by: Neeraj Upadhyay (AMD) <neeraj.iitr10@gmail.com>
| | | * | | | rcu: Remove unused macros from rcupdate.hPedro Falcato2023-12-121-3/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ulong2long, USHORT_CMP_GE and USHORT_CMP_LT are redundant and have been unused for quite a few releases. Signed-off-by: Pedro Falcato <pedro.falcato@gmail.com> Signed-off-by: Paul E. McKenney <paulmck@kernel.org> Signed-off-by: Neeraj Upadhyay (AMD) <neeraj.iitr10@gmail.com>
| | | * | | | rcu: Restrict access to RCU CPU stall notifiersPaul E. McKenney2023-12-127-12/+62
| | | |/ / / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Although the RCU CPU stall notifiers can be useful for dumping state when tracking down delicate forward-progress bugs where NUMA effects cause cache lines to be delivered to a given CPU regularly, but always in a state that prevents that CPU from making forward progress. These bugs can be detected by the RCU CPU stall-warning mechanism, but in some cases, the stall-warnings printk()s disrupt the forward-progress bug before any useful state can be obtained. Unfortunately, the notifier mechanism added by commit 5b404fdabacf ("rcu: Add RCU CPU stall notifier") can make matters worse if used at all carelessly. For example, if the stall warning was caused by a lock not being released, then any attempt to acquire that lock in the notifier will hang. This will prevent not only the notifier from producing any useful output, but it will also prevent the stall-warning message from ever appearing. This commit therefore hides this new RCU CPU stall notifier mechanism under a new RCU_CPU_STALL_NOTIFIER Kconfig option that depends on both DEBUG_KERNEL and RCU_EXPERT. In addition, the rcupdate.rcu_cpu_stall_notifiers=1 kernel boot parameter must also be specified. The RCU_CPU_STALL_NOTIFIER Kconfig option's help text contains a warning and explains the dangers of careless use, recommending lockless notifier code. In addition, a WARN() is triggered each time that an attempt is made to register a stall-warning notifier in kernels built with CONFIG_RCU_CPU_STALL_NOTIFIER=y. This combination of measures will keep use of this mechanism confined to debug kernels and away from routine deployments. [ paulmck: Apply Dan Carpenter feedback. ] Fixes: 5b404fdabacf ("rcu: Add RCU CPU stall notifier") Reported-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Paul E. McKenney <paulmck@kernel.org> Reviewed-by: Joel Fernandes (Google) <joel@joelfernandes.org> Signed-off-by: Neeraj Upadhyay (AMD) <neeraj.iitr10@gmail.com>
| | * | | | rcutorture: Add fqs_holdoff check before fqs_task is createdZqiang2023-11-231-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | For rcutorture tests on RCU implementations that support force-quiescent-state operations and that set the fqs_duration module parameter greater than zero, the fqs_task kthread will be created. However, if the fqs_holdoff module parameter is not set, then its default value of zero will cause fqs_task enter a long-term busy loop until stopped by kthread_stop(). This commit therefore adds a fqs_holdoff check before the fqs_task is created, making sure that whenever the fqs_task is created, the fqs_holdoff will be greater than zero. Signed-off-by: Zqiang <qiang.zhang1211@gmail.com> Signed-off-by: Paul E. McKenney <paulmck@kernel.org> Signed-off-by: Neeraj Upadhyay (AMD) <neeraj.iitr10@gmail.com>
| | * | | | rcutorture: Add mid-sized stall to TREE07Paul E. McKenney2023-11-231-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There is code in rcu_implicit_dynticks_qs() that checks for the current grace period being halfway to the RCU CPU stall timeout, but rcutorture currently does not test this code. This commit therefore adds a 14-second stall to the TREE07 scenario in order to test this code given the default RCU CPU stall warning timeout of 21 seconds. Signed-off-by: Paul E. McKenney <paulmck@kernel.org> Signed-off-by: Neeraj Upadhyay (AMD) <neeraj.iitr10@gmail.com>
| | * | | | rcutorture: add nolibc init support for mips, ppc and rv64Thomas Weißschuh2023-11-231-1/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Use nolibc for all support architectures. Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> Signed-off-by: Paul E. McKenney <paulmck@kernel.org> Signed-off-by: Neeraj Upadhyay (AMD) <neeraj.iitr10@gmail.com>
| | * | | | locktorture: Increase Hamming distance between call_rcu_chain and ↵Paul E. McKenney2023-11-231-9/+9
| | |/ / / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | rcu_call_chains One letter difference is really not enough, so this commit changes call_rcu_chain to call_rcu_chain_list. Reported-by: Dan Carpenter <dan.carpenter@linaro.org> Signed-off-by: Paul E. McKenney <paulmck@kernel.org> Signed-off-by: Neeraj Upadhyay (AMD) <neeraj.iitr10@gmail.com>
| * | | | doc: Clarify historical disclaimers in memory-barriers.txtPaul E. McKenney2023-12-141-7/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This commit makes it clear that the reason that these sections are historical is that smp_read_barrier_depends() is no more. It also removes the point about comparison operations, given that there are other optimizations that can break address dependencies. Suggested-by: Jonas Oberhauser <jonas.oberhauser@huaweicloud.com> Signed-off-by: Paul E. McKenney <paulmck@kernel.org> Cc: Alan Stern <stern@rowland.harvard.edu> Cc: Andrea Parri <parri.andrea@gmail.com> Cc: Will Deacon <will@kernel.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Boqun Feng <boqun.feng@gmail.com> Cc: Nicholas Piggin <npiggin@gmail.com> Cc: David Howells <dhowells@redhat.com> Cc: Jade Alglave <j.alglave@ucl.ac.uk> Cc: Luc Maranget <luc.maranget@inria.fr> Cc: Akira Yokosawa <akiyks@gmail.com> Cc: Daniel Lustig <dlustig@nvidia.com> Cc: Joel Fernandes <joel@joelfernandes.org> Cc: Jonathan Corbet <corbet@lwn.net> Cc: <linux-arch@vger.kernel.org> Cc: <linux-doc@vger.kernel.org> Signed-off-by: Neeraj Upadhyay (AMD) <neeraj.iitr10@gmail.com>
| * | | | doc: Mention address and data dependencies in rcu_dereference.rstPaul E. McKenney2023-12-141-7/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This commit adds discussion of address and data dependencies to the beginning of rcu_dereference.rst in order to enable readers to more easily make the connection to the Linux-kernel memory model in general and to memory-barriers.txt in particular. Reported-by: Jonas Oberhauser <jonas.oberhauser@huaweicloud.com> Reported-by: Akira Yokosawa <akiyks@gmail.com> Signed-off-by: Paul E. McKenney <paulmck@kernel.org> Signed-off-by: Neeraj Upadhyay (AMD) <neeraj.iitr10@gmail.com>
| * | | | doc: Clarify RCU Tasks reader/updater checklistPaul E. McKenney2023-12-141-9/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently, the reader/updater compatibility rules for the three RCU Tasks flavors are squished together in a single paragraph, which can result in confusion. This commit therefore splits them out into a list, clearly showing the distinction between these flavors. Link: https://lore.kernel.org/all/20231002211936.5948253e@gandalf.local.home/ Reported-by: Steven Rostedt <rostedt@goodmis.org> Signed-off-by: Paul E. McKenney <paulmck@kernel.org> Reviewed-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com> Reviewed-by: Steven Rostedt (Google) <rostedt@goodmis.org> Signed-off-by: Neeraj Upadhyay (AMD) <neeraj.iitr10@gmail.com>
| * | | | rculist.h: docs: Fix wrong function summaryPhilipp Stanner2023-12-141-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The brief summary in the docstring for function list_next_or_null_rcu() states that the function is supposed to provide the "first" member of a list, whereas in truth it returns the next member. Change the docstring so it describes what the function actually does. Signed-off-by: Philipp Stanner <pstanner@redhat.com> Signed-off-by: Paul E. McKenney <paulmck@kernel.org> Signed-off-by: Neeraj Upadhyay (AMD) <neeraj.iitr10@gmail.com>
| * | | | Documentation: RCU: Remove repeated word in commentsCharles Han2023-12-141-1/+1
| |/ / / | | | | | | | | | | | | | | | | | | | | | | | | | | | | Remove the repeated word "of" in comments. Signed-off-by: Charles Han <hanchunchao@inspur.com> Signed-off-by: Paul E. McKenney <paulmck@kernel.org> Signed-off-by: Neeraj Upadhyay (AMD) <neeraj.iitr10@gmail.com>
* | | | Merge tag 'devicetree-for-6.8' of ↵Linus Torvalds2024-01-1265-604/+1432
|\ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux Pull devicetree updates from Rob Herring: - Convert FPGA bridge, all TPMs (finally), and Rockchip HDMI bindings to schemas - Improvements in Samsung GPU schemas - A few more cases of dropping unneeded quotes in schemas - Merge QCom idle-states txt binding into common idle-states schema - Add X1E80100, SM8650, SM8650, and SDX75 SoCs to QCom Power Domain Controller - Add NXP i.mx8dl to SCU PD - Add synaptics r63353 panel controller - Clarify the wording around the use of 'wakeup-source' property - Add a DTS coding style doc - Add smi vendor prefix - Fix DT_SCHEMA_FILES incorrect matching of paths outside the kernel tree - Disable sysfb (e.g. EFI FB) when simple-framebuffer node is present - Fix double free in of_parse_phandle_with_args_map() - A couple of kerneldoc fixes * tag 'devicetree-for-6.8' of git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux: (37 commits) of: unittest: Fix of_count_phandle_with_args() expected value message dt-bindings: fpga: altera: Convert bridge bindings to yaml dt-bindings: fpga: Convert bridge binding to yaml dt-bindings: vendor-prefixes: Add smi dt-bindings: power: Clarify wording for wakeup-source property of: Fix double free in of_parse_phandle_with_args_map dt-bindings: ignore paths outside kernel for DT_SCHEMA_FILES drivers: of: Fixed kernel doc warning dt-bindings: tpm: Document Microsoft fTPM bindings dt-bindings: tpm: Convert IBM vTPM bindings to DT schema dt-bindings: tpm: Convert Google Cr50 bindings to DT schema dt-bindings: tpm: Consolidate TCG TIS bindings dt-bindings: display: rockchip,inno-hdmi: Document RK3128 compatible dt-bindings: arm: Add remote etm dt-binding dt-bindings: mmc: sdhci-pxa: Fix 'regs' typo media: dt-bindings: samsung,s5p-mfc: Fix iommu properties schemas dt-bindings: display: panel: Add synaptics r63353 panel controller dt-bindings: arm: merge qcom,idle-state with idle-state dt-bindings: drm: rockchip: convert inno_hdmi-rockchip.txt to yaml dt-bindings: cache: qcom,llcc: correct QDU1000 reg entries ...
| * | | | of: unittest: Fix of_count_phandle_with_args() expected value messageGeert Uytterhoeven2024-01-111-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The expected result value for the call to of_count_phandle_with_args() was updated from 7 to 8, but the accompanying error message was forgotten. Fixes: 4dde83569832f937 ("of: Fix double free in of_parse_phandle_with_args_map") Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://lore.kernel.org/r/20240111085025.2073894-1-geert+renesas@glider.be Signed-off-by: Rob Herring <robh@kernel.org>
| * | | | dt-bindings: fpga: altera: Convert bridge bindings to yamlMichal Simek2024-01-116-69/+123
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Convert Altera's bridges to yaml with using fpga-bridge.yaml. Signed-off-by: Michal Simek <michal.simek@amd.com> Reviewed-by: Xu Yilun <yilun.xu@intel.com> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/r/07d646a6d82cc21b100e45ced7cae3ef05faa2cc.1704807147.git.michal.simek@amd.com Signed-off-by: Rob Herring <robh@kernel.org>
| * | | | dt-bindings: fpga: Convert bridge binding to yamlMichal Simek2024-01-113-14/+34
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Convert the generic fpga bridge DT binding to json-schema. Signed-off-by: Michal Simek <michal.simek@amd.com> Reviewed-by: Xu Yilun <yilun.xu@intel.com> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/r/14558a4dcfab5255c1683015287e9c7f48b1afc2.1704807147.git.michal.simek@amd.com Signed-off-by: Rob Herring <robh@kernel.org>
| * | | | dt-bindings: vendor-prefixes: Add smiYoshinori Sato2024-01-111-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add Silicon Mortion Technology Corporation https://www.siliconmotion.com/ Signed-off-by: Yoshinori Sato <ysato@users.sourceforge.jp> Acked-by: Conor Dooley <conor.dooley@microchip.com> Link: https://lore.kernel.org/r/c8aaf67e3fcdb7e60632c53a784691aabfc7733e.1704788539.git.ysato@users.sourceforge.jp Signed-off-by: Rob Herring <robh@kernel.org>
| * | | | dt-bindings: power: Clarify wording for wakeup-source propertyMark Hasemeyer2024-01-101-7/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The wording in the current documentation is a little strong. The intention was not to fix any particular interrupt as wakeup capable but leave those details to the device. It wasn't intended to enforce any rules as what can be or can't be a wakeup interrupt. Soften the wording to not mandate that the 'wakeup-source' property be used, and clarify what it means when an interrupt is marked (or not marked) for wakeup. Link: https://lore.kernel.org/all/ZYAjxxHcCOgDVMTQ@bogus/ Link: https://lore.kernel.org/all/CAL_Jsq+MYwOG40X26cYmO9EkZ9xqWrXDi03MaRfxnV-+VGkXWQ@mail.gmail.com/ Signed-off-by: Mark Hasemeyer <markhas@chromium.org> Link: https://lore.kernel.org/r/20240102140734.v4.4.I1016a45ac9e8daf8a9ebc9854ab90ec3542e7c30@changeid Signed-off-by: Rob Herring <robh@kernel.org>
| * | | | of: Fix double free in of_parse_phandle_with_args_mapChristian A. Ehrhardt2024-01-093-32/+53
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In of_parse_phandle_with_args_map() the inner loop that iterates through the map entries calls of_node_put(new) to free the reference acquired by the previous iteration of the inner loop. This assumes that the value of "new" is NULL on the first iteration of the inner loop. Make sure that this is true in all iterations of the outer loop by setting "new" to NULL after its value is assigned to "cur". Extend the unittest to detect the double free and add an additional test case that actually triggers this path. Fixes: bd6f2fd5a1 ("of: Support parsing phandle argument lists through a nexus node") Cc: Stephen Boyd <stephen.boyd@linaro.org> Signed-off-by: "Christian A. Ehrhardt" <lk@c--e.de> Link: https://lore.kernel.org/r/20231229105411.1603434-1-lk@c--e.de Signed-off-by: Rob Herring <robh@kernel.org>
| * | | | dt-bindings: ignore paths outside kernel for DT_SCHEMA_FILESAndré Draszik2024-01-091-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If the location of the kernel sources contains the string that we're filtering for using DT_SCHEMA_FILES, then all schemas will currently be matched, returned and checked, not just the ones we actually expected. As an example, if the kernel sources happen to be below a directory 'google', and DT_SCHEMA_FILES=google, everything is checked. More common examples might be having the sources below people's home directories that contain the string st or arm and then searching for those. The list is endless. Fix this by only matching for schemas below the kernel source's bindings directory. Note that I opted for the implementation here so as to not having to deal with escaping DT_SCHEMA_FILES, which would have been the alternative if the grep match itself had been updated. Cc: Masahiro Yamada <masahiroy@kernel.org> Signed-off-by: André Draszik <andre.draszik@linaro.org> Link: https://lore.kernel.org/r/20231220145537.2163811-1-andre.draszik@linaro.org Signed-off-by: Rob Herring <robh@kernel.org>
| * | | | drivers: of: Fixed kernel doc warningMuzammil Ashraf2024-01-091-3/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | property.c:1220 : Fixed excess struct member definition warning property.c:444 : Fixed missing a blank line after declarations Signed-off-by: Muzammil Ashraf <m.muzzammilashraf@gmail.com> Reviewed-by: Randy Dunlap <rdunlap@infradead.org> Tested-by: Randy Dunlap <rdunlap@infradead.org> Link: https://lore.kernel.org/r/20231219062317.17650-1-muzammil@dreambigsemi.com Signed-off-by: Rob Herring <robh@kernel.org>
| * | | | dt-bindings: tpm: Document Microsoft fTPM bindingsLukas Wunner2024-01-091-0/+47
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | A driver for Microsoft's firmware-based Trusted Platform Module (fTPM) was merged with commit 09e574831b27 ("tpm/tpm_ftpm_tee: A driver for firmware TPM running inside TEE"), but its devicetree bindings were not. This is the only remaining undocumented compatible string for a TPM, so add a DT schema based on the patch linked below. Link: https://lore.kernel.org/all/20190409184958.7476-2-sashal@kernel.org/ Signed-off-by: Lukas Wunner <lukas@wunner.de> Reviewed-by: Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/99523409eb5aec9276055ff358ae6f2ceb10be6d.1702806810.git.lukas@wunner.de Signed-off-by: Rob Herring <robh@kernel.org>
| * | | | dt-bindings: tpm: Convert IBM vTPM bindings to DT schemaLukas Wunner2024-01-092-41/+104
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Convert the devicetree bindings for the IBM Virtual Trusted Platform Module to DT schema. Drop properties which are already documented in tpm-common.yaml. Document the "IBM,vtpm20" compatible string introduced by commit 18b3670d79ae ("tpm: ibmvtpm: Add support for TPM2"). Signed-off-by: Lukas Wunner <lukas@wunner.de> Reviewed-by: Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/5c41e045dfe7cc3f27dd41c08c62ed8c4a90d8a4.1702806810.git.lukas@wunner.de Signed-off-by: Rob Herring <robh@kernel.org>
generated by cgit v1.2.3 (git 2.25.1) at 2024-10-02 02:54:00 +0000