OpenZFS on Linux and FreeBSD
Go to file
Richard Yao a988a35a93 Enforce architecture-specific barriers around clear_bit()
The comment above the Linux 3.16 kernel's clear_bit() states:

/**
 * clear_bit - Clears a bit in memory
 * @nr: Bit to clear
 * @addr: Address to start counting from
 *
 * clear_bit() is atomic and may not be reordered.  However, it does
 * not contain a memory barrier, so if it is used for locking purposes,
 * you should call smp_mb__before_atomic() and/or smp_mb__after_atomic()
 * in order to ensure changes are visible on other processors.
 */

This comment does not make sense in the context of x86 because x86 maps the
operations to barrier(), which is a compiler barrier. However, it does make
sense to me when I consider architectures that reorder around atomic
instructions. In such situations, a processor is allowed to execute the
wake_up_bit() before clear_bit() and we have a race. There are a few
architectures that suffer from this issue.

In such situations, the other processor would wake-up, see the bit is still
taken and go to sleep, while the one responsible for waking it up will
assume that it did its job and continue.

This patch implements a wrapper that maps smp_mb__{before,after}_atomic() to
smp_mb__{before,after}_clear_bit() on older kernels and changes our code to
leverage it in a manner consistent with the mainline kernel.

Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
2015-01-16 13:55:09 -08:00
cmd Retire legacy debugging infrastructure 2014-11-19 10:35:07 -08:00
config Retire legacy debugging infrastructure 2014-11-19 10:35:07 -08:00
include Add hooks for disabling direct reclaim 2015-01-16 13:55:09 -08:00
lib Remove autotools products 2012-08-27 11:46:23 -07:00
man Refactor generic memory allocation interfaces 2015-01-16 13:55:09 -08:00
module Enforce architecture-specific barriers around clear_bit() 2015-01-16 13:55:09 -08:00
rpm Tag spl-0.6.3 2014-06-12 11:32:38 -07:00
scripts Retire legacy debugging infrastructure 2014-11-19 10:35:07 -08:00
.gitignore Ignore *.{deb,rpm,tar.gz} files in the top directory. 2013-04-24 16:18:14 -07:00
AUTHORS Refresh AUTHORS 2012-12-19 09:40:18 -08:00
COPYING Public Release Prep 2010-05-17 15:18:00 -07:00
DISCLAIMER Public Release Prep 2010-05-17 15:18:00 -07:00
META Make license compatibility checks consistent 2014-10-17 15:07:28 -07:00
Makefile.am Kernel header installation should respect --prefix 2014-10-28 09:31:48 -07:00
README.markdown Document how to run SPLAT 2013-10-09 13:52:59 -07:00
autogen.sh build: do not call boilerplate ourself 2013-04-02 11:08:46 -07:00
configure.ac Document SPL module parameters. 2013-11-21 12:32:41 -08:00
copy-builtin Copy spl.release.in to kernel dir 2013-06-21 15:40:04 -07:00
spl.release.in Move spl.release generation to configure step 2012-07-12 12:13:47 -07:00

README.markdown

The Solaris Porting Layer (SPL) is a Linux kernel module which provides many of the Solaris kernel APIs. This shim layer makes it possible to run Solaris kernel code in the Linux kernel with relatively minimal modification. This can be particularly useful when you want to track upstream Solaris development closely and do not want the overhead of maintaining a large patch which converts Solaris primitives to Linux primitives.

To build packages for your distribution:

$ ./configure
$ make pkg

If you are building directly from the git tree and not an officially released tarball you will need to generate the configure script. This can be done by executing the autogen.sh script after installing the GNU autotools for your distribution.

To copy the kernel code inside your kernel source tree for builtin compilation:

$ ./configure --enable-linux-builtin --with-linux=/usr/src/linux-...
$ ./copy-builtin /usr/src/linux-...

The SPL comes with an automated test suite called SPLAT. The test suite is implemented in two parts. There is a kernel module which contains the tests and a user space utility which controls which tests are run. To run the full test suite:

$ sudo insmod ./module/splat/splat.ko
$ sudo ./cmd/splat --all

Full documentation for building, configuring, testing, and using the SPL can be found at: http://zfsonlinux.org