From: Trond Myklebust <trondmy@hammerspace.com>
To: "jlayton@kernel.org" <jlayton@kernel.org>,
"neilb@suse.de" <neilb@suse.de>,
"jrife@google.com" <jrife@google.com>,
"chuck.lever@oracle.com" <chuck.lever@oracle.com>
Cc: "linux-nfs@vger.kernel.org" <linux-nfs@vger.kernel.org>
Subject: Re: [PATCH] SUNRPC: Avoid address overwrite with eBPF NAT
Date: Thu, 17 Aug 2023 02:29:52 +0000 [thread overview]
Message-ID: <545e445a56bdd9b0befa49610d4330c7c3cd32a3.camel@hammerspace.com> (raw)
In-Reply-To: <96353f2cafa6e06cac240aeaab47a1eac177b07a.camel@hammerspace.com>
On Thu, 2023-08-17 at 02:09 +0000, Trond Myklebust wrote:
> On Wed, 2023-08-16 at 20:48 -0500, Jordan Rife wrote:
> > [You don't often get email from jrife@google.com. Learn why this is
> > important at https://aka.ms/LearnAboutSenderIdentification ]
> >
> > kernel_connect() will modify the rpc_xprt socket address in
> > contexts
> > where eBPF programs perform NAT instead of iptables. In these
> > contexts,
> > it is common for an NFS mount to be mounted to be a static virtual
> > IP
> > while the server has an ephemeral IP leading to a problem where the
> > virtual IP gets overwritten and forgotten. When the endpoint IP
> > changes,
> > reconnect attempts fail and the mount never recovers.
> >
> > This patch protects addr from being modified in these scenarios,
> > allowing
> > NFS reconnects to work as intended.
>
> What? No! A connect() call should not be allowed to modify its own
> call
> parameters.
>
To put it more succinctly, the struct rpc_xprt is one of many private
kernel structures. Parts of it can be exposed through public APIs, such
as the sysfs API that we're building, but when you use eBPF to hack
your way around those public APIs, then you're on your own. We're not
going to commit to support your hacks.
--
Trond Myklebust
Linux NFS client maintainer, Hammerspace
trond.myklebust@hammerspace.com
prev parent reply other threads:[~2023-08-17 2:30 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-08-17 1:48 [PATCH] SUNRPC: Avoid address overwrite with eBPF NAT Jordan Rife
2023-08-17 2:07 ` Chuck Lever III
2023-08-17 2:09 ` Trond Myklebust
2023-08-17 2:29 ` Trond Myklebust [this message]
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=545e445a56bdd9b0befa49610d4330c7c3cd32a3.camel@hammerspace.com \
--to=trondmy@hammerspace.com \
--cc=chuck.lever@oracle.com \
--cc=jlayton@kernel.org \
--cc=jrife@google.com \
--cc=linux-nfs@vger.kernel.org \
--cc=neilb@suse.de \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox