RGBCube/serenity
1
Fork 0
mirror of https://github.com/RGBCube/serenity synced 2025-07-25 20:37:35 +00:00
Code Issues Activity Actions

Kernel: Use RefPtr instead of LockRefPtr for Custody

Browse source 
By protecting all the RefPtr<Custody> objects that may be accessed from
multiple threads at the same time (with spinlocks), we remove the need
for using LockRefPtr<Custody> (which is basically a RefPtr with a
built-in spinlock.)
This commit is contained in:
Andreas Kling 2022-08-21 01:04:35 +02:00
parent 5331d243c6
commit 728c3fbd14
23 changed files with 143 additions and 102 deletions
Download patch file Download diff file Expand all files Collapse all files

3
Kernel/Syscalls/unveil.cpp
View file

@ -5,6 +5,7 @@
* SPDX-License-Identifier: BSD-2-Clause
*/
#include <AK/RefPtr.h>
#include <AK/StringView.h>
#include <Kernel/FileSystem/Custody.h>
#include <Kernel/FileSystem/VirtualFileSystem.h>
@ -79,7 +80,7 @@ ErrorOr<FlatPtr> Process::sys$unveil(Userspace<Syscall::SC_unveil_params const*>
// However, if the user specified unveil() with "c" permissions, we don't set errno if ENOENT is encountered,
// because they most likely intend the program to create the file for them later on.
// If this case is encountered, the parent node of the path is returned and the custody of that inode is used instead.
LockRefPtr<Custody> parent_custody; // Parent inode in case of ENOENT
RefPtr<Custody> parent_custody; // Parent inode in case of ENOENT
OwnPtr<KString> new_unveiled_path;
auto custody_or_error = VirtualFileSystem::the().resolve_path_without_veil(path->view(), VirtualFileSystem::the().root_custody(), &parent_custody);
if (!custody_or_error.is_error()) {