[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[RFC PATCH tarfs 0/6] mmap support for tarfs
From: |
Sergey Bugaev |
Subject: |
[RFC PATCH tarfs 0/6] mmap support for tarfs |
Date: |
Thu, 29 Apr 2021 21:57:10 +0300 |
Hello,
I'm trying to implement mmap support in tarfs.
The reason I need it is I want to run some binaries directly form a tarfs
mount, without unpacking them to disk (ext2fs). ld.so uses mmap to load shared
libraries uncoditionally [0].
So I've been digging through libpager, libnetfs, tarfs, and other code, trying
to understand how things fit together and hook them up. The patch series I'm
attaching implements mmap by lazily creating a pager for each node. The pager
reads and writes data the same way tarfs_read_node () and tarfs_write_node ()
do: namely, by calling into the existing cache implementation.
The most challenging part has been "mmap coherence" (perhaps there is an
established term for this concept that I'm not aware of?). Basically, the file
system has to guarantee that any modificaitons made to a file via io_write ()
(and other similar APIs) are immediately visible through any mappings of the
file, and similarly any changes made through a mapping have to be immediately
visible through io_read (). I peeked at how libdiskfs deals with this (since
this does work as expected with ext2fs in my testing), and it forwards any
reads/writes to pager_memcpy () instead of accessing the underlying data
directly. I've tried to do the same, except that I only forward the calls to
a pager if there is one.
I've written a tiny program to test mmap behavior (I've uploaded its source
here [1]), and used it to verify that my implementation behaves somewhat
sanely. I'm also able to load binaries and shared libraries from tarfs with
this patchset. In fact, I'm able to run code chrooted to tarfs.
Please help me out by commenting on the patches. Does the overall approach look
fine, or am I missing some crucial details? Have I messed up reference
counting? Is there a better way to deal with a held mutex that unlocking it
before calling a function that re-locks it? (Making the mutex recursive,
perhaps? Or extracting the inner part into its own function?)
[0]: https://www.gnu.org/software/hurd/open_issues/libnetfs_io_map.html
[1]: https://paste.gg/p/anonymous/7de6f56e7a1c4babbab17bd6ccc2db46
Sergey Bugaev (6):
Plumb io_map () through the backend layer
Link to libpager and initialize it on startup
Implement basic read-only mmap support
Implement basic support for writable mappings
Attempt to implement mmap coherence
Update TODO and BUGS
BUGS | 1 -
Makefile | 4 +-
TODO | 2 -
backend.h | 3 ++
main.c | 13 +++++
netfs.c | 36 +++++++++++---
pager.c | 141 ++++++++++++++++++++++++++++++++++++++++++++++++++++++
pager.h | 9 ++++
tarfs.c | 114 ++++++++++++++++++++++++++++++++++++++-----
tarfs.h | 2 +
10 files changed, 302 insertions(+), 23 deletions(-)
create mode 100644 pager.c
create mode 100644 pager.h
--
2.31.1
- [RFC PATCH tarfs 0/6] mmap support for tarfs,
Sergey Bugaev <=
- [RFC PATCH tarfs 2/6] Link to libpager and initialize it on startup, Sergey Bugaev, 2021/04/29
- [RFC PATCH tarfs 4/6] Implement basic support for writable mappings, Sergey Bugaev, 2021/04/29
- [RFC PATCH tarfs 5/6] Attempt to implement mmap coherence, Sergey Bugaev, 2021/04/29
- [RFC PATCH tarfs 3/6] Implement basic read-only mmap support, Sergey Bugaev, 2021/04/29
- [RFC PATCH tarfs 6/6] Update TODO and BUGS, Sergey Bugaev, 2021/04/29
- [RFC PATCH tarfs 1/6] Plumb io_map () through the backend layer, Sergey Bugaev, 2021/04/29