user/sven/linux.git/include/linux/sunrpc/cache.h, branch v2.6.16.45

[PATCH] sunrpc: cache_register can use wrong module reference

2005-09-07T23:57:25Z

When registering an RPC cache, cache_register() always sets the owner as the sunrpc module. However, there are RPC caches owned by other modules. With the incorrect owner setting, the real owning module can be removed potentially with an open reference to the cache from userspace. For example, if one were to stop the nfs server and unmount the nfsd filesystem, the nfsd module could be removed eventhough rpc.idmapd had references to the idtoname and nametoid caches (i.e. /proc/net/rpc/nfs4./channel is still open). This resulted in a system panic on one of our machines when attempting to restart the nfs services after reloading the nfsd module. The following patch adds a 'struct module *owner' field in struct cache_detail. The owner is further assigned to the struct proc_dir_entry in cache_register() so that the module cannot be unloaded while user-space daemons have an open reference on the associated file under /proc. Signed-off-by: Bruce Allan Cc: Trond Myklebust Cc: Neil Brown Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

[PATCH] nfsd: discard CACHE_HASHED flag, keeping information in refcount instead.

2005-03-05T01:15:09Z

This patch should fix a problem that has been experienced on at-least one busy NFS server, but it has not had lots of testing yet. If -mm could provide that ..... The rpc auth cache currently differentiates between a reference due to being in a hash chain (signalled by CACHE_HASHED flag) and any other reference (counted in refcnt). This is an artificial difference due to an historical accident, and it makes cache_put unsafe. This patch removes the distinction so now existance in a hash chain is counted just like any other reference. Thus a race window in cache_put is closed. Signed-off-by: Neil Brown Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

[SUNRPC]: Staticize, kill unused functions, and remove unneeded exports.

2004-12-27T10:29:36Z

Signed-off-by: Adrian Bunk Signed-off-by: David S. Miller

[PATCH] nfsd: simplify auth_domain_lookup

2004-08-23T06:00:59Z

The interface between the auth_domain and the cache code is messy; the auth_domain code is the only real user of the full 11-argument DefineCacheLookup, and does weird stuff with it (like passing in through one of the arguments a bit of code with a conditional return). We could further parametrize DefineCacheLookup, but I think it's already too complicated. My solution is to just ignore DefineCacheLookup and write the auth_domain_lookup function from scratch. It's actually a pretty short function (much simpler than DefineCacheLookup itself), and it's much easier to read this short function than it is to read some special-cased DefineCacheLookup to verify that it does what it says it does.... Signed-off-by: J. Bruce Fields Signed-off-by: Neil Brown Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

[PATCH] nfsd: make cache_init initialize reference count to 1

2004-08-23T06:00:47Z

Presumably anyone creating a new cache entry is going to want a reference on that cache; and indeed every caller of cache_init increments the reference count immediately afterwards. So may as well make cache_init set an initial reference count of 1. Also, note that cache_init initializes the flags; callers don't need to. Signed-off-by: J. Bruce Fields Signed-off-by: Neil Brown Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

[PATCH] Prevent scary warnings from knfsd

2004-05-25T01:36:31Z

From: "J. Bruce Fields" The kernel currently prints: nfsd: nobody listening for auth.unix.ip upcall; has some daemon not been started? on every bootup, during initscripts. Neil Brown says: It was part of the recent set of idmapper patches. Bruce wanted the admin to get a warning when the idmapper daemon wasn't running. I thought the same warning should apply to any daemon that responded to upcalls. In the case of auth.unix.ip it isn't strictly necessary for a daemon to be running (for comparability with 2.4). You can get rid of the warning by doing: mount -t nfsd nfsd /proc/fs/nfs before mountd is started (init scripts should start doing this I hope, but distributions don't tend to use the init script from nfs-utils, so it is hard to push it). This will trigger mountd to listen on auth.unix.ip and others. That's a hassle, so Bruce's patch limits the warning purely to the new idmapper cache. It provides a callback in the cache_detail that individual caches can use to log messages when upcalls fail because a userspace daemon not running. Implement this method for the idmapping caches.

[PATCH] kNFSd: Add a warning when upcalls fail,

2004-05-19T09:41:00Z

From: NeilBrown From: "J. Bruce Fields" To help the user diagnose problems caused by user-level daemons not running.

[PATCH] kNFSd: Make sure CACHE_NEGATIVE is cleared when a cache entry is updates.

2004-05-19T09:39:35Z

From: NeilBrown This is important for update-in-place caches which may change from being negative to posative. Thanks to "J. Bruce Fields" and Olaf Kirch

[PATCH] kNFSd: Allow sunrpc/svc cache init function to modify the "key"

2004-02-18T12:50:28Z

From: NeilBrown When adding a item to a sunrpc/svc cache that contains kmalloced data it is usefully to move the malloced data out of the key object into the new cache object rather than copying (as then we would need to cope with kmalloc failure and such). This means modifying the original. If the kmalloced data forms part of the key, then we must not move the data out until after the key isn't needed any more. So this patch moves the call to "INIT" on a new item (which fills in the key) to *after* the item has been found (or not), and also makes sure we only call the HASH function once. Thanks to "J. Bruce Fields" also 1/ remove unnecessary assignment 2/ fix comments that lag behind implementation.

[PATCH] NFS/RPC modprobe -r sunrpc causes an oops

2004-01-20T11:17:23Z

From: Steve Dickson Here is a patch for the 2.6.1 kernel that fixes an oops that occurs when the sunrpc module is unloaded. The problem was the RPC cache_register() call was not saving entry pointers to the procfs entries it was creating. So when it came time to dismantle the entires, a BUG_ON() was tripped in remove_proc_entry() since the tree was not broken down completely. (acked by neilb)