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
Without these, you can't unmount a volume on which incfs was
mounted and the tests run.
Also incfs_tests would fail sporadically without the fix to
test_inode
Test: Run incfs_test and unmount underlying volume 1000 times
Bug: 152636070
Signed-off-by: Paul Lawrence <paullawrence@google.com>
Change-Id: I88f11f5d4269c22d9073e5eb671d0c7cc4629f6c
(cherry picked from commit c062bc8e769f0f6e47cc41fb9b7ab30e3e7f2689)
Signed-off-by: Sorayukii <sorayukii69@gmail.com>
Paul Lawrenceauthored and Sorayukiicommited 2026-05-15 18:07:13 +07:00
Provide a securable way to open a file for filling
Test: incfs_test passes
Bug: 138149732
Signed-off-by: Paul Lawrence <paullawrence@google.com>
Change-Id: Ib4b6fd839ad30ce08e31121d19e2c0d7066d302f
Signed-off-by: Sorayukii <sorayukii69@gmail.com>
Paul Lawrenceauthored and Sorayukiicommited 2026-05-15 18:07:12 +07:00
Filling blocks is not equivalent to writing a file, since they are
constrained by the root hash. selinux policy may wish to treat them
differently, for instance.
Test: incfs_test passes
Bug: 138149732
Signed-off-by: Paul Lawrence <paullawrence@google.com>
Change-Id: Ic369b84b92547b1cfefe422bd881c4e466090aed
Signed-off-by: Sorayukii <sorayukii69@gmail.com>
Paul Lawrenceauthored and Sorayukiicommited 2026-05-15 18:07:12 +07:00
They provide no value and simply duplicate a check in copy_from/to_user
Test: incfs_test passes
Bug: 138149732
Signed-off-by: Paul Lawrence <paullawrence@google.com>
Change-Id: Icc6054a2d6a495c9a03cd1507dda1ab8ca0b0dc4
Signed-off-by: Sorayukii <sorayukii69@gmail.com>
Paul Lawrenceauthored and Sorayukiicommited 2026-05-15 18:07:12 +07:00
To make selinux work, add xattr support. This is a bit clunky -
it seems like it would be better for the log and pending read
functionality to be ioctls rather than this mixture of real
and virtual files.
Bug: 133435829
Change-Id: I56579fabe2ae7efb88f0344553948dc9573299aa
Signed-off-by: Paul Lawrence <paullawrence@google.com>
Signed-off-by: Sorayukii <sorayukii69@gmail.com>
Paul Lawrenceauthored and Sorayukiicommited 2026-05-15 18:07:11 +07:00
- added chmod() to +0222 to make all backing files and dirs
writable. vold/system_server have a umask that clears those
flags, making incfs unusable
Signed-off-by: Yurii Zubrytskyi <zyy@google.com>
Signed-off-by: Paul Lawrence <paullawrence@google.com>
Bug: 133435829
Change-Id: Id9258401570cc2cc7cd5735aace89d379a9b043d
Signed-off-by: Sorayukii <sorayukii69@gmail.com>
Yurii Zubrytskyiauthored and Sorayukiicommited 2026-05-15 18:07:11 +07:00
Fix all sparse errors in fs/incfs except
fs/incfs/integrity.c:192:9: warning: Variable length array is used
Test: incfs_test passes
Bug: 133435829
Change-Id: I9c2e26e4e1a06a894977f11a3c8559b968dd115e
Signed-off-by: Paul Lawrence <paullawrence@google.com>
Signed-off-by: Sorayukii <sorayukii69@gmail.com>
Paul Lawrenceauthored and Sorayukiicommited 2026-05-15 18:07:11 +07:00
Fixed incfs_test build errors
Fixed Kconfig errors
Readded .gitignore
Test: With just enabling CONFIG_INCREMENTAL_FS, both defconfig and
cuttlefish_defconfig build and incfs_test runs and passes
Bug: 133435829
Change-Id: Id3247ffcc63a095f66dcedf554017a06c5a9ce4a
Signed-off-by: Paul Lawrence <paullawrence@google.com>
Signed-off-by: Sorayukii <sorayukii69@gmail.com>
Paul Lawrenceauthored and Sorayukiicommited 2026-05-15 18:07:10 +07:00
The original dedup code does not handle collision from the observation
that it practically does not happen.
For additional peace of mind, use a bigger hash size for reducing the
possibility of collision even further.
Signed-off-by: Juhyung Park <qkrwngud825@gmail.com>
Signed-off-by: Marco Zanin <mrczn.bb@gmail.com>
Signed-off-by: snnbyyds <snnbyyds@gmail.com>
Signed-off-by: Sorayukii <sorayukii69@gmail.com>
Juhyung Parkauthored and Sorayukiicommited 2026-05-15 18:07:10 +07:00
Makoto report a below KASAN error: zram does out-of-bounds read. Because
strscpy copies from source up to count bytes unconditionally. It could
cause out-of-bounds read on next object in slab.
To prevent it, use strlcpy which checks source's length automatically.
BUG: KASAN: slab-out-of-bounds in strscpy+0x68/0x154
Read of size 8 at addr ffffffc0c3495a00 by task system_server/1314
..
Call trace:
strscpy+0x68/0x154
idle_store+0xc4/0x34c
dev_attr_store+0x50/0x6c
sysfs_kf_write+0x98/0xb4
kernfs_fop_write+0x198/0x260
__vfs_write+0x10c/0x338
vfs_write+0x114/0x238
SyS_write+0xc8/0x168
__sys_trace_return+0x0/0x4
Allocated by task 1314:
__kmalloc+0x280/0x318
kernfs_fop_write+0xac/0x260
__vfs_write+0x10c/0x338
vfs_write+0x114/0x238
SyS_write+0xc8/0x168
__sys_trace_return+0x0/0x4
Freed by task 2855:
kfree+0x138/0x630
kernfs_put_open_node+0x10c/0x124
kernfs_fop_release+0xd8/0x114
__fput+0x130/0x2a4
____fput+0x1c/0x28
task_work_run+0x16c/0x1c8
do_notify_resume+0x2bc/0x107c
work_pending+0x8/0x10
The buggy address belongs to the object at ffffffc0c3495a00
which belongs to the cache kmalloc-128 of size 128
The buggy address is located 0 bytes inside of
128-byte region [ffffffc0c3495a00, ffffffc0c3495a80)
The buggy address belongs to the page:
page:ffffffbf030d2500 count:1 mapcount:0 mapping: (null) index:0x0 compound_mapcount: 0
flags: 0x4000000000010200(slab|head)
page dumped because: kasan: bad access detected
Memory state around the buggy address:
ffffffc0c3495900: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
ffffffc0c3495980: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
>ffffffc0c3495a00: 04 fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
^
ffffffc0c3495a80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
ffffffc0c3495b00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Link: http://lkml.kernel.org/r/20190319231911.145968-1-minchan@kernel.org
Cc: <stable@vger.kernel.org> [5.0]
Signed-off-by: Minchan Kim <minchan@kernel.org>
Reported-by: Makoto Wu <makotowu@google.com>
Reviewed-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Change-Id: I785c262bc2c95a07e826a6244c21e3d85520b525
Signed-off-by: Marco Zanin <mrczn.bb@gmail.com>
Signed-off-by: snnbyyds <snnbyyds@gmail.com>
Signed-off-by: Sorayukii <sorayukii69@gmail.com>
Minchan Kimauthored and Sorayukiicommited 2026-05-15 18:07:10 +07:00
zram_table_entry::flags stores object size in the lower bits and zram
pageflags in the upper bits. However, for some reason, we use 24 lower
bits, while maximum zram object size is PAGE_SIZE, which requires
PAGE_SHIFT bits (up to 16 on arm64). This wastes 24 - PAGE_SHIFT bits
that we can use for additional zram pageflags instead.
Also add a BUILD_BUG_ON() to alert us should we run out of bits in
zram_table_entry::flags.
Link: https://lkml.kernel.org/r/20220912152744.527438-1-senozhatsky@chromium.org
Signed-off-by: Sergey Senozhatsky <senozhatsky@chromium.org>
Reviewed-by: Brian Geffon <bgeffon@google.com>
Acked-by: Minchan Kim <minchan@kernel.org>
Cc: Nitin Gupta <ngupta@vflare.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Marco Zanin <mrczn.bb@gmail.com>
Signed-off-by: snnbyyds <snnbyyds@gmail.com>
Signed-off-by: Sorayukii <sorayukii69@gmail.com>
Sergey Senozhatskyauthored and Sorayukiicommited 2026-05-15 18:07:09 +07:00
zram was the motivation for creating memset_l(). Minchan Kim sees a 7%
performance improvement on x86 with 100MB of non-zero deduplicatable
data:
perf stat -r 10 dd if=/dev/zram0 of=/dev/null
vanilla: 0.232050465 seconds time elapsed ( +- 0.51% )
memset_l: 0.217219387 seconds time elapsed ( +- 0.07% )
Link: http://lkml.kernel.org/r/20170720184539.31609-7-willy@infradead.org
Signed-off-by: Matthew Wilcox <mawilcox@microsoft.com>
Tested-by: Minchan Kim <minchan@kernel.org>
Cc: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: "James E.J. Bottomley" <jejb@linux.vnet.ibm.com>
Cc: "Martin K. Petersen" <martin.petersen@oracle.com>
Cc: David Miller <davem@davemloft.net>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Ivan Kokshaysky <ink@jurassic.park.msu.ru>
Cc: Matt Turner <mattst88@gmail.com>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: Richard Henderson <rth@twiddle.net>
Cc: Russell King <rmk+kernel@armlinux.org.uk>
Cc: Sam Ravnborg <sam@ravnborg.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Marco Zanin <mrczn.bb@gmail.com>
Signed-off-by: snnbyyds <snnbyyds@gmail.com>
Signed-off-by: Sorayukii <sorayukii69@gmail.com>
Matthew Wilcoxauthored and Sorayukiicommited 2026-05-15 18:07:09 +07:00
Install the callbacks via the state machine with multi instance support and let
the core invoke the callbacks on the already online CPUs.
[bigeasy: wire up the multi instance stuff]
[B--B: fixed wrong spacing and newlines]
Signed-off-by: Anna-Maria Gleixner <anna-maria@linutronix.de>
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>
Cc: Minchan Kim <minchan@kernel.org>
Cc: rt@linutronix.de
Cc: Nitin Gupta <ngupta@vflare.org>
Link: http://lkml.kernel.org/r/20161126231350.10321-19-bigeasy@linutronix.de
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Marco Zanin <mrczn.bb@gmail.com>
Signed-off-by: snnbyyds <snnbyyds@gmail.com>
Signed-off-by: Sorayukii <sorayukii69@gmail.com>
Anna-Maria Gleixnerauthored and Sorayukiicommited 2026-05-15 18:07:09 +07:00
Mikhail reported a lockdep spat detailing how __zram_bvec_read() and
__zram_bvec_write() use zstrm->lock and zspage->lock in opposite order.
Reported-by: Mikhail Gavrilov <mikhail.v.gavrilov@gmail.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Tested-by: Mikhail Gavrilov <mikhail.v.gavrilov@gmail.com>
Acked-by: Minchan Kim <minchan@kernel.org>
Acked-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Marco Zanin <mrczn.bb@gmail.com>
Signed-off-by: snnbyyds <snnbyyds@gmail.com>
Signed-off-by: Sorayukii <sorayukii69@gmail.com>
Peter Zijlstraauthored and Sorayukiicommited 2026-05-15 18:07:09 +07:00