Thus d_revalidate is not obliged to check on as much, which will
eventually lead the way to hammering the filesystem servers much less.
Signed-off-by: Martin Brandenburg <martin@omnibond.com>
Signed-off-by: Mike Marshall <hubcap@omnibond.com>
A couple of caches were no longer needed:
- iov_iter improvements to orangefs_devreq_write_iter eliminated
the need for the dev_req_cache.
- removal (months ago) of the old AIO code eliminated the need
for the kiocb_cache.
Also, deobfuscation of use of GFP_KERNEL when calling kmem_cache_(z)alloc
for remaining caches.
Signed-off-by: Mike Marshall <hubcap@omnibond.com>
There were two just alike, making it hard maybe to tell which one
you were looking at in syslog... so I changed it a little by adding
some extra interesting tidbits to it...
Signed-off-by: Mike Marshall <hubcap@omnibond.com>
Previously, it would update a live inode. This was fixed, but it did not
ever check that the inode attributes in the dcache are correct. This
checks all inode attributes and rejects any that are not correct, which
causes a lookup and thus a new getattr.
Perhaps inode_operations->permission should replace or augment some of
this.
There is no actual caching, and this does a rather excessive amount of
network operations back to the filesystem server.
Signed-off-by: Martin Brandenburg <martin@omnibond.com>
Signed-off-by: Mike Marshall <hubcap@omnibond.com>
fold orangefs_op_initialize() in there, don't bother locking something
nobody else could've seen yet, use kmem_cache_zalloc() instead of
explicit memset()...
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Mike Marshall <hubcap@omnibond.com>
... we are not going to get woken up anyway, so it's just going to time out
and whine.
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Mike Marshall <hubcap@omnibond.com>
All timeouts are in _seconds_, so all calls are of form
MSECS_TO_JIFFIES(n * 1000), which is a convoluted way to
spell n * HZ.
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Mike Marshall <hubcap@omnibond.com>
* create with refcount 1
* make op_release() decrement and free if zero (i.e. old put_op()
has become that).
* mark when submitter has given up waiting; from that point nobody
else can move between the lists, change state, etc.
* have daemon read/write_iter grab a reference when picking op
and *always* give it up in the end
* don't put into hash until we know it's been successfully passed to
daemon
* move op->lock _lower_ than htab_in_progress_lock (and make sure
to take it in purge_inprogress_ops())
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Mike Marshall <hubcap@omnibond.com>
... otherwise some thread is running in .text that is about to
be freed.
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Mike Marshall <hubcap@omnibond.com>
Until now, orangefs_devreq_write_iter has just been a wrapper for
the old-fashioned orangefs_devreq_writev... linux would call
.write_iter with "struct kiocb *iocb" and "struct iov_iter *iter"
and .write_iter would just:
return pvfs2_devreq_writev(iocb->ki_filp,
iter->iov,
iter->nr_segs,
&iocb->ki_pos);
Signed-off-by: Mike Marshall <hubcap@omnibond.com>
This only changes the names of things, so there is no functional change.
Signed-off-by: Martin Brandenburg <martin@omnibond.com>
Signed-off-by: Mike Marshall <hubcap@omnibond.com>
Prefix public functions with "orangefs_" do don't
pollute the global namespace.
This fixes a build issue on UML which also has block_signals().
Signed-off-by: Richard Weinberger <richard@nod.at>
Signed-off-by: Martin Brandenburg <martin@omnibond.com>
Signed-off-by: Mike Marshall <hubcap@omnibond.com>
This export_operations structure is never modified, so declare it as const.
Most other structures of this type are already const.
Done with the help of Coccinelle.
Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
Signed-off-by: Mike Marshall <hubcap@omnibond.com>
Orangefs fails to build on 32-bit SMP configurations due to a simple
misspelling, this does the obvious fix.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Fixes: 575e946125 ("Orangefs: change pvfs2 filenames to orangefs")
Signed-off-by: Mike Marshall <hubcap@omnibond.com>
This is an API consolidation only. The use of kmalloc + memset to 0
should be equivalent to kzalloc in this case.
Signed-off-by: Nicholas Mc Guire <hofrat@osadl.org>
Signed-off-by: Mike Marshall <hubcap@omnibond.com>
All callers were outside of the file these functions were declared in,
so nothing was ever inlined anyway.
Further this happens before I/O and any speedup by not having to do a
call will be dwarfed by the time it takes to talk to the server.
Signed-off-by: Mike Marshall <hubcap@omnibond.com>
Signed-off-by: Martin Brandenburg <martin@omnibond.com>
There was previously MAX_ALIGNED_DEV_REQ_(UP|DOWN)SIZE macros which
evaluated to MAX_DEV_REQ_(UP|DOWN)SIZE+8. As it is unclear what this is
for, other than creating a situation where we accept more data than we
can parse, it is removed.
Signed-off-by: Mike Marshall <hubcap@omnibond.com>
Signed-off-by: Martin Brandenburg <martin@omnibond.com>
AV dislikes many parts of orangefs_devreq_writev. Besides making
orangefs_devreq_writev more easily readable and better commented,
this patch makes an effort to address some of the problems:
> The 5th is quietly ignored unless trailer_size is positive and
> status is zero. If trailer_size > 0 && status == 0, you verify that
> the length of the 5th segment is no more than trailer_size and copy
> it to vmalloc'ed buffer. Without bothering to zero the rest of that
> buffer out.
It was just wrong to allow a 5th segment that is not exactly equal to
trailer_size. Now that that's fixed, there's nothing to zero out in
the vmalloced buffer - it is exactly the right size to hold the
5th segment.
> Another API bogosity: when the 5th segment is present, successful writev()
> returns the sum of sizes of the first 4.
Added size of 5th segment to writev return...
> if concatenation of the first 4 segments is longer than
> 16 + sizeof(struct pvfs2_downcall_s) by no more than sizeof(long) => whine
> and proceed with garbage.
If 4th segment isn't exactly sizeof(struct pvfs2_downcall_s), whine and fail.
> if the 32bit value 4 bytes into op->downcall is zero and 64bit
> value following it is non-zero, the latter is interpreted as the size of
> trailer data.
The latter is what userspace claimed was the length of the trailer data.
The kernel module now compares it to the trailer iovec's iov_len as a
sanity check.
> if there's no trailer, the 5th segment (if present) is completely ignored.
Whine and fail if there should be no trailer, yet a 5th segment is present.
> if vmalloc fails, act as if status (32bit at offset 5 into
> op->downcall) had been -ENOMEM and don't look at the 5th segment at all.
whine and fail with -ENOMEM.
Signed-off-by: Mike Marshall <hubcap@omnibond.com>
OrangeFS was formerly known as PVFS2 and retains the name in many places.
I leave the device /dev/pvfs2-req since this affects userspace.
I leave the filesystem type pvfs2 since this affects userspace. Further
the OrangeFS sysint library reads fstab for an entry of type pvfs2
independently of kernel mounts.
I leave extended attribute keys user.pvfs2 and system.pvfs2 as the
sysint library understands these.
I leave references to userspace binaries still named pvfs2.
I leave the filenames.
Signed-off-by: Yi Liu <yi9@clemson.edu>
[martin@omnibond.com: clairify above constraints and merge]
Signed-off-by: Martin Brandenburg <martin@omnibond.com>
Signed-off-by: Mike Marshall <hubcap@omnibond.com>
On Wed, Nov 11, 2015 at 10:19:48AM +0000, Al Viro wrote:
> I'll cook the minimal fixup for API change after I get some sleep and
> send it your way, unless somebody gets there first...
This should do it - switches ->ioctl() to pvfs2_inode_[gs]etxattr() and
converts xattr_handler ->[gs]et() to new API.
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Mike Marshall <hubcap@omnibond.com>
* Kick invalid arguments out early, so handling them does not clutter
the code.
* Avoid possibility of race by not releasing lock until completely done.
* Do not leak ops (memory) in certain error condition.
* Check for more error conditions.
* Put module name in all error and debug logs.
* Document behavior.
Signed-off-by: Martin Brandenburg <martin@omnibond.com>
Signed-off-by: Mike Marshall <hubcap@omnibond.com>
Also removes remnants of iox (readx/writex) which previously used
trailers, but no longer exist.
Signed-off-by: Martin Brandenburg <martin@omnibond.com>
Signed-off-by: Mike Marshall <hubcap@omnibond.com>
minimal fix; it would be better to reject such requests outright.
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Mike Marshall <hubcap@omnibond.com>
The latter is never used, the former has one user and would be
better off spelled out right there.
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>
... 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>
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>
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>
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>
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>
