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