linux/drivers/staging/lustre
Linus Torvalds 33692f2759 vm: add VM_FAULT_SIGSEGV handling support
The core VM already knows about VM_FAULT_SIGBUS, but cannot return a
"you should SIGSEGV" error, because the SIGSEGV case was generally
handled by the caller - usually the architecture fault handler.

That results in lots of duplication - all the architecture fault
handlers end up doing very similar "look up vma, check permissions, do
retries etc" - but it generally works.  However, there are cases where
the VM actually wants to SIGSEGV, and applications _expect_ SIGSEGV.

In particular, when accessing the stack guard page, libsigsegv expects a
SIGSEGV.  And it usually got one, because the stack growth is handled by
that duplicated architecture fault handler.

However, when the generic VM layer started propagating the error return
from the stack expansion in commit fee7e49d45 ("mm: propagate error
from stack expansion even for guard page"), that now exposed the
existing VM_FAULT_SIGBUS result to user space.  And user space really
expected SIGSEGV, not SIGBUS.

To fix that case, we need to add a VM_FAULT_SIGSEGV, and teach all those
duplicate architecture fault handlers about it.  They all already have
the code to handle SIGSEGV, so it's about just tying that new return
value to the existing code, but it's all a bit annoying.

This is the mindless minimal patch to do this.  A more extensive patch
would be to try to gather up the mostly shared fault handling logic into
one generic helper routine, and long-term we really should do that
cleanup.

Just from this patch, you can generally see that most architectures just
copied (directly or indirectly) the old x86 way of doing things, but in
the meantime that original x86 model has been improved to hold the VM
semaphore for shorter times etc and to handle VM_FAULT_RETRY and other
"newer" things, so it would be a good idea to bring all those
improvements to the generic case and teach other architectures about
them too.

Reported-and-tested-by: Takashi Iwai <tiwai@suse.de>
Tested-by: Jan Engelhardt <jengelh@inai.de>
Acked-by: Heiko Carstens <heiko.carstens@de.ibm.com> # "s390 still compiles and boots"
Cc: linux-arch@vger.kernel.org
Cc: stable@vger.kernel.org
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2015-01-29 10:51:32 -08:00
..
include/linux staging: lustre: libcfs_debug.h: remove final uses of the GOTO macro 2014-11-22 10:55:00 -08:00
lnet staging: lustre: Fix sparse warnings for lnet/lnet/router.c 2014-11-26 12:35:23 -08:00
lustre vm: add VM_FAULT_SIGSEGV handling support 2015-01-29 10:51:32 -08:00
Kconfig
Makefile staging: lustre: remove top level ccflags variable 2014-07-11 20:51:16 -07:00
README.txt lustre: Add some basic documentation 2014-08-30 11:53:54 -07:00
TODO staging: lustre: remove hpdd-discuss list from TODO file 2014-07-12 18:01:57 -07:00

Lustre Parallel Filesystem Client
=================================

The Lustre file system is an open-source, parallel file system
that supports many requirements of leadership class HPC simulation
environments.
Born from from a research project at Carnegie Mellon University,
the Lustre file system is a widely-used option in HPC.
The Lustre file system provides a POSIX compliant file system interface,
can scale to thousands of clients, petabytes of storage and
hundreds of gigabytes per second of I/O bandwidth.

Unlike shared disk storage cluster filesystems (e.g. OCFS2, GFS, GPFS),
Lustre has independent Metadata and Data servers that clients can access
in parallel to maximize performance.

In order to use Lustre client you will need to download lustre client
tools from
https://downloads.hpdd.intel.com/public/lustre/latest-feature-release/
the package name is lustre-client.

You will need to install and configure your Lustre servers separately.

Mount Syntax
============
After you installed the lustre-client tools including mount.lustre binary
you can mount your Lustre filesystem with:

mount -t lustre mgs:/fsname mnt

where mgs is the host name or ip address of your Lustre MGS(management service)
fsname is the name of the filesystem you would like to mount.


Mount Options
=============

  noflock
	Disable posix file locking (Applications trying to use
	the functionality will get ENOSYS)

  localflock
	Enable local flock support, using only client-local flock
	(faster, for applications that require flock but do not run
	 on multiple nodes).

  flock
	Enable cluster-global posix file locking coherent across all
	client nodes.

  user_xattr, nouser_xattr
	Support "user." extended attributes (or not)

  user_fid2path, nouser_fid2path
	Enable FID to path translation by regular users (or not)

  checksum, nochecksum
	Verify data consistency on the wire and in memory as it passes
	between the layers (or not).

  lruresize, nolruresize
	Allow lock LRU to be controlled by memory pressure on the server
	(or only 100 (default, controlled by lru_size proc parameter) locks
	 per CPU per server on this client).

  lazystatfs, nolazystatfs
	Do not block in statfs() if some of the servers are down.

  32bitapi
	Shrink inode numbers to fit into 32 bits. This is necessary
	if you plan to reexport Lustre filesystem from this client via
	NFSv4.

  verbose, noverbose
	Enable mount/umount console messages (or not)

More Information
================
You can get more information at
OpenSFS website: http://lustre.opensfs.org/about/
Intel HPDD wiki: https://wiki.hpdd.intel.com

Out of tree Lustre client and server code is available at:
http://git.whamcloud.com/fs/lustre-release.git

Latest binary packages:
http://lustre.opensfs.org/download-lustre/