The previous size, 2048, is only the size of the 'environment' for the
uevent message, but doesn't include the <action>@<dev path> portion.
The <action> portion has a max length < 10, but the <dev path> portion
is unbounded.
8192 should be plenty to capture all of these parameters.
Bug: 161580785
Test: ueventd still works
Change-Id: I6de6fd3a444ac91b3b4df154097abde3696e21b3
After r.android.com/1288984 we started failing to dump memory contents
for heap addresses because the tag started causing any addresses to
fail this bounds check. Add an untag_address() call to the bounds check
so that the tag is ignored.
Bug: 154272452
Change-Id: I3a6d1a078b21871bd93164150a123549f83289f6
To profile different log buffer types and configuration, this change
adds the ability to record log messages and adds a tool that will
replay those log messages through different log buffer implementations
and collect stats about the execution.
Test: log messages replay correctly
Change-Id: I0dc6c545b782fa7732e325dde109c496b137d0dd
This will hopefully identify misusage of the erase-remove idiom.
Test: "foo.erase(std::remove_if(...))" produces error.
Test: mmm system/core/adb -j (no warnings)
Change-Id: Iba0a6fc40cb6e7c65a7a3926d915874dc89a60c6
* changes:
fs_mgr: adb-remount-test.sh: use 24-bit forground colors
fs_mgr: adb-remount-test.sh: Port to MAC OS/X
fs_mgr: adb-remount-test.sh report kernel version of device
fs_mgr: adb-remount-test.sh filter out ramdumpfs administrative mount
Do not attempt to mount scratch r/w if it is ext4 dedupe, this causes
too much noise and troubling but innocuous error reports.
Assumption is we normally try f2fs first on all devices, we only try
ext4 first if we do not have f2fs tools, or if the existing
filesystem is ext4. That said, we only have to check if it is ext4
dedupe during the first mount attempt, the fallback mount attempt for
ext4 is unlikely to need this checking.
Changes the output report for a retrofit DAP device from:
$ adb remount
Disabling verity for /system
[libfs_mgr]superblock s_max_mnt_count:65535,/dev/block/by-name/system_b
[libfs_mgr]check_fs(): mount(/dev/block/by-name/system_b,/mnt/scratch,ext4)=-1: Invalid argument
[libfs_mgr]Running /system/bin/e2fsck on /dev/block/sda6
[libfs_mgr]__mount(source=/dev/block/by-name/system_b,target=/mnt/scratch,type=ext4)=-1: Invalid argument
[libfs_mgr]Running /system/bin/fsck.f2fs -a /dev/block/sda6
[libfs_mgr]__mount(source=/dev/block/by-name/system_b,target=/mnt/scratch,type=f2fs)=0: Success
Using overlayfs for /system
. . .
To the more pleasant:
$ adb $BL1 remount
Disabling verity for /system
[libfs_mgr]superblock s_max_mnt_count:65535,/dev/block/by-name/system_b
[libfs_mgr]__mount(source=/dev/block/by-name/system_b,target=/mnt/scratch,type=ext4)=0: Success
[libfs_mgr]umount(/mnt/scratch)
[libfs_mgr]Running /system/bin/fsck.f2fs -a /dev/block/sda6
[libfs_mgr]__mount(source=/dev/block/by-name/system_b,target=/mnt/scratch,type=f2fs)=0: Success
Using overlayfs for /system
. . .
Signed-off-by: Mark Salyzyn <salyzyn@google.com>
Test: adb-remount-test.sh
Change-Id: Ic8c642912b1bafe0b4210c69c99a1d89fa20f204
This allows colors to rendor according to user preferences
in terminal emulator settings.
Signed-off-by: Mark Salyzyn <salyzyn@google.com>
Bug: 161454607
Test: make sure colors make sense
Change-Id: Ie2749dcce66954deddbca2863dadfa270cc6633e
This script did not run on a MAC, adjust so that it is usable.
Signed-off-by: Mark Salyzyn <salyzyn@google.com>
Bug: 161454607
Test: script can be used to test and replicate reported problem
Change-Id: Id1c97b9cd85d150a96733b8d39e40f6a4bcc0721
Report kernel version as part of the report. Also warn user that
they are waiting for the screen to come up, and if the delay is
far too long, or the device is headless, then consider using the
--no-wait-screen option
Signed-off-by: Mark Salyzyn <salyzyn@google.com>
Test: adb-remount-test.sh
Bug: ????
Change-Id: I68d1757da62d028dc3633b1175b06af19e469d9f
Causes flakes as the ramdumpfs may temporarily be applied
to check and/or retrieve content.
Signed-off-by: Mark Salyzyn <salyzyn@google.com>
Bug: 161454607
Test: no more flakes
Change-Id: I8e4b6a808ab81ec5b4f760a810b9b651a0b329d0
When calculating the space used for pruning, if a log chunk is
compressed, that size is used otherwise the uncompressed size is
used. This is intended to reach a steady state where 1/4 of the log
buffer is the uncompressed log chunk that is being written to and the
other 3/4 of the log buffer is compressed logs.
If we wait until there are no readers referencing the log chunk before
compressing it, we end up with 2 uncompressed logs (the one that was
just filled, that readers are still referencing, and the new one that
was allocated to fit the most recent log), which take up 1/2 of the
log buffer's allotted size and will thus cause prune to delete more
compressed logs than it should.
Instead, we should always compress the log chunks in FinishWriting()
such that the compressed size will always be used for log chunks other
than the one that is not actively written to.
Decompressed logs due to readers are ephemeral by their nature and
thus don't add to the log buffer size for pruning.
Test: observe that log buffers can be filled in the presence of a reader.
Change-Id: Ie21ccff032e41c4a0e51710cc435c5ab316563cb
