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
e09de2a5ca