Commit Graph

9 Commits

Author SHA1 Message Date
Christoph Hellwig 49705b7743 [PATCH] sanitize lookup_hash prototype
->permission and ->lookup have a struct nameidata * argument these days to
pass down lookup intents.  Unfortunately some callers of lookup_hash don't
actually pass this one down.  For lookup_one_len() we don't have a struct
nameidata to pass down, but as this function is a library function only
used by filesystem code this is an acceptable limitation.  All other
callers should pass down the nameidata, so this patch changes the
lookup_hash interface to only take a struct nameidata argument and derives
the other two arguments to __lookup_hash from it.  All callers already have
the nameidata argument available so this is not a problem.

At the same time I'd like to deprecate the lookup_hash interface as there
are better exported interfaces for filesystem usage.  Before it can
actually be removed I need to fix up rpc_pipefs.

Signed-off-by: Christoph Hellwig <hch@lst.de>
Cc: Ram Pai <linuxram@us.ibm.com>
Cc: Jeff Mahoney <jeffm@suse.com>
Cc: Al Viro <viro@ftp.linux.org.uk>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-11-09 07:56:00 -08:00
Trond Myklebust 6070fe6f82 RPC: Ensure that nobody can queue up new upcalls after rpc_close_pipes()
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
2005-10-27 22:12:46 -04:00
Trond Myklebust 6fa05b1736 Revert "RPC: stops the release_pipe() funtion from being called twice"
This reverts 747c5534c9 commit.
2005-10-27 19:08:18 -04:00
Steve Dickson 747c5534c9 RPC: stops the release_pipe() funtion from being called twice
This patch stops the release_pipe() funtion from being called
 twice by invalidating the ops pointer in the rpc_inode
 when rpc_pipe_release() is called.

 Signed-off-by: Steve Dickson <steved@redhat.com>
 Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
2005-10-18 23:19:40 -07:00
Trond Myklebust f134585a73 Revert "[PATCH] RPC,NFS: new rpc_pipefs patch"
This reverts 17f4e6febca160a9f9dd4bdece9784577a2f4524 commit.
2005-09-23 12:39:00 -04:00
Christoph Hellwig 278c995c8a [PATCH] RPC,NFS: new rpc_pipefs patch
Currently rpc_mkdir/rpc_rmdir and rpc_mkpipe/mk_unlink have an API that's
 a little unfortunate.  They take a path relative to the rpc_pipefs root and
 thus need to perform a full lookup.  If you look at debugfs or usbfs they
 always store the dentry for directories they created and thus can pass in
 a dentry + single pathname component pair into their equivalents of the
 above functions.

 And in fact rpc_pipefs actually stores a dentry for all but one component so
 this change not only simplifies the core rpc_pipe code but also the callers.

 Unfortuntately this code path is only used by the NFS4 idmapper and
 AUTH_GSSAPI for which I don't have a test enviroment.  Could someone give
 it a spin?  It's the last bit needed before we can rework the
 lookup_hash API

 Signed-off-by: Christoph Hellwig <hch@lst.de>
 Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
2005-09-23 12:38:57 -04:00
Rolf Eike Beer d51fe1be3f [PATCH] remove driverfs references from include/linux/cpu.h and net/sunrpc/rpc_pipe.c
This patch is against 2.6.10, but still applies cleanly. It's just
s/driverfs/sysfs/ in these two files.

Signed-off-by: Rolf Eike Beer <eike-kernel@sf-tec.de>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-09-02 00:57:31 -07:00
Eric Dumazet ba89966c19 [NET]: use __read_mostly on kmem_cache_t , DEFINE_SNMP_STAT pointers
This patch puts mostly read only data in the right section
(read_mostly), to help sharing of these data between CPUS without
memory ping pongs.

On one of my production machine, tcp_statistics was sitting in a
heavily modified cache line, so *every* SNMP update had to force a
reload.

Signed-off-by: Eric Dumazet <dada1@cosmosbay.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2005-08-29 16:11:18 -07:00
Linus Torvalds 1da177e4c3 Linux-2.6.12-rc2
Initial git repository build. I'm not bothering with the full history,
even though we have it. We can create a separate "historical" git
archive of that later if we want to, and in the meantime it's about
3.2GB when imported into git - space that would just make the early
git days unnecessarily complicated, when we don't have a lot of good
infrastructure for it.

Let it rip!
2005-04-16 15:20:36 -07:00