Re: [Ksummit-discuss] [CORE TOPIC] Run-time kernel checking

[Li Zefan <lizefan@huawei.com>]

On 2014/5/10 18:04, Catalin Marinas wrote:
> There is already a topic proposed on static checking (sparse, coverity)
> but I would like to propose a complementary one: run-time checking.
> 
> Linux has several run-time checking tools to spot potential problems
> before actually causing a kernel crash: lockdep, spinlock debugging, RCU
> debugging, memory poisoning, kmemcheck, kmemleak etc. Some of these are
> simpler (e.g. poisoning), others are more complex and have significant
> run-time overhead.
> 
> What I would like to get out of such discussion:
> 
> 1. Which tools do people use on a regular basis? How useful are they?
> 2. Use-cases and feedback on how they can be improved (e.g. better
>    reporting, more information, lower overhead)
> 3. What else do we miss? Can we borrow ideas from other tools? How
>    feasible would it be (e.g. helgrind-like tool in the kernel)?
> 
> People for this topic: at least the maintainers of the existing run-time
> checkers (and I’m sure I missed many others):
> 
> Peter Zijlstra (lockdep)
> Ingo Molnar (lockdep)
> Paul E. McKenney (RCU)
> Dipankar Sarma (RCU)
> Vegard Nossum (kmemcheck)
> Pekka Enberg (kmemcheck)
> Catalin Marinas (kmemleak)
> 
> However, rather than a discussion between the above maintainers, the aim
> is to get feedback from users of these tools and ideas for new tools
> (hence the core topic tag).
> 

I'm interested in this topic.

I saw some modified run-time checking tools in Huawei. For example a simplified
lockdep feature, they said they did some benchmarks and decided they can bear
the overhead in product environment.

Another one is supporting re-enablement of kmemleak, which you already saw the
patch and expressed your NACK.

https://lkml.org/lkml/2014/1/17/102

We also wanted kmemcheck smp support, because in that product the system can't
work in UP.