rxrpc kernel sockets hold additional reference to dst

[David Howells]

Vadim Fedorenko <vfedorenko at novek.ru> wrote:

> >> I'm not sure how to deal with early demux in this case. I think we should add
> >> more restrictions to  __udp4_lib_demux_lookup but I'm not sure which exactly.
> >> Do you have any suggestions?
> > Is there a way to allocate an unused port from UDP?
> 
> I'm not sure that it's possible in terms of binding to listen, no matter UDP
> or TCP. I think server side should always know the port it wants to listen.

That's not necessary in this case.

In an AFS client, there's a UDP port that's used for sending RPC calls (rxrpc
client) and receiving notifications (rxrpc server).  The fileserver doesn't
talk to the notification-receiving server (known as an AFS cache manager)
unless it's first received an RPC call to register an interest in a file (a
callback promise).

When it receives an RPC that queries something about a file or directory, the
server will note the source address for the RPC and, if 3rd party interference
occurs, will send an RPC back to the this address to notify of this.

The only requirement, really, is that the client must keep listening on the
same port it sent the original RPC on for as long as the callback promise is
valid if it wants to receive notifications.

There's a standard port for the client (afs-callback: 7001), but that can only
be used by one namespace at a time.  The problem is how to deal with an AFS
mount on a second namespace?  Letting pick a random port is fine since the
fileserver finds out when we talk to it.

David