| Message ID | 6809750d3e746fb0732995bb9a0c1fa846bbd486.camel@hammerspace.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | [GIT,PULL] Please pull NFS client changes for 5.14 | expand |
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
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.
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
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!
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