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
