From 902dac7f5fa7e116ba495a4a9dbd13f0bf3ec07f Mon Sep 17 00:00:00 2001 From: Liav A Date: Fri, 26 May 2023 13:20:10 +0300 Subject: [PATCH] Kernel: Don't lock ProcFS mutex when calling traverse_as_directory This is not needed, because when we are doing this traversing, functions that are called from this function are using proper and more "atomic" locking. --- Kernel/FileSystem/ProcFS/Inode.cpp | 2 -- 1 file changed, 2 deletions(-) diff --git a/Kernel/FileSystem/ProcFS/Inode.cpp b/Kernel/FileSystem/ProcFS/Inode.cpp index 7140ea7e4d..f7845a26eb 100644 --- a/Kernel/FileSystem/ProcFS/Inode.cpp +++ b/Kernel/FileSystem/ProcFS/Inode.cpp @@ -124,7 +124,6 @@ ErrorOr ProcFSInode::traverse_as_root_directory(Function(Fil ErrorOr ProcFSInode::traverse_as_directory(Function(FileSystem::DirectoryEntryView const&)> callback) const { - MutexLocker locker(procfs().m_lock); if (m_type == Type::ProcessSubdirectory) { VERIFY(m_associated_pid.has_value()); auto process = Process::from_pid_in_same_jail(m_associated_pid.value()); @@ -174,7 +173,6 @@ ErrorOr> ProcFSInode::lookup_as_root_directory(StringView n ErrorOr> ProcFSInode::lookup(StringView name) { - MutexLocker locker(procfs().m_lock); if (m_type == Type::ProcessSubdirectory) { VERIFY(m_associated_pid.has_value()); auto process = Process::from_pid_in_same_jail(m_associated_pid.value());