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

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

[Catalin Marinas]

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).

Thanks,

Catalin

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

[Li Zefan]

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.

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

[Catalin Marinas]

On Mon, May 12, 2014 at 10:33:37AM +0100, Li Zefan wrote:
> 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

And I nack'ed it for good reasons ;). But since you haven't explained
your reasons, I haven't followed up with any alternative solutions (for
example, if overhead is what you are after, you could have specific
kmemleak options to still track objects but for example don't save a
stack trace for each allocation).

-- 
Catalin