From: NeilBrown <neilb@suse.de>
To: Jeff Layton <jlayton@poochiereds.net>
Cc: linux-mm@kvack.org, linux-nfs@vger.kernel.org,
linux-kernel@vger.kernel.org, xfs@oss.sgi.com,
netdev@vger.kernel.org
Subject: Re: [PATCH 05/19] SUNRPC: track whether a request is coming from a loop-back interface.
Date: Thu, 17 Apr 2014 09:25:04 +1000 [thread overview]
Message-ID: <20140417092504.57a49f9d@notabene.brown> (raw)
In-Reply-To: <20140416104702.264cde48@tlielax.poochiereds.net>
[-- Attachment #1: Type: text/plain, Size: 4281 bytes --]
On Wed, 16 Apr 2014 10:47:02 -0400 Jeff Layton <jlayton@poochiereds.net>
wrote:
> On Wed, 16 Apr 2014 14:03:36 +1000
> NeilBrown <neilb@suse.de> wrote:
>
> > If an incoming NFS request is coming from the local host, then
> > nfsd will need to perform some special handling. So detect that
> > possibility and make the source visible in rq_local.
> >
> > Signed-off-by: NeilBrown <neilb@suse.de>
> > ---
> > include/linux/sunrpc/svc.h | 1 +
> > include/linux/sunrpc/svc_xprt.h | 1 +
> > net/sunrpc/svcsock.c | 10 ++++++++++
> > 3 files changed, 12 insertions(+)
> >
> > diff --git a/include/linux/sunrpc/svc.h b/include/linux/sunrpc/svc.h
> > index 04e763221246..a0dbbd1e00e9 100644
> > --- a/include/linux/sunrpc/svc.h
> > +++ b/include/linux/sunrpc/svc.h
> > @@ -254,6 +254,7 @@ struct svc_rqst {
> > u32 rq_prot; /* IP protocol */
> > unsigned short
> > rq_secure : 1; /* secure port */
> > + unsigned short rq_local : 1; /* local request */
> >
> > void * rq_argp; /* decoded arguments */
> > void * rq_resp; /* xdr'd results */
> > diff --git a/include/linux/sunrpc/svc_xprt.h b/include/linux/sunrpc/svc_xprt.h
> > index b05963f09ebf..b99bdfb0fcf9 100644
> > --- a/include/linux/sunrpc/svc_xprt.h
> > +++ b/include/linux/sunrpc/svc_xprt.h
> > @@ -63,6 +63,7 @@ struct svc_xprt {
> > #define XPT_DETACHED 10 /* detached from tempsocks list */
> > #define XPT_LISTENER 11 /* listening endpoint */
> > #define XPT_CACHE_AUTH 12 /* cache auth info */
> > +#define XPT_LOCAL 13 /* connection from loopback interface */
> >
> > struct svc_serv *xpt_server; /* service for transport */
> > atomic_t xpt_reserved; /* space on outq that is rsvd */
> > diff --git a/net/sunrpc/svcsock.c b/net/sunrpc/svcsock.c
> > index b6e59f0a9475..193115fe968c 100644
> > --- a/net/sunrpc/svcsock.c
> > +++ b/net/sunrpc/svcsock.c
> > @@ -811,6 +811,7 @@ static struct svc_xprt *svc_tcp_accept(struct svc_xprt *xprt)
> > struct socket *newsock;
> > struct svc_sock *newsvsk;
> > int err, slen;
> > + struct dst_entry *dst;
> > RPC_IFDEBUG(char buf[RPC_MAX_ADDRBUFLEN]);
> >
> > dprintk("svc: tcp_accept %p sock %p\n", svsk, sock);
> > @@ -867,6 +868,14 @@ static struct svc_xprt *svc_tcp_accept(struct svc_xprt *xprt)
> > }
> > svc_xprt_set_local(&newsvsk->sk_xprt, sin, slen);
> >
> > + clear_bit(XPT_LOCAL, &newsvsk->sk_xprt.xpt_flags);
> > + rcu_read_lock();
> > + dst = rcu_dereference(newsock->sk->sk_dst_cache);
> > + if (dst && dst->dev &&
> > + (dst->dev->features & NETIF_F_LOOPBACK))
> > + set_bit(XPT_LOCAL, &newsvsk->sk_xprt.xpt_flags);
> > + rcu_read_unlock();
> > +
>
> In the use-case you describe, the client is unlikely to have mounted
> "localhost", but is more likely to be mounting a floating address in
> the cluster.
>
> Will this flag end up being set in such a situation? It looks like
> NETIF_F_LOOPBACK isn't set on all adapters -- mostly on "lo" and a few
> others that support MAC-LOOPBACK.
I was hoping someone on net-dev would have commented if it didn't work - I
probably should have explicitly asked.
My testing certainly suggests that this works if I use any local address to
perform the mount, not just 127.0.0.1.
I don't know enough about routing and neighbours and the dst cache to be
certain but my shallow understanding was always that traffic to any local
address was pseudo-routed through the lo interface and would never get
anywhere near e.g. the eth0 interface.
Can any network people confirm?
Thanks,
NeilBrown
>
>
> > if (serv->sv_stats)
> > serv->sv_stats->nettcpconn++;
> >
> > @@ -1112,6 +1121,7 @@ static int svc_tcp_recvfrom(struct svc_rqst *rqstp)
> >
> > rqstp->rq_xprt_ctxt = NULL;
> > rqstp->rq_prot = IPPROTO_TCP;
> > + rqstp->rq_local = !!test_bit(XPT_LOCAL, &svsk->sk_xprt.xpt_flags);
> >
> > p = (__be32 *)rqstp->rq_arg.head[0].iov_base;
> > calldir = p[1];
> >
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
WARNING: multiple messages have this Message-ID (diff)
From: NeilBrown <neilb@suse.de>
To: Jeff Layton <jlayton@poochiereds.net>
Cc: linux-mm@kvack.org, linux-nfs@vger.kernel.org,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
xfs@oss.sgi.com
Subject: Re: [PATCH 05/19] SUNRPC: track whether a request is coming from a loop-back interface.
Date: Thu, 17 Apr 2014 09:25:04 +1000 [thread overview]
Message-ID: <20140417092504.57a49f9d@notabene.brown> (raw)
In-Reply-To: <20140416104702.264cde48@tlielax.poochiereds.net>
[-- Attachment #1.1: Type: text/plain, Size: 4281 bytes --]
On Wed, 16 Apr 2014 10:47:02 -0400 Jeff Layton <jlayton@poochiereds.net>
wrote:
> On Wed, 16 Apr 2014 14:03:36 +1000
> NeilBrown <neilb@suse.de> wrote:
>
> > If an incoming NFS request is coming from the local host, then
> > nfsd will need to perform some special handling. So detect that
> > possibility and make the source visible in rq_local.
> >
> > Signed-off-by: NeilBrown <neilb@suse.de>
> > ---
> > include/linux/sunrpc/svc.h | 1 +
> > include/linux/sunrpc/svc_xprt.h | 1 +
> > net/sunrpc/svcsock.c | 10 ++++++++++
> > 3 files changed, 12 insertions(+)
> >
> > diff --git a/include/linux/sunrpc/svc.h b/include/linux/sunrpc/svc.h
> > index 04e763221246..a0dbbd1e00e9 100644
> > --- a/include/linux/sunrpc/svc.h
> > +++ b/include/linux/sunrpc/svc.h
> > @@ -254,6 +254,7 @@ struct svc_rqst {
> > u32 rq_prot; /* IP protocol */
> > unsigned short
> > rq_secure : 1; /* secure port */
> > + unsigned short rq_local : 1; /* local request */
> >
> > void * rq_argp; /* decoded arguments */
> > void * rq_resp; /* xdr'd results */
> > diff --git a/include/linux/sunrpc/svc_xprt.h b/include/linux/sunrpc/svc_xprt.h
> > index b05963f09ebf..b99bdfb0fcf9 100644
> > --- a/include/linux/sunrpc/svc_xprt.h
> > +++ b/include/linux/sunrpc/svc_xprt.h
> > @@ -63,6 +63,7 @@ struct svc_xprt {
> > #define XPT_DETACHED 10 /* detached from tempsocks list */
> > #define XPT_LISTENER 11 /* listening endpoint */
> > #define XPT_CACHE_AUTH 12 /* cache auth info */
> > +#define XPT_LOCAL 13 /* connection from loopback interface */
> >
> > struct svc_serv *xpt_server; /* service for transport */
> > atomic_t xpt_reserved; /* space on outq that is rsvd */
> > diff --git a/net/sunrpc/svcsock.c b/net/sunrpc/svcsock.c
> > index b6e59f0a9475..193115fe968c 100644
> > --- a/net/sunrpc/svcsock.c
> > +++ b/net/sunrpc/svcsock.c
> > @@ -811,6 +811,7 @@ static struct svc_xprt *svc_tcp_accept(struct svc_xprt *xprt)
> > struct socket *newsock;
> > struct svc_sock *newsvsk;
> > int err, slen;
> > + struct dst_entry *dst;
> > RPC_IFDEBUG(char buf[RPC_MAX_ADDRBUFLEN]);
> >
> > dprintk("svc: tcp_accept %p sock %p\n", svsk, sock);
> > @@ -867,6 +868,14 @@ static struct svc_xprt *svc_tcp_accept(struct svc_xprt *xprt)
> > }
> > svc_xprt_set_local(&newsvsk->sk_xprt, sin, slen);
> >
> > + clear_bit(XPT_LOCAL, &newsvsk->sk_xprt.xpt_flags);
> > + rcu_read_lock();
> > + dst = rcu_dereference(newsock->sk->sk_dst_cache);
> > + if (dst && dst->dev &&
> > + (dst->dev->features & NETIF_F_LOOPBACK))
> > + set_bit(XPT_LOCAL, &newsvsk->sk_xprt.xpt_flags);
> > + rcu_read_unlock();
> > +
>
> In the use-case you describe, the client is unlikely to have mounted
> "localhost", but is more likely to be mounting a floating address in
> the cluster.
>
> Will this flag end up being set in such a situation? It looks like
> NETIF_F_LOOPBACK isn't set on all adapters -- mostly on "lo" and a few
> others that support MAC-LOOPBACK.
I was hoping someone on net-dev would have commented if it didn't work - I
probably should have explicitly asked.
My testing certainly suggests that this works if I use any local address to
perform the mount, not just 127.0.0.1.
I don't know enough about routing and neighbours and the dst cache to be
certain but my shallow understanding was always that traffic to any local
address was pseudo-routed through the lo interface and would never get
anywhere near e.g. the eth0 interface.
Can any network people confirm?
Thanks,
NeilBrown
>
>
> > if (serv->sv_stats)
> > serv->sv_stats->nettcpconn++;
> >
> > @@ -1112,6 +1121,7 @@ static int svc_tcp_recvfrom(struct svc_rqst *rqstp)
> >
> > rqstp->rq_xprt_ctxt = NULL;
> > rqstp->rq_prot = IPPROTO_TCP;
> > + rqstp->rq_local = !!test_bit(XPT_LOCAL, &svsk->sk_xprt.xpt_flags);
> >
> > p = (__be32 *)rqstp->rq_arg.head[0].iov_base;
> > calldir = p[1];
> >
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
[-- Attachment #2: Type: text/plain, Size: 121 bytes --]
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next prev parent reply other threads:[~2014-04-16 23:25 UTC|newest]
Thread overview: 151+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-04-16 4:03 [PATCH/RFC 00/19] Support loop-back NFS mounts NeilBrown
2014-04-16 4:03 ` NeilBrown
2014-04-16 4:03 ` NeilBrown
2014-04-16 4:03 ` NeilBrown
2014-04-16 4:03 ` [PATCH 14/19] driver core: set PF_FSTRANS while holding gdp_mutex NeilBrown
2014-04-16 4:03 ` NeilBrown
2014-04-16 4:03 ` NeilBrown
2014-04-16 4:03 ` [PATCH 07/19] nfsd and VM: use PF_LESS_THROTTLE to avoid throttle in shrink_inactive_list NeilBrown
2014-04-16 4:03 ` NeilBrown
2014-04-16 4:03 ` NeilBrown
2014-04-16 4:03 ` [PATCH 12/19] NET: set PF_FSTRANS while holding rtnl_lock NeilBrown
2014-04-16 4:03 ` NeilBrown
2014-04-16 4:03 ` NeilBrown
2014-04-16 4:03 ` NeilBrown
2014-04-16 4:03 ` [PATCH 13/19] MM: set PF_FSTRANS while allocating per-cpu memory to avoid deadlock NeilBrown
2014-04-16 4:03 ` NeilBrown
2014-04-16 4:03 ` NeilBrown
2014-04-16 5:49 ` Dave Chinner
2014-04-16 5:49 ` Dave Chinner
2014-04-16 5:49 ` Dave Chinner
2014-04-16 6:22 ` NeilBrown
2014-04-16 6:22 ` NeilBrown
2014-04-16 6:30 ` Dave Chinner
2014-04-16 6:30 ` Dave Chinner
2014-04-16 6:30 ` Dave Chinner
2014-04-16 4:03 ` [PATCH 09/19] XFS: ensure xfs_file_*_read cannot deadlock in memory allocation NeilBrown
2014-04-16 4:03 ` NeilBrown
2014-04-16 4:03 ` NeilBrown
2014-04-16 6:04 ` Dave Chinner
2014-04-16 6:04 ` Dave Chinner
2014-04-16 6:04 ` Dave Chinner
2014-04-16 6:27 ` NeilBrown
2014-04-16 6:27 ` NeilBrown
2014-04-16 6:31 ` Dave Chinner
2014-04-16 6:31 ` Dave Chinner
2014-04-16 6:31 ` Dave Chinner
2014-04-16 4:03 ` [PATCH 04/19] Make effect of PF_FSTRANS to disable __GFP_FS universal NeilBrown
2014-04-16 4:03 ` NeilBrown
2014-04-16 4:03 ` NeilBrown
2014-04-16 5:37 ` Dave Chinner
2014-04-16 5:37 ` Dave Chinner
2014-04-16 5:37 ` Dave Chinner
2014-04-16 6:17 ` NeilBrown
2014-04-16 6:17 ` NeilBrown
2014-04-17 1:03 ` NeilBrown
2014-04-17 1:03 ` NeilBrown
2014-04-17 4:41 ` Dave Chinner
2014-04-17 4:41 ` Dave Chinner
2014-04-17 4:41 ` Dave Chinner
2014-04-16 4:03 ` [PATCH 03/19] lockdep: improve scenario messages for RECLAIM_FS errors NeilBrown
2014-04-16 4:03 ` NeilBrown
2014-04-16 4:03 ` NeilBrown
2014-04-16 7:22 ` Peter Zijlstra
2014-04-16 7:22 ` Peter Zijlstra
2014-04-16 7:22 ` Peter Zijlstra
2014-04-16 4:03 ` [PATCH 10/19] NET: set PF_FSTRANS while holding sk_lock NeilBrown
2014-04-16 4:03 ` NeilBrown
2014-04-16 4:03 ` NeilBrown
2014-04-16 4:03 ` NeilBrown
2014-04-16 5:13 ` Eric Dumazet
2014-04-16 5:13 ` Eric Dumazet
2014-04-16 5:13 ` Eric Dumazet
2014-04-16 5:13 ` Eric Dumazet
2014-04-16 5:47 ` NeilBrown
2014-04-16 5:47 ` NeilBrown
2014-04-16 5:47 ` NeilBrown
2014-04-16 13:00 ` David Miller
2014-04-16 13:00 ` David Miller
2014-04-16 13:00 ` David Miller
2014-04-17 2:38 ` NeilBrown
2014-04-17 2:38 ` NeilBrown
2014-04-16 4:03 ` [PATCH 05/19] SUNRPC: track whether a request is coming from a loop-back interface NeilBrown
2014-04-16 4:03 ` NeilBrown
2014-04-16 4:03 ` NeilBrown
2014-04-16 4:03 ` NeilBrown
2014-04-16 14:47 ` Jeff Layton
2014-04-16 14:47 ` Jeff Layton
2014-04-16 14:47 ` Jeff Layton
2014-04-16 23:25 ` NeilBrown [this message]
2014-04-16 23:25 ` NeilBrown
2014-04-16 4:03 ` [PATCH 06/19] nfsd: set PF_FSTRANS for nfsd threads NeilBrown
2014-04-16 4:03 ` NeilBrown
2014-04-16 4:03 ` NeilBrown
2014-04-16 7:28 ` Peter Zijlstra
2014-04-16 7:28 ` Peter Zijlstra
2014-04-16 7:28 ` Peter Zijlstra
2014-04-16 4:03 ` [PATCH 08/19] Set PF_FSTRANS while write_cache_pages calls ->writepage NeilBrown
2014-04-16 4:03 ` NeilBrown
2014-04-16 4:03 ` NeilBrown
2014-04-16 4:03 ` [PATCH 02/19] lockdep: lockdep_set_current_reclaim_state should save old value NeilBrown
2014-04-16 4:03 ` NeilBrown
2014-04-16 4:03 ` NeilBrown
2014-04-16 4:03 ` [PATCH 01/19] Promote current_{set, restore}_flags_nested from xfs to global NeilBrown
2014-04-16 4:03 ` NeilBrown
2014-04-16 4:03 ` NeilBrown
2014-04-16 4:03 ` [PATCH 11/19] FS: set PF_FSTRANS while holding mmap_sem in exec.c NeilBrown
2014-04-16 4:03 ` NeilBrown
2014-04-16 4:03 ` NeilBrown
2014-04-16 4:03 ` [PATCH 17/19] VFS: set PF_FSTRANS while namespace_sem is held NeilBrown
2014-04-16 4:03 ` NeilBrown
2014-04-16 4:03 ` NeilBrown
2014-04-16 4:46 ` Al Viro
2014-04-16 4:46 ` Al Viro
2014-04-16 5:52 ` NeilBrown
2014-04-16 5:52 ` NeilBrown
2014-04-16 16:37 ` Al Viro
2014-04-16 16:37 ` Al Viro
2014-04-16 16:37 ` Al Viro
2014-04-16 4:03 ` [PATCH 19/19] XFS: set PF_FSTRANS while ilock is held in xfs_free_eofblocks NeilBrown
2014-04-16 4:03 ` NeilBrown
2014-04-16 4:03 ` NeilBrown
2014-04-16 6:18 ` Dave Chinner
2014-04-16 6:18 ` Dave Chinner
2014-04-16 6:18 ` Dave Chinner
2014-04-16 4:03 ` [PATCH 16/19] VFS: use GFP_NOFS rather than GFP_KERNEL in __d_alloc NeilBrown
2014-04-16 4:03 ` NeilBrown
2014-04-16 4:03 ` NeilBrown
2014-04-16 6:25 ` Dave Chinner
2014-04-16 6:25 ` Dave Chinner
2014-04-16 6:25 ` Dave Chinner
2014-04-16 6:49 ` NeilBrown
2014-04-16 6:49 ` NeilBrown
2014-04-16 9:00 ` Dave Chinner
2014-04-16 9:00 ` Dave Chinner
2014-04-16 9:00 ` Dave Chinner
2014-04-17 0:51 ` NeilBrown
2014-04-17 0:51 ` NeilBrown
2014-04-17 5:58 ` Dave Chinner
2014-04-17 5:58 ` Dave Chinner
2014-04-17 5:58 ` Dave Chinner
2014-04-16 4:03 ` [PATCH 15/19] nfsd: set PF_FSTRANS when client_mutex is held NeilBrown
2014-04-16 4:03 ` NeilBrown
2014-04-16 4:03 ` NeilBrown
2014-04-16 4:03 ` [PATCH 18/19] nfsd: set PF_FSTRANS during nfsd4_do_callback_rpc NeilBrown
2014-04-16 4:03 ` NeilBrown
2014-04-16 4:03 ` NeilBrown
2014-04-16 14:42 ` [PATCH/RFC 00/19] Support loop-back NFS mounts Jeff Layton
2014-04-16 14:42 ` Jeff Layton
2014-04-16 14:42 ` Jeff Layton
2014-04-17 0:20 ` NeilBrown
2014-04-17 0:20 ` NeilBrown
2014-04-17 0:20 ` NeilBrown
2014-04-17 1:27 ` Dave Chinner
2014-04-17 1:27 ` Dave Chinner
2014-04-17 1:27 ` Dave Chinner
2014-04-17 1:50 ` NeilBrown
2014-04-17 1:50 ` NeilBrown
2014-04-17 1:50 ` NeilBrown
2014-04-17 4:23 ` Dave Chinner
2014-04-17 4:23 ` Dave Chinner
2014-04-17 4:23 ` Dave Chinner
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=20140417092504.57a49f9d@notabene.brown \
--to=neilb@suse.de \
--cc=jlayton@poochiereds.net \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-nfs@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=xfs@oss.sgi.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.