| Age | Commit message (Collapse) | Author |
|---|
|
- Renamed try_create_absolute_path() => try_serialize_absolute_path()
- Use KResultOr and TRY() to propagate errors
- Don't call this when it's only for debug logging
|
|
This commit moves the KResult and KResultOr objects to Kernel/API to
signify that they may now be freely used by userspace code at points
where a syscall-related error result is to be expected. It also exposes
KResult and KResultOr to the global namespace to make it nicer to use
for userspace code.
|
|
This patch adds a (spinlock-protected) custody cache. It's a simple
intrusive list containing all currently live custody objects.
This allows us to re-use existing custodies instead of creating them
again and again.
This gives a pretty decent performance improvement on "find /" :^)
|
|
|
|
This adds a way to get a Custody's absolute path as KString, which
enables it to fail gracefully on OOM.
|
|
The try_ prefix indicates that this may fail. :^)
|
|
|
|
|
|
Modify the Custody::create(..) API so it has the ability to propagate
OOM back to the caller.
|
|
This makes it more symmetrical with adopt_own() (which is used to
create a NonnullOwnPtr from the result of a naked new.)
|
|
SPDX License Identifiers are a more compact / standardized
way of representing file license information.
See: https://spdx.dev/resources/use/#identifiers
This was done with the `ambr` search and replace tool.
ambr --no-parent-ignore --key-from-file --rep-from-file key.txt rep.txt *
|
|
This adds support for MS_RDONLY, a mount flag that tells the kernel to disallow
any attempts to write to the newly mounted filesystem. As this flag is
per-mount, and different mounts of the same filesystems (such as in case of bind
mounts) can have different mutability settings, you have to go though a custody
to find out if the filesystem is mounted read-only, instead of just asking the
filesystem itself whether it's inherently read-only.
This also adds a lot of checks we were previously missing; and moves some of
them to happen after more specific checks (such as regular permission checks).
One outstanding hole in this system is sys$mprotect(PROT_WRITE), as there's no
way we can know if the original file description this region has been mounted
from had been opened through a readonly mount point. Currently, we always allow
such sys$mprotect() calls to succeed, which effectively allows anyone to
circumvent the effect of MS_RDONLY. We should solve this one way or another.
|
|
We'll probably want some kind of Custody caching in the future, but as
it's not used at the moment, let's simplify things a bit.
|
|
|
|
|
|
|
|
As suggested by Joshua, this commit adds the 2-clause BSD license as a
comment block to the top of every source file.
For the first pass, I've just added myself for simplicity. I encourage
everyone to add themselves as copyright holders of any file they've
added or modified in some significant way. If I've added myself in
error somewhere, feel free to replace it with the appropriate copyright
holder instead.
Going forward, all new source files should include a license header.
|
|
At the moment, the actual flags are ignored, but we correctly propagate them all
the way from the original mount() syscall to each custody that resides on the
mounted FS.
|
|
This was a workaround to be able to build on case-insensitive file
systems where it might get confused about <string.h> vs <String.h>.
Let's just not support building that way, so String.h can have an
objectively nicer name. :^)
|
|
|
|
Yet more of this same thing. Each one of these patches has a small but
noticeable impact on the steady-state kmalloc numbers. :^)
|
|
|
|
|
|
|
|
(And various related renames that go along with it.)
|
|
Walk the custody cache and try to reuse an existing one when possible.
The VFS is responsible for updating them when something happens that would
cause the described relationship to change.
This is definitely not perfect but it does work for the basic scenarios like
renaming and removing directory entries.
|
|
The current working directory is now stored as a custody. Likewise for a
process executable file. This unbreaks /proc/PID/fd which has not been
working since we made the filesystem bigger.
This still needs a bunch of work, for instance when renaming or removing
a file somewhere, we have to update the relevant custody links.
|
|
A custody is kind of a directory entry abstraction that represents a single
entry in a parent directory that tells us the name of a child inode.
The idea here is for path resolution to produce a chain of custody objects.
|
