On Wed 2019-12-04 09:41:15, Alexander Potapenko wrote: > On Tue, Dec 3, 2019 at 7:38 PM Steven Rostedt <rostedt@xxxxxxxxxxx> wrote: > > > > On Tue, 3 Dec 2019 16:14:17 +0100 > > Alexander Potapenko <glider@xxxxxxxxxx> wrote: > > > > > On Tue, Dec 3, 2019 at 4:00 PM Qian Cai <cai@xxxxxx> wrote: > > > > > > > > > > > > > > > > > On Dec 3, 2019, at 9:35 AM, Alexander Potapenko <glider@xxxxxxxxxx> wrote: > > > > > > > > > > At this point I don't really know why KMSAN and lockdep don't play > > > > > well together, but I'm not expecting anyone to use them together > > > > > either. > > > > > > > > Of course people will use those together. For example, distro debug kernel variants. > > > Some tools are just not designed to work together. > > > For example, you won't be able to compile the kernel with both KASAN > > > and KMSAN enabled at the same time. > > > > > > Lockdep doesn't require any instrumentation to work, so it _might_ be > > > possible to make it work with KMSAN, but it will probably still slow > > > down the things to an unacceptable level. > > > I'm inclining towards disabling the two together for now, unless > > > anyone is willing to address that issue. > > > > Note, I'm much more interested in someone running with lockdep than > > with KMSAN. Thus, you may not get as much use if you do not work with > > lockdep. I enable lockdep first when testing out my code. If KMSAN is > > not compatible, it wont get enabled. > > > > > > > > Please let me know if you think I need to keep the link to > > > https://github.com/google/kmsan/issues/57 in the Kconfig comment, > > > right now it looks like: > > > > > > # KMSAN is currently incompatible with lockdep. > > > > > > > Function tracing had lots of issues with lockdep, but I worked hard to > > make sure they could be compatible. This usually required having the > > lockdep code not be traced. Is it possible to have the same with KMSAN. > > That is, have KMSAN not look at anything that lockdep does? > > > > -- Steve > Qian, Steve, thanks for the data points. > I thought it might be more valuable to cut some edges to make KMSAN > available to early users, Makes sense to me. > but in the case most developers use a single > build for testing it indeed makes more sense to fix lockdep > interoperability. > I'll look into that. IMHO, a generic distro debug kernel could not enable debugging options that would significantly slow down the kernel. Most users would refuse using such kernels. Also they might slow down the system to the point that many problems won't be visible. For example, I do not see KASAN enabled in SUSE debug kernel. I guess that it will be the same with KMSAN. These options can be enabled in custom kernels when debugging particular problems. Best Regards, Petr
