[ Upstream commit bccdd808902f8c677317cec47c306e42b93b849e ]
In some cases running with the test-ww_mutex code, I was seeing
odd behavior where sometimes it seemed flush_workqueue was
returning before all the work threads were finished.
Often this would cause strange crashes as the mutexes would be
freed while they were being used.
Looking at the code, there is a lifetime problem as the
controlling thread that spawns the work allocates the
"struct stress" structures that are passed to the workqueue
threads. Then when the workqueue threads are finished,
they free the stress struct that was passed to them.
Unfortunately the workqueue work_struct node is in the stress
struct. Which means the work_struct is freed before the work
thread returns and while flush_workqueue is waiting.
It seems like a better idea to have the controlling thread
both allocate and free the stress structures, so that we can
be sure we don't corrupt the workqueue by freeing the structure
prematurely.
So this patch reworks the test to do so, and with this change
I no longer see the early flush_workqueue returns.
Signed-off-by: John Stultz <jstultz@google.com>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Link: https://lore.kernel.org/r/20230922043616.19282-3-jstultz@google.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
Nothing uses the argument. Remove it as preparation to use
pi_state_update_owner().
MTK-Commit-Id: 2ed5be187ffd3df7c09d2602d503d4d1d207fb1a
Change-Id: Ib6567d9da83a23f2381f5c3bdfeb4177fc991031
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: ot_dick.yang <ot_dick.yang@mediatek.com>
Signed-off-by: Cheng Jui Wang <cheng-jui.wang@mediatek.com>
CR-Id: ALPS05894440
Feature: Google Security Patch
(cherry picked from commit 4f4f5be764ba502072b2c4e1de8bba3e08d31a0f)
handle kmalloc() failure in test function
MTK-Commit-Id: 2af3c0176582e3275c46b6c51cc08fcc354ac959
Change-Id: I06021af3c8516250445b50a4781be9aea7debf9e
CR-Id: ALPS05573895
Feature: [Module]Lockdep
Signed-off-by: Cheng Jui Wang <cheng-jui.wang@mediatek.com>
(cherry picked from commit 29f98f9739d775d3176f6e9175eca2e68f2ce54d)
Disable "held locks too much" AEE dump.
This type of AEE dump is not common and may not be a real problem.
MTK-Commit-Id: 4587e78d4410fd1889bfc2ac87a10c3c50ac73ca
Change-Id: I5a1d95a7c676fbddfe8e5d1efeff40aa0bf1a351
Signed-off-by: Cheng Jui Wang <cheng-jui.wang@mediatek.com>
CR-Id: ALPS05361714
Feature: [Module]Lockdep
Its a bad idea to do anything while the IRQ events are not match
with the CPU IRQ status. Lets fix it.
MTK-Commit-Id: b2a5405af7ff0e3e364854ded34b96608365182d
Change-Id: Ib56becc7abe66dad4de4d071964182b7caa9489d
Signed-off-by: Cheng Jui Wang <cheng-jui.wang@mediatek.com>
CR-Id: ALPS05224425
Feature: [Module]Lockdep
Improve lock monitor to differentiate between lock owner
and others automatically and enhance test cases for this
modification.
MTK-Commit-Id: ecce08578297309430203934b995c73d50f5a796
Change-Id: I5de23c5f5a0c204ebdb0cd06886c44783b477da1
CR-Id: ALPS05139516
Feature: [Module]Lockdep
Signed-off-by: Kobe Wu <kobe-cp.wu@mediatek.com>
The new method to dump task stack is not stable.
So we revert the function to the old method.
MTK-Commit-Id: 549d7b6565122f069474a20b28f988267de31d56
Change-Id: I74d615e69d0ef0c64ace3d294faa71d869edd6d3
CR-Id: ALPS05100325
Feature: [Module]Lockdep
Signed-off-by: Kobe Wu <kobe-cp.wu@mediatek.com>
The trace_hardirqs_off_time() and trace_hardirqs_on_time()
called before trace_hardirqs_off_caller and
trace_hardirqs_on_caller will generate warning when testing
current->hardirqs_enabled flag in arm architecture
Move xxx_time() to the next line of xxx_caller()
MTK-Commit-Id: 71051fa7b93e414e1f1181690bb425e8a48b283a
Change-Id: I156096a95d3b6f9a19660c779bc44c55708e1b74
CR-Id: ALPS05095852
Feature: [Module]Lockdep
Signed-off-by: Cheng Jui Wang <cheng-jui.wang@mediatek.com>
Spinlock debugging is bundled to CONFIG_DEBUG_SPINLOCK.
Lock monitor is bundled to CONFIG_LOCKDEP.
CONFIG_DEBUG_LOCK_ALLOC is the basic option to enable
CONFIG_LOCKDEP (Lock monitor). The other choices are
CONFIG_LOCK_STAT and CONFIG_PROVE_LOCKING.
MTK-Commit-Id: 58b4cd9af33bdfd797320eb147d8bb7b726667ee
Change-Id: Ie50a28a379b4174e75c018a7d0481255c7d30231
Signed-off-by: Kobe Wu <kobe-cp.wu@mediatek.com>
CR-Id: ALPS04994668
Feature: [Module]Lockdep
1. set a limitation to prevent from log too much
2. add aee dump on held lock too much
3. ignore performance warning on KASAN/UBSAN load
4. increase size of lockdep chain buffer
5. refine function to dump task stack
6. refine mt_aee_dump_held_locks
MTK-Commit-Id: 5d2ddb79008c3919483973c2e5459e1405f70a30
Change-Id: I8c5d6c467873cdb9be896089cd2d8100b16f11c1
CR-Id: ALPS04994668
Feature: [Module]Lockdep
Signed-off-by: Kobe Wu <kobe-cp.wu@mediatek.com>
Promote normal task to turbo task while turbo-task blocked.
1) Speedup binder call via infecting turbo ability to binder thread
2) Speedup sempahores owner if turbo waiting for
3) Turbo task can preempt others in futex/sempahore waiting queue
Related trace event:
a. echo 1 > /d/tracing/events/task_turbo/turbo_set/enable
- Tracking task set turbo
b. echo 1 > /d/tracing/events/task_turbo/turbo_inherit_start/enable
echo 1 > /d/tracing/events/task_turbo/ turbo_inherit_end/enable
- Tracking task start or end inherit turbo
MTK-Commit-Id: 73406f24e745b0a4c26b5d8c06e9ef6616ada80d
Change-Id: Idb3da6b5f201fa5ee60443d00ac49d7afa93a2c6
Signed-off-by: JianMin Liu <jian-min.liu@mediatek.com>
CR-Id: ALPS04791510
Feature: System Performance
refactor schedule monitor functions into four domains
- irq processing time tracer (CONFIG_MTK_SCHED_MONITOR)
- irq count status tracer (CONFIG_MTK_IRQ_COUNT_TRACER)
- irq off tracer (CONFIG_MTK_IRQ_OFF_TRACER)
- preempt off tracer (CONFIG_MTK_PREEMPT_TRACER)
The major changes
- support debug in user load
- support preempt off detection
- support default setting in device tree
- refactor /proc/mtmon architecture
- refactor debug information for aee dump
- move mtk_sched_mon.h to drivers/misc/mediatek/include/mt-plat
MTK-Commit-Id: 16ecf23a9a75a442c612422b5e7648fd5fa04394
Change-Id: Id506d0c76efc99c78ef854c3b54d83650c060a22
CR-Id: ALPS04993096
Feature: [Module]Schedule Monitor
Signed-off-by: Kobe Wu <kobe-cp.wu@mediatek.com>
sdi = per_cpu_ptr(&sp_dbg, owner_cpu);
sdi->detector_cpu = -1;
If the lock is already released, owner_cpu would be -1 and
result in kernel exception when access sdi pointer.
MTK-Commit-Id: 58a071c37566f21de74559ec28a94b6e32c011ca
Change-Id: Ic126afcbbfa267ecaffb61b7a5a93717336cd03e
CR-Id: ALPS04810076
Feature: [Module]Lockdep
Signed-off-by: Kobe Wu <kobe-cp.wu@mediatek.com>
Lockdep should not use printk when port_lock_key is held by
current task. Otherwise it will result in deadlock. Lockdep
will print warning message to trace event when port_lock_key
is already held by current task.
MTK-Commit-Id: af6dd0b10758cb9b0cb30992bd7fb7ba78b79306
Change-Id: I5df76b92df0aa525019deb2fd07eb1eda634f236
CR-Id: ALPS04715249
Feature: [Module]Lockdep
Signed-off-by: Kobe Wu <kobe-cp.wu@mediatek.com>
Because the old spinlock debugger might result in rq->lock
lockup in schedule flow. (only occurred on mt6771 Android Q)
We introduce the spinlock debugger v2 to avoid this problem.
The new version wouldnt show warnings when a task is spinning
for a spinlock. It only shows the holding time, spinning time,
and stack trace when a lock is released by the owner and above
the threshold. It wouldnt show magic number and raw_lock value.
MTK-Commit-Id: 1ef4259a053b21af07a6d33d66d629994d90c79e
Change-Id: Ib89b0b9456daa3188c8b8f05a5697849ef5db3ce
CR-Id: ALPS04677019
Feature: [Module]Lockdep
Signed-off-by: Kobe Wu <kobe-cp.wu@mediatek.com>
This is a temporary patch to disable spinlock debugger
warning on spin time. The root cause of spin time warning
on rq->lock is still under tracking.
MTK-Commit-Id: 1fa36bd2112a6ee68ebf1d0e95054a0d5c42857d
Change-Id: I375b27c2c46883eb0760c5dff532f9c6d8b7e87c
CR-Id: ALPS04670617
Feature: [Module]Lockdep
Signed-off-by: Kobe Wu <kobe-cp.wu@mediatek.com>
Reduce warning messages of spinlock debugger and lock monitor.
Only trigger aee dump once while more than one task are spinning
for the same spinlock. Remove backtrace of spinning tasks.
MTK-Commit-Id: 732bcd60d3237229bbc614c53f511284dfbe83ac
Change-Id: I25769faede5f49203e5232dd441e1123904dfa3f
CR-Id: ALPS04659845
Feature: [Module]Lockdep
Signed-off-by: Kobe Wu <kobe-cp.wu@mediatek.com>
Because a spinlock could be held by a task and other tasks are
waiting for it. If each task waiting for the spinlock triggers
an aee dump. It will make system very busy and many similar
warning messages will be shown in kernel log. This patch make
sure that aee dump will be triggered once under some conditions.
MTK-Commit-Id: 5d2505a40d384124ffd53f20b4ff3e3da5e62a27
Change-Id: I0bc3cb6416767758292c6ce63138fed15f89ab69
CR-Id: ALPS04657041
Feature: [Module]Lockdep
Signed-off-by: Kobe Wu <kobe-cp.wu@mediatek.com>
Because locks are acquired and released anytime. If we reserve
lock->owner information without using atomic operation. The
information could be invalid at that moment and results in
kernel exception when reading the information.
We will check the lock->owner information after reserving it
to a local variable. To see the information is valid or not.
MTK-Commit-Id: a314923a1dd34a4da86c1bfc4b9f03065929dbf2
Change-Id: I7150ab58bce45d68505e286e5179a04dc0c26638
CR-Id: ALPS04503017
Feature: [Module]Lockdep
Signed-off-by: Kobe Wu <kobe-cp.wu@mediatek.com>
Before we trigger aee dump in the call flow of spinning task.
Now we trigger aee dump in the call flow of lock owner.
This is helpful to find correct owner directly.
MTK-Commit-Id: ab41c7d331a3f19fd99ec4f4a81721b15f98e682
Change-Id: I8190ffc7e434774409bb3ca0597a367452b396f3
CR-Id: ALPS04644130
Feature: [Module]Lockdep
Signed-off-by: Kobe Wu <kobe-cp.wu@mediatek.com>
Trigger aee dump on lockdep warnings, then we can be aware of them.
MTK-Commit-Id: 0db5f4acc192b82a7cd15cb15ddf0c9483ab2bea
Change-Id: I3a58b83a61cee9e53874b3a48eeb340721a29d9e
CR-Id: ALPS04532107
Feature: [Module]Lockdep
Signed-off-by: Kobe Wu <kobe-cp.wu@mediatek.com>
Lockdep will trigger aee dump when a warning happened. aee dump
works based on workqueue and works_lock is needed by workqueue.
So it should not trigger aee dump when works_lock is already
held by the current task. Otherwise it will result in deadlock.
Add works_lock to checklist and check the list before trigger
aee dump.
MTK-Commit-Id: f948d020881f268a18354c1676c80d5647fbfee3
Change-Id: I0ccf127ca1a8bb928495df563459eddee97daf5e
CR-Id: ALPS04425783
Feature: [Module]Lockdep
Signed-off-by: Kobe Wu <kobe-cp.wu@mediatek.com>
When a possible circular locking dependency detected, lockdep
have to invoke kernel API dump to keep warning message. But kernel
API dump works based on workqueue and pool->lock is needed by
workqueue. If pool->lock is already held by current task, invoking
kernel API dump will result in deadlock on pool->lock.
The solution is to check if pool->lock is held by current task and
dont invoke kernel API dump to avoid deadlock.
MTK-Commit-Id: d6645694f271119aa2019b0407109850ec22ced6
Change-Id: I680dceed71e0e8d0677c2c42fea3c7657e5d72a7
CR-Id: ALPS04379940
Feature: [Module]Lockdep
Signed-off-by: Kobe Wu <kobe-cp.wu@mediatek.com>
(cherry picked from commit 1fd08092895a71a2972f92bdd7ae78c7738a4a54)
