On Thu, 14 Nov 2019 at 23:16, Paul E. McKenney [off-list ref] wrote:

On Thu, Nov 14, 2019 at 10:33:03PM +0100, Marco Elver wrote:

quoted

On Thu, 14 Nov 2019, Paul E. McKenney wrote:

quoted

On Thu, Nov 14, 2019 at 07:02:53PM +0100, Marco Elver wrote:

quoted

This is the patch-series for the Kernel Concurrency Sanitizer (KCSAN).
KCSAN is a sampling watchpoint-based *data race detector*. More details
are included in **Documentation/dev-tools/kcsan.rst**. This patch-series
only enables KCSAN for x86, but we expect adding support for other
architectures is relatively straightforward (we are aware of
experimental ARM64 and POWER support).

To gather early feedback, we announced KCSAN back in September, and have
integrated the feedback where possible:
http://lkml.kernel.org/r/CANpmjNPJ_bHjfLZCAPV23AXFfiPiyXXqqu72n6TgWzb2Gnu1eA@mail.gmail.com

The current list of known upstream fixes for data races found by KCSAN
can be found here:
https://github.com/google/ktsan/wiki/KCSAN#upstream-fixes-of-data-races-found-by-kcsan

We want to point out and acknowledge the work surrounding the LKMM,
including several articles that motivate why data races are dangerous
[1, 2], justifying a data race detector such as KCSAN.

[1] https://lwn.net/Articles/793253/
[2] https://lwn.net/Articles/799218/

I queued this and ran a quick rcutorture on it, which completed
successfully with quite a few reports.

Great. Many thanks for queuing this in -rcu. And regarding merge window
you mentioned, we're fine with your assumption to targeting the next
(v5.6) merge window.

I've just had a look at linux-next to check what a future rebase
requires:

- There is a change in lib/Kconfig.debug and moving KCSAN to the
  "Generic Kernel Debugging Instruments" section seems appropriate.
- bitops-instrumented.h was removed and split into 3 files, and needs
  re-inserting the instrumentation into the right places.

Otherwise there are no issues. Let me know what you recommend.

Sounds good!

I will be rebasing onto v5.5-rc1 shortly after it comes out.  My usual
approach is to fix any conflicts during that rebasing operation.
Does that make sense, or would you prefer to send me a rebased stack at
that point?  Either way is fine for me.

That's fine with me, thanks!  To avoid too much additional churn on
your end, I just replied to the bitops patch with a version that will
apply with the change to bitops-instrumented infrastructure.

Also considering the merge window, we had a discussion and there are
some arguments for targeting the v5.5 merge window:
- we'd unblock ARM and POWER ports;
- we'd unblock people wanting to use the data_race macro;
- we'd unblock syzbot just tracking upstream;
Unless there are strong reasons to not target v5.5, I leave it to you
if you think it's appropriate.

Thanks,
-- Marco