All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Sachin S. Prabhu" <sprabhu@redhat.com>
To: Rob Gardner <rob.gardner@hp.com>
Cc: "linux-nfs@vger.kernel.org" <linux-nfs@vger.kernel.org>
Subject: Re: Virtual IPs and blocking locks
Date: Mon, 18 May 2009 14:41:15 +0100	[thread overview]
Message-ID: <4A11657B.4070002@redhat.com> (raw)
In-Reply-To: <4A0D9D63.1090102@hp.com>

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?

Sachin Prabhu

  reply	other threads:[~2009-05-18 13:41 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-05-15 14:48 Virtual IPs and blocking locks Sachin S. Prabhu
2009-05-15 16:50 ` Rob Gardner
2009-05-18 13:41   ` Sachin S. Prabhu [this message]
2009-05-18 13:46     ` Trond Myklebust
2009-05-18 13:55     ` Rob Gardner
2009-05-19 20:43       ` Huge race in lockd for async lock requests? Rob Gardner
2009-05-19 21:33         ` Tom Talpey
2009-05-20  6:55         ` Rob Gardner
2009-05-20 14:00           ` Tom Talpey
     [not found]             ` <4a140d0a.85c2f10a.53bc.0979-ATjtLOhZ0NVl57MIdRCFDg@public.gmane.org>
2009-05-20 14:14               ` Tom Talpey
     [not found]                 ` <4a14106e.48c3f10a.7ce3.0e55-ATjtLOhZ0NVl57MIdRCFDg@public.gmane.org>
2009-05-20 23:20                   ` Rob Gardner
2009-05-20 16:37               ` Rob Gardner
2009-05-28 20:05                 ` J. Bruce Fields
2009-05-28 21:34                   ` Rob Gardner
2009-05-29  0:26                     ` J. Bruce Fields
2009-05-29  2:59                       ` Rob Gardner
2009-05-29 13:22                         ` Tom Talpey
     [not found]                           ` <4a1fe1c0.06045a0a.165b.5fbc-ATjtLOhZ0NVl57MIdRCFDg@public.gmane.org>
2009-05-29 15:24                             ` Rob Gardner
2009-05-29 19:14                               ` J. Bruce Fields

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4A11657B.4070002@redhat.com \
    --to=sprabhu@redhat.com \
    --cc=linux-nfs@vger.kernel.org \
    --cc=rob.gardner@hp.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.