diff options
author | David S. Miller <davem@davemloft.net> | 2017-06-06 12:05:57 -0400 |
---|---|---|
committer | David S. Miller <davem@davemloft.net> | 2017-06-06 12:05:57 -0400 |
commit | bb3631405460a4436aede80a60181e6087795597 (patch) | |
tree | 685e7d6bc92e186090b441863d9b83a77883e706 /usr | |
parent | 25f411501bb0a674f3af9208fda2b9861b54ca6f (diff) | |
parent | 4e255721d1575a766ada06dc7eb03acdcd34eaaf (diff) | |
download | linux-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 'usr')
0 files changed, 0 insertions, 0 deletions