Currently, there are various global init exit issues encountered
on Andriod/linux system. It's hard to debug these issues on product
environment without a usable coredump.
For example, it's hard to get the root cause why global init task exited from the below kmsg:
[ 4.696032][T400001] e2fsck: /dev/block/by-name/metadata: clean, 35/8192 files, 2083/8192 blocks
[ 4.696783][T500326] [bq27z561] fg_debug_dump_regs: slave_dump:Reg[0x0073] = 0x05C5
[ 4.700583][T400001] EXT4-fs (sdc17): mounted filesystem with ordered data mode. Opts: discard
[ 4.706445][T400001] Kernel panic - not syncing: Attempted to kill init! exitcode=0x00007f0000
[ 4.706459][T400001] CPU: 4 PID: 1 Comm: init Tainted: G S W 5.10.136-android12-9-00005-gf9a66cbe7091-ab9177899 #1
[ 4.706464][T400001] Hardware name: MT6983Z/TCZA (DT)
[ 4.706469][T400001] Call trace:
[ 4.706482][T400001] dump_backtrace.cfi_jt+0x0/0x8
[ 4.706493][T400001] dump_stack_lvl+0xc4/0x140
[ 4.706504][T400001] panic+0x178/0x464
[ 4.706511][T400001] do_exit+0xb30/0xf9c
[ 4.706517][T400001] do_group_exit+0x130/0x1c8
[ 4.706523][T400001] do_group_exit+0x0/0x1c8
[ 4.706529][T400001] __do_sys_exit_group+0x0/0x18
[ 4.706535][T400001] __se_sys_exit_group+0x0/0x14
[ 4.706543][T400001] el0_svc_common+0xd4/0x270
[ 4.706551][T400001] el0_svc+0x28/0x88
[ 4.706559][T400001] el0_sync_handler+0x8c/0xf0
[ 4.706567][T400001] el0_sync+0x1b4/0x1c0
Add hook for task exiting routine, while will be helpful for OEMs to
get the reason of any exiting task to be noticed such as dump last
exit thread executable sections and registers info.
Bug: 324013972
Link: https://lore.kernel.org/lkml/20231110032043.34516-1-qiwu.chen@transsion.com/T/
Change-Id: Ibb7c9012af18b99a1bb458d236f166e6450241c3
Signed-off-by: qiwu.chen <qiwu.chen@transsion.com>
Recently we have discovered many lag issues caused by percpu_rwsem
lock-holding tasks not being scheduled for a long time. we need to
identify them and provide appropriate scheduling protection in our
oem scheduler.
To support this, we add one hook below:
trace_android_vh_percpu_rwsem_wq_add
Bug: 301066838
Change-Id: Id770c1a7978842abfc62d3fa9aeb5ac7a1904972
Signed-off-by: xieliujie <xieliujie@oppo.com>
(cherry picked from commit f451f4a59950135ea9a6ede218c58f10dbb3abaa)
These hooks help us do the following things:
a) Record the number of mutex and rwsem optimistic spin.
b) Monitor the time of mutex and rwsem optimistic spin.
c) Make it possible if oems don't want mutex and rwsem to optimistic spin
for a long time.
Bug: 267565260
Change-Id: I2bee30fb17946be85e026213b481aeaeaee2459f
Signed-off-by: Liujie Xie <xieliujie@oppo.com>
Renamed trace_android_vh_record_percpu_rwsem_lock_starttime to
trace_android_vh_record_pcpu_rwsem_starttime.
Because the orignal name is too long, which results to the
compile-err of .ko that uses the symbol:
ERROR: modpost:
too long symbol "__tracepoint_android_vh_record_percpu_rwsem_lock_starttime"
There is not any users of the the orignal hooks so that it is safe to
rename it.
Bug: 241191475
Signed-off-by: Peifeng Li <lipeifeng@oppo.com>
Change-Id: Ie246a933414db5e9e28a65a4c280fae3a1cbefe3
This reverts commit 8c3ac02bca.
The hook android_vh_mutex_start_check_new_owner is not used by any
vendor, so remove it to help with merge issues with future LTS releases.
If this is needed by any real user, it can easily be reverted to add it
back and then the symbol should be added to the abi list at the same
time to prevent it from being removed again later.
Bug: 203756332
Bug: 231647361
Cc: Liujie Xie <xieliujie@oppo.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I8c3bf787525d684f64b8d0654d379df78eb7b69e
Providing vendor hooks to record the start time of holding the lock, which
protects rwsem/mutex locking-process from being preemptedfor a short time
in some cases.
- android_vh_record_mutex_lock_starttime
- android_vh_record_rtmutex_lock_starttime
- android_vh_record_rwsem_lock_starttime
- android_vh_record_percpu_rwsem_lock_starttime
Bug: 241191475
Signed-off-by: Peifeng Li <lipeifeng@oppo.com>
Change-Id: I0e967a1e8b77c32a1ad588acd54028fae2f90c4e
Due to the existence of optimistic spin, we need to
sense whether the owner of the lock has changed in the loop,
so as to do priority inheritance on the owner more accurately,
trace_android_vh_mutex_wait_start does not meet our needs.
Bug: 231647361
Change-Id: Iab2832fd3c352d8c1229348a5e7befced70ee92e
Signed-off-by: Liujie Xie <xieliujie@oppo.com>
Current might be preempt after spin_unlock(&lock->wait_lock),
we want to add a hook after wake_up_q(&wake_q) in which to
disable owner's privilege in scheduler.
Bug: 231647361
Change-Id: I3016da2fd31b8bdc8435df4e800f91381a64af4f
Signed-off-by: Liujie Xie <xieliujie@oppo.com>
We already applied the 'vendor hook' for Dtask Debugging Information
in below issue.
(https://issuetracker.google.com/issues/162776704)
There are vendor hook call in mutex and rw_semaphore, but not for rt_mutex
Please refer to description in details as below,
1. Description
This feature writes rt mutex lock waiting information
on the task_struct structure. We can check mutex information and
mutex owner through the kernel log and custom analysis tools.
Like the previous feature in mutex and rw semaphore,
added data can be checked by ramdump analysis.
2. Vendor Hook Position
1) VENDOR_DATA
- struct task_struct in sched.h
VENDOR_DATA_ARRAY(2)
[0] : type // RTmutex (Mutex, Rwsem, ...)
[1] : pointer // address of lock
2) VENDOR_HOOKs
- __rt_mutex_slowlock() in kernel/locking/rtmutex.c
3. Example
- SysRq-w in kernel log
...
[ 54.164463] [3: kworker/u16:3: 253] kworker/3:2 D12736 418 2 0x00000228
[ 54.164497] [3: kworker/u16:3: 253] RTmutex: 0xffffffc051fa3ae8: owner[sh :9003]
[ 54.167812] [3: kworker/u16:3: 253] sh D12848 9003 6900 0x04000200
[ 54.167824] [3: kworker/u16:3: 253] RTmutex: 0xffffffc051fa3b08: owner[kworker/3:2 :418]
...
Bug: 186567468
Signed-off-by: JINHO LIM <jordan.lim@samsung.com>
Change-Id: I93f9753be0b2c1fa1a6eaea09379d54c31d1ebcf
(cherry picked from commit e289faa9f12811d3546def3083bac0cc35c54ba8)
Remove macro versions of hooks that are no longer needed. The
macro versions are still needed when the _rcuidle version
of the hook is used (as in include/trace/hooks/debug.h).
Bug: 177416721
Signed-off-by: Todd Kjos <tkjos@google.com>
Change-Id: I4b50447e9a922ed038663d1459d7622dab30ffbb
- Add the hook to get mutex/rwsem information that the tasks
are waiting for.
- Add the hook to print messages for sched_show_task.
- ANDROID_VENDOR_DATA_ARRAY added to task_struct
Bug: 162776704
Signed-off-by: Sangmoon Kim <sangmoon.kim@samsung.com>
Change-Id: Ib436fbd8d0ad509c3b5a73ea8f5170e0761a13fd
(cherry picked from commit b519ac4237)
