MIME-Version: 1.0
References: <20230307220525.54895-1-Jerry@skydio.com> <167822825917.8008.11050193827453206272@noble.neil.brown.name>
In-Reply-To: <167822825917.8008.11050193827453206272@noble.neil.brown.name>
From:   Jerry Zhang <jerry@skydio.com>
Date:   Tue, 7 Mar 2023 14:52:53 -0800
Message-ID: <CAMKO5Cv1Uh1rSFQ0cR1kfA88iXXHP5RMO-euU15Xrn2i93J5rg@mail.gmail.com>
Subject: Re: [PATCH] sunrpc: Fix incorrect parsing of expiry time
To:     NeilBrown <neilb@suse.de>
Cc:     embedded@skydio.com, Chuck Lever <chuck.lever@oracle.com>,
        Jeff Layton <jlayton@kernel.org>,
        Trond Myklebust <trond.myklebust@hammerspace.com>,
        Anna Schumaker <anna@kernel.org>,
        "J. Bruce Fields" <bfields@redhat.com>, linux-nfs@vger.kernel.org,
        linux-kernel@vger.kernel.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

On Tue, Mar 7, 2023 at 2:31=E2=80=AFPM NeilBrown <neilb@suse.de> wrote:
>
> On Wed, 08 Mar 2023, Jerry Zhang wrote:
> > The expiry time field is mean to be expressed in seconds since boot.
>
> Correct.
>
> > The get_expiry() function parses a relative time value in seconds.
>
> Incorrect.  It parses and absoulte wall-clock time.
I'm not familiar with the source of truth for this info. Is there a
specification of some sort?

For reference, we were seeing writes to
/proc/net/rpc/nfsd.export/channel randomly fail with EINVAL despite
usually succeeding with the same invocation. Upon investigation this
was the string that exportfs was writing "-test-client- /path/to/mount
 3 0 65534 65534 0". "3" was the value for expiry in this message,
which led me to conclude that this is a relative field. If it isn't,
perhaps this is a bug in userspace nfs tools?

The failure in this was if nfs-server starts exactly 3s after bootup,
boot.tv_sec would be 3 and thus get_expiry() returns 0, causing a
failure to be returned.
>
> NeilBrown
>
> > In order to get the absolute time of seconds since boot that the given
> > message will expire, the right thing is to add seconds_since_boot()
> > to the given relative value.
> >
> > Previously this logic was subtracting boot.tv_sec from the relative
> > value, which was causing some confusing behavior. The return type of
> > time64_t could possibly underflow if time since boot is greater than
> > the passed in relative argument. Also several checks in nfs code compar=
e
> > the return value to 0 to indicate failure, and this could spuriously
> > be tripped if seconds since boot happened to match the argument.
> >
> > Fixes: c5b29f885afe ("sunrpc: use seconds since boot in expiry cache")
> > Signed-off-by: Jerry Zhang <Jerry@skydio.com>
> > ---
> >  include/linux/sunrpc/cache.h | 4 +---
> >  1 file changed, 1 insertion(+), 3 deletions(-)
> >
> > diff --git a/include/linux/sunrpc/cache.h b/include/linux/sunrpc/cache.=
h
> > index ec5a555df96f..b96b1319c93d 100644
> > --- a/include/linux/sunrpc/cache.h
> > +++ b/include/linux/sunrpc/cache.h
> > @@ -301,16 +301,14 @@ static inline int get_time(char **bpp, time64_t *=
time)
> >  }
> >
> >  static inline time64_t get_expiry(char **bpp)
> >  {
> >       time64_t rv;
> > -     struct timespec64 boot;
> >
> >       if (get_time(bpp, &rv))
> >               return 0;
> >       if (rv < 0)
> >               return 0;
> > -     getboottime64(&boot);
> > -     return rv - boot.tv_sec;
> > +     return rv + seconds_since_boot();
> >  }
> >
> >  #endif /*  _LINUX_SUNRPC_CACHE_H_ */
> > --
> > 2.37.3
> >
> >
>