On Thu, Apr 11, 2019 at 10:37:51AM -0700, Dhaval Giani wrote: > Hi Folks, > > This is a call for participation for the Linux Testing microconference > at LPC this year. > > For those who were at LPC last year, as the closing panel mentioned, > testing is probably the next big push needed to improve quality. From > getting more selftests in, to regression testing to ensure we don't > break realtime as more of PREEMPT_RT comes in, to more stable distros, > we need more testing around the kernel. > > We have talked about different efforts around testing, such as fuzzing > (using syzkaller and trinity), automating fuzzing with syzbot, 0day > testing, test frameworks such as ktests, smatch to find bugs in the > past. We want to push this discussion further this year and are > interested in hearing from you what you want to talk about, and where > kernel testing needs to go next.
I'd be interested to discuss what we could do with annotations and compiler instrumentation to make the kernel more amenable to static and dynamic analysis (and to some extent, documenting implicit requirements). One idea that I'd like to explore in the context of RT is to annotate function signatures with their required IRQ/preempt context, such that we could dynamically check whether those requirements were violated (even if it didn't happen to cause a problem at that point in time), and static analysis would be able to find some obviously broken usage. I had some rough ideas of how to do the dynamic part atop/within ftrace. Maybe there are similar problems elsewhere. I know that some clang folk were interested in similar stuff. IIRC Nick Desaulniers was interested in whether clang's thread safety analysis tooling could be applied to the kernel (e.g. based on lockdep annotations). Thanks, Mark.
