Age | Commit message (Collapse) | Author |
|
This matches MutexLocker, and doesn't sound like it's a lock itself.
|
|
|
|
This has several benefits:
1) We no longer just blindly derefence a null pointer in various places
2) We will get nicer runtime error messages if the current process does
turn out to be null in the call location
3) GCC no longer complains about possible nullptr dereferences when
compiling without KUBSAN
|
|
...in a few more places, at least.
find(1) is about to start relying on the reported types more or less
reflecting reality. This is especially relevant for magic symlinks
in ProcFS.
|
|
|
|
|
|
We don't need to create a new string from a number in order to compare
an existing string to that number. Converting the existing string to a
number is much cheaper, since it does not require any heap allocations.
Ran into this while profiling "find /" :^)
|
|
We are not using this for anything and it's just been sitting there
gathering dust for well over a year, so let's stop carrying all this
complexity around for no good reason.
|
|
This allows us to 1) let go of the Process when an inode is ref'ing for
ProcFSExposedComponent related reasons, and 2) change our ref/unref
implementation.
|
|
There were many places in which allocation failure was noticed but
ignored.
|
|
Instead, use more static patterns to acquire that sort of data.
|
|
We commonly talk about "a process's address space" so let's nudge the
code towards matching how we talk about it. :^)
|
|
|
|
This directory isn't just about virtual memory, it's about all kinds
of memory management.
|
|
This patch changes the semantics of purgeable memory.
- AnonymousVMObject now has a "purgeable" flag. It can only be set when
constructing the object. (Previously, all anonymous memory was
effectively purgeable.)
- AnonymousVMObject now has a "volatile" flag. It covers the entire
range of physical pages. (Previously, we tracked ranges of volatile
pages, effectively making it a page-level concept.)
- Non-volatile objects maintain a physical page reservation via the
committed pages mechanism, to ensure full coverage for page faults.
- When an object is made volatile, it relinquishes any unused committed
pages immediately. If later made non-volatile again, we then attempt
to make a new committed pages reservation. If this fails, we return
ENOMEM to userspace.
mmap() now creates purgeable objects if passed the MAP_PURGEABLE option
together with MAP_ANONYMOUS. anon_create() memory is always purgeable.
|
|
|
|
|
|
Folders are a GUI concept. File systems have directories.
|
|
Let's be explicit about what kind of lock this is meant to be.
|
|
In case we are about to delete the PID directory, we clear the Process
pointer. If someone still holds a reference to the PID directory (by
opening it), we still need to delete the process, but we can't delete
the directory, so we will keep it alive, but any operation on it will
fail by propogating the error to userspace about that the Process was
deleted and therefore there's no meaning to trying to do operations on
the directory.
Fixes #8576.
|
|
This matches the formatting used in SysFS.
|
|
Folders are a GUI concept, file systems have directories. :^)
|
|
This matches our common naming style better.
|
|
|
|
|
|
Now we use WeakPtrs to break Ref-counting cycle. Also, we call the
prepare_for_deletion method to ensure deleted objects are ready for
deletion. This is necessary to ensure we don't keep dead processes,
which would become zombies.
In addition to that, add some debug prints to aid debug in the future.
|
|
|
|
Instead of using one file for the entire "backend" of the ProcFS data
and metadata, we could split that file into two files that represent
2 logical chunks of the ProcFS exposed objects:
1. Global and inter-process information. This includes all fixed data in
the root folder of the ProcFS, networking information and the bus
folder.
2. Per-process information. This includes all dynamic data about a
process that resides in the /proc/PID/ folder.
This change makes it more easier to read the code and to change it,
hence we do it although there's no technical benefit from it now :)
|