summaryrefslogtreecommitdiff
path: root/Kernel/FileSystem/UnveilNode.h
diff options
context:
space:
mode:
authorJean-Baptiste Boric <jblbeurope@gmail.com>2021-07-18 10:03:10 +0200
committerAndreas Kling <kling@serenityos.org>2021-08-07 11:48:00 +0200
commit75260bff92fa75033c92cf09d0ab6cf55b515c85 (patch)
tree63519d1ab6a1d4c5c6367cd82e06861e89d62268 /Kernel/FileSystem/UnveilNode.h
parent39ceefa5ddc01c422d1c85b919cb1ef3bbf68ff2 (diff)
downloadserenity-75260bff92fa75033c92cf09d0ab6cf55b515c85.zip
Kernel: Introduce ProtectedValue
A protected value is a variable with enforced locking semantics. The value is protected with a Mutex and can only be accessed through a Locked object that holds a MutexLocker to said Mutex. Therefore, the value itself cannot be accessed except through the proper locking mechanism, which enforces correct locking semantics. The Locked object has knowledge of shared and exclusive lock types and will only return const-correct references and pointers. This should help catch incorrect locking usage where a shared lock is acquired but the user then modifies the locked value. This is not a perfect solution because dereferencing the Locked object returns the value, so the caller could defeat the protected value semantics once it acquires a lock by keeping a pointer or a reference to the value around. Then again, this is C++ and we can't protect against malicious users from within the kernel anyways, but we can raise the threshold above "didn't pay attention".
Diffstat (limited to 'Kernel/FileSystem/UnveilNode.h')
0 files changed, 0 insertions, 0 deletions