public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Eugene Shatokhin <eugene.shatokhin@rosalab.ru>
To: LKML <linux-kernel@vger.kernel.org>
Cc: Nikita Komarov <nikita@kmrov.ru>
Subject: [ANNOUNCE] RaceHound 1.0 - data race detector for the kernel
Date: Thu, 21 May 2015 11:56:37 +0300	[thread overview]
Message-ID: <555D9DC5.9050101@rosalab.ru> (raw)

Hi,

RaceHound 1.0 has been released.

This tool can be used to detect data races in the kernel code in runtime 
on x86. It may miss races but should produce no false alarms.

Suppose it is needed to check if an instruction that accesses data in 
memory may race for these data with some other code. RaceHound operates 
as follows.

1. Place a software breakpoint (Kprobe, actually) on the instruction.
2. When the software breakpoint hits, determine the address and size of 
the data the instruction is about to access.
3. Arm a hardware breakpoint to detect the conflicting accesses to these 
data (writes if the instruction only reads the data, both reads and 
writes otherwise). The hardware breakpoint may cover only a limited 
amount of memory but that is OK for now.
4. Make a delay (the length is configurable).
5. If the hardware breakpoint hits during the delay, report a race.
6. Disarm the hardware breakpoint and let the code execution continue 
normally.

In addition, RaceHound checks if the accessed data have been modified 
during the delay. This also helps detect races if the hardware 
breakpoints have missed them.

The ideas behind all this are similar to those implemented in 
DataCollider tool for MS Windows [1].

In this version, RaceHound was rewritten to use Kprobes for software 
breakpoints as well as to be able to monitor almost any place in the 
kernel where a Kprobe can be placed. So it can now monitor not only the 
instructions in the loadable modules like before, but also in the kernel 
proper or the built-in modules.

Although the tool can now only monitor the instructions supplied by the 
user, I think, I could later implement some kind of automated "sweeping" 
through the given area of code, checking the memory accesses there. May 
be, something similar to what they do on MS Windows [1].

The code of RaceHound is available at https://github.com/winnukem/racehound.
The instructions on how to setup and use it are also there: 
https://github.com/winnukem/racehound/blob/master/README

References:
[1] John Erickson et. al., "Effective Data-Race Detection for the 
Kernel" - Proc. 9th USENIX Symposium on Operating Systems Design and 
Implementation (OSDI'10).

Regards,

Eugene
-- 
Eugene Shatokhin, ROSA
www.rosalab.com

                 reply	other threads:[~2015-05-21  8:56 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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=555D9DC5.9050101@rosalab.ru \
    --to=eugene.shatokhin@rosalab.ru \
    --cc=linux-kernel@vger.kernel.org \
    --cc=nikita@kmrov.ru \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox