A new interface, F2FS_IOC_SEC_TRIM_FILE, has been added to F2FS
filesystem to send secure discard command to a specific file,
not to block device. We can use this interface for better discard
command handling on a file basis.
[how to use F2FS_IOC_SEC_TRIM_FILE]
start: start offset in byte (should be aligned with 4096)
len: length in byte (should be aligned with 4096, except designating EOF)
-1 also means till EOF.
flags: F2FS_TRIM_FILE_DISCARD - sending secure discard command. If the
device doesn't support it, send normal
discard.
F2FS_TRIM_FILE_ZEROOUT - overwrite zero data in the file.
Bug: 140759142
Test: execute "secdiscard -- <file_path>" and check the content of file
Signed-off-by: Daeho Jeong <daehojeong@google.com>
Change-Id: I6ee44a047d291274c9d70ae5e4ccccfc06a52f89
The interface which is imported by an unstable interface is 'unstable'
as well. Until now, the ODR violation checker in aidl has omitted an
interface imported, but it will be checked, accordingly, fix the current
problem
Bug: 146436251
Test: m nothing
Change-Id: Id3c4bbc9149ba7c3e0a0d728026f02f60cb17424
Merged-In: Id3c4bbc9149ba7c3e0a0d728026f02f60cb17424
Exempt-From-Owner-Approval: cp from internal
Add new benchmark capable of generating specific inode operations
workloads. Currently, it supports create, delete, move, hardlink and
symlink.
Test: Manual run on cuttlefish and physical device
Bug: 165903680
Signed-off-by: Stefano Duo <stefanoduo@google.com>
Change-Id: Ia47f259b7ccea5fe1665b272c3cbc9ec1bf2eb56
The name "pre_gki_level" is causing some confusion because not all
devices launching with Android R are subject to the GKI requirement.
(See b/161563110#comment11.) E.g., devices that use a 4.14-based kernel
are exempt from GKI. However, the encryption requirements still apply.
Just use __ANDROID_API_Q__ directly instead.
No change in behavior.
Change-Id: Id02ae1140845ac1ae7cf78be4e57fe34da028abf
Block groups with EXT4_BG_BLOCK_UNINIT still have backup superblocks
(and backup block group descriptors). Fix EncryptInPlace to encrypt
these backup superblocks rather than leave them unencrypted.
Previously leaving the backup superblocks unencrypted didn't cause any
problems, but due to system/core commit 72abd7b246f7 ("Try to recover
corrupted ext4 /data with backup superblock") it is causing problems.
Bug: 162479411
Bug: 161871210
Change-Id: Ic090bf4e88193b289b04c5254ddf661ef40b037e
Regression introduced by
commit 7ebcc2bcfd
("Revert "[Vold] Conditional dependency to ARC++ ObbVolume"")
errantly removed the product_variables support for
-D__ANDROID_DEBUGGABLE__ when built for userdebug builds.
Restore stanza.
Signed-off-by: Mark Salyzyn <salyzyn@google.com>
Bug: 161454607
Test: adb-remount-test no longer reports a problem
Change-Id: Ia7e55d1174fa7fac2d934d4aac06d15e8be388af
Now that Bionic's copy of <linux/fscrypt.h> has been updated, there's no
need for vold to carry its own fscrypt_uapi.h.
Test: build
Change-Id: I61581ac74f7cf77bc8a835e64d96553a9d0c517a
Use C++'s built-in mechanism for one-time initialization rather than
implement it ourselves in a way that isn't thread-safe.
(It doesn't *actually* need to be thread-safe, since all callers of this
run under ACQUIRE_CRYPT_LOCK. But that's not easy to verify.)
Test: booted Cuttlefish and checked log for the one-time message
"Detected support for FS_IOC_ADD_ENCRYPTION_KEY"
Change-Id: I6ca5b143ca305fa95144e388efc9657e3507bf05
This reverts commit aedae617fe.
Reason for revert: ArcObbVolume is not needed by ARCVM R and above.
Bug: 157885448
Test: trybot
Change-Id: I16395ac8b6902cedea263f51e306b297d719043f
