[GIT PULL] Please pull NFS client changes for 5.14

[GIT PULL] Please pull NFS client changes for 5.14

[Trond Myklebust]

Hi Linus,

The following changes since commit 009c9aa5be652675a06d5211e1640e02bbb1c33d:

  Linux 5.13-rc6 (2021-06-13 14:43:10 -0700)

are available in the Git repository at:

  git://git.linux-nfs.org/projects/trondmy/linux-nfs.git tags/nfs-for-5.14-1

for you to fetch changes up to 878b3dfc42c4ddbf9e38cd9061e3ddd99a69747a:

  Merge part 2 of branch 'sysfs-devel' (2021-07-08 14:03:26 -0400)

Please note that this branch was rebased today. The reason was I discovered
that one of the topic branches that was merged contained some duplicated patches
from the main branch (mea culpa). So the rebase simply removed those duplicates
from the topic branch.

Thanks
   Trond

----------------------------------------------------------------
NFS client updates for Linux 5.14

Highlights include:

Stable fixes:
- Two sunrpc fixes for deadlocks involving privileged rpc_wait_queues

Bugfixes
- SUNRPC: Avoid a KASAN slab-out-of-bounds bug in xdr_set_page_base()
- SUNRPC: prevent port reuse on transports which don't request it.
- NFSv3: Fix memory leak in posix_acl_create()
- NFS: Various fixes to attribute revalidation timeouts
- NFSv4: Fix handling of non-atomic change attribute updates
- NFSv4: If a server is down, don't cause mounts to other servers to
  hang as well
- pNFS: Fix an Oops in pnfs_mark_request_commit() when doing O_DIRECT
- NFS: Fix mount failures due to incorrect setting of the has_sec_mnt_opts
  filesystem flag
 - NFS: Ensure nfs_readpage returns promptly when an internal error occurs
 - NFS: Fix fscache read from NFS after cache error
 - pNFS: Various bugfixes around the LAYOUTGET operation

Features
- Multiple patches to add support for fcntl() leases over NFSv4.
- A sysfs interface to display more information about the various
  transport connections used by the RPC client
- A sysfs interface to allow a suitably privileged user to offline a
  transport that may no longer point to a valid server
- A sysfs interface to allow a suitably privileged user to change the
  server IP address used by the RPC client

----------------------------------------------------------------
Anna Schumaker (1):
      sunrpc: Avoid a KASAN slab-out-of-bounds bug in xdr_set_page_base()

Colin Ian King (1):
      rpc: remove redundant initialization of variable status

Dave Wysochanski (3):
      NFS: Remove unnecessary inode parameter from nfs_pageio_complete_read()
      NFS: Ensure nfs_readpage returns promptly when internal error occurs
      NFS: Fix fscache read from NFS after cache error

Gao Xiang (1):
      nfs: fix acl memory leak of posix_acl_create()

NeilBrown (1):
      SUNRPC: prevent port reuse on transports which don't request it.

Olga Kornievskaia (21):
      sunrpc: Create a sunrpc directory under /sys/kernel/
      sunrpc: Create a client/ subdirectory in the sunrpc sysfs
      sunrpc: Create per-rpc_clnt sysfs kobjects
      sunrpc: add xprt id
      sunrpc: add IDs to multipath
      sunrpc: keep track of the xprt_class in rpc_xprt structure
      sunrpc: add xprt_switch direcotry to sunrpc's sysfs
      sunrpc: add a symlink from rpc-client directory to the xprt_switch
      sunrpc: add add sysfs directory per xprt under each xprt_switch
      SUNRPC mark the first transport
      SUNRPC display xprt's main value in sysfs's xprt_info
      SUNRPC query transport's source port
      SUNRPC for TCP display xprt's source port in sysfs xprt_info
      sunrpc: add dst_attr attributes to the sysfs xprt directory
      SUNRPC: take a xprt offline using sysfs
      sunrpc: provide transport info in the sysfs directory
      NFSv4.1 identify and mark RPC tasks that can move between transports
      sunrpc: provide multipath info in the sysfs directory
      sunrpc: display xprt's queuelen of assigned tasks via sysfs
      sunrpc: provide showing transport's state info in the sysfs directory
      sunrpc: remove an offlined xprt using sysfs

Scott Mayhew (1):
      nfs: update has_sec_mnt_opts after cloning lsm options from parent

Trond Myklebust (18):
      NFSv4: Fix delegation return in cases where we have to retry
      NFSv4: Add lease breakpoints in case of a delegation recall or return
      NFSv4: Add support for application leases underpinned by a delegation
      NFSv4: Initialise connection to the server in nfs4_alloc_client()
      NFSv4: Fix an Oops in pnfs_mark_request_commit() when doing O_DIRECT
      NFS: Fix up inode attribute revalidation timeouts
      NFSv4: Fix handling of non-atomic change attrbute updates
      NFS: Avoid duplicate resets of attribute cache timeouts
      NFS: nfs_find_open_context() may only select open files
      NFSv4: setlease should return EAGAIN if locks are not available
      Merge branch 'leases-devel'
      Merge branch 'sysfs-devel'
      NFSv4/pnfs: Fix the layout barrier update
      NFSv4/pnfs: Fix layoutget behaviour after invalidation
      NFSv4/pnfs: Clean up layout get on open
      NFSv4/pNFS: Don't call _nfs4_pnfs_v3_ds_connect multiple times
      NFSv4/pNFS: Return an error if _nfs4_pnfs_v3_ds_connect can't load NFSv3
      Merge part 2 of branch 'sysfs-devel'

Zhang Xiaoxu (2):
      SUNRPC: Fix the batch tasks count wraparound.
      SUNRPC: Should wake up the privileged task firstly.

 fs/nfs/delegation.c                  |  94 ++++--
 fs/nfs/delegation.h                  |   1 +
 fs/nfs/direct.c                      |  17 +-
 fs/nfs/fscache.c                     |  18 +-
 fs/nfs/getroot.c                     |  12 +-
 fs/nfs/inode.c                       |  61 ++--
 fs/nfs/nfs3proc.c                    |   4 +-
 fs/nfs/nfs4_fs.h                     |   4 +-
 fs/nfs/nfs4client.c                  |  82 ++---
 fs/nfs/nfs4file.c                    |   8 +-
 fs/nfs/nfs4proc.c                    | 114 +++++--
 fs/nfs/pagelist.c                    |   8 +-
 fs/nfs/pnfs.c                        |  68 ++--
 fs/nfs/pnfs_nfs.c                    |  54 ++--
 fs/nfs/read.c                        |  20 +-
 fs/nfs/write.c                       |   6 +-
 include/linux/nfs_fs.h               |   1 +
 include/linux/nfs_xdr.h              |   1 +
 include/linux/sunrpc/clnt.h          |   2 +
 include/linux/sunrpc/sched.h         |   2 +
 include/linux/sunrpc/xprt.h          |  10 +
 include/linux/sunrpc/xprtmultipath.h |   6 +
 include/linux/sunrpc/xprtsock.h      |   1 +
 net/sunrpc/Makefile                  |   2 +-
 net/sunrpc/auth_gss/svcauth_gss.c    |   2 +-
 net/sunrpc/clnt.c                    |  30 ++
 net/sunrpc/sched.c                   |  12 +-
 net/sunrpc/sunrpc_syms.c             |  10 +
 net/sunrpc/sysfs.c                   | 588 +++++++++++++++++++++++++++++++++++
 net/sunrpc/sysfs.h                   |  42 +++
 net/sunrpc/xdr.c                     |   7 +-
 net/sunrpc/xprt.c                    |  30 +-
 net/sunrpc/xprtmultipath.c           |  38 ++-
 net/sunrpc/xprtrdma/transport.c      |   2 +
 net/sunrpc/xprtsock.c                |  19 +-
 35 files changed, 1141 insertions(+), 235 deletions(-)
 create mode 100644 net/sunrpc/sysfs.c
 create mode 100644 net/sunrpc/sysfs.h

-- 
Trond Myklebust
Linux NFS client maintainer, Hammerspace
trond.myklebust@hammerspace.com

Re: [GIT PULL] Please pull NFS client changes for 5.14

[Linus Torvalds]

On Thu, Jul 8, 2021 at 11:16 AM Trond Myklebust <trondmy@hammerspace.com> wrote:
>
> Please note that this branch was rebased today. The reason was I discovered
> that one of the topic branches that was merged contained some duplicated patches
> from the main branch (mea culpa). So the rebase simply removed those duplicates
> from the topic branch.

Please don't rebase just for pointless details like this.

Duplicate patches aren't a problem, and we have them all the time.

Yes, they can cause annoying merge conflicts (not on their own -
identical patches will merge just fine - but if there are then *other*
changes to the same area). But it's seldom all that big of a deal, and
if there's just a couple of duplicates, then rebasing is much _worse_
than the fix.

If there were *tons* of duplicate patches, and you have some workflow
issue, that's one thing - and then you need to fix the workflow. But
particularly for just a couple of patches, rebasing and losing all the
testing is really entirely the wrong thing to do.

In other words: only rebase for *catastrophic* stuff. Only yo fix
things that are actively broken. Not for some minor technical issue.

I've pulled this, but please avoid this in the future.

               Linus

Re: [GIT PULL] Please pull NFS client changes for 5.14

[Trond Myklebust]

On Fri, 2021-07-09 at 09:51 -0700, Linus Torvalds wrote:
> On Thu, Jul 8, 2021 at 11:16 AM Trond Myklebust
> <trondmy@hammerspace.com> wrote:
> > 
> > Please note that this branch was rebased today. The reason was I
> > discovered
> > that one of the topic branches that was merged contained some
> > duplicated patches
> > from the main branch (mea culpa). So the rebase simply removed
> > those duplicates
> > from the topic branch.
> 
> Please don't rebase just for pointless details like this.
> 
> Duplicate patches aren't a problem, and we have them all the time.
> 
> Yes, they can cause annoying merge conflicts (not on their own -
> identical patches will merge just fine - but if there are then
> *other*
> changes to the same area). But it's seldom all that big of a deal,
> and
> if there's just a couple of duplicates, then rebasing is much _worse_
> than the fix.
> 
> If there were *tons* of duplicate patches, and you have some workflow
> issue, that's one thing - and then you need to fix the workflow. But
> particularly for just a couple of patches, rebasing and losing all
> the
> testing is really entirely the wrong thing to do.
> 
> In other words: only rebase for *catastrophic* stuff. Only yo fix
> things that are actively broken. Not for some minor technical issue.
> 
> I've pulled this, but please avoid this in the future.
> 
>                Linus

Thanks! It didn't result in any overall code changes or even changes to
the result of the merges. However if you're OK with the occasional
duplicate patch then I'll make sure to avoid this in the future.

-- 
Trond Myklebust
Linux NFS client maintainer, Hammerspace
trond.myklebust@hammerspace.com

Re: [GIT PULL] Please pull NFS client changes for 5.14

[Linus Torvalds]

On Fri, Jul 9, 2021 at 9:55 AM Trond Myklebust <trondmy@hammerspace.com> wrote:
>
> Thanks! It didn't result in any overall code changes or even changes to
> the result of the merges. However if you're OK with the occasional
> duplicate patch then I'll make sure to avoid this in the future.

The occasional duplicate patch is actually completely normal.

Particularly when it is something like an important fix that gets
pushed to mainline late in the -rc series: people often want them in
their development trees as well for testing, and so you end up with
the same fix both in mainline and in the "for next merge window"
branch.

In fact, that "important fix that goes to both branches" can be a very
good thing, exactly because you want to test that -next branch, and
you want to do it without having to worry about old bugs that might
trigger or hide new issues.

And then I very much want to pull that _tested_ development branch,
not some "ok, I removed that fix from the branch before asking Linus
to pull, because it's already in his tree".

See?

And yes, sometimes they happen by mistake, and the duplication is not
intentional, and it's not some "good thing". It happens just because
the same patch was sent two different ways.

That's fine too.

It's a problem if they happen a _lot_ - partly because they do make it
much more likely to cause pointless merge conflicts (and mistakes can
happen during that stage), but even more because it shows that
something is going wrong in the patch management, and people are
stepping on each other's feet.

So then the duplicate patches is not necessarily a _technical_
problem, but it's indicative that something is wrong with patch flow.

But even then removing the duplicate patches is generally less
important than trying to fix the maintenance issue.

So on the whole, a couple of duplicate patches isn't a big deal, and
not worth rebasing.

Aim to keep rebasing mainly for "oh, keeping that will cause actual
problems" (and sometimes the "actual problems" can be about things
like truly horribly mangled commit messages and wrong attribution
etc).

So rebasing isn't necessarily always "wrong", but it just needs to
have a fairly compelling reason.

              Linus

Re: [GIT PULL] Please pull NFS client changes for 5.14

[pr-tracker-bot]

The pull request you sent on Thu, 8 Jul 2021 18:16:06 +0000:

> git://git.linux-nfs.org/projects/trondmy/linux-nfs.git tags/nfs-for-5.14-1

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/96890bc2eaa1f6bfc1b194e0f0815a10824352a4

Thank you!

-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/prtracker.html