Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Mike Marshall <hubcap@omnibond.com>

The only reason for that thing used to be the API of mount_nodev()
callback;  since we are calling pvfs2_fill_sb() ourselves now,
we don't have to shove everything into a single structure.
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Mike Marshall <hubcap@omnibond.com>

Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Mike Marshall <hubcap@omnibond.com>

Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Mike Marshall <hubcap@omnibond.com>

Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Mike Marshall <hubcap@omnibond.com>

... and make the only caller use page-backed iov_iter,
getting rid of kmap/kunmap *and* of the bug with
attempted use of iovec-backed copy_page_to_iter()
on a kernel pointer.
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Mike Marshall <hubcap@omnibond.com>

no need to build a copy of what the caller already has;
what's more, we want the one given to caller properly
advanced *and* we shouldn't depend upon it being an
iovec-backed one.
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Mike Marshall <hubcap@omnibond.com>

copy_page_{to,from}_iter() advances it just fine *and* it has no
problem with partially consumed segments.
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Mike Marshall <hubcap@omnibond.com>

incidentally, insane or compromised server returning *more* than
requested on read should not oops the kernel - initialize the
iov_iter for read according to the iovec we've got.  That's why
pvfs_bufmap_copy_to_iovec() needed a separate size argument - we
shouldn't abuse iov_iter_count(iter) for passing that.
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Mike Marshall <hubcap@omnibond.com>

Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Mike Marshall <hubcap@omnibond.com>

Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Mike Marshall <hubcap@omnibond.com>

Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Mike Marshall <hubcap@omnibond.com>

Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Mike Marshall <hubcap@omnibond.com>

Signed-off-by: Mike Marshall <hubcap@omnibond.com>

Errors from the server need to be decoded. A bunch of code was imported from
the server to do this but much of it is convoluted and not even needed. The
result is better but still as convoluted as required by the protocol.
Signed-off-by: Martin Brandenburg <martin@omnibond.com>
Signed-off-by: Mike Marshall <hubcap@omnibond.com>

Previously the code silently failed to update the disk. Now it will not
allow writable and shared mmaps.
Signed-off-by: Martin Brandenburg <martin@omnibond.com>
Signed-off-by: Mike Marshall <hubcap@omnibond.com>

Signed-off-by: Mike Marshall <hubcap@omnibond.com>

Signed-off-by: Mike Marshall <hubcap@omnibond.com>

Signed-off-by: Mike Marshall <hubcap@omnibond.com>

Signed-off-by: Mike Marshall <hubcap@omnibond.com>

Signed-off-by: Mike Marshall <hubcap@omnibond.com>

Al Viro glanced at readdir and surmised that getdents
would misbehave the way it was written... and sure enough.
Signed-off-by: Mike Marshall <hubcap@omnibond.com>

replace opencoded pvfs_bufmap_copy_to_kernel_iovec,
pvfs_bufmap_copy_to_user_iovec, pvfs_bufmap_copy_iovec_from_kernel,
and pvfs_bufmap_copy_iovec_from_user with pvfs_bufmap_copy_to_iovec
and pvfs_bufmap_copy_from_iovec, which both use the iov_iter
interface.
Signed-off-by: Mike Marshall <hubcap@omnibond.com>

spinlock_types.h requires types from linux/types.h.
Including spinlock_types.h first may result in the following build errors,
as seen with arm:allmodconfig.

arch/arm/include/asm/spinlock_types.h:12:3: error: unknown type name 'u32'
arch/arm/include/asm/spinlock_types.h:16:4: error: unknown type name 'u16'

Fixes: deb4fb58ff73 ("Orangefs: kernel client part 2")
Cc: Mark Brown <broonie@kernel.org>
Cc: Mike Marshall <hubcap@omnibond.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Mike Marshall <hubcap@omnibond.com>

This makes no sense and causes warnings on boot.
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Signed-off-by: Mike Marshall <hubcap@omnibond.com>

Signed-off-by: Mike Marshall <hubcap@omnibond.com>

make.cross ARCH=tile doesn't like "inode->i_bytes = PAGE_CACHE_SIZE;",
so cast PAGE_CACHE_SIZE to unsigned short.
Signed-off-by: Mike Marshall <hubcap@omnibond.com>

  Don't check for negative rc from boolean.

  Don't pointlessly initialize variables, it short-circuits
  gcc's uninitialized variable warnings. And max_new_nr_segs
  can never be zero, so don't check for it.

  Preserve original kstrdup pointer for freeing later.

  Don't check for negative value in unsigned variable.
Signed-off-by: Mike Marshall <hubcap@omnibond.com>

Signed-off-by: Mike Marshall <hubcap@omnibond.com>

Stephen Rothwell noticed that orangefs would not compile
on powerpc...
Signed-off-by: Mike Marshall <hubcap@omnibond.com>

Signed-off-by: Mike Marshall <hubcap@omnibond.com>

Signed-off-by: Mike Marshall <hubcap@omnibond.com>

Signed-off-by: Mike Marshall <hubcap@omnibond.com>

Signed-off-by: Mike Marshall <hubcap@omnibond.com>

Signed-off-by: Mike Marshall <hubcap@omnibond.com>

Signed-off-by: Mike Marshall <hubcap@omnibond.com>

OrangeFS (formerly PVFS) is an lgpl licensed userspace networked parallel
file system. OrangeFS can be accessed through included system utilities,
user integration libraries, MPI-IO and can be used by the Hadoop
ecosystem as an alternative to the HDFS filesystem. OrangeFS is used
widely for parallel science, data analytics and engineering applications.

While applications often don't require Orangefs to be mounted into
the VFS, users do like to be able to access their files in the normal way.
The Orangefs kernel client allows Orangefs filesystems to be mounted as
a VFS. The kernel client communicates with a userspace daemon which in
turn communicates with the Orangefs server daemons that implement the
filesystem. The server daemons (there's almost always more than one)
need not be running on the same host as the kernel client.

Orangefs filesystems can also be mounted with FUSE, and we
ship code and instructions to facilitate that, but most of our users
report preferring to use our kernel module instead. Further, as an example
of a problem we can't solve with fuse, we have in the works a
not-yet-ready-for-prime-time version of a file_operations lock function
that accounts for the server daemons being distributed across more
than one running kernel.

Many people and organizations, including Clemson University,
Argonne National Laboratories and Acxiom Corporation have
helped to create what has become Orangefs over more than twenty
years. Some of the more recent contributors to the kernel client
include:

  Mike Marshall
  Christoph Hellwig
  Randy Martin
  Becky Ligon
  Walt Ligon
  Michael Moore
  Rob Ross
  Phil Carnes
Signed-off-by: Mike Marshall <hubcap@omnibond.com>

Pull x86 fixes from Thomas Gleixner:
 "Two bugfixes from Andy addressing at least some of the subtle NMI
  related wreckage which has been reported by Sasha Levin"

* 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  x86/nmi/64: Fix a paravirt stack-clobbering bug in the NMI code
  x86/paravirt: Replace the paravirt nop with a bona fide empty function

Pull irq fix from Thomass Gleixner:
 "A bugfix for the atmel aic5 irq chip driver which caches the wrong
  data and thereby breaking resume"

* 'irq-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  irqchip/atmel-aic5: Use per chip mask caches in mask/unmask()