Re: Virtual IPs and blocking locks

[Trond Myklebust <trond.myklebust@fys.uio.no>]

On Mon, 2009-05-18 at 14:41 +0100, Sachin S. Prabhu wrote:
> Rob Gardner wrote:
> > It looks to me like recent kernels have added a "h_srcaddr" filed to the 
> > nlm_host structure, and this should be set to the server's virtual ip 
> > address. Then when the server sends the GRANTED_MSG call to the client, 
> > it should appear to be coming from the virtual ip address, not the 
> > server's primary ip address. So either h_srcaddr isn't getting set up 
> > correctly with your virtual ip address, or rpc_create() isn't binding it 
> > as the source address as it should. In our (older kernel) code, we 
> > explicitly call xprt_set_bindaddr() with the virtual ip address to make 
> > this happen, but I don't immediately see where this happens in the 
> > latest kernel source.
> 
> You are right, I cannot reproduce this issue with nfs servers based on later 
> versions on the kernel containing the patches for
> 'NLM: fix source address in server callbacks'
> 
> However this still leaves the question of the client handling such a situation 
> where a callback is made from a different ip address. Should the client accept 
> such callbacks or is the current behaviour of rejecting these callbacks correct?

The decision to reject callbacks from other ip addresses was deliberate.
There is no good justification for a server to send callbacks or replies
using an address that won't be recognised by the client.

  Trond