All of lore.kernel.org
 help / color / mirror / Atom feed
From: Boqun Feng <boqun.feng@gmail.com>
To: Marco Elver <elver@google.com>
Cc: "Paul E. McKenney" <paulmck@kernel.org>,
	kasan-dev <kasan-dev@googlegroups.com>,
	rust-for-linux@vger.kernel.org
Subject: Re: Can the Kernel Concurrency Sanitizer Own Rust Code?
Date: Thu, 7 Oct 2021 22:15:02 +0800	[thread overview]
Message-ID: <YV8A5iQczHApZlD6@boqun-archlinux> (raw)
In-Reply-To: <CANpmjNMijbiMqd6w37_Lrh7bV=aRm45f9j5R=A0CcRnd5nU-Ww@mail.gmail.com>

Hi Marco,

On Thu, Oct 07, 2021 at 03:01:07PM +0200, Marco Elver wrote:
> Hi Paul,
> 
> Thanks for writing up https://paulmck.livejournal.com/64970.html --
> these were also my thoughts. Similarly for KASAN.
> 
> Sanitizer integration will also, over time, provide quantitative data
> on the rate of bugs in C code, unsafe-Rust, and of course safe-Rust
> code as well as any number of interactions between them once the
> fuzzers are let loose on Rust code.
> 
> Re integrating KCSAN with Rust, this should be doable since rustc does
> support ThreadSanitizer instrumentation:
> https://rustc-dev-guide.rust-lang.org/sanitizers.html
> 
> Just need to pass all the rest of the -mllvm options to rustc as well,
> and ensure it's not attempting to link against compiler-rt. I haven't
> tried, so wouldn't know how it currently behaves.
> 

Thanks for looking into this, and I think you're right: if rustc
supports ThreadSanitizer, then basic features os KCSAN should work.

> Also of importance will be the __tsan_atomic*() instrumentation, which
> KCSAN already provides: my guess is that whatever subset of the LKMM
> Rust initially provides (looking at the current version it certainly
> is the case), the backend will lower them to LLVM atomic intrinsics
> [1], which ThreadSanitizer instrumentation turns into __tsan_atomic*()
> calls.
> [1] https://llvm.org/docs/Atomics.html
> 

Besides atomics, the counterpart of READ_ONCE() and WRITE_ONCE() should
also be looked into, IOW the core::ptr::{read,write}_volatile()
(although I don't think their semantics is completely defined since the
memory model of Rust is incomplete). There could easily be cases where
Rust-side do writes with lock critical sections while C-side do reads
out of the lock critical sections, so Rust-side need to play the
volatile game.

I'm not sure whether rustc will generate special instrumentation for
{read,write}_volatile(), if not, we need to provide something similar to
KCSAN does for READ_ONCE() and WRITE_ONCE().

Regards,
Boqun

> Thanks,
> -- Marco

  reply	other threads:[~2021-10-07 14:16 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-10-07 13:01 Can the Kernel Concurrency Sanitizer Own Rust Code? Marco Elver
2021-10-07 14:15 ` Boqun Feng [this message]
2021-10-07 14:22   ` Marco Elver
2021-10-07 14:43     ` Boqun Feng
2021-10-07 17:44     ` Miguel Ojeda
2021-10-07 18:50       ` Paul E. McKenney
2021-10-07 21:42         ` Gary Guo
2021-10-07 22:30           ` Paul E. McKenney
2021-10-07 23:06             ` Gary Guo
2021-10-07 23:42               ` Paul E. McKenney
2021-10-07 23:59                 ` Gary Guo
2021-10-08  0:27                   ` comex
2021-10-08 17:40                   ` Paul E. McKenney
2021-10-08 21:32                     ` Miguel Ojeda
2021-10-09  0:08                       ` Paul E. McKenney
2021-10-09 16:31                         ` Miguel Ojeda
2021-10-09 23:59                           ` Paul E. McKenney
2021-10-11  1:24                             ` Miguel Ojeda
2021-10-11 19:01                               ` Paul E. McKenney
2021-10-13 11:48                                 ` Miguel Ojeda
2021-10-13 16:07                                   ` Paul E. McKenney
2021-10-13 17:50                                     ` Wedson Almeida Filho
2021-10-14  3:35                                       ` Paul E. McKenney
2021-10-14  8:03                                         ` Wedson Almeida Filho
2021-10-14 19:43                                           ` Paul E. McKenney
2021-10-15 15:06                                             ` Wedson Almeida Filho
2021-10-15 23:29                                               ` Paul E. McKenney
2021-10-08 19:53                 ` Miguel Ojeda
2021-10-08 23:57                   ` Paul E. McKenney
2021-10-09 16:30                     ` Miguel Ojeda
2021-10-09 23:48                       ` Paul E. McKenney
2021-10-11  0:59                         ` Miguel Ojeda
2021-10-11 18:52                           ` Paul E. McKenney
2021-10-13 11:47                             ` Miguel Ojeda
2021-10-13 23:29                               ` Paul E. McKenney
2021-10-22 19:17                                 ` Miguel Ojeda
2021-10-22 20:34                                   ` Paul E. McKenney
2021-10-07 16:30 ` Paul E. McKenney
2021-10-07 16:35   ` Marco Elver

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=YV8A5iQczHApZlD6@boqun-archlinux \
    --to=boqun.feng@gmail.com \
    --cc=elver@google.com \
    --cc=kasan-dev@googlegroups.com \
    --cc=paulmck@kernel.org \
    --cc=rust-for-linux@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.