thin-pool and thin targets are supported via DmTargetThinPool and
DmTargetThin. DM_TARGET_MSG is also added via a new method
SendMessage() because it's used to create a thin volumn.
dmctl is extended to support thin-pool and thin targets.
TODO: thin-pool target constructor can accept feature arguments.
Bug: 327081431
Test: atest libdm_test (CF with dm-thin enabled kernel)
Change-Id: I4c51c668bfe1489b959f6d03c205a5e2e63d9a1d
This adds an option "ima" in dmctl.
$ dmctl ima product-verity
Targets in the device-mapper table for product-verity:
0-7463768: verity, target_name=verity,target_version=1.9.0,hash_failed=V,verity_version=1,data_device_name=254:4,hash_device_name=254:4,verity_algorithm=sha256,root_digest=d7af9fcb04d184219ba5477b97bb2bbc89fd23a46e03d1dea31d674cc4934769,salt=19d4f2345adfc8b7cc22a3c2f21dd413e5020fc7920a08a33f46f3c61492dfcc,ignore_zero_blocks=y,check_at_most_once=n,verity_mode=restart_on_corruption;
Change-Id: I057970b6c786b3f9a394b4919f5f5115b27cbc08
Signed-off-by: Jaegeuk Kim <jaegeuk@google.com>
Add dm stripe in dmctl framework to support stripe on two block devices.
Bug: 321628121
Change-Id: I2f326f19f7ccff1ee03598743022fb702b3e8d6a
Signed-off-by: Ed Tsai <ed.tsai@mediatek.com>
Before this patch, DeleteDeviceWithTimeout was checking that the dev
node (i.e. /dev/block/dm-XX) is deleted after the call to DeleteDevice
API. Since ueventd first deletes the symlinks that correspond to a
device and only then deletes this device node, this assertion introduced
a race condition (DeleteDevice API waits for the symlink to be deleted).
This patch changes the DeleteDeviceWithTimeout test to check that unique
path of the device has been deleted.
Bug: 318425605
Test: presubmit
Change-Id: I3fd9de507c75bcf6ac1350fa0b8adfdb5a2e89e8
Previously, libdm ensured that uevent will be generated when a dm device
is deleted. However, there actually are cases where uevent can't be
expected; for example, if an empty dm device is created, but then gets
deleted without being activated, then there should be no uevent upon
deleting because there actually is nothing to remove from /dev. (dm
device gets added to /dev only if it is activated).
Actually such a case exists in apexd. As a performance optimization, it
proactively creates empty dm devices for all APEXes it scanns. But
some of them don't ever get activated if the APEX is already in a
dm-verity protected block device (i.e. the pre-instaled APEX is the
latest one). In that cases, the empty dm devices are deleted at the end
of the boot process as a clean up.
The libdm triggered error during the clean up, because there was no
uevent generated for the empty dm devices. This has triggered a lot of
false alarms to the apex team.
This CL fixes this by ensuring uevent only for activate dm devices. If
the dm device doesn't show up in /dev, we just delete the in-kernel
object and don't expect it to generate uevent for it - which actually is
the kernel's behavior.
Bug: 286176029
Test: build and run aosp_cf_x86_64_phone. observe dmesg.
Before the change:
I apexd : Deleting unused dm device com.android.hardware.core_permissions
E apexd : Didn't generate uevent for [com.android.hardware.core_permissions] removal
W apexd : Failed to delete dm-device com.android.hardware.core_permissions
After the change:
I apexd : Deleting unused dm device com.android.hardware.core_permissions
<no error or warning logs>
Change-Id: I52042de7d4d9ab62e6a13428c32a67e13395d1b5
We've had flake in libdm_test for a long time, with no clear cause.
Lately however it has become particularly reproducible when running
the UeventAfterLoadTable test in isolation, and thus we've identified
the root cause.
uevents for device-mapper are fired when the sysfs node is added, but at
that time, the "dm" subnode has not yet been added. The root node and dm
node are added very close together, so usually it works, but sometimes
ueventd is too fast.
Instead of relying on sysfs, query the uuid/name node directly from
device-mapper.
Bug: 270183812
Test: libdm_test
Change-Id: I258de5de05d813c3cb7f129e82e56dbfe8bf3117
This fuzzer can only mutate the numerical inputs to a dm-linear table,
which is unlikely to find kernel bugs, and very unlikely to find libdm
bugs. There are a number of automated notifications from it due to
making ASSERT_EQ a no-op, which causes misuse of libdm API calls. None
of these appear to be real bugs.
Bug: 174907083
Test: N/A
Change-Id: Iaa8955eaa4423e4315b8cb74741e6425a56cc303
This test was added only for behavior introduced in the 5.15 kernel, where uevents are delayed until a table is laoded.
Bug: 263291020
Test: libdm_test
Change-Id: I6236c4304d8e6b780704df405290f7361d5827cc
DM_DEV_CREATE no longer creates sysfs nodes. Note this in ueventd and
add some helper APIs to libdm, so devices can be created with a
placeholder table.
This also fixes a bug in dmctl where the detailed info on suspended
devices was wrong.
Bug: 259328366
Test: dmctl with "uevents" tool
Change-Id: I822f8010e48d32841aa0ee508822f76d03a3dd85
Support building fs_mgr against musl by including the missing
sys/types.h header.
Bug: 190084016
Test: m USE_HOST_MUSL=true host-native
Change-Id: Ie3b3907b1c60ba550c04e8780f11b7adf09a6471
Test options for the api levels are moved to test_options.
test_min_api_level property will be removed with this change.
Bug: 187258404
Test: build
Change-Id: Id943566de2ac693b5955bd84a8463e5013a8bb0f
Userdata spaces leak when zram writeback is enable and repeatedly kill
system_server(restart android).
The reason is that per_boot‘s inode is hold by loop device
although per_boot is deleted by user which become orphan inode in system.
Adds LO_FLAGS_AUTOCLEAR for loop device of zram backing device,
so loop device can release resouce.
Bug: 200904398
Change-Id: Ifeee9c0b58b10cdf7698077fbcaf54d5faccc3b1
Signed-off-by: Liangcai Fan <liangcai.fan@unisoc.com>
Signed-off-by: Hongyu Jin <hongyu.jin@unisoc.com>
Signed-off-by: Jing Xia <jing.xia@unisoc.com>
It is difficult to test libsnapshot failures because there is no way to
inject failure scenarios into the kernel's device-mapper. Exposing a
virtual interface will allow this kind of testing via dependency
injection.
Bug: 199785546
Test: builds, tests pass
Change-Id: I5add0c7e24f7fa2853114eaeda7c479eaa4e0552
Make this function available to libdm users. A caller outside libdm will
be added by a later patch.
Bug: 194450129
Test: mm libfs_mgr libdm_test
Change-Id: I3e3560f3cdef8978eac644d5b53cf3851209c0c2
Signed-off-by: Bart Van Assche <bvanassche@google.com>
From https://engdoc.corp.google.com/eng/doc/devguide/cpp/styleguide.md:
"Prefer using return values over output parameters: they improve
readability, and often provide the same or better performance (see the C++
Primer)." Implement this advice for ExtractBlockDeviceName(). This patch
does not change any functionality.
Bug: 194450129
Test: mm libfs_mgr libdm_test
Change-Id: I6363781163eba08e6128507b403200f472f68a59
Signed-off-by: Bart Van Assche <bvanassche@google.com>
When the device is rebooted after OTA is done,
daemon will read through all the dynamic partitions
to bring the blocks to memory. When update-verifier
runs, all the blocks would be in page-cache thereby
cutting down the boot time.
Boot time improvements on Pixel:
Full OTA:
===========
VABC (Without this patch): 37.308 seconds
VABC (With this patch): 28.604 seconds
Incremental OTA:
=================
VABC (Without this patch): 39.072 seconds
VABC (With this patch): 27.523 seconds
We read the blocks only during second stage transition. Thus,
it shouldn't impact when snapuserd is spin up during
post-install phase or during first-stage init.
Bug: 193863442
Test: Full and Incremental OTA on pixel
Signed-off-by: Akilesh Kailash <akailash@google.com>
Change-Id: Id654449238e22125f7d6288c7100fde512cc2ced
Judging from local experiments, it looks like device-mapper doesn't
always generate a uevent after DM_DEV_CREATE ioctl.
Test: presubmit
Bug: 193462349
Change-Id: I8a74375631b20c14a32a41dbaf38380ebc0078e6
These APIs support a flow in which dm devices can be created before they
are actually needed, hence minimizing the time a process will wait for
ueventd to create user space paths.
Bug: 190618831
Test: atest libdm_test
Change-Id: I4dfa14e5271a6a13de6da73ec3c7efb1ebc0f8b8
This can be useful in case when a device mapper device can't be deleted
straight away, and instead delete needs to be enqueued until last
reference to the device is closed.
Bug: 187864524
Bug: 188713178
Test: atest libdm_test
Change-Id: Ie8a130baa54e6e16d8d159389bd760bf873eca40
The latest kernel supports dm-verity has new error handling mode(panic).
However, there is no code to support in android.
Signed-off-by: JeongHyeon Lee <jhs2.lee@samsung.com>
Change-Id: Ib88ec258adb76ca4c88df1a78636f73f40604b40
It looks like in some rare scenarios device-mapper won't create an
uevent while handling DM_DEV_REMOVE ioctl.
Since failure to generate uevent will result in ueventd not cleaning up
/dev paths in user space, it should be ok to just fail DeleteDevice call
without aborting the entire process.
Test: presubmit
Bug: 171266986
Change-Id: Iece28e6e02c35ac4bf33b9be74dfe1bbbb466bd4
Rather than using some implicit naming scheme, we've decided to just let
userspace pick whatever control device naming scheme it wants. This requires
an additional argument to be passed to the kernel.
Test: cow_snapuserd_test
Bug: 168259959
Signed-off-by: Palmer Dabbelt <palmerdabbelt@google.com>
Change-Id: Ibf7f378b67abb6ca7457a9fdc9b8739e3d31bee3
Signed-off-by: Akilesh Kailash <akailash@google.com>
Add basic support for daemon creation and handle signals
Test: Add test case to test system and product COW partitions
Bug: 162790322
Signed-off-by: Akilesh Kailash <akailash@google.com>
Change-Id: Icf8dbe49d2237cec6f7dbcdd84256eb6c5afa1cd
This makes looking up device UUIDs a bit easier, as rather than depending on
the device mapper's sysfs layout we can depend on dmctl. There's some
associated libdm plumbing, but the UUID was already pretty much availiable.
Test: I just ran this by hand.
Signed-off-by: Palmer Dabbelt <palmerdabbelt@google.com>
Change-Id: I7028eec6ab04601308047b67057e51a0ff44c0a7
Right now this is open-coded. As the API stabilizes it will be
integrated into libdm.
Bug: 154536437
Test: manual test
Change-Id: I07bb811b6fb80d85d55e218d788023634c8158b7
dm-user is very much a WIP and while this may change (we need to figure out how
to get credentials to the dm-user daemon, for example) it seems like a somewhat
safe bet to assume that the behavior will at least include a start/end range.
Test: I just ran "dmctl create palmer user 0 1024", which created the device.
Signed-off-by: Palmer Dabbelt <palmerdabbelt@google.com>
Change-Id: Ic5f84de6a4f09bf906246035d450edd637cc38ed
Fix block-level checkpointing to work correctly when used in combination with
512 byte hardware sectors and metadata encryption with dm-default-key v2.
Bug: 153512828
Test: Parameter is passed to dm-bow based on first_api_level
Change-Id: Ic0a071221559271db20b06b2f17459b5b041e02d
When delivering single-stage, non-AB OTAs, the updater binary is built
on a newer OS than recovery is compiled with. libdm relies on newer ueventd
behavior which therefore breaks this model. As a workaround, we allow
libdm to fallback to the old ueventd logic if the following conditions
hold true: (1) we're in recovery, (2) the device is not an AB device,
and (3) the release is <= 10.
Since the old ueventd behavior can lead to races in libdm, this fallback
should stay as narrow as possible.
Bug: 156536673
Bug: 155202260
Test: manual test
Change-Id: I7f9da49e4ba8dfe165e0923d9918827d51d090cd
Bug: 151896491
Test: local build
Exempt-From-Owner-Approval: This CL moves all tests in vts-core to vts.
It won't change test logic or behavior.
Change-Id: I24779951257ce37fc18929f214d3cf5f76c23a19
Merged-In: I24779951257ce37fc18929f214d3cf5f76c23a19
To make it easier to support disk formats created using old versions
of dm-default-key with new kernels, stop checking the kernel module
version; instead, the caller decides whether to use the old or new
options format.
Bug: 150761030
Test: crosshatch and cuttlefish boot normally; cuttlefish
fails with "default-key: Not enough arguments" as expected when
option is set to 1
Change-Id: I810bb7e085b9b8648858de1a02165162d1fd163e
