Commit Graph

20 Commits

Author SHA1 Message Date
Adrian Bunk 87ae9afdca cleanup asm/scatterlist.h includes
Not architecture specific code should not #include <asm/scatterlist.h>.

This patch therefore either replaces them with
#include <linux/scatterlist.h> or simply removes them if they were
unused.

Signed-off-by: Adrian Bunk <bunk@kernel.org>
Signed-off-by: Jens Axboe <jens.axboe@oracle.com>
2007-11-02 08:47:06 +01:00
Jens Axboe 60c74f8193 Update fs/ to use sg helpers
Signed-off-by: Jens Axboe <jens.axboe@oracle.com>
2007-10-22 21:19:55 +02:00
Alexey Dobriyan e8edc6e03a Detach sched.h from mm.h
First thing mm.h does is including sched.h solely for can_do_mlock() inline
function which has "current" dereference inside. By dealing with can_do_mlock()
mm.h can be detached from sched.h which is good. See below, why.

This patch
a) removes unconditional inclusion of sched.h from mm.h
b) makes can_do_mlock() normal function in mm/mlock.c
c) exports can_do_mlock() to not break compilation
d) adds sched.h inclusions back to files that were getting it indirectly.
e) adds less bloated headers to some files (asm/signal.h, jiffies.h) that were
   getting them indirectly

Net result is:
a) mm.h users would get less code to open, read, preprocess, parse, ... if
   they don't need sched.h
b) sched.h stops being dependency for significant number of files:
   on x86_64 allmodconfig touching sched.h results in recompile of 4083 files,
   after patch it's only 3744 (-8.3%).

Cross-compile tested on

	all arm defconfigs, all mips defconfigs, all powerpc defconfigs,
	alpha alpha-up
	arm
	i386 i386-up i386-defconfig i386-allnoconfig
	ia64 ia64-up
	m68k
	mips
	parisc parisc-up
	powerpc powerpc-up
	s390 s390-up
	sparc sparc-up
	sparc64 sparc64-up
	um-x86_64
	x86_64 x86_64-up x86_64-defconfig x86_64-allnoconfig

as well as my two usual configs.

Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-05-21 09:18:19 -07:00
Peter Zijlstra 4b75f78edc [PATCH] lockdep: annotate nfsd4 recover code
> =============================================
> [ INFO: possible recursive locking detected ]
> 2.6.18-1.2724.lockdepPAE #1
> ---------------------------------------------
> nfsd/6884 is trying to acquire lock:
>  (&inode->i_mutex){--..}, at: [<c04811e5>] vfs_rmdir+0x73/0xf4
>
> but task is already holding lock:
>  (&inode->i_mutex){--..}, at: [<f8dfa621>]
> nfsd4_clear_clid_dir+0x1f/0x3d [nfsd]
>
> other info that might help us debug this:
> 3 locks held by nfsd/6884:
>  #0:  (hash_sem){----}, at: [<f8de05eb>] nfsd+0x181/0x2ea [nfsd]
>  #1:  (client_mutex){--..}, at: [<f8df6d19>]
> nfsd4_setclientid_confirm+0x3b/0x2cf [nfsd]
>  #2:  (&inode->i_mutex){--..}, at: [<f8dfa621>]
> nfsd4_clear_clid_dir+0x1f/0x3d [nfsd]
>
> stack backtrace:
>  [<c040524d>] dump_trace+0x69/0x1af
>  [<c04053ab>] show_trace_log_lvl+0x18/0x2c
>  [<c040595f>] show_trace+0xf/0x11
>  [<c0405a53>] dump_stack+0x15/0x17
>  [<c043ca7a>] __lock_acquire+0x110/0x9b6
>  [<c043d91e>] lock_acquire+0x5c/0x7a
>  [<c061a41b>] __mutex_lock_slowpath+0xde/0x234
>  [<c04811e5>] vfs_rmdir+0x73/0xf4
>  [<f8dfa62b>] nfsd4_clear_clid_dir+0x29/0x3d [nfsd]
>  [<f8dfa733>] nfsd4_remove_clid_dir+0xb8/0xf8 [nfsd]
>  [<f8df6e90>] nfsd4_setclientid_confirm+0x1b2/0x2cf [nfsd]
>  [<f8def19a>] nfsd4_proc_compound+0x137a/0x166c [nfsd]
>  [<f8de00d5>] nfsd_dispatch+0xc5/0x180 [nfsd]
>  [<f8d09d83>] svc_process+0x3bd/0x631 [sunrpc]
>  [<f8de0604>] nfsd+0x19a/0x2ea [nfsd]
>  [<c0404e27>] kernel_thread_helper+0x7/0x10
> DWARF2 unwinder stuck at kernel_thread_helper+0x7/0x10
> Leftover inexact backtrace:
>  =======================

Some nesting annotation to the nfsd4 recovery code.
The vfs operations called will take dentry->d_inode->i_mutex.

Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Neil Brown <neilb@suse.de>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-12-08 08:29:01 -08:00
Srinivasa Ds 7ef55b8a05 [PATCH] NFS4: fix for recursive locking problem
When I was performing some operations on NFS, I got below error on server
side.

  =============================================
  [ INFO: possible recursive locking detected ]
  2.6.19-prep #1
  ---------------------------------------------
  nfsd4/3525 is trying to acquire lock:
   (&inode->i_mutex){--..}, at: [<c0611e5a>] mutex_lock+0x21/0x24

  but task is already holding lock:
   (&inode->i_mutex){--..}, at: [<c0611e5a>] mutex_lock+0x21/0x24

  other info that might help us debug this:
  2 locks held by nfsd4/3525:
   #0:  (client_mutex){--..}, at: [<c0611e5a>] mutex_lock+0x21/0x24
   #1:  (&inode->i_mutex){--..}, at: [<c0611e5a>] mutex_lock+0x21/0x24

  stack backtrace:
   [<c04051ed>] show_trace_log_lvl+0x58/0x16a
   [<c04057fa>] show_trace+0xd/0x10
   [<c0405913>] dump_stack+0x19/0x1b
   [<c043b6f1>] __lock_acquire+0x778/0x99c
   [<c043be86>] lock_acquire+0x4b/0x6d
   [<c0611ceb>] __mutex_lock_slowpath+0xbc/0x20a
   [<c0611e5a>] mutex_lock+0x21/0x24
   [<c047fd7e>] vfs_rmdir+0x76/0xf8
   [<f94b7ce9>] nfsd4_clear_clid_dir+0x2c/0x41 [nfsd]
   [<f94b7de9>] nfsd4_remove_clid_dir+0xb1/0xe8 [nfsd]
   [<f94b307b>] laundromat_main+0x9b/0x1c3 [nfsd]
   [<c04333d6>] run_workqueue+0x7a/0xbb
   [<c0433d0b>] worker_thread+0xd2/0x107
   [<c0436285>] kthread+0xc3/0xf2
   [<c0402005>] kernel_thread_helper+0x5/0xb
  ===================================================================

Cause for this problem was,2 successive mutex_lock calls on 2 diffrent inodes ,as shown below

	static int
	nfsd4_clear_clid_dir(struct dentry *dir, struct dentry *dentry)
	{
	        int status;

	        /* For now this directory should already be empty, but we empty it of
        	 * any regular files anyway, just in case the directory was created by
	         * a kernel from the future.... */
        	nfsd4_list_rec_dir(dentry, nfsd4_remove_clid_file);
	        mutex_lock(&dir->d_inode->i_mutex);
	        status = vfs_rmdir(dir->d_inode, dentry);
	...

	int vfs_rmdir(struct inode *dir, struct dentry *dentry)
	{
	        int error = may_delete(dir, dentry, 1);

	        if (error)
	                return error;

	        if (!dir->i_op || !dir->i_op->rmdir)
        	        return -EPERM;

	        DQUOT_INIT(dir);

	        mutex_lock(&dentry->d_inode->i_mutex);
	...

So I have developed the patch to overcome this problem.

Signed-off-by: Srinivasa DS <srinivasa@in.ibm.com>
Cc: Neil Brown <neilb@suse.de>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-11-03 12:27:57 -08:00
Al Viro b37ad28bca [PATCH] nfsd: nfs4 code returns error values in net-endian
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Acked-by: Trond Myklebust <trond.myklebust@fys.uio.no>
Acked-by: Neil Brown <neilb@suse.de>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-10-20 10:26:42 -07:00
David Howells afefdbb28a [PATCH] VFS: Make filldir_t and struct kstat deal in 64-bit inode numbers
These patches make the kernel pass 64-bit inode numbers internally when
communicating to userspace, even on a 32-bit system.  They are required
because some filesystems have intrinsic 64-bit inode numbers: NFS3+ and XFS
for example.  The 64-bit inode numbers are then propagated to userspace
automatically where the arch supports it.

Problems have been seen with userspace (eg: ld.so) using the 64-bit inode
number returned by stat64() or getdents64() to differentiate files, and
failing because the 64-bit inode number space was compressed to 32-bits, and
so overlaps occur.

This patch:

Make filldir_t take a 64-bit inode number and struct kstat carry a 64-bit
inode number so that 64-bit inode numbers can be passed back to userspace.

The stat functions then returns the full 64-bit inode number where
available and where possible.  If it is not possible to represent the inode
number supplied by the filesystem in the field provided by userspace, then
error EOVERFLOW will be issued.

Similarly, the getdents/readdir functions now pass the full 64-bit inode
number to userspace where possible, returning EOVERFLOW instead when a
directory entry is encountered that can't be properly represented.

Note that this means that some inodes will not be stat'able on a 32-bit
system with old libraries where they were before - but it does mean that
there will be no ambiguity over what a 32-bit inode number refers to.

Note similarly that directory scans may be cut short with an error on a
32-bit system with old libraries where the scan would work before for the
same reasons.

It is judged unlikely that this situation will occur because modern glibc
uses 64-bit capable versions of stat and getdents class functions
exclusively, and that older systems are unlikely to encounter
unrepresentable inode numbers anyway.

[akpm: alpha build fix]
Signed-off-by: David Howells <dhowells@redhat.com>
Cc: Trond Myklebust <trond.myklebust@fys.uio.no>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-10-03 08:03:40 -07:00
Herbert Xu 3505868791 [CRYPTO] users: Use crypto_hash interface instead of crypto_digest
This patch converts all remaining crypto_digest users to use the new
crypto_hash interface.

Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2006-09-21 11:46:21 +10:00
J. Bruce Fields c2642ab05b [PATCH] nfsd4: recovery lookup dir check
Make sure we get a directory when we look up the recovery directory.

Thanks to Christoph Hellwig for the bug report.

Based on feedback from Christoph and others, we may remove the need for this
lookup and just pass in a file descriptor from userspace instead, and/or
completely move the directory handling to userspace.  For now we're just
fixing the obvious bugs.

Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
Signed-off-by: Neil Brown <neilb@suse.de>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-01-18 19:20:26 -08:00
J. Bruce Fields d22749b62f [PATCH] nfsd4: fix open of recovery directory
We should be opening this directory RDONLY, not RDWR.

Thanks to Christoph Hellwig for the bug report.

Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
Signed-off-by: Neil Brown <neilb@suse.de>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-01-18 19:20:26 -08:00
Jes Sorensen 1b1dcc1b57 [PATCH] mutex subsystem, semaphore to mutex: VFS, ->i_sem
This patch converts the inode semaphore to a mutex. I have tested it on
XFS and compiled as much as one can consider on an ia64. Anyway your
luck with it might be different.

Modified-by: Ingo Molnar <mingo@elte.hu>

(finished the conversion)

Signed-off-by: Jes Sorensen <jes@sgi.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
2006-01-09 15:59:24 -08:00
Jesper Juhl 573dbd9596 [CRYPTO]: crypto_free_tfm() callers no longer need to check for NULL
Since the patch to add a NULL short-circuit to crypto_free_tfm() went in,
there's no longer any need for callers of that function to check for NULL.
This patch removes the redundant NULL checks and also a few similar checks
for NULL before calls to kfree() that I ran into while doing the
crypto_free_tfm bits.

I've succesfuly compile tested this patch, and a kernel with the patch 
applied boots and runs just fine.

When I posted the patch to LKML (and other lists/people on Cc) it drew the
following comments :

 J. Bruce Fields commented
  "I've no problem with the auth_gss or nfsv4 bits.--b."

 Sridhar Samudrala said
  "sctp change looks fine."

 Herbert Xu signed off on the patch.

So, I guess this is ready to be dropped into -mm and eventually mainline.

Signed-off-by: Jesper Juhl <jesper.juhl@gmail.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: David S. Miller <davem@davemloft.net>
2005-09-01 17:44:29 -07:00
Herbert Xu eb6f1160dd [CRYPTO]: Use CRYPTO_TFM_REQ_MAY_SLEEP where appropriate
This patch goes through the current users of the crypto layer and sets
CRYPTO_TFM_REQ_MAY_SLEEP at crypto_alloc_tfm() where all crypto operations
are performed in process context.

Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: David S. Miller <davem@davemloft.net>
2005-09-01 17:43:25 -07:00
NeilBrown 67be431350 [PATCH] nfsd4: prevent multiple unlinks of recovery directories
Make sure we don't try to delete client recovery directories multiple times;
fixes some spurious error messages.

Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
Signed-off-by: Neil Brown <neilb@cse.unsw.edu.au>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-07-07 18:24:08 -07:00
NeilBrown cdc5524e8a [PATCH] nfsd4: lookup_one_len takes i_sem
Oops, this lookup_one_len needs the i_sem.

Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
Signed-off-by: Neil Brown <neilb@cse.unsw.edu.au>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-07-07 18:24:07 -07:00
NeilBrown a6ccbbb886 [PATCH] nfsd4: fix sync'ing of recovery directory
We need to fsync the recovery directory after writing to it, but we weren't
doing this correctly.  (For example, we weren't taking the i_sem when calling
->fsync().)

Just reuse the existing nfsd fsync code instead.

Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
Signed-off-by: Neil Brown <neilb@cse.unsw.edu.au>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-07-07 18:24:07 -07:00
NeilBrown 0964a3d3f1 [PATCH] knfsd: nfsd4 reboot dirname fix
Set the recovery directory via /proc/fs/nfsd/nfs4recoverydir.

It may be changed any time, but is used only on startup.

Signed-off-by: Andy Adamson <andros@citi.umich.edu>
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
Signed-off-by: Neil Brown <neilb@cse.unsw.edu.au>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-06-24 00:06:36 -07:00
NeilBrown c7b9a45927 [PATCH] knfsd: nfsd4: reboot recovery
This patch adds the code to create and remove client subdirectories from the
recovery directory, as described in the previous patch comment.

Signed-off-by: Andy Adamson <andros@citi.umich.edu>
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
Signed-off-by: Neil Brown <neilb@cse.unsw.edu.au>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-06-24 00:06:36 -07:00
NeilBrown 190e4fbf96 [PATCH] knfsd: nfsd4: initialize recovery directory
NFSv4 clients are required to know what state they have on the server so that
they can reclaim it on server reboot.  However, it is possible for
pathalogical combinations of server reboots and network partitions to leave a
client in a state where it cannot know whether it has lost its state on the
server.

For this reason, rfc3530 requires that we store some information about clients
to stable storage.

So we maintain a directory /var/lib/nfs/v4recovery with a subdirectory for
each client with active state.  We leave open the possibility of including
files underneath each such subdirectory with information about the client, but
for now the subdirectories are empty.

We create a client subdirectory whenever a client makes its first non-reclaim
open_confirm.

We remove a client subdirectory whenever either
        a) its lease expires, or
	b) the grace period ends without it reclaiming anything.
When handling reclaims, we allow the reclaim if and only if the client doing
the reclaim has a subdirectory.

This patch adds just the code to scan the recovery directory on nfsd startup.

Signed-off-by: Andy Adamson <andros@citi.umich.edu>
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
Signed-off-by: Neil Brown <neilb@cse.unsw.edu.au>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-06-24 00:06:35 -07:00
NeilBrown a55370a3c0 [PATCH] knfsd: nfsd4: reboot hash
For the purposes of reboot recovery we keep a directory with subdirectories
each having a name that is the ascii hex representation of the md5 sum of a
client identifier for an active client.

This adds the code to calculate that name.  We also use it for the purposes of
comparing clients, so if someone ever manages to find two client names that
are md5 collisions, then we'll return clid_inuse to the second.

Signed-off-by: Andy Adamson <andros@citi.umich.edu>
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
Signed-off-by: Neil Brown <neilb@cse.unsw.edu.au>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-06-24 00:06:33 -07:00