Clang emits -Wdefault-const-init-var-unsafe when using u64_to_user_ptr()
due to the typecheck() macro creating an uninitialized dummy variable.
Replace u64_to_user_ptr() with an explicit cast through uintptr_t to
avoid the warning while keeping the same behavior.
Signed-off-by: Sorayukii <sorayukii69@gmail.com>
The full pagecache drop at the end of FS_IOC_ENABLE_VERITY is causing
performance problems and is hindering adoption of fsverity. It was
intended to solve a race condition where unverified pages might be left
in the pagecache. But actually it doesn't solve it fully.
Since the incomplete solution for this race condition has too much
performance impact for it to be worth it, let's remove it for now.
Fixes: 3fda4c617e84 ("fs-verity: implement FS_IOC_ENABLE_VERITY ioctl")
Cc: stable@vger.kernel.org
Reviewed-by: Victor Hsieh <victorhsieh@google.com>
Link: https://lore.kernel.org/r/20230314235332.50270-1-ebiggers@kernel.org
Signed-off-by: Eric Biggers <ebiggers@google.com>
Bug: 273320626
(cherry picked from commit a075bacde257f755bea0e53400c9f1cdd1b8e8e6)
Change-Id: I28dacf122bba5ac816f9b748dcbaa82dc1072fed
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Sorayukii <sorayukii69@gmail.com>
Eric Biggersauthored and Sorayukiicommited 2026-05-15 18:07:20 +07:00
WQ_UNBOUND causes significant scheduler latency on ARM64/Android. This
is problematic for latency sensitive workloads, like I/O
post-processing.
Removing WQ_UNBOUND gives a 96% reduction in fsverity workqueue related
scheduler latency and improves app cold startup times by ~30ms.
WQ_UNBOUND was also removed from the dm-verity workqueue for the same
reason [1].
This code was tested by running Android app startup benchmarks and
measuring how long the fsverity workqueue spent in the runnable state.
Before
Total workqueue scheduler latency: 553800us
After
Total workqueue scheduler latency: 18962us
[1]: https://lore.kernel.org/all/20230202012348.885402-1-nhuck@google.com/
Signed-off-by: Nathan Huckleberry <nhuck@google.com>
Fixes: 8a1d0f9cacc9 ("fs-verity: add data verification hooks for ->readpages()")
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20230310193325.620493-1-nhuck@google.com
Signed-off-by: Eric Biggers <ebiggers@google.com>
Bug: 258554362
(cherry picked from commit f959325e6ac3f499450088b8d9c626d1177be160)
Change-Id: I13f74e0df913894938969582604947e8a1fc51a3
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Sorayukii <sorayukii69@gmail.com>
Nathan Huckleberryauthored and Sorayukiicommited 2026-05-15 18:07:20 +07:00
Remove the unnecessary 'extern' keywords from function declarations.
This makes it so that we don't have a mix of both styles, so it won't be
ambiguous what to use in new fs-verity patches. This also makes the
code shorter and matches the 'checkpatch --strict' expectation.
Link: https://lore.kernel.org/r/20200511192118.71427-3-ebiggers@kernel.org
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Sorayukii <sorayukii69@gmail.com>
Eric Biggersauthored and Sorayukiicommited 2026-05-15 18:07:19 +07:00
Fix all kerneldoc warnings in fs/verity/ and include/linux/fsverity.h.
Most of these were due to missing documentation for function parameters.
Detected with:
scripts/kernel-doc -v -none fs/verity/*.{c,h} include/linux/fsverity.h
This cleanup makes it possible to check new patches for kerneldoc
warnings without having to filter out all the existing ones.
Link: https://lore.kernel.org/r/20200511192118.71427-2-ebiggers@kernel.org
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Sorayukii <sorayukii69@gmail.com>
Eric Biggersauthored and Sorayukiicommited 2026-05-15 18:07:19 +07:00
<linux/kernel.h> already provides a macro u64_to_user_ptr().
Use it instead of open-coding the two casts.
No change in behavior.
Link: https://lore.kernel.org/r/20191231175408.20524-1-ebiggers@kernel.org
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Sorayukii <sorayukii69@gmail.com>
Eric Biggersauthored and Sorayukiicommited 2026-05-15 18:07:19 +07:00
When initializing an fs-verity hash algorithm, also initialize a mempool
that contains a single preallocated hash request object. Then replace
the direct calls to ahash_request_alloc() and ahash_request_free() with
allocating and freeing from this mempool.
This eliminates the possibility of the allocation failing, which is
desirable for the I/O path.
This doesn't cause deadlocks because there's no case where multiple hash
requests are needed at a time to make forward progress.
Link: https://lore.kernel.org/r/20191231175545.20709-1-ebiggers@kernel.org
Reviewed-by: Theodore Ts'o <tytso@mit.edu>
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Sorayukii <sorayukii69@gmail.com>
Eric Biggersauthored and Sorayukiicommited 2026-05-15 18:07:19 +07:00
When it builds the first level of the Merkle tree, FS_IOC_ENABLE_VERITY
sequentially reads each page of the file using read_mapping_page().
This works fine if the file's data is already in pagecache, which should
normally be the case, since this ioctl is normally used immediately
after writing out the file.
But in any other case this implementation performs very poorly, since
only one page is read at a time.
Fix this by implementing readahead using the functions from
mm/readahead.c.
This improves performance in the uncached case by about 20x, as seen in
the following benchmarks done on a 250MB file (on x86_64 with SHA-NI):
FS_IOC_ENABLE_VERITY uncached (before) 3.299s
FS_IOC_ENABLE_VERITY uncached (after) 0.160s
FS_IOC_ENABLE_VERITY cached 0.147s
sha256sum uncached 0.191s
sha256sum cached 0.145s
Note: we could instead switch to kernel_read(). But that would mean
we'd no longer be hashing the data directly from the pagecache, which is
a nice optimization of its own. And using kernel_read() would require
allocating another temporary buffer, hashing the data and tree pages
separately, and explicitly zero-padding the last page -- so it wouldn't
really be any simpler than direct pagecache access, at least for now.
Link: https://lore.kernel.org/r/20200106205410.136707-1-ebiggers@kernel.org
Reviewed-by: Theodore Ts'o <tytso@mit.edu>
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Sorayukii <sorayukii69@gmail.com>
Eric Biggersauthored and Sorayukiicommited 2026-05-15 18:07:19 +07:00
To meet some users' needs, add optional support for having fs-verity
handle a portion of the authentication policy in the kernel. An
".fs-verity" keyring is created to which X.509 certificates can be
added; then a sysctl 'fs.verity.require_signatures' can be set to cause
the kernel to enforce that all fs-verity files contain a signature of
their file measurement by a key in this keyring.
See the "Built-in signature verification" section of
Documentation/filesystems/fsverity.rst for the full documentation.
Reviewed-by: Theodore Ts'o <tytso@mit.edu>
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Sorayukii <sorayukii69@gmail.com>
Eric Biggersauthored and Sorayukiicommited 2026-05-15 18:07:19 +07:00
Add SHA-512 support to fs-verity. This is primarily a demonstration of
the trivial changes needed to support a new hash algorithm in fs-verity;
most users will still use SHA-256, due to the smaller space required to
store the hashes. But some users may prefer SHA-512.
Reviewed-by: Theodore Ts'o <tytso@mit.edu>
Reviewed-by: Jaegeuk Kim <jaegeuk@kernel.org>
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Sorayukii <sorayukii69@gmail.com>
Eric Biggersauthored and Sorayukiicommited 2026-05-15 18:07:19 +07:00
Add a function for filesystems to call to implement the
FS_IOC_MEASURE_VERITY ioctl. This ioctl retrieves the file measurement
that fs-verity calculated for the given file and is enforcing for reads;
i.e., reads that don't match this hash will fail. This ioctl can be
used for authentication or logging of file measurements in userspace.
See the "FS_IOC_MEASURE_VERITY" section of
Documentation/filesystems/fsverity.rst for the documentation.
Reviewed-by: Theodore Ts'o <tytso@mit.edu>
Reviewed-by: Jaegeuk Kim <jaegeuk@kernel.org>
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Sorayukii <sorayukii69@gmail.com>
Eric Biggersauthored and Sorayukiicommited 2026-05-15 18:07:18 +07:00
Add a function for filesystems to call to implement the
FS_IOC_ENABLE_VERITY ioctl. This ioctl enables fs-verity on a file.
See the "FS_IOC_ENABLE_VERITY" section of
Documentation/filesystems/fsverity.rst for the documentation.
Reviewed-by: Theodore Ts'o <tytso@mit.edu>
Reviewed-by: Jaegeuk Kim <jaegeuk@kernel.org>
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Sorayukii <sorayukii69@gmail.com>
Eric Biggersauthored and Sorayukiicommited 2026-05-15 18:07:18 +07:00
Add functions that verify data pages that have been read from a
fs-verity file, against that file's Merkle tree. These will be called
from filesystems' ->readpage() and ->readpages() methods.
Since data verification can block, a workqueue is provided for these
methods to enqueue verification work from their bio completion callback.
See the "Verifying data" section of
Documentation/filesystems/fsverity.rst for more information.
Reviewed-by: Theodore Ts'o <tytso@mit.edu>
Reviewed-by: Jaegeuk Kim <jaegeuk@kernel.org>
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Sorayukii <sorayukii69@gmail.com>
Eric Biggersauthored and Sorayukiicommited 2026-05-15 18:07:18 +07:00
Add a function fsverity_prepare_setattr() which filesystems that support
fs-verity must call to deny truncates of verity files.
Reviewed-by: Theodore Ts'o <tytso@mit.edu>
Reviewed-by: Jaegeuk Kim <jaegeuk@kernel.org>
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Sorayukii <sorayukii69@gmail.com>
Eric Biggersauthored and Sorayukiicommited 2026-05-15 18:07:18 +07:00
Add the fsverity_file_open() function, which prepares an fs-verity file
to be read from. If not already done, it loads the fs-verity descriptor
from the filesystem and sets up an fsverity_info structure for the inode
which describes the Merkle tree and contains the file measurement. It
also denies all attempts to open verity files for writing.
This commit also begins the include/linux/fsverity.h header, which
declares the interface between fs/verity/ and filesystems.
Reviewed-by: Theodore Ts'o <tytso@mit.edu>
Reviewed-by: Jaegeuk Kim <jaegeuk@kernel.org>
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Sorayukii <sorayukii69@gmail.com>
Eric Biggersauthored and Sorayukiicommited 2026-05-15 18:07:18 +07:00
Add the beginnings of the fs/verity/ support layer, including the
Kconfig option and various helper functions for hashing. To start, only
SHA-256 is supported, but other hash algorithms can easily be added.
Reviewed-by: Theodore Ts'o <tytso@mit.edu>
Reviewed-by: Jaegeuk Kim <jaegeuk@kernel.org>
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Sorayukii <sorayukii69@gmail.com>
Eric Biggersauthored and Sorayukiicommited 2026-05-15 18:07:18 +07:00
Since evicting inodes triggers writes to the backing file, which uses
the mi_owner field from the mount_info struct, make sure inodes are
evicted before we free the mount_info data
Test: incfs_test
Bug: 270117845
Change-Id: I673b2e0e04b5adc3998caf6f22443598a30338af
Signed-off-by: Paul Lawrence <paullawrence@google.com>
(cherry picked from commit 7899985277527b29c47929a6d6a89c5c89b406ad)
(cherry picked from commit faf3626b8e34df3dfff3a99e6582a9abd24410ce)
Signed-off-by: Lee Jones <joneslee@google.com>
Signed-off-by: Sorayukii <sorayukii69@gmail.com>
Paul Lawrenceauthored and Sorayukiicommited 2026-05-15 18:07:17 +07:00
Syzbot recently found a number of issues related to incremental-fs
(see bug numbers below). All have to do with the fact that incr-fs
allows mounts of the same source and target multiple times.
This is a design decision and the user space component "Data Loader"
expects this to work for app re-install use case.
The mounting depth needs to be controlled, however, and only allowed
to be two levels deep. In case of more than two mount attempts the
driver needs to return an error.
In case of the issues listed below the common pattern is that the
reproducer calls:
mount("./file0", "./file0", "incremental-fs", 0, NULL)
many times and then invokes a file operation like chmod, setxattr,
or open on the ./file0. This causes a recursive call for all the
mounted instances, which eventually causes a stack overflow and
a kernel crash:
BUG: stack guard page was hit at ffffc90000c0fff8
kernel stack overflow (double-fault): 0000 [#1] PREEMPT SMP KASAN
This change also cleans up the mount error path to properly clean
allocated resources and call deactivate_locked_super(), which
causes the incfs_kill_sb() to be called, where the sb is freed.
Bug: 211066171
Bug: 213140206
Bug: 213215835
Bug: 211914587
Bug: 211213635
Bug: 213137376
Bug: 211161296
Signed-off-by: Tadeusz Struk <tadeusz.struk@linaro.org>
Change-Id: I08d9b545a2715423296bf4beb67bdbbed78d1be1
Signed-off-by: Sorayukii <sorayukii69@gmail.com>
Tadeusz Strukauthored and Sorayukiicommited 2026-05-15 18:07:17 +07:00
This reverts commit 4ab5bac1598e3ed91a6267f6cada336467312112 and
2da7ed1f781983a2bc818f1d6f7cc9f2fa3ff1d2.
This is to fix the incrementalinstall test.
Can now install the same apk twice, and repeated installs are stable.
Bug: 217661925
Bug: 219731048
Signed-off-by: Tadeusz Struk <tadeusz.struk@linaro.org>
Change-Id: I77f038b296041b329060ff9350e4c9711f5ed91d
Signed-off-by: Sorayukii <sorayukii69@gmail.com>
Tadeusz Strukauthored and Sorayukiicommited 2026-05-15 18:07:17 +07:00
Cleanup incremental-fs left overs on umount, otherwise incr-fs will
complain as below:
BUG: Dentry {i=47a,n=.incomplete} still in use [unmount of incremental-fs]
This requires vfs_rmdir() of the special index dir.
Since set_anon_super() was used in incfs_mount_fs() the incfs_kill_sb()
should use kill_anon_super() instead of generic_shutdown_super()
otherwise it will leak the pseudo dev_t that set_anon_super() allocates.
Bug: 211066171
Signed-off-by: Tadeusz Struk <tadeusz.struk@linaro.org>
Change-Id: I7ea54db63513fc130e1997cbf79121015ee12405
Signed-off-by: Sorayukii <sorayukii69@gmail.com>
Tadeusz Strukauthored and Sorayukiicommited 2026-05-15 18:07:16 +07:00
Syzbot recently found a number of issues related to incremental-fs
(see bug numbers below). All have to do with the fact that incr-fs
allows mounts of the same source and target multiple times.
The correct behavior for a file system is to allow only one such
mount, and then every subsequent attempt should fail with a -EBUSY
error code. In case of the issues listed below the common pattern
is that the reproducer calls:
mount("./file0", "./file0", "incremental-fs", 0, NULL)
many times and then invokes a file operation like chmod, setxattr,
or open on the ./file0. This causes a recursive call for all the
mounted instances, which eventually causes a stack overflow and
a kernel crash:
BUG: stack guard page was hit at ffffc90000c0fff8
kernel stack overflow (double-fault): 0000 [#1] PREEMPT SMP KASAN
The reason why many mounts with the same source and target are
possible is because the incfs_mount_fs() as it is allocates a new
super_block for every call, regardless of whether a given mount already
exists or not. This happens every time the sget() function is called
with a test param equal to NULL.
The correct behavior for an FS mount implementation is to call
appropriate mount vfs call for it's type, i.e. mount_bdev() for
a block device backed FS, mount_single() for a pseudo file system,
like sysfs that is mounted in a single, well know location, or
mount_nodev() for other special purpose FS like overlayfs.
In case of incremental-fs the open coded mount logic doesn't check
for abusive mount attempts such as overlays.
To fix this issue the logic needs to be changed to pass a proper
test function to sget() call, which then checks if a super_block
for a mount instance has already been allocated and also allows
the VFS to properly verify invalid mount attempts.
Bug: 211066171
Bug: 213140206
Bug: 213215835
Bug: 211914587
Bug: 211213635
Bug: 213137376
Bug: 211161296
Signed-off-by: Tadeusz Struk <tadeusz.struk@linaro.org>
Change-Id: I66cfc3f1b5aaffb32b0845b2dad3ff26fe952e27
Signed-off-by: Sorayukii <sorayukii69@gmail.com>
Tadeusz Strukauthored and Sorayukiicommited 2026-05-15 18:07:16 +07:00
Use same selinux scheme as incfs v2
Fix memory leak
Bug: 174692664
Test: incfs_test passes
Signed-off-by: Paul Lawrence <paullawrence@google.com>
Change-Id: I6058ddad9d43ba01b2eabd7d3c576f2cc9b42292
Signed-off-by: Sorayukii <sorayukii69@gmail.com>
Paul Lawrenceauthored and Sorayukiicommited 2026-05-15 18:07:16 +07:00
READ/WRITE_ONCE are for atomic data types, not for structures. Fix this
up by doing a memcpy to make it explicit just how messy this copy is...
This fixes a build error on 5.8-rc1, as things are more strict, odds are
it's also wrong in other kernel versions as well...
Cc: Daniel Mentz <danielmentz@google.com>
Cc: Paul Lawrence <paullawrence@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I7ecd3d05bd94c936dd5e69c63028458786f37a78
Signed-off-by: Sorayukii <sorayukii69@gmail.com>
Greg Kroah-Hartmanauthored and Sorayukiicommited 2026-05-15 18:07:16 +07:00
It's still magic number issue which cannot be compatible with
arm-32 platform, although we try to fix it in Iae4f3877444
("ANDROID: Incremental fs: magic number compatible 32-bit"),
there is still incompatible scenario, such as: get_incfs_node(),
it will return NULL then kernel exception will be trigger because
of NULL pointer access. (inode_set() -> get_incfs_node(), then used
node->xxx directly)
We change magic number directly, otherwise, we must fix above issues
one by one.
Bug: 159772865
Fixes: Iae4f3877444("ANDROID: Incremental fs: magic number compatible 32-bit")
Signed-off-by: Peng Zhou <Peng.Zhou@mediatek.com>
Signed-off-by: mtk81325 <peng.zhou@mediatek.com>
Change-Id: I71f279c1bb55ea296ab33a47644f30df4a9f60a6
Signed-off-by: Paul Lawrence <paullawrence@google.com>
Signed-off-by: Sorayukii <sorayukii69@gmail.com>
mtk81325authored and Sorayukiicommited 2026-05-15 18:07:16 +07:00
Incfs's matic is bigger than 32-bit, but super block structure's
s_magic is unsigned long which is 32-bit in ARM 32-bit platform.
Do the cast for magic.
Bug: 159772865
Signed-off-by: Peng Zhou <Peng.Zhou@mediatek.com>
Signed-off-by: mtk81325 <peng.zhou@mediatek.com>
Change-Id: Iae4f38774440c7d6ae44529d4f0f8ebb2ec5dacc
Signed-off-by: Sorayukii <sorayukii69@gmail.com>
mtk81325authored and Sorayukiicommited 2026-05-15 18:07:16 +07:00
Incremental fs appears to not depend on pkcs7 anymore.
Bug: 151584760
Signed-off-by: Daniel Mentz <danielmentz@google.com>
Change-Id: I809b4b5651d84ca70fd8bf837765e33df8547418
Signed-off-by: Paul Lawrence <paullawrence@google.com>
(cherry picked from commit 83c1d9116ec0d695b02f36cda51f305257718e09)
Signed-off-by: Sorayukii <sorayukii69@gmail.com>
Daniel Mentzauthored and Sorayukiicommited 2026-05-15 18:07:15 +07:00
This reverts commit ab185e45f637ba0b0239268f1130890c8837981d.
This change used the PageChecked flag to mark the Merkle tree as
checked. However, f2fs uses this internally. This caused file system
hangs on devices after installs.
Test: incfs_test passes, installs no longer hang
Bug: 157589629
Signed-off-by: Paul Lawrence <paullawrence@google.com>
Change-Id: I980a700d65eb4f4a77434715d61dda4b8e80658c
Signed-off-by: Sorayukii <sorayukii69@gmail.com>
Paul Lawrenceauthored and Sorayukiicommited 2026-05-15 18:07:15 +07:00
Waking up the waiters accounts for 80+% of the total logging
time, and about 40% of overall read_single_page() with no
signature verification. By throttling it to once every 16ms
we get back all read performance, reduce the waiter's CPU
usage and still leave it enough time to pull the logs out.
Bug: 155996534
Test: adb install megacity.apk & dd from the installed apk
Signed-off-by: Yurii Zubrytskyi <zyy@google.com>
Signed-off-by: Paul Lawrence <paullawrence@google.com>
Change-Id: I4a118dc226d7ca318cf099ba3e239f0120bb23c2
Signed-off-by: Sorayukii <sorayukii69@gmail.com>
Yurii Zubrytskyiauthored and Sorayukiicommited 2026-05-15 18:07:15 +07:00
If an incfs file is created, then the file system is sync'd,on opening
the incfs file inode_set reads the size from the backing file from
within iget5_locked, causing this error.
Test: incfs_test passes, this no longer occurs
Bug: 156413528
Signed-off-by: Paul Lawrence <paullawrence@google.com>
Change-Id: I8939c4afa514d39d251c044d7680cfc69272669e
Signed-off-by: Sorayukii <sorayukii69@gmail.com>
Paul Lawrenceauthored and Sorayukiicommited 2026-05-15 18:07:15 +07:00
With a verified file (use incfs_perf to create a verified file), throughput
measured using dd after dropping caches increases from 200M/s to 290M/s
Test: incfs_test passes
Bug: 155996534
Signed-off-by: Paul Lawrence <paullawrence@google.com>
Change-Id: I7abb5ad92e4167f82f3452acc9db322fec8307dd
Signed-off-by: Sorayukii <sorayukii69@gmail.com>
Paul Lawrenceauthored and Sorayukiicommited 2026-05-15 18:07:15 +07:00
As was, chmod would change the cached inode's mode, which would
persist until the inode was uncached.
Fix to change mode of backing file, but make sure mount files
are read only, backing files are always writeable.
Test: App no longer fails with incfs errors
Bug: 154972299
Signed-off-by: Paul Lawrence <paullawrence@google.com>
Change-Id: I40517331f24329484387c6b880f1517f887b29f6
(cherry picked from commit fe4fae35fe307a15cacc5e6693a98bf5140e643b)
Signed-off-by: Sorayukii <sorayukii69@gmail.com>
Paul Lawrenceauthored and Sorayukiicommited 2026-05-15 18:07:14 +07:00
incfs only syncs at createfile time. This was making createfile take
a very long time. It also appears to offer little actual value -
whether we flush or no, if the device crashes the header will be
partial.
Bug: 15356649
Test: incfs_test passes, createfile takes less than half the time
Change-Id: I8f1fa138226868ebfb4a6a41254444af453070c8
Signed-off-by: Paul Lawrence <paullawrence@google.com>
(cherry picked from commit 4cc78c93ada6d0d8744c5b1ae12fddb50ea6a620)
Signed-off-by: Sorayukii <sorayukii69@gmail.com>
Paul Lawrenceauthored and Sorayukiicommited 2026-05-15 18:07:14 +07:00
Bug: 153560805
Test: incfs_test passes on qemu and Pixel 4
Signed-off-by: Paul Lawrence <paullawrence@google.com>
Change-Id: I1b55341e4e4247a74f3f539b9d190fef0ca409b8
Signed-off-by: Sorayukii <sorayukii69@gmail.com>
Paul Lawrenceauthored and Sorayukiicommited 2026-05-15 18:07:14 +07:00
Read log buffer can have multiple threads doing any of these
operations simultaneously:
- Polling for changes
- Reading log records
- Adding new log records
- Updating log buffer size, or enabling/disabling it completely
As we don't control the userspace, and it turns out that they
all currently originate from different processes, code needs to
be safe against parallel access to a read buffer and a request
for reallocating it.
This CL add an r/w spinlock to protect the buffer and its size.
Each remount takes the write lock, while everything else takes
a read lock. Remount makes sure it doesn't take too long by
preallocating and precalculating all updates, while other
operations don't care much about their critical section size -
they all can still run together.
Bug: 152633648
Test: manual remount + reading
Signed-off-by: Yurii Zubrytskyi <zyy@google.com>
Signed-off-by: Paul Lawrence <paullawrence@google.com>
Change-Id: I7271b4cb89f1ae2cbee6e5b073758f344c4ba66a
Signed-off-by: Sorayukii <sorayukii69@gmail.com>
Yurii Zubrytskyiauthored and Sorayukiicommited 2026-05-15 18:07:14 +07:00
This led to a 20x speed improvement on QEMU. 512 is somewhat
arbitrary - most of the gains are already there reading 64 records
at a time, but since the record size is 10 bytes, 512 is just over
a page and seems a good choice.
Bug: 153170997
Test: incfs_test passes. Adding logging to incfs_get_filled_blocks
to measure performance shows a 20x improvement
Signed-off-by: Paul Lawrence <paullawrence@google.com>
Change-Id: Ifb2da77cfd8c9d653c7047ba1eb7f39d795fa1c2
Signed-off-by: Sorayukii <sorayukii69@gmail.com>
Paul Lawrenceauthored and Sorayukiicommited 2026-05-15 18:07:14 +07:00
Found by sparse
Bug: 153174547
Test: make C=2 fs/incfs/incrementalfs.ko no errors, incfs_test pass
Signed-off-by: Paul Lawrence <paullawrence@google.com>
Change-Id: I9ff4f4f35975fe09936724488b96cd8bdeeb719e
Signed-off-by: Sorayukii <sorayukii69@gmail.com>
Paul Lawrenceauthored and Sorayukiicommited 2026-05-15 18:07:13 +07:00
This change was never cherry-picked to other branches,
is just syntactic sugar, and clashes with another change. Revert,
and then apply cleanly over all branches as needed.
This reverts commit 2664a43d88d91eb09f212cb26e111656a4acee49.
Change-Id: I51dca9cb046cc15302c22e8f73e58dcf4849f84d
Signed-off-by: Paul Lawrence <paullawrence@google.com>
Signed-off-by: Sorayukii <sorayukii69@gmail.com>
Paul Lawrenceauthored and Sorayukiicommited 2026-05-15 18:07:13 +07:00
Since INCFS_IOC_GET_FILLED_BLOCKS potentially leaks information about usage
patterns, and is only useful to someone filling the file, best protect it in
the same way as INCFS_IOC_FILL_BLOCKS.
Add useful field data_block_out as well
Test: incfs_test passes
Bug: 152983639
Signed-off-by: Paul Lawrence <paullawrence@google.com>
Change-Id: I126a8cf711e56592479093e9aadbfd0e7f700752
Signed-off-by: Sorayukii <sorayukii69@gmail.com>
Paul Lawrenceauthored and Sorayukiicommited 2026-05-15 18:07:13 +07:00
When read log is 0 sized, we still need to init the wait queue to avoid
kernel panics if someone does decide to poll on the read log.
Test: Added test for this condition, incfs_test crashes
With fix, incfs_test doesn't crash
Signed-off-by: Paul Lawrence <paullawrence@google.com>
Bug: 152909243
Change-Id: Ic3250523bb7ddb1839f8e95852c17103e5ffb782
Signed-off-by: Sorayukii <sorayukii69@gmail.com>
Paul Lawrenceauthored and Sorayukiicommited 2026-05-15 18:07:13 +07:00
When returning incomplete results index_out has to be usable to
call the function again and resume from the same location. This
means that if the output buffer was too small the function needs
to check for that when encountering the _beginning_ of a next
output range, not the end of it. Otherwise resuming from the
end of the range that didn't fit into the buffer would cause
the call to never return that range
+ Make the backing file header flags update thread safe
Bug: 152691988
Test: libincfs-test, incfs_test passes
Signed-off-by: Yurii Zubrytskyi <zyy@google.com>
Change-Id: I351156beba0b74e1942a39117279d3fcdb5e0c78
Signed-off-by: Paul Lawrence <paullawrence@google.com>
Signed-off-by: Sorayukii <sorayukii69@gmail.com>
Yurii Zubrytskyiauthored and Sorayukiicommited 2026-05-15 18:07:13 +07:00
Sorayukii
commited 
backslashxx
authored and
Eric Biggers
authored and
Nathan Huckleberry
authored and
Paul Lawrence
authored and
Tadeusz Struk
authored and
Lee Jones
authored and
Greg Kroah-Hartman
authored and
mtk81325
authored and
Daniel Mentz
authored and
Yurii Zubrytskyi
authored and