summaryrefslogtreecommitdiffstats
path: root/fs
diff options
context:
space:
mode:
authorDavid S. Miller <davem@davemloft.net>2017-06-06 12:05:57 -0400
committerDavid S. Miller <davem@davemloft.net>2017-06-06 12:05:57 -0400
commitbb3631405460a4436aede80a60181e6087795597 (patch)
tree685e7d6bc92e186090b441863d9b83a77883e706 /fs
parent25f411501bb0a674f3af9208fda2b9861b54ca6f (diff)
parent4e255721d1575a766ada06dc7eb03acdcd34eaaf (diff)
downloadlinux-bb3631405460a4436aede80a60181e6087795597.tar.gz
linux-bb3631405460a4436aede80a60181e6087795597.tar.bz2
linux-bb3631405460a4436aede80a60181e6087795597.zip
Merge tag 'rxrpc-rewrite-20170606' of git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs
David Howells says: ==================== rxrpc: Support service upgrade Here's a set of patches that allow AF_RXRPC to support the AuriStor service upgrade facility. This allows the server to change the service ID requested to an upgraded service if the client requests it upon the initiation of a connection. This is used by the AuriStor AFS-compatible servers to implement IPv6 handling and improved facilities by providing improved volume location, volume, protection, file and cache management services. Note that certain parts of the AFS protocol carry hard-coded IPv4 addresses. The reason AuriStor does it this way is that probing the improved service ID first will not incur an ABORT or any other response on some servers if the server is not listening on it - and so one have to employ a timeout. This is implemented in the server by allowing an AF_RXRPC server to call bind() twice on a socket to allow it to listen on two service IDs and then call setsockopt() to instruct the server to upgrade one into the other if the client requests it (by setting userStatus to 1 on the first DATA packet on a connection). If the upgrade occurs, all further operations on that connection are done with the new service ID. AF_RXRPC has to handle this automatically as connections are not exposed to userspace. Clients can request this facility by setting an RXRPC_UPGRADE_SERVICE command in the sendmsg() control buffer and then observing the resultant service ID in the msg_addr returned by recvmsg(). This should only be used to probe the service. Clients should then use the returned service ID in all subsequent communications with that server. Note that the kernel will not retain this information should the connection expire from its cache. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
Diffstat (limited to 'fs')
0 files changed, 0 insertions, 0 deletions