DEPT(DEPendency Tracker) #416
Open
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
added 30 commits
December 8, 2025 14:19
CURRENT STATUS
--------------
Lockdep tracks lock acquisition order to identify deadlock conditions.
Additionally, it tracks IRQ state changes — via {en,dis}able — to detect
cases where locks are acquired unintentionally during interrupt handling.
PROBLEM
-------
Waits and their associated events that are never reachable can
eventually lead to deadlocks. However, since Lockdep focuses solely on
lock acquisition order, it has inherent limitations when handling waits
and events.
Moreover, by tracking only lock acquisition order, Lockdep cannot
properly handle read locks or cross-event scenarios — such as
wait_for_completion() and complete() — making it increasingly inadequate
as a general-purpose deadlock detection tool.
SOLUTION
--------
Once again, waits and their associated events that are never reachable
can eventually lead to deadlocks. The new solution, DEPT, focuses
directly on waits and events. DEPT monitors waits and events, and
reports them when any become unreachable.
DEPT provides:
* Correct handling of read locks.
* Support for general waits and events.
* Continuous operation, even after multiple reports.
* Simple, intuitive annotation APIs.
Q & A
-----
Q. Is this the first attempt to solve this problem?
A. No. The cross-release feature (commit b09be67) attempted to
address it — as a Lockdep extension. It was merged, but quickly
reverted, because:
While it uncovered valuable hidden issues, it also introduced false
positives. Since these false positives mask further real problems
with Lockdep — and developers strongly dislike them — the feature was
rolled back.
Q. Why wasn’t DEPT built as a Lockdep extension?
A. Lockdep is the result of years of work by kernel developers — and is
now very stable. But I chose to build DEPT separately, because:
While reusing BFS(Breadth First Search) and Lockdep’s hashing is
beneficial, the rest of the system must be rebuilt from scratch to
align with DEPT’s wait-event model — since Lockdep was originally
designed for tracking lock acquisition orders, not wait-event
dependencies.
Q. Do you plan to replace Lockdep entirely?
A. Not at all — Lockdep still plays a vital role in validating correct
lock usage. While its dependency-checking logic should eventually be
superseded by DEPT, the rest of its functionality should stay.
Q. Should we replace the dependency check immediately?
A. Absolutely not. Lockdep’s stability is the result of years of hard
work by kernel developers. Lockdep and DEPT should run side by side
until DEPT matures.
Q. Stronger detection often leads to more false positives — which was a
major pain point when cross-release was added. Is DEPT designed to
handle this?
A. Yes. DEPT’s simple, generalized design enables flexible reporting —
so while false positives still need fixing, they’re far less
disruptive than they were under the Lockdep extension, cross-release.
Q. Why not fix all false positives out-of-tree before merging?
A. Since the affected subsystems span the entire kernel, like Lockdep,
which has relied on annotations to avoid false positives over the
last two decades, dept too will require the annotation efforts.
Performing annotation work within the mainline will help us add
annotations more appropriately and will also make dept a useful tool
for a wider range of users more quickly.
CONFIG_DEPT is marked EXPERIMENTAL, so it’s opt-in. Some users are
already interested in using DEPT to analyze complex synchronization
patterns and extract dependency insights.
Signed-off-by: Byungchul Park <byungchul@sk.com>
Tested-by: Harry Yoo <harry.yoo@oracle.com>
Tested-by: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com>
Tested-by: Yunseong Kim <ysk@kzalloc.com>
Tested-by: Yeoreum Yun <yeoreum.yun@arm.com>
Wrapped the base APIs for easier annotation on wait and event. Start
with supporting waiters on each single event. More general support for
multiple events is a future work. Do more when the need arises.
How to annotate:
1. Initaialize a map for the interesting wait.
/*
* Place along with the wait instance.
*/
struct dept_map my_wait;
/*
* Place in the initialization code.
*/
sdt_map_init(&my_wait);
2. Place the following at the wait code.
sdt_wait(&my_wait);
3. Place the following at the event code.
sdt_event(&my_wait);
That's it!
Signed-off-by: Byungchul Park <byungchul@sk.com>
Wrap the base APIs for easier annotation on typical lock. Signed-off-by: Byungchul Park <byungchul@sk.com>
How to place dept this way looks so ugly. However, it's inevitable for now. The way should be enhanced gradually. Signed-off-by: Byungchul Park <byungchul@sk.com>
It'd be useful to show dept internal stats and dependency graph on runtime via proc for better information. Introduce the knobs. Signed-off-by: Byungchul Park <byungchul@sk.com>
Each unique kernel context, in dept's point of view, should be identified on every entrance to kernel mode e.g. system call or user oriented fault. Otherwise, dept may track meaningless dependencies across different kernel context. Signed-off-by: Byungchul Park <byungchul@sk.com>
Workqueue already provides concurrency control. By that, any wait in a work doesn't prevents events in other works with the control enabled. Thus, each work would better be considered a different context. So let dept assign a different context id to each work. Signed-off-by: Byungchul Park <byungchul@sk.com>
dept engine works in a constrained environment. For example, dept cannot make use of dynamic allocation e.g. kmalloc(). So dept has been using static pools to keep memory chunks dept uses. However, dept would barely work once any of the pools gets run out. So implemented a mechanism for the refill on the lack, using irq work and workqueue that fits on the contrained environment. Signed-off-by: Byungchul Park <byungchul@sk.com>
The current code records all the waits for later use to track relation between waits and events within each context. However, since the same class is handled the same way, it'd be okay to record only one on behalf of the others if they all have the same class. Even though it's the ideal to search the whole history buffer for that, since it'd cost too high, alternatively, let's keep the latest one when the same class'ed waits consecutively appear. Signed-off-by: Byungchul Park <byungchul@sk.com>
…mplete() Make dept able to track dependencies by wait_for_completion()/complete(). Signed-off-by: Byungchul Park <byungchul@sk.com>
Make dept able to track dependencies by swaits. Signed-off-by: Byungchul Park <byungchul@sk.com>
Make dept able to track dependencies by waitqueue waits. Signed-off-by: Byungchul Park <byungchul@sk.com>
Make dept able to track dependencies by hashed-waitqueue waits. Signed-off-by: Byungchul Park <byungchul@sk.com>
Make dept able to track dependencies by dma fence waits and signals. Signed-off-by: Byungchul Park <byungchul@sk.com>
Waits with valid timeouts don't actually cause deadlocks. However, dept has been reporting the cases as well because it's worth informing the circular dependency for some cases where, for example, timeout is used to avoid a deadlock. However, yes, there are also a lot of, even more, cases where timeout is used for its clear purpose and meant to be expired. Report these as an information rather than warning DEADLOCK. Plus, introduce CONFIG_DEPT_AGGRESSIVE_TIMEOUT_WAIT Kconfig to make it optional so that any reports involving waits with timeouts can be turned on/off depending on the purpose. Signed-off-by: Byungchul Park <byungchul@sk.com>
Now that CONFIG_DEPT_AGGRESSIVE_TIMEOUT_WAIT was introduced, apply the consideration to wait_for_completion()/complete(). Signed-off-by: Byungchul Park <byungchul@sk.com>
Now that CONFIG_DEPT_AGGRESSIVE_TIMEOUT_WAIT was introduced, apply the consideration to swait, assuming an input 'ret' in ___swait_event() macro is used as a timeout value. Signed-off-by: Byungchul Park <byungchul@sk.com>
Now that CONFIG_DEPT_AGGRESSIVE_TIMEOUT_WAIT was introduced, apply the consideration to waitqueue wait, assuming an input 'ret' in ___wait_event() macro is used as a timeout value. Signed-off-by: Byungchul Park <byungchul@sk.com>
Now that CONFIG_DEPT_AGGRESSIVE_TIMEOUT_WAIT was introduced, apply the consideration to hashed-waitqueue wait, assuming an input 'ret' in ___wait_var_event() macro is used as a timeout value. Signed-off-by: Byungchul Park <byungchul@sk.com>
Now that CONFIG_DEPT_AGGRESSIVE_TIMEOUT_WAIT was introduced, apply the consideration to dma fence wait. Signed-off-by: Byungchul Park <byungchul@sk.com>
There is a case where the total map size of waits of a class is so large. For instance, PG_locked is the case if every struct page embeds its regular map for PG_locked. The total size for the maps will be 'the # of pages * sizeof(struct dept_map)', which is too big to accept. Keep the minimum data in the case, timestamp called 'wgen', that dept uses. Make dept able to work with the wgen instead of whole regular map. Signed-off-by: Byungchul Park <byungchul@sk.com>
Makes dept able to track PG_locked waits and events, which will be useful in practice. See the following link that shows dept worked with PG_locked and detected real issues in practice: https://lore.kernel.org/lkml/1674268856-31807-1-git-send-email-byungchul.park@lge.com/ Signed-off-by: Byungchul Park <byungchul@sk.com>
Currently, print nothing about what event wakes up in report. However, it makes hard to interpret dept's report. Make it print wait's stacktrace that the event wakes up. Signed-off-by: Byungchul Park <byungchul@sk.com>
…)'ed
lockdep provides APIs for assertion only if lockdep is enabled at the
moment asserting to avoid unnecessary confusion, using the following
condition, debug_locks && !this_cpu_read(lockdep_recursion).
However, lockdep_{off,on}() are also used for disabling and enabling
lockdep for a simular purpose. Add !lockdep_recursing(current) that is
updated by lockdep_{off,on}() to the condition so that the assertions
are aware of !__lockdep_enabled if lockdep_off()'ed.
Signed-off-by: Byungchul Park <byungchul@sk.com>
Add documents describing the concept and APIs of dept. Signed-off-by: Byungchul Park <byungchul@sk.com>
cb92173 ("locking/lockdep, cpu/hotplug: Annotate AP thread") was introduced to make lockdep_assert_cpus_held() work in AP thread. However, the annotation is too strong for that purpose. We don't have to use more than try lock annotation for that. rwsem_acquire() implies: 1. might be a waiter on contention of the lock. 2. enter to the critical section of the lock. All we need in here is to act 2, not 1. So trylock version of annotation is sufficient for that purpose. Now that dept partially relies on lockdep annotaions, dept interpets rwsem_acquire() as a potential wait and might report a deadlock by the wait. Replace it with trylock version of annotation. Signed-off-by: Byungchul Park <byungchul@sk.com>
Resolved the following false positive by introducing explicit dept map
and annotations for dealing with this case:
*** DEADLOCK ***
context A
[S] (unknown)(<sched>:0)
[W] lock(&mm->mmap_lock:0)
[E] try_to_wake_up(<sched>:0)
context B
[S] lock(&mm->mmap_lock:0)
[W] mmu_interval_read_begin(<sched>:0)
[E] unlock(&mm->mmap_lock:0)
[S]: start of the event context
[W]: the wait blocked
[E]: the event not reachable
dept already tracks dependencies between scheduler sleep and ttwu based
on internal timestamp called wgen. However, in case that more than one
event contexts are overwrapped, dept has chance to wrongly guess the
start of the event context like the following:
<before this patch>
context A: lock L
context A: mmu_notifier_invalidate_range_start()
context B: lock L'
context B: mmu_interval_read_begin() : wait
<- here is the start of the event context of C.
context B: unlock L'
context C: lock L''
context C: mmu_notifier_invalidate_range_start()
context A: mmu_notifier_invalidate_range_end()
context A: unlock L
context C: mmu_notifier_invalidate_range_end() : ttwu
<- here is the end of the event context of C. dept observes a wait,
lock L'' within the event context of C. Which causes a false
positive dept report.
context C: unlock L''
By explicitly annotating the interesting event context range, make dept
work with more precise information like:
<after this patch>
context A: lock L
context A: mmu_notifier_invalidate_range_start()
context B: lock L'
context B: mmu_interval_read_begin() : wait
context B: unlock L'
context C: lock L''
context C: mmu_notifier_invalidate_range_start()
<- here is the start of the event context of C.
context A: mmu_notifier_invalidate_range_end()
context A: unlock L
context C: mmu_notifier_invalidate_range_end() : ttwu
<- here is the end of the event context of C. dept doesn't observe
the wait, lock L'' within the event context of C. context C is
responsible only for the range delimited by
mmu_notifier_invalidate_range_{start,end}().
context C: unlock L''
Signed-off-by: Byungchul Park <byungchul@sk.com>
dma fence can be used at various points in the code and it's very hard to distinguish dma fences between different usages. Using a single dept_key for all the dma fences could trigger false positive reports. Assign unique dept_key to each distinct dma fence wait to avoid false positive reports. Signed-off-by: Byungchul Park <byungchul@sk.com>
commit eb1cfd0 ("lockdep: Add lock_set_cmp_fn() annotation") has been added to address the issue that lockdep was not able to detect a true deadlock like the following: https://lore.kernel.org/lkml/20220510232633.GA18445@X58A-UD3R/ The approach is only for lockdep but dept should work being aware of it because the new annotation is already used to avoid false positive of lockdep in the code. Make dept aware of the new lockdep annotation. Signed-off-by: Byungchul Park <byungchul@sk.com>
For many reasons, debug_locks_off() is called to stop lock debuging feature e.g. on panic(). dept should also stop it in the conditions. Signed-off-by: Byungchul Park <byungchul@sk.com>
…aller wait_for_completion() can be used at various points in the code and it's very hard to distinguish wait_for_completion()s between different usages. Using a single dept_key for all the wait_for_completion()s could trigger false positive reports. Assign unique dept_key to each distinct wait_for_completion() caller to avoid false positive reports. While at it, add a rust helper for wait_for_completion() to avoid build errors. Signed-off-by: Byungchul Park <byungchul@sk.com>
Currently, dept uses dept's map embedded in task_struct to track dependencies related to wait_for_completion() and its family. So it doesn't need an explicit map basically. However, for those who want to set the maps with customized class or key, introduce a new API to use external maps. Signed-off-by: Byungchul Park <byungchul@sk.com>
… sites It's worth reporting wait-event circular dependency even if it doesn't lead to an actual deadlock, because it's a good information about a circular dependency anyway. However, it should be suppressed once turning out it doesn't lead an actual deadlock, for instance, there are other wake-up(or event) paths. The report needs to be suppressed by annotating that an event can be recovered by other sites triggering the desired wake-up, using a newly introduced API, dept_recover_event() specifying an event site and its recover site. By the introduction, need of a new type of dependency tracking arises since a loop of recover dependency could trigger another type of deadlock. So implement a logic to track the new type of dependency between multi event sites for a single wait. Lastly, to make sure that recover sites must be used in code, introduce a section '.dept.event_sites' to mark it as 'used' only if used in code, and warn it if dept_recover_event()s are annotated with recover sites, not used in code. Signed-off-by: Byungchul Park <byungchul@sk.com>
…te_dep struct dept_event_site and struct dept_event_site_dep have been introduced to track dependencies between multi event sites for a single wait, that will be loaded to data segment. Plus, a custom section, '.dept.event_sites', also has been introduced to keep pointers to the objects to make sure all the event sites defined exist in code. dept should work with the section and segment of module. Add the support to handle the section and segment properly whenever modules are loaded and unloaded. Signed-off-by: Byungchul Park <byungchul@sk.com>
…rable With multi event sites for a single wait, dept allows to skip tracking an event that is recoverable by other recover paths. Introduce an API, event_site(), to skip tracking the event in the case. Signed-off-by: Byungchul Park <byungchul@sk.com>
Implement CONFIG_DEPT_UNIT_TEST introducing a kernel module that runs basic unit test for dept. Signed-off-by: Byungchul Park <byungchul@sk.com>
For dept to function properly, dept_task()->hardirqs_enabled must be set correctly. If it fails to set this value to false, for example, dept may mistakenly think irq is still enabled even when it's not. Do dept_hardirqs_off() regardless of irq state not to miss any unexpected cases by any chance e.g. changes of the state by asm code. Signed-off-by: Byungchul Park <byungchul@sk.com>
The current implementation shares the same dept key for multiple
synchronization points, which can lead to false positive reports in
dependency tracking and potential confusion in debugging. For example,
both normal RCU and tasks trace RCU synchronization points use the same
dept key. Specifically:
1. synchronize_rcu() uses a dept key embedded in __wait_rcu_gp():
synchronize_rcu()
synchronize_rcu_normal()
_wait_rcu_gp()
__wait_rcu_gp() <- the key as static variable
2. synchronize_rcu_tasks_trace() uses the dept key, too:
synchronize_rcu_tasks_trace()
synchronize_rcu_tasks_generic()
_wait_rcu_gp()
__wait_rcu_gp() <- the key as static variable
Since the both rely on the same dept key, dept may report false positive
circular dependency. To resolve this, separate dept keys and maps
should be assigned to each struct rcu_synchronize.
===================================================
DEPT: Circular dependency has been detected.
6.15.0-rc6-00042-ged94bafc6405 #2 Not tainted
---------------------------------------------------
summary
---------------------------------------------------
*** DEADLOCK ***
context A
[S] lock(cpu_hotplug_lock:0)
[W] __wait_rcu_gp(<sched>:0)
[E] unlock(cpu_hotplug_lock:0)
context B
[S] (unknown)(<sched>:0)
[W] lock(cpu_hotplug_lock:0)
[E] try_to_wake_up(<sched>:0)
[S]: start of the event context
[W]: the wait blocked
[E]: the event not reachable
---------------------------------------------------
context A's detail
---------------------------------------------------
context A
[S] lock(cpu_hotplug_lock:0)
[W] __wait_rcu_gp(<sched>:0)
[E] unlock(cpu_hotplug_lock:0)
[S] lock(cpu_hotplug_lock:0):
[<ffff8000802ce964>] cpus_read_lock+0x14/0x20
stacktrace:
percpu_down_read.constprop.0+0x88/0x2ec
cpus_read_lock+0x14/0x20
cgroup_procs_write_start+0x164/0x634
__cgroup_procs_write+0xdc/0x4d0
cgroup_procs_write+0x34/0x74
cgroup_file_write+0x25c/0x670
kernfs_fop_write_iter+0x2ec/0x498
vfs_write+0x574/0xc30
ksys_write+0x124/0x244
__arm64_sys_write+0x70/0xa4
invoke_syscall+0x88/0x2e0
el0_svc_common.constprop.0+0xe8/0x2e0
do_el0_svc+0x44/0x60
el0_svc+0x50/0x188
el0t_64_sync_handler+0x10c/0x140
el0t_64_sync+0x198/0x19c
[W] __wait_rcu_gp(<sched>:0):
[<ffff8000804ce88c>] __wait_rcu_gp+0x324/0x498
stacktrace:
schedule+0xcc/0x348
schedule_timeout+0x1a4/0x268
__wait_for_common+0x1c4/0x3f0
__wait_for_completion_state+0x20/0x38
__wait_rcu_gp+0x35c/0x498
synchronize_rcu_normal+0x200/0x218
synchronize_rcu+0x234/0x2a0
rcu_sync_enter+0x11c/0x300
percpu_down_write+0xb4/0x3e0
cgroup_procs_write_start+0x174/0x634
__cgroup_procs_write+0xdc/0x4d0
cgroup_procs_write+0x34/0x74
cgroup_file_write+0x25c/0x670
kernfs_fop_write_iter+0x2ec/0x498
vfs_write+0x574/0xc30
ksys_write+0x124/0x244
[E] unlock(cpu_hotplug_lock:0):
(N/A)
---------------------------------------------------
context B's detail
---------------------------------------------------
context B
[S] (unknown)(<sched>:0)
[W] lock(cpu_hotplug_lock:0)
[E] try_to_wake_up(<sched>:0)
[S] (unknown)(<sched>:0):
(N/A)
[W] lock(cpu_hotplug_lock:0):
[<ffff8000802ce964>] cpus_read_lock+0x14/0x20
stacktrace:
percpu_down_read.constprop.0+0x6c/0x2ec
cpus_read_lock+0x14/0x20
check_all_holdout_tasks_trace+0x90/0xa30
rcu_tasks_wait_gp+0x47c/0x938
rcu_tasks_one_gp+0x75c/0xef8
rcu_tasks_kthread+0x180/0x1dc
kthread+0x3ac/0x74c
ret_from_fork+0x10/0x20
[E] try_to_wake_up(<sched>:0):
[<ffff8000804233b8>] complete+0xb8/0x1e8
stacktrace:
try_to_wake_up+0x374/0x1164
complete+0xb8/0x1e8
wakeme_after_rcu+0x14/0x20
rcu_tasks_invoke_cbs+0x218/0xaa8
rcu_tasks_one_gp+0x834/0xef8
rcu_tasks_kthread+0x180/0x1dc
kthread+0x3ac/0x74c
ret_from_fork+0x10/0x20
(wait to wake up)
stacktrace:
__schedule+0xf64/0x3614
schedule+0xcc/0x348
schedule_timeout+0x1a4/0x268
__wait_for_common+0x1c4/0x3f0
__wait_for_completion_state+0x20/0x38
__wait_rcu_gp+0x35c/0x498
synchronize_rcu_tasks_generic+0x14c/0x220
synchronize_rcu_tasks_trace+0x24/0x8c
rcu_init_tasks_generic+0x168/0x194
do_one_initcall+0x174/0xa00
kernel_init_freeable+0x744/0x7dc
kernel_init+0x78/0x220
ret_from_fork+0x10/0x20
Separating the dept key and map for each of struct rcu_synchronize,
ensuring proper tracking for each execution context.
Signed-off-by: Yunseong Kim <ysk@kzalloc.com>
[ Rewrote the changelog. ]
Signed-off-by: Byungchul Park <byungchul@sk.com>
… usage False positive reports have been observed since dept assumes that all the pages have the same dept class, but the class should be split since the call paths are different depending on what the page is used for. At least, ones for block device and ones for regular file have exclusively different usages. Define usage candidates like: DEPT_PAGE_REGFILE_CACHE /* page in regular file's address_space */ DEPT_PAGE_BDEV_CACHE /* page in block device's address_space */ DEPT_PAGE_DEFAULT /* the others */ Introduce APIs to set each page usage properly and make sure not to interact between DEPT_PAGE_REGFILE_CACHE and DEPT_PAGE_BDEV_CACHE. Besides that, it allows the other cases: interaction between DEPT_PAGE_DEFAULT and DEPT_PAGE_REGFILE_CACHE, interaction between DEPT_PAGE_DEFAULT and DEPT_PAGE_BDEV_CACHE, interaction between DEPT_PAGE_DEFAULT and DEPT_PAGE_DEFAULT. Signed-off-by: Byungchul Park <byungchul@sk.com>
Makes dept able to track PG_writeback waits and events, which will be useful in practice. Signed-off-by: Byungchul Park <byungchul@sk.com>
While compiling Linux kernel with DEPT on, the following error was
observed:
./include/linux/rcupdate.h:1084:17: note: in expansion of macro
‘BUILD_BUG_ON’
1084 | BUILD_BUG_ON(offsetof(typeof(*(ptr)), rhf) >= 4096); \
| ^~~~~~~~~~~~
./include/linux/rcupdate.h:1047:29: note: in expansion of macro
'kvfree_rcu_arg_2'
1047 | #define kfree_rcu(ptr, rhf) kvfree_rcu_arg_2(ptr, rhf)
| ^~~~~~~~~~~~~~~~
net/sunrpc/xprt.c:1856:9: note: in expansion of macro 'kfree_rcu'
1856 | kfree_rcu(xprt, rcu);
| ^~~~~~~~~
CC net/kcm/kcmproc.o
make[4]: *** [scripts/Makefile.build:203: net/sunrpc/xprt.o] Error 1
Since kfree_rcu() assumes 'offset of struct rcu_head in a rcu-managed
struct < 4096', the offest of struct rcu_head in struct rpc_xprt should
not exceed 4096 but does, due to the debug information added by DEPT.
Relocate struct rcu_head to the first field of struct rpc_xprt from an
arbitrary location to avoid the issue and meet the assumption.
Reported-by: Yunseong Kim <ysk@kzalloc.com>
Signed-off-by: Byungchul Park <byungchul@sk.com>
Reviewed-by: Jeff Layton <jlayton@kernel.org>
…_SIZE Yunseong reported a build failure due to the BUILD_BUG_ON() statement in alloc_kmem_cache_cpus(). In the following test: PERCPU_DYNAMIC_EARLY_SIZE < NR_KMALLOC_TYPES * KMALLOC_SHIFT_HIGH * sizeof(struct kmem_cache_cpu) The following factors increase the right side of the equation: 1. PAGE_SIZE > 4KiB increases KMALLOC_SHIFT_HIGH. 2. DEPT increases the size of the local_lock_t in kmem_cache_cpu. Increase PERCPU_DYNAMIC_SIZE_SHIFT to 11 on configs with PAGE_SIZE larger than 4KiB and DEPT enabled. Reported-by: Yunseong Kim <ysk@kzalloc.com> Signed-off-by: Byungchul Park <byungchul@sk.com>
Author
|
Upstream branch: 2690a55 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Pull request for series with
subject: DEPT(DEPendency Tracker)
version: 18
url: https://patchwork.kernel.org/project/linux-block/list/?series=1030724