mirror of
https://github.com/RGBCube/serenity
synced 2025-07-25 04:57:44 +00:00
Kernel: Use RefPtr instead of LockRefPtr for Custody
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:
parent
5331d243c6
commit
728c3fbd14
23 changed files with 143 additions and 102 deletions
|
@ -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()) {
|
||||
|
|
Loading…
Add table
Add a link
Reference in a new issue