LadybirdBrowser/ladybird
1
1
Fork 0
mirror of https://github.com/LadybirdBrowser/ladybird.git synced 2024-09-22 10:59:51 +03:00
Code Issues Packages Projects Releases Wiki Activity
459115a59c
ladybird/Kernel/FileSystem/ProcFS.h

198 lines
7.5 KiB
C
Raw Normal View History

Meta: Add license header to source files 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.
2020-01-18 11:38:21 +03:00
/*
* Copyright (c) 2018-2020, Andreas Kling <kling@serenityos.org>
*
Everything: Move to SPDX license identifiers in all files. 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 *
2021-04-22 11:24:48 +03:00
* SPDX-License-Identifier: BSD-2-Clause
Meta: Add license header to source files 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.
2020-01-18 11:38:21 +03:00
*/
Kernel: Rewrite ProcFS. Now the filesystem is generated on-the-fly instead of manually adding and removing inodes as processes spawn and die. The code is convoluted and bloated as I wrote it while sleepless. However, it's still vastly better than the old ProcFS, so I'm committing it. I also added /proc/PID/fd/N symlinks for each of a process's open fd's.
2019-02-03 14:33:11 +03:00
#pragma once
Kernel: Add forward declaration header
2020-02-16 03:50:16 +03:00
#include <AK/HashMap.h>
Kernel: Rewrite ProcFS. Now the filesystem is generated on-the-fly instead of manually adding and removing inodes as processes spawn and die. The code is convoluted and bloated as I wrote it while sleepless. However, it's still vastly better than the old ProcFS, so I'm committing it. I also added /proc/PID/fd/N symlinks for each of a process's open fd's.
2019-02-03 14:33:11 +03:00
#include <AK/Types.h>
Kernel: Move FS-related files into Kernel/FileSystem/
2019-04-03 13:25:24 +03:00
#include <Kernel/FileSystem/FileSystem.h>
Kernel: Move Inode to its own files.
2019-05-16 04:02:37 +03:00
#include <Kernel/FileSystem/Inode.h>
Kernel: Use Forward.h headers more
2021-07-11 12:49:16 +03:00
#include <Kernel/Forward.h>
Kernel: Improve ProcFS behavior in low memory conditions When ProcFS could no longer allocate KBuffer objects to serve calls to read, it would just return 0, indicating EOF. This then triggered parsing errors because code assumed it read the file. Because read isn't supposed to return ENOMEM, change ProcFS to populate the file data upon file open or seek to the beginning. This also means that calls to open can now return ENOMEM if needed. This allows the caller to either be able to successfully open the file and read it, or fail to open it in the first place.
2020-09-17 22:51:09 +03:00
#include <Kernel/KBufferBuilder.h>
Kernel: Move Mutex into Locking/
2021-07-18 10:10:27 +03:00
#include <Kernel/Locking/Mutex.h>
Kernel: Introduce the new ProcFS design The new ProcFS design consists of two main parts: 1. The representative ProcFS class, which is derived from the FS class. The ProcFS and its inodes are much more lean - merely 3 classes to represent the common type of inodes - regular files, symbolic links and directories. They're backed by a ProcFSExposedComponent object, which is responsible for the functional operation behind the scenes. 2. The backend of the ProcFS - the ProcFSComponentsRegistrar class and all derived classes from the ProcFSExposedComponent class. These together form the entire backend and handle all the functions you can expect from the ProcFS. The ProcFSExposedComponent derived classes split to 3 types in the manner of lifetime in the kernel: 1. Persistent objects - this category includes all basic objects, like the root folder, /proc/bus folder, main blob files in the root folders, etc. These objects are persistent and cannot die ever. 2. Semi-persistent objects - this category includes all PID folders, and subdirectories to the PID folders. It also includes exposed objects like the unveil JSON'ed blob. These object are persistent as long as the the responsible process they represent is still alive. 3. Dynamic objects - this category includes files in the subdirectories of a PID folder, like /proc/PID/fd/* or /proc/PID/stacks/*. Essentially, these objects are always created dynamically and when no longer in need after being used, they're deallocated. Nevertheless, the new allocated backend objects and inodes try to use the same InodeIndex if possible - this might change only when a thread dies and a new thread is born with a new thread stack, or when a file descriptor is closed and a new one within the same file descriptor number is opened. This is needed to actually be able to do something useful with these objects. The new design assures that many ProcFS instances can be used at once, with one backend for usage for all instances.
2021-06-12 04:23:58 +03:00
#include <Kernel/ProcessExposed.h>
Kernel: Steer away from heap allocations for ProcFS process data Instead, use more static patterns to acquire that sort of data.
2021-08-10 20:51:28 +03:00
#include <Kernel/UnixTypes.h>
Kernel: Rewrite ProcFS. Now the filesystem is generated on-the-fly instead of manually adding and removing inodes as processes spawn and die. The code is convoluted and bloated as I wrote it while sleepless. However, it's still vastly better than the old ProcFS, so I'm committing it. I also added /proc/PID/fd/N symlinks for each of a process's open fd's.
2019-02-03 14:33:11 +03:00
Kernel: Move all code into the Kernel namespace
2020-02-16 03:27:42 +03:00
namespace Kernel {
Kernel: Rename FS => FileSystem This matches our common naming style better.
2021-07-11 01:20:38 +03:00
class ProcFS final : public FileSystem {
Kernel: Rewrite ProcFS. Now the filesystem is generated on-the-fly instead of manually adding and removing inodes as processes spawn and die. The code is convoluted and bloated as I wrote it while sleepless. However, it's still vastly better than the old ProcFS, so I'm committing it. I also added /proc/PID/fd/N symlinks for each of a process's open fd's.
2019-02-03 14:33:11 +03:00
friend class ProcFSInode;
Kernel: Introduce the new ProcFS design The new ProcFS design consists of two main parts: 1. The representative ProcFS class, which is derived from the FS class. The ProcFS and its inodes are much more lean - merely 3 classes to represent the common type of inodes - regular files, symbolic links and directories. They're backed by a ProcFSExposedComponent object, which is responsible for the functional operation behind the scenes. 2. The backend of the ProcFS - the ProcFSComponentsRegistrar class and all derived classes from the ProcFSExposedComponent class. These together form the entire backend and handle all the functions you can expect from the ProcFS. The ProcFSExposedComponent derived classes split to 3 types in the manner of lifetime in the kernel: 1. Persistent objects - this category includes all basic objects, like the root folder, /proc/bus folder, main blob files in the root folders, etc. These objects are persistent and cannot die ever. 2. Semi-persistent objects - this category includes all PID folders, and subdirectories to the PID folders. It also includes exposed objects like the unveil JSON'ed blob. These object are persistent as long as the the responsible process they represent is still alive. 3. Dynamic objects - this category includes files in the subdirectories of a PID folder, like /proc/PID/fd/* or /proc/PID/stacks/*. Essentially, these objects are always created dynamically and when no longer in need after being used, they're deallocated. Nevertheless, the new allocated backend objects and inodes try to use the same InodeIndex if possible - this might change only when a thread dies and a new thread is born with a new thread stack, or when a file descriptor is closed and a new one within the same file descriptor number is opened. This is needed to actually be able to do something useful with these objects. The new design assures that many ProcFS instances can be used at once, with one backend for usage for all instances.
2021-06-12 04:23:58 +03:00
friend class ProcFSDirectoryInode;
Kernel: Steer away from heap allocations for ProcFS process data Instead, use more static patterns to acquire that sort of data.
2021-08-10 20:51:28 +03:00
friend class ProcFSProcessDirectoryInode;
friend class ProcFSGlobalInode;
friend class ProcFSAssociatedProcessInode;
friend class ProcFSProcessSubDirectoryInode;
Add clang-format file Also run it across the whole tree to get everything using the One True Style. We don't yet run this in an automated fashion as it's a little slow, but there is a snippet to do so in makeall.sh.
2019-05-28 12:53:16 +03:00
Kernel: Rewrite ProcFS. Now the filesystem is generated on-the-fly instead of manually adding and removing inodes as processes spawn and die. The code is convoluted and bloated as I wrote it while sleepless. However, it's still vastly better than the old ProcFS, so I'm committing it. I also added /proc/PID/fd/N symlinks for each of a process's open fd's.
2019-02-03 14:33:11 +03:00
public:
virtual ~ProcFS() override;
Kernel: Move ProcFS API towards OOM safety
2021-05-28 15:41:31 +03:00
static RefPtr<ProcFS> create();
Kernel: Rewrite ProcFS. Now the filesystem is generated on-the-fly instead of manually adding and removing inodes as processes spawn and die. The code is convoluted and bloated as I wrote it while sleepless. However, it's still vastly better than the old ProcFS, so I'm committing it. I also added /proc/PID/fd/N symlinks for each of a process's open fd's.
2019-02-03 14:33:11 +03:00
virtual bool initialize() override;
Kernel: Make FileSystem::class_name() return a StringView
2021-07-17 21:59:06 +03:00
virtual StringView class_name() const override { return "ProcFS"sv; }
Kernel: Rewrite ProcFS. Now the filesystem is generated on-the-fly instead of manually adding and removing inodes as processes spawn and die. The code is convoluted and bloated as I wrote it while sleepless. However, it's still vastly better than the old ProcFS, so I'm committing it. I also added /proc/PID/fd/N symlinks for each of a process's open fd's.
2019-02-03 14:33:11 +03:00
Kernel: Make FileSystem::root_inode() return a plain Inode& All file system classes are expected to keep their root Inode object in memory, so this function can safely return an Inode&.
2021-07-18 02:50:47 +03:00
virtual Inode& root_inode() override;
Kernel: Rewrite ProcFS. Now the filesystem is generated on-the-fly instead of manually adding and removing inodes as processes spawn and die. The code is convoluted and bloated as I wrote it while sleepless. However, it's still vastly better than the old ProcFS, so I'm committing it. I also added /proc/PID/fd/N symlinks for each of a process's open fd's.
2019-02-03 14:33:11 +03:00
private:
ProcFS();
Kernel: Introduce the new ProcFS design The new ProcFS design consists of two main parts: 1. The representative ProcFS class, which is derived from the FS class. The ProcFS and its inodes are much more lean - merely 3 classes to represent the common type of inodes - regular files, symbolic links and directories. They're backed by a ProcFSExposedComponent object, which is responsible for the functional operation behind the scenes. 2. The backend of the ProcFS - the ProcFSComponentsRegistrar class and all derived classes from the ProcFSExposedComponent class. These together form the entire backend and handle all the functions you can expect from the ProcFS. The ProcFSExposedComponent derived classes split to 3 types in the manner of lifetime in the kernel: 1. Persistent objects - this category includes all basic objects, like the root folder, /proc/bus folder, main blob files in the root folders, etc. These objects are persistent and cannot die ever. 2. Semi-persistent objects - this category includes all PID folders, and subdirectories to the PID folders. It also includes exposed objects like the unveil JSON'ed blob. These object are persistent as long as the the responsible process they represent is still alive. 3. Dynamic objects - this category includes files in the subdirectories of a PID folder, like /proc/PID/fd/* or /proc/PID/stacks/*. Essentially, these objects are always created dynamically and when no longer in need after being used, they're deallocated. Nevertheless, the new allocated backend objects and inodes try to use the same InodeIndex if possible - this might change only when a thread dies and a new thread is born with a new thread stack, or when a file descriptor is closed and a new one within the same file descriptor number is opened. This is needed to actually be able to do something useful with these objects. The new design assures that many ProcFS instances can be used at once, with one backend for usage for all instances.
2021-06-12 04:23:58 +03:00
NonnullRefPtr<ProcFSDirectoryInode> m_root_inode;
Kernel: Rewrite ProcFS. Now the filesystem is generated on-the-fly instead of manually adding and removing inodes as processes spawn and die. The code is convoluted and bloated as I wrote it while sleepless. However, it's still vastly better than the old ProcFS, so I'm committing it. I also added /proc/PID/fd/N symlinks for each of a process's open fd's.
2019-02-03 14:33:11 +03:00
};
Kernel: Introduce the new ProcFS design The new ProcFS design consists of two main parts: 1. The representative ProcFS class, which is derived from the FS class. The ProcFS and its inodes are much more lean - merely 3 classes to represent the common type of inodes - regular files, symbolic links and directories. They're backed by a ProcFSExposedComponent object, which is responsible for the functional operation behind the scenes. 2. The backend of the ProcFS - the ProcFSComponentsRegistrar class and all derived classes from the ProcFSExposedComponent class. These together form the entire backend and handle all the functions you can expect from the ProcFS. The ProcFSExposedComponent derived classes split to 3 types in the manner of lifetime in the kernel: 1. Persistent objects - this category includes all basic objects, like the root folder, /proc/bus folder, main blob files in the root folders, etc. These objects are persistent and cannot die ever. 2. Semi-persistent objects - this category includes all PID folders, and subdirectories to the PID folders. It also includes exposed objects like the unveil JSON'ed blob. These object are persistent as long as the the responsible process they represent is still alive. 3. Dynamic objects - this category includes files in the subdirectories of a PID folder, like /proc/PID/fd/* or /proc/PID/stacks/*. Essentially, these objects are always created dynamically and when no longer in need after being used, they're deallocated. Nevertheless, the new allocated backend objects and inodes try to use the same InodeIndex if possible - this might change only when a thread dies and a new thread is born with a new thread stack, or when a file descriptor is closed and a new one within the same file descriptor number is opened. This is needed to actually be able to do something useful with these objects. The new design assures that many ProcFS instances can be used at once, with one backend for usage for all instances.
2021-06-12 04:23:58 +03:00
class ProcFSInode : public Inode {
Kernel: Rewrite ProcFS. Now the filesystem is generated on-the-fly instead of manually adding and removing inodes as processes spawn and die. The code is convoluted and bloated as I wrote it while sleepless. However, it's still vastly better than the old ProcFS, so I'm committing it. I also added /proc/PID/fd/N symlinks for each of a process's open fd's.
2019-02-03 14:33:11 +03:00
friend class ProcFS;
Add clang-format file Also run it across the whole tree to get everything using the One True Style. We don't yet run this in an automated fashion as it's a little slow, but there is a snippet to do so in makeall.sh.
2019-05-28 12:53:16 +03:00
Kernel: Rewrite ProcFS. Now the filesystem is generated on-the-fly instead of manually adding and removing inodes as processes spawn and die. The code is convoluted and bloated as I wrote it while sleepless. However, it's still vastly better than the old ProcFS, so I'm committing it. I also added /proc/PID/fd/N symlinks for each of a process's open fd's.
2019-02-03 14:33:11 +03:00
public:
virtual ~ProcFSInode() override;
Kernel: Steer away from heap allocations for ProcFS process data Instead, use more static patterns to acquire that sort of data.
2021-08-10 20:51:28 +03:00
protected:
ProcFSInode(const ProcFS&, InodeIndex);
ProcFS& procfs() { return static_cast<ProcFS&>(Inode::fs()); }
ProcFS const& procfs() const { return static_cast<ProcFS const&>(Inode::fs()); }
// ^Inode
virtual KResult attach(FileDescription& description) = 0;
virtual void did_seek(FileDescription&, off_t) = 0;
virtual void flush_metadata() override final;
virtual KResultOr<NonnullRefPtr<Inode>> create_child(StringView name, mode_t, dev_t, uid_t, gid_t) override final;
virtual KResult add_child(Inode&, const StringView& name, mode_t) override final;
virtual KResult remove_child(const StringView& name) override final;
virtual KResult chmod(mode_t) override final;
virtual KResult chown(uid_t, gid_t) override final;
virtual KResult truncate(u64) override final;
};
class ProcFSGlobalInode : public ProcFSInode {
friend class ProcFS;
public:
static NonnullRefPtr<ProcFSGlobalInode> create(const ProcFS&, const ProcFSExposedComponent&);
virtual ~ProcFSGlobalInode() override {};
Kernel: Introduce the new ProcFS design The new ProcFS design consists of two main parts: 1. The representative ProcFS class, which is derived from the FS class. The ProcFS and its inodes are much more lean - merely 3 classes to represent the common type of inodes - regular files, symbolic links and directories. They're backed by a ProcFSExposedComponent object, which is responsible for the functional operation behind the scenes. 2. The backend of the ProcFS - the ProcFSComponentsRegistrar class and all derived classes from the ProcFSExposedComponent class. These together form the entire backend and handle all the functions you can expect from the ProcFS. The ProcFSExposedComponent derived classes split to 3 types in the manner of lifetime in the kernel: 1. Persistent objects - this category includes all basic objects, like the root folder, /proc/bus folder, main blob files in the root folders, etc. These objects are persistent and cannot die ever. 2. Semi-persistent objects - this category includes all PID folders, and subdirectories to the PID folders. It also includes exposed objects like the unveil JSON'ed blob. These object are persistent as long as the the responsible process they represent is still alive. 3. Dynamic objects - this category includes files in the subdirectories of a PID folder, like /proc/PID/fd/* or /proc/PID/stacks/*. Essentially, these objects are always created dynamically and when no longer in need after being used, they're deallocated. Nevertheless, the new allocated backend objects and inodes try to use the same InodeIndex if possible - this might change only when a thread dies and a new thread is born with a new thread stack, or when a file descriptor is closed and a new one within the same file descriptor number is opened. This is needed to actually be able to do something useful with these objects. The new design assures that many ProcFS instances can be used at once, with one backend for usage for all instances.
2021-06-12 04:23:58 +03:00
StringView name() const;
protected:
Kernel: Steer away from heap allocations for ProcFS process data Instead, use more static patterns to acquire that sort of data.
2021-08-10 20:51:28 +03:00
ProcFSGlobalInode(const ProcFS&, const ProcFSExposedComponent&);
Kernel: Rewrite ProcFS. Now the filesystem is generated on-the-fly instead of manually adding and removing inodes as processes spawn and die. The code is convoluted and bloated as I wrote it while sleepless. However, it's still vastly better than the old ProcFS, so I'm committing it. I also added /proc/PID/fd/N symlinks for each of a process's open fd's.
2019-02-03 14:33:11 +03:00
// ^Inode
Kernel: Steer away from heap allocations for ProcFS process data Instead, use more static patterns to acquire that sort of data.
2021-08-10 20:51:28 +03:00
virtual KResult attach(FileDescription& description) override final;
virtual KResultOr<size_t> read_bytes(off_t, size_t, UserOrKernelBuffer& buffer, FileDescription*) const override final;
virtual KResultOr<size_t> write_bytes(off_t, size_t, const UserOrKernelBuffer& buffer, FileDescription*) override final;
virtual void did_seek(FileDescription&, off_t) override final;
Kernel: Introduce the new ProcFS design The new ProcFS design consists of two main parts: 1. The representative ProcFS class, which is derived from the FS class. The ProcFS and its inodes are much more lean - merely 3 classes to represent the common type of inodes - regular files, symbolic links and directories. They're backed by a ProcFSExposedComponent object, which is responsible for the functional operation behind the scenes. 2. The backend of the ProcFS - the ProcFSComponentsRegistrar class and all derived classes from the ProcFSExposedComponent class. These together form the entire backend and handle all the functions you can expect from the ProcFS. The ProcFSExposedComponent derived classes split to 3 types in the manner of lifetime in the kernel: 1. Persistent objects - this category includes all basic objects, like the root folder, /proc/bus folder, main blob files in the root folders, etc. These objects are persistent and cannot die ever. 2. Semi-persistent objects - this category includes all PID folders, and subdirectories to the PID folders. It also includes exposed objects like the unveil JSON'ed blob. These object are persistent as long as the the responsible process they represent is still alive. 3. Dynamic objects - this category includes files in the subdirectories of a PID folder, like /proc/PID/fd/* or /proc/PID/stacks/*. Essentially, these objects are always created dynamically and when no longer in need after being used, they're deallocated. Nevertheless, the new allocated backend objects and inodes try to use the same InodeIndex if possible - this might change only when a thread dies and a new thread is born with a new thread stack, or when a file descriptor is closed and a new one within the same file descriptor number is opened. This is needed to actually be able to do something useful with these objects. The new design assures that many ProcFS instances can be used at once, with one backend for usage for all instances.
2021-06-12 04:23:58 +03:00
virtual InodeMetadata metadata() const override;
Kernel: Steer away from heap allocations for ProcFS process data Instead, use more static patterns to acquire that sort of data.
2021-08-10 20:51:28 +03:00
virtual KResult traverse_as_directory(Function<bool(FileSystem::DirectoryEntryView const&)>) const override;
virtual RefPtr<Inode> lookup(StringView) override;
Kernel: Introduce the new ProcFS design The new ProcFS design consists of two main parts: 1. The representative ProcFS class, which is derived from the FS class. The ProcFS and its inodes are much more lean - merely 3 classes to represent the common type of inodes - regular files, symbolic links and directories. They're backed by a ProcFSExposedComponent object, which is responsible for the functional operation behind the scenes. 2. The backend of the ProcFS - the ProcFSComponentsRegistrar class and all derived classes from the ProcFSExposedComponent class. These together form the entire backend and handle all the functions you can expect from the ProcFS. The ProcFSExposedComponent derived classes split to 3 types in the manner of lifetime in the kernel: 1. Persistent objects - this category includes all basic objects, like the root folder, /proc/bus folder, main blob files in the root folders, etc. These objects are persistent and cannot die ever. 2. Semi-persistent objects - this category includes all PID folders, and subdirectories to the PID folders. It also includes exposed objects like the unveil JSON'ed blob. These object are persistent as long as the the responsible process they represent is still alive. 3. Dynamic objects - this category includes files in the subdirectories of a PID folder, like /proc/PID/fd/* or /proc/PID/stacks/*. Essentially, these objects are always created dynamically and when no longer in need after being used, they're deallocated. Nevertheless, the new allocated backend objects and inodes try to use the same InodeIndex if possible - this might change only when a thread dies and a new thread is born with a new thread stack, or when a file descriptor is closed and a new one within the same file descriptor number is opened. This is needed to actually be able to do something useful with these objects. The new design assures that many ProcFS instances can be used at once, with one backend for usage for all instances.
2021-06-12 04:23:58 +03:00
NonnullRefPtr<ProcFSExposedComponent> m_associated_component;
};
Kernel: Rewrite ProcFS. Now the filesystem is generated on-the-fly instead of manually adding and removing inodes as processes spawn and die. The code is convoluted and bloated as I wrote it while sleepless. However, it's still vastly better than the old ProcFS, so I'm committing it. I also added /proc/PID/fd/N symlinks for each of a process's open fd's.
2019-02-03 14:33:11 +03:00
Kernel: Steer away from heap allocations for ProcFS process data Instead, use more static patterns to acquire that sort of data.
2021-08-10 20:51:28 +03:00
class ProcFSLinkInode : public ProcFSGlobalInode {
Kernel: Introduce the new ProcFS design The new ProcFS design consists of two main parts: 1. The representative ProcFS class, which is derived from the FS class. The ProcFS and its inodes are much more lean - merely 3 classes to represent the common type of inodes - regular files, symbolic links and directories. They're backed by a ProcFSExposedComponent object, which is responsible for the functional operation behind the scenes. 2. The backend of the ProcFS - the ProcFSComponentsRegistrar class and all derived classes from the ProcFSExposedComponent class. These together form the entire backend and handle all the functions you can expect from the ProcFS. The ProcFSExposedComponent derived classes split to 3 types in the manner of lifetime in the kernel: 1. Persistent objects - this category includes all basic objects, like the root folder, /proc/bus folder, main blob files in the root folders, etc. These objects are persistent and cannot die ever. 2. Semi-persistent objects - this category includes all PID folders, and subdirectories to the PID folders. It also includes exposed objects like the unveil JSON'ed blob. These object are persistent as long as the the responsible process they represent is still alive. 3. Dynamic objects - this category includes files in the subdirectories of a PID folder, like /proc/PID/fd/* or /proc/PID/stacks/*. Essentially, these objects are always created dynamically and when no longer in need after being used, they're deallocated. Nevertheless, the new allocated backend objects and inodes try to use the same InodeIndex if possible - this might change only when a thread dies and a new thread is born with a new thread stack, or when a file descriptor is closed and a new one within the same file descriptor number is opened. This is needed to actually be able to do something useful with these objects. The new design assures that many ProcFS instances can be used at once, with one backend for usage for all instances.
2021-06-12 04:23:58 +03:00
friend class ProcFS;
Kernel: Improve ProcFS behavior in low memory conditions When ProcFS could no longer allocate KBuffer objects to serve calls to read, it would just return 0, indicating EOF. This then triggered parsing errors because code assumed it read the file. Because read isn't supposed to return ENOMEM, change ProcFS to populate the file data upon file open or seek to the beginning. This also means that calls to open can now return ENOMEM if needed. This allows the caller to either be able to successfully open the file and read it, or fail to open it in the first place.
2020-09-17 22:51:09 +03:00
Kernel: Introduce the new ProcFS design The new ProcFS design consists of two main parts: 1. The representative ProcFS class, which is derived from the FS class. The ProcFS and its inodes are much more lean - merely 3 classes to represent the common type of inodes - regular files, symbolic links and directories. They're backed by a ProcFSExposedComponent object, which is responsible for the functional operation behind the scenes. 2. The backend of the ProcFS - the ProcFSComponentsRegistrar class and all derived classes from the ProcFSExposedComponent class. These together form the entire backend and handle all the functions you can expect from the ProcFS. The ProcFSExposedComponent derived classes split to 3 types in the manner of lifetime in the kernel: 1. Persistent objects - this category includes all basic objects, like the root folder, /proc/bus folder, main blob files in the root folders, etc. These objects are persistent and cannot die ever. 2. Semi-persistent objects - this category includes all PID folders, and subdirectories to the PID folders. It also includes exposed objects like the unveil JSON'ed blob. These object are persistent as long as the the responsible process they represent is still alive. 3. Dynamic objects - this category includes files in the subdirectories of a PID folder, like /proc/PID/fd/* or /proc/PID/stacks/*. Essentially, these objects are always created dynamically and when no longer in need after being used, they're deallocated. Nevertheless, the new allocated backend objects and inodes try to use the same InodeIndex if possible - this might change only when a thread dies and a new thread is born with a new thread stack, or when a file descriptor is closed and a new one within the same file descriptor number is opened. This is needed to actually be able to do something useful with these objects. The new design assures that many ProcFS instances can be used at once, with one backend for usage for all instances.
2021-06-12 04:23:58 +03:00
public:
static NonnullRefPtr<ProcFSLinkInode> create(const ProcFS&, const ProcFSExposedComponent&);
ProcFS: Fix /proc/PID/* hardening bypass This enabled trivial ASLR bypass for non-dumpable programs by simply opening /proc/PID/vm before exec'ing. We now hold the target process's ptrace lock across the refresh/write operations, and deny access if the process is non-dumpable. The lock is necessary to prevent a TOCTOU race on Process::is_dumpable() while the target is exec'ing. Fixes #5270.
2021-02-19 11:41:35 +03:00
Kernel: Introduce the new ProcFS design The new ProcFS design consists of two main parts: 1. The representative ProcFS class, which is derived from the FS class. The ProcFS and its inodes are much more lean - merely 3 classes to represent the common type of inodes - regular files, symbolic links and directories. They're backed by a ProcFSExposedComponent object, which is responsible for the functional operation behind the scenes. 2. The backend of the ProcFS - the ProcFSComponentsRegistrar class and all derived classes from the ProcFSExposedComponent class. These together form the entire backend and handle all the functions you can expect from the ProcFS. The ProcFSExposedComponent derived classes split to 3 types in the manner of lifetime in the kernel: 1. Persistent objects - this category includes all basic objects, like the root folder, /proc/bus folder, main blob files in the root folders, etc. These objects are persistent and cannot die ever. 2. Semi-persistent objects - this category includes all PID folders, and subdirectories to the PID folders. It also includes exposed objects like the unveil JSON'ed blob. These object are persistent as long as the the responsible process they represent is still alive. 3. Dynamic objects - this category includes files in the subdirectories of a PID folder, like /proc/PID/fd/* or /proc/PID/stacks/*. Essentially, these objects are always created dynamically and when no longer in need after being used, they're deallocated. Nevertheless, the new allocated backend objects and inodes try to use the same InodeIndex if possible - this might change only when a thread dies and a new thread is born with a new thread stack, or when a file descriptor is closed and a new one within the same file descriptor number is opened. This is needed to actually be able to do something useful with these objects. The new design assures that many ProcFS instances can be used at once, with one backend for usage for all instances.
2021-06-12 04:23:58 +03:00
protected:
ProcFSLinkInode(const ProcFS&, const ProcFSExposedComponent&);
virtual InodeMetadata metadata() const override;
Kernel: Rewrite ProcFS. Now the filesystem is generated on-the-fly instead of manually adding and removing inodes as processes spawn and die. The code is convoluted and bloated as I wrote it while sleepless. However, it's still vastly better than the old ProcFS, so I'm committing it. I also added /proc/PID/fd/N symlinks for each of a process's open fd's.
2019-02-03 14:33:11 +03:00
};
ProcFS: Implement symlink magic
2020-01-15 14:05:02 +03:00
Kernel: Steer away from heap allocations for ProcFS process data Instead, use more static patterns to acquire that sort of data.
2021-08-10 20:51:28 +03:00
class ProcFSDirectoryInode final : public ProcFSGlobalInode {
Kernel: Introduce the new ProcFS design The new ProcFS design consists of two main parts: 1. The representative ProcFS class, which is derived from the FS class. The ProcFS and its inodes are much more lean - merely 3 classes to represent the common type of inodes - regular files, symbolic links and directories. They're backed by a ProcFSExposedComponent object, which is responsible for the functional operation behind the scenes. 2. The backend of the ProcFS - the ProcFSComponentsRegistrar class and all derived classes from the ProcFSExposedComponent class. These together form the entire backend and handle all the functions you can expect from the ProcFS. The ProcFSExposedComponent derived classes split to 3 types in the manner of lifetime in the kernel: 1. Persistent objects - this category includes all basic objects, like the root folder, /proc/bus folder, main blob files in the root folders, etc. These objects are persistent and cannot die ever. 2. Semi-persistent objects - this category includes all PID folders, and subdirectories to the PID folders. It also includes exposed objects like the unveil JSON'ed blob. These object are persistent as long as the the responsible process they represent is still alive. 3. Dynamic objects - this category includes files in the subdirectories of a PID folder, like /proc/PID/fd/* or /proc/PID/stacks/*. Essentially, these objects are always created dynamically and when no longer in need after being used, they're deallocated. Nevertheless, the new allocated backend objects and inodes try to use the same InodeIndex if possible - this might change only when a thread dies and a new thread is born with a new thread stack, or when a file descriptor is closed and a new one within the same file descriptor number is opened. This is needed to actually be able to do something useful with these objects. The new design assures that many ProcFS instances can be used at once, with one backend for usage for all instances.
2021-06-12 04:23:58 +03:00
friend class ProcFS;
ProcFS: Implement symlink magic
2020-01-15 14:05:02 +03:00
public:
Kernel: Introduce the new ProcFS design The new ProcFS design consists of two main parts: 1. The representative ProcFS class, which is derived from the FS class. The ProcFS and its inodes are much more lean - merely 3 classes to represent the common type of inodes - regular files, symbolic links and directories. They're backed by a ProcFSExposedComponent object, which is responsible for the functional operation behind the scenes. 2. The backend of the ProcFS - the ProcFSComponentsRegistrar class and all derived classes from the ProcFSExposedComponent class. These together form the entire backend and handle all the functions you can expect from the ProcFS. The ProcFSExposedComponent derived classes split to 3 types in the manner of lifetime in the kernel: 1. Persistent objects - this category includes all basic objects, like the root folder, /proc/bus folder, main blob files in the root folders, etc. These objects are persistent and cannot die ever. 2. Semi-persistent objects - this category includes all PID folders, and subdirectories to the PID folders. It also includes exposed objects like the unveil JSON'ed blob. These object are persistent as long as the the responsible process they represent is still alive. 3. Dynamic objects - this category includes files in the subdirectories of a PID folder, like /proc/PID/fd/* or /proc/PID/stacks/*. Essentially, these objects are always created dynamically and when no longer in need after being used, they're deallocated. Nevertheless, the new allocated backend objects and inodes try to use the same InodeIndex if possible - this might change only when a thread dies and a new thread is born with a new thread stack, or when a file descriptor is closed and a new one within the same file descriptor number is opened. This is needed to actually be able to do something useful with these objects. The new design assures that many ProcFS instances can be used at once, with one backend for usage for all instances.
2021-06-12 04:23:58 +03:00
static NonnullRefPtr<ProcFSDirectoryInode> create(const ProcFS&, const ProcFSExposedComponent&);
virtual ~ProcFSDirectoryInode() override;
ProcFS: Implement symlink magic
2020-01-15 14:05:02 +03:00
Kernel: Introduce the new ProcFS design The new ProcFS design consists of two main parts: 1. The representative ProcFS class, which is derived from the FS class. The ProcFS and its inodes are much more lean - merely 3 classes to represent the common type of inodes - regular files, symbolic links and directories. They're backed by a ProcFSExposedComponent object, which is responsible for the functional operation behind the scenes. 2. The backend of the ProcFS - the ProcFSComponentsRegistrar class and all derived classes from the ProcFSExposedComponent class. These together form the entire backend and handle all the functions you can expect from the ProcFS. The ProcFSExposedComponent derived classes split to 3 types in the manner of lifetime in the kernel: 1. Persistent objects - this category includes all basic objects, like the root folder, /proc/bus folder, main blob files in the root folders, etc. These objects are persistent and cannot die ever. 2. Semi-persistent objects - this category includes all PID folders, and subdirectories to the PID folders. It also includes exposed objects like the unveil JSON'ed blob. These object are persistent as long as the the responsible process they represent is still alive. 3. Dynamic objects - this category includes files in the subdirectories of a PID folder, like /proc/PID/fd/* or /proc/PID/stacks/*. Essentially, these objects are always created dynamically and when no longer in need after being used, they're deallocated. Nevertheless, the new allocated backend objects and inodes try to use the same InodeIndex if possible - this might change only when a thread dies and a new thread is born with a new thread stack, or when a file descriptor is closed and a new one within the same file descriptor number is opened. This is needed to actually be able to do something useful with these objects. The new design assures that many ProcFS instances can be used at once, with one backend for usage for all instances.
2021-06-12 04:23:58 +03:00
protected:
ProcFSDirectoryInode(const ProcFS&, const ProcFSExposedComponent&);
ProcFS: Implement symlink magic
2020-01-15 14:05:02 +03:00
// ^Inode
virtual InodeMetadata metadata() const override;
Kernel: Rename FS => FileSystem This matches our common naming style better.
2021-07-11 01:20:38 +03:00
virtual KResult traverse_as_directory(Function<bool(FileSystem::DirectoryEntryView const&)>) const override;
Kernel: Make Inode::lookup() return a RefPtr<Inode> Previously this API would return an InodeIdentifier, which meant that there was a race in path resolution where an inode could be unlinked in between finding the InodeIdentifier for a path component, and actually resolving that to an Inode object. Attaching a test that would quickly trip an assertion before. Test: Kernel/path-resolution-race.cpp
2020-02-01 11:23:46 +03:00
virtual RefPtr<Inode> lookup(StringView name) override;
ProcFS: Implement symlink magic
2020-01-15 14:05:02 +03:00
};
Kernel: Use Forward.h headers more
2021-07-11 12:49:16 +03:00
Kernel: Steer away from heap allocations for ProcFS process data Instead, use more static patterns to acquire that sort of data.
2021-08-10 20:51:28 +03:00
class ProcFSProcessAssociatedInode : public ProcFSInode {
friend class ProcFS;
protected:
ProcFSProcessAssociatedInode(const ProcFS&, ProcessID, InodeIndex);
ProcessID associated_pid() const { return m_pid; }
// ^Inode
virtual KResultOr<size_t> write_bytes(off_t, size_t, const UserOrKernelBuffer& buffer, FileDescription*) override final;
private:
const ProcessID m_pid;
};
class ProcFSProcessDirectoryInode final : public ProcFSProcessAssociatedInode {
friend class ProcFS;
public:
static NonnullRefPtr<ProcFSProcessDirectoryInode> create(const ProcFS&, ProcessID);
private:
ProcFSProcessDirectoryInode(const ProcFS&, ProcessID);
// ^Inode
virtual KResult attach(FileDescription& description) override;
virtual void did_seek(FileDescription&, off_t) override { }
virtual InodeMetadata metadata() const override;
virtual KResult traverse_as_directory(Function<bool(FileSystem::DirectoryEntryView const&)>) const override;
virtual KResultOr<size_t> read_bytes(off_t, size_t, UserOrKernelBuffer& buffer, FileDescription*) const override final;
virtual RefPtr<Inode> lookup(StringView name) override;
};
class ProcFSProcessSubDirectoryInode final : public ProcFSProcessAssociatedInode {
friend class ProcFS;
public:
static NonnullRefPtr<ProcFSProcessSubDirectoryInode> create(const ProcFS&, SegmentedProcFSIndex::ProcessSubDirectory, ProcessID);
private:
ProcFSProcessSubDirectoryInode(const ProcFS&, SegmentedProcFSIndex::ProcessSubDirectory, ProcessID);
// ^Inode
virtual KResult attach(FileDescription& description) override;
virtual void did_seek(FileDescription&, off_t) override;
virtual InodeMetadata metadata() const override;
virtual KResult traverse_as_directory(Function<bool(FileSystem::DirectoryEntryView const&)>) const override;
virtual KResultOr<size_t> read_bytes(off_t, size_t, UserOrKernelBuffer& buffer, FileDescription*) const override final;
virtual RefPtr<Inode> lookup(StringView name) override;
const SegmentedProcFSIndex::ProcessSubDirectory m_sub_directory_type;
};
class ProcFSProcessPropertyInode final : public ProcFSProcessAssociatedInode {
friend class ProcFS;
public:
static NonnullRefPtr<ProcFSProcessPropertyInode> create_for_file_description_link(const ProcFS&, unsigned, ProcessID);
static NonnullRefPtr<ProcFSProcessPropertyInode> create_for_thread_stack(const ProcFS&, ThreadID, ProcessID);
static NonnullRefPtr<ProcFSProcessPropertyInode> create_for_pid_property(const ProcFS&, SegmentedProcFSIndex::MainProcessProperty, ProcessID);
private:
ProcFSProcessPropertyInode(const ProcFS&, SegmentedProcFSIndex::MainProcessProperty, ProcessID);
ProcFSProcessPropertyInode(const ProcFS&, ThreadID, ProcessID);
ProcFSProcessPropertyInode(const ProcFS&, unsigned, ProcessID);
// ^Inode
virtual KResult attach(FileDescription& description) override;
virtual void did_seek(FileDescription&, off_t) override;
virtual InodeMetadata metadata() const override;
virtual KResult traverse_as_directory(Function<bool(FileSystem::DirectoryEntryView const&)>) const override;
virtual KResultOr<size_t> read_bytes(off_t, size_t, UserOrKernelBuffer& buffer, FileDescription*) const override final;
virtual RefPtr<Inode> lookup(StringView name) override final;
KResult refresh_data(FileDescription& description);
KResult try_to_acquire_data(Process& process, KBufferBuilder& builder) const;
const SegmentedProcFSIndex::ProcessSubDirectory m_parent_sub_directory_type;
union {
SegmentedProcFSIndex::MainProcessProperty property_type;
unsigned property_index;
} m_possible_data;
mutable Mutex m_refresh_lock;
};
Kernel: Move all code into the Kernel namespace
2020-02-16 03:27:42 +03:00
}
Reference in New Issue Copy Permalink