[PATCH 00/16] AF_RXRPC socket family and AFS rewrite [try #4]
From: David Howells
Date: Wed Apr 25 2007 - 11:50:17 EST
The first of these patches together provide secure client-side RxRPC
connectivity as a Linux kernel socket family. Only the RxRPC transport/session
side is supplied - the presentation side (marshalling the data) is left to the
client. Copies of the patches can be found here:
Further patches make the in-kernel AFS filesystem use AF_RXRPC and delete the
old RxRPC implementation:
And then the rest of the patches extend AFS to provide automatic unmounting of
automount trees, security support and directory-level write support (create,
Note that file-level write support is not yet complete and so is not included
in this patch set.
The userspace access methods make use of the control data passed to/by
sendmsg() and recvmsg(). See the three simple test programs:
The klog program is provided to go and get a Kerberos IV key from the AFS
kaserver. Currently it must be edited before compiling to note the right
server IP address and the appropriate credentials.
These programs can be compiled by:
make klog rxrpc listen CFLAGS="-Wall -g" LDLIBS="-lcrypto -lcrypt -lkrb4 -lkeyutils"
Then a ticket can be obtained by:
If a security key is acquired in this way, then all subsequent AFS operations -
including VL lookups and mounts - performed with that session keyring will be
authenticated using that key. The key can be viewed like so:
[root@andromeda ~]# keyctl show
-3 --alswrv 0 0 keyring: _ses.3268
2 --alswrv 0 0 \_ keyring: _uid.0
111416553 --als--v 0 0 \_ rxrpc: afs@xxxxxxxxxxxxxxxxxxxx
(*) Make certain parameters (such as connection timeouts) userspace
(*) Make userspace utilities use it; librxrpc.
(*) Userspace documentation.
(*) KerberosV security.
(*) SOCK_RPC has been removed. SOCK_DGRAM is now used instead.
(*) I've add a facility whereby calls can be made to destinations other than
the connect() address of a client socket by making use of msg_name in the
msghdr struct when using sendmsg() to send the first data packet of a
call. Indeed, a client socket need not be connected before being used
(*) I've also added a facility whereby client calls may also be made on
server sockets, again by using msg_name in the msghdr struct. In such a
case, the server's local transport endpoint is used.
(*) I've made the write buffer space check available to various callers
(sk_write_space) and implemented poll support.
(*) Rewrote rxrpc_recvmsg(). It now concatenates adjacent data messages from
the same call when delivering them.
(*) Updated the documentation to include notes on recvmsg, cover control
messages and cover SOL_RXRPC-level socket options.
(*) Provided an in-kernel interface to give in-kernel utilities easier access
to the facility.
(*) Made fs/afs/ use it.
(*) Deleted the old contents of net/rxrpc/.
(*) Use the scatterlist interface to the crypto API for now. The patch that
added the direct access interface conflicts with patches Herbert Xu is
producing, so I've dropped it for the moment.
(*) Moved a bug fix to make secure connection reuse work from the
af_rxrpc-kernel patch to the af_rxrpc main patch.
(*) Make RxRPC use its own private work queues rather than keventd's to avoid
deadlocks when AFS tries to use keventd too. This also puts encryption
in the private work queue rather than keventd's queue as that might take
a relatively long time to process.
(*) Shorten the dead call timeout to 2 seconds. Without this, each completed
call sits around eating up resources for 10 seconds. The calls need to
hang around for a little while in case duplicate packets appear, but 10
seconds is excessive.
(*) Decrement the number of available calls on a connection when a new call is
allocated for a connection that doesn't have any calls in progress.
(*) Rename header files with uppercase names to lowercase names.
(*) Make sure include/keys/rxrpc-type.h is included.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/