 Hello, I'm Byung-cheol Park, working for LG Electronics. I'm going to talk about what locked up does and doesn't, and what we can improve. My interest is task scheduler and synchronization mechanism, including RCU and general locking mechanism. Locked up is a tool to check correctness of synchronization mechanism. Some checking is about lock usage correctness. Some checking is about RCU usage correctness. Some checking is about lock dependency correctness. Let's look at one by one. Lock and unlock must be used in pairs. This code tries to terminate the task without releasing A, which is problematic. So lock that, report it as a problem. This one is similar to the previous one. This code tries to return to user without releasing A, which is problematic as well. So lock that, report it as a problem. Your text lock shouldn't be acquired in a spinlock critical section. This code tries to acquire your text lock B with spinlock A held, which is problematic. So lock that would report it as a problem. Here, I will assume, or you guys are familiar with, lock usage. I will not explain lock usage in detail. Let me continue. Spinlock shouldn't be acquired in a raw spinlock critical section. Which is similar to the previous one. This code tries to acquire spinlock B with raw spinlock A held, which is problematic. So lock that, report it as a problem. Nest lock API should be called with the nest lock held. This code is correct lock usage. When you call spinlock nest API, you should specify nest lock. And we should have the nest lock already held. But if somebody who is confused at using proper API, use spinlock nest this way, without nest lock held, then this code would be problematic. So lock that, report it as a problem. Let's look at the next one. RCU usage correctness. RCU read forbidden context. For example, idle shouldn't have RCU read sections. So somebody who is confused at using RCU API, try to specify RCU read section like this in a RCU read forbidden context. This code would be problematic. So lock that, report it as a problem. RCU dereference protected is supposed to be used with updated lock held. RCU just dereference is supposed to be used in RCU read section. So depending on the context, we have to choose proper one. In this case, not RCU dereference underscore protected, just RCU dereference should be used. If somebody use RCU dereference this way, it would be problematic. So lock that would report it as a problem. RCU read APIs should be used in a section, delimited by RCU read lock, RCU read unlock. List for each entry RCU is one of RCU read APIs. So the API should be used within RCU read side section. But this code try to use the API out of read side section. So this code would be problematic. Lock that would report it as a problem. Let's look at the next one. Lock dependent correctness. All the lock acquisition order should be kept across the kernel code. In the left side of code, acquire the spinlock A and then try to acquire spinlock B while holding A. Right side of the code acquired spinlock B and then try to acquire spinlock A while holding B. The lock acquisition order between left side and right side is different, which is problematic, which lead to deadlock. So lock that would report it as a problem. The spinlock should be acquired twice in a single context. This code definitely problematic. So lock that would report it as a problem. IRQ save APIs should be used if the lock is used in either process context or interact context like this. This is correct lock usage. So if the spinlock A used either in interact context or process context like this, underscore IRQ API should be used like this. But if someone who is confused at using proper API use spinlock this way, then this code would lead this situation, which is going to be deadlock. So lock that report it as a problem. As we've seen so far, lock that is quite cool tool for checking these. What about this code? Do you think it's problematic? Yes, this code is problematic. Because it goes to deadlock. Because wait for event B cannot be working out. Because event B on the right side of the code cannot be triggered. Because mutex lock A on the right side of the code cannot be working out. Because mutex unlock A on the left side of the code cannot be triggered. Because wait for event B on the left side of the code cannot be working out. So this code lead deadlock. But because lock that is working on lock API, so lock that cannot see the code called red here. So lock that would work with the code here. So it would consider this code safe. So lock that will not report any problem. What makes the case missed? I need to explain how does lock that track dependence first. Lock that defines dependence this way. If someone acquire lock A and try to lock B while holding A, lock that says A depends on B. Let's look at this example code. Someone acquire the spin lock A and then try to acquire spin lock B while holding A. Then by the definition we can generate the dependence A to B and add two dependence graph like this. This code acquire the spin lock B and then try to acquire spin lock A while holding B. By the definition we can generate the dependence B to A and add two dependence graph like this. So using the graph we can detect the circular dependence and we can look for the problem. In practice the graph looks more complicated like this. If dependence Y to Q is generated and added to the graph, then we can detect the circular dependence. So we can report the problem. Is a deadlock caused by incorrect lock acquisition order? Partially yes, but more precisely a deadlock is caused by waiters that cannot be woken up. In other words, a deadlock is caused by events that are not reachable. The deadlock detection tool should focus on waits and event themselves. So instead of using the definition, I'd like to redefine the dependence this way. So when event A occurrence depends on event B occurrence, I'd say A depends on B. This diagram shows why the new definition makes sense more. Event A cannot be triggered unless wait B is woken up. In other words, event B is triggered. So event A occurrence depends on event B occurrence. Let's look at this example code. This code is the one we already looked at which locked up couldn't detect the problem. Even though there is a deadlock. By the new definition, move text unlock A occurrence depends on event B. So we can generate dependence A to B. This code by the definition, I mean by the new definition, event B depends on releasing A event. So by the new definition, we can generate dependence B to A like this. So with this graph, we can detect circular dependency and report it as a problem. Okay, let's look at all the examples that we already have been looking at. We have to see wait an event in each code. In this example, we have to see wait an event like this. In this example, we have to see wait an event like this. In this example, like this. Even in this example, we have to see wait an event like this. So, LockDep is a great tool for checking these tools. Lock usage correctness, RCU usage correctness. But, LockDep is not the best tool for this proposal. Lock dependence correctness. So, I decided to develop a new tool named Depth to replace the third part to deal with dependency in the best way. So, Depth is the best tool for this proposal. Depth detects situations where waiters cannot be woken up, or Depth detects situations where events are not reachable. Depth works with all types of wait. It supports multiple reports efficiently. It provides easy APIs to annotate wait and event. But, it just started, so still has first positives. You can check LKML discussion with the first link, and the source code with the second link. I'm looking for someone who are interested in improving this area of the kernel. Thank you!