Message ID | CAFX2Jf=8s+rrwgGxm1FsaPUvEHygLFaUCNeFh989v4MXmLJFSg@mail.gmail.com (mailing list archive) |
---|---|
State | New, archived |
Headers | show |
Series | [GIT,PULL] Please pull NFS Client Updates for 5.17 | expand |
Hi Linus, On Wed, Jan 19, 2022 at 3:47 PM Anna Schumaker <anna.schumaker@netapp.com> wrote: > > Hi Linus, > > The following changes since commit c9e6606c7fe92b50a02ce51dda82586ebdf99b48: > > Linux 5.16-rc8 (2022-01-02 14:23:25 -0800) > > are available in the Git repository at: > > git://git.linux-nfs.org/projects/anna/linux-nfs.git tags/nfs-for-5.17-1 > > for you to fetch changes up to aed28b7a2d620cb5cd0c554cb889075c02e25e8e: > > SUNRPC: Don't dereference xprt->snd_task if it's a cookie > (2022-01-14 10:37:00 -0500) I just wanted to make sure you saw my pull request since we're getting towards the end of the week. I remember last year there was some issue where the mailer didn't deliver it to you, so I'm worried that's happened again. Anna > > ---------------------------------------------------------------- > - New Features: > - Basic handling for case insensitive filesystems > - Initial support for fs_locations and server trunking > > - Bugfixes and Cleanups: > - Cleanups to how the "struct cred *" is handled for the nfs_access_entry > - Ensure the server has an up to date ctimes before hardlinking or renaming > - Update 'blocks used' after writeback, fallocate, and clone > - nfs_atomic_open() fixes > - Improvements to sunrpc tracing > - Various null check & indenting related cleanups > - Some improvements to the sunrpc sysfs code > - Use default_groups in kobj_type > - Fix some potential races and reference leaks > - A few tracepoint cleanups in xprtrdma > > I had to drop a few patches at the end of last week when some last > minute objections came in, but everything else should be ready. > > Thanks, > Anna > ---------------------------------------------------------------- > Anna Schumaker (1): > sunrpc: Fix potential race conditions in rpc_sysfs_xprt_state_change() > > Chuck Lever (3): > xprtrdma: Remove final dprintk call sites from xprtrdma > xprtrdma: Remove definitions of RPCDBG_FACILITY > SUNRPC: Don't dereference xprt->snd_task if it's a cookie > > Greg Kroah-Hartman (2): > NFS: use default_groups in kobj_type > SUNRPC: use default_groups in kobj_type > > Gustavo A. R. Silva (1): > nfs41: pnfs: filelayout: Replace one-element array with > flexible-array member > > Jiapeng Chong (1): > SUNRPC: clean up some inconsistent indenting > > NeilBrown (3): > NFS: change nfs_access_get_cached to only report the mask > NFS: pass cred explicitly for access tests > NFS: don't store 'struct cred *' in struct nfs_access_entry > > Olga Kornievskaia (8): > NFSv4 only print the label when its queried > NFSv4 remove zero number of fs_locations entries error check > NFSv4 store server support for fs_location attribute > NFSv4.1 query for fs_location attr on a new file system > NFSv4 expose nfs_parse_server_name function > NFSv4 handle port presence in fs_location server string > SUNRPC allow for unspecified transport time in rpc_clnt_add_xprt > NFSv4.1 test and add 4.1 trunking transport > > Pierguido Lambri (1): > SUNRPC: Add source address/port to rpc_socket* traces > > Trond Myklebust (12): > NFS: Ensure the server has an up to date ctime before hardlinking > NFS: Ensure the server has an up to date ctime before renaming > NFSv4.1: Fix uninitialised variable in devicenotify > NFSv4: Add some support for case insensitive filesystems > NFSv4: Just don't cache negative dentries on case insensitive servers > NFS: Invalidate negative dentries on all case insensitive > directory changes > NFS: Add a helper to remove case-insensitive aliases > NFS: Fix the verifier for case sensitive filesystem in nfs_atomic_open() > NFSv4: Allow writebacks to request 'blocks used' > NFSv42: Fallocate and clone should also request 'blocks used' > NFSv4: Handle case where the lookup of a directory fails > NFSv4: nfs_atomic_open() can race when looking up a non-regular file > > Xiaoke Wang (1): > nfs: nfs4clinet: check the return value of kstrdup() > > Xiyu Yang (1): > net/sunrpc: fix reference count leaks in rpc_sysfs_xprt_state_change > > Xu Wang (1): > sunrpc: Remove unneeded null check > > fs/nfs/callback.h | 2 +- > fs/nfs/callback_proc.c | 2 +- > fs/nfs/callback_xdr.c | 22 +++++++++++----------- > fs/nfs/client.c | 7 +++++++ > fs/nfs/dir.c | 146 > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++---------------------------- > fs/nfs/filelayout/filelayout.h | 2 +- > fs/nfs/filelayout/filelayoutdev.c | 4 +--- > fs/nfs/internal.h | 1 + > fs/nfs/nfs3proc.c | 5 +++-- > fs/nfs/nfs42proc.c | 13 ++++++++----- > fs/nfs/nfs4_fs.h | 14 +++++++++----- > fs/nfs/nfs4client.c | 5 ++++- > fs/nfs/nfs4namespace.c | 19 ++++++++++++------- > fs/nfs/nfs4proc.c | 197 > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++----------------------------------------- > fs/nfs/nfs4state.c | 6 +++++- > fs/nfs/nfs4xdr.c | 49 > ++++++++++++++++++++++++++++++++++++++++++++----- > fs/nfs/sysfs.c | 3 ++- > include/linux/nfs_fs.h | 10 ++++++---- > include/linux/nfs_fs_sb.h | 4 +++- > include/linux/nfs_xdr.h | 5 ++++- > include/trace/events/sunrpc.h | 70 > +++++++++++++++++++++++++++++++++++++++++++++------------------------- > net/sunrpc/auth_gss/gss_generic_token.c | 6 ++---- > net/sunrpc/clnt.c | 5 ++++- > net/sunrpc/sysfs.c | 47 > +++++++++++++++++++++++++++-------------------- > net/sunrpc/xprtrdma/backchannel.c | 4 ---- > net/sunrpc/xprtrdma/frwr_ops.c | 4 ---- > net/sunrpc/xprtrdma/rpc_rdma.c | 4 ---- > net/sunrpc/xprtrdma/transport.c | 4 ---- > net/sunrpc/xprtrdma/verbs.c | 23 ----------------------- > net/sunrpc/xprtsock.c | 2 +- > 30 files changed, 476 insertions(+), 209 deletions(-)
Hi Linus, On Fri, Jan 21, 2022 at 1:34 PM Anna Schumaker <anna.schumaker@netapp.com> wrote: > > Hi Linus, > > On Wed, Jan 19, 2022 at 3:47 PM Anna Schumaker > <anna.schumaker@netapp.com> wrote: > > > > Hi Linus, > > > > The following changes since commit c9e6606c7fe92b50a02ce51dda82586ebdf99b48: > > > > Linux 5.16-rc8 (2022-01-02 14:23:25 -0800) > > > > are available in the Git repository at: > > > > git://git.linux-nfs.org/projects/anna/linux-nfs.git tags/nfs-for-5.17-1 > > > > for you to fetch changes up to aed28b7a2d620cb5cd0c554cb889075c02e25e8e: > > > > SUNRPC: Don't dereference xprt->snd_task if it's a cookie > > (2022-01-14 10:37:00 -0500) > > I just wanted to make sure you saw my pull request since we're getting > towards the end of the week. I remember last year there was some issue > where the mailer didn't deliver it to you, so I'm worried that's > happened again. I'm still not seeing this in your tree. Was there something wrong with the pull request? What can I do to fix it? Anna > > Anna > > > > ---------------------------------------------------------------- > > - New Features: > > - Basic handling for case insensitive filesystems > > - Initial support for fs_locations and server trunking > > > > - Bugfixes and Cleanups: > > - Cleanups to how the "struct cred *" is handled for the nfs_access_entry > > - Ensure the server has an up to date ctimes before hardlinking or renaming > > - Update 'blocks used' after writeback, fallocate, and clone > > - nfs_atomic_open() fixes > > - Improvements to sunrpc tracing > > - Various null check & indenting related cleanups > > - Some improvements to the sunrpc sysfs code > > - Use default_groups in kobj_type > > - Fix some potential races and reference leaks > > - A few tracepoint cleanups in xprtrdma > > > > I had to drop a few patches at the end of last week when some last > > minute objections came in, but everything else should be ready. > > > > Thanks, > > Anna > > ---------------------------------------------------------------- > > Anna Schumaker (1): > > sunrpc: Fix potential race conditions in rpc_sysfs_xprt_state_change() > > > > Chuck Lever (3): > > xprtrdma: Remove final dprintk call sites from xprtrdma > > xprtrdma: Remove definitions of RPCDBG_FACILITY > > SUNRPC: Don't dereference xprt->snd_task if it's a cookie > > > > Greg Kroah-Hartman (2): > > NFS: use default_groups in kobj_type > > SUNRPC: use default_groups in kobj_type > > > > Gustavo A. R. Silva (1): > > nfs41: pnfs: filelayout: Replace one-element array with > > flexible-array member > > > > Jiapeng Chong (1): > > SUNRPC: clean up some inconsistent indenting > > > > NeilBrown (3): > > NFS: change nfs_access_get_cached to only report the mask > > NFS: pass cred explicitly for access tests > > NFS: don't store 'struct cred *' in struct nfs_access_entry > > > > Olga Kornievskaia (8): > > NFSv4 only print the label when its queried > > NFSv4 remove zero number of fs_locations entries error check > > NFSv4 store server support for fs_location attribute > > NFSv4.1 query for fs_location attr on a new file system > > NFSv4 expose nfs_parse_server_name function > > NFSv4 handle port presence in fs_location server string > > SUNRPC allow for unspecified transport time in rpc_clnt_add_xprt > > NFSv4.1 test and add 4.1 trunking transport > > > > Pierguido Lambri (1): > > SUNRPC: Add source address/port to rpc_socket* traces > > > > Trond Myklebust (12): > > NFS: Ensure the server has an up to date ctime before hardlinking > > NFS: Ensure the server has an up to date ctime before renaming > > NFSv4.1: Fix uninitialised variable in devicenotify > > NFSv4: Add some support for case insensitive filesystems > > NFSv4: Just don't cache negative dentries on case insensitive servers > > NFS: Invalidate negative dentries on all case insensitive > > directory changes > > NFS: Add a helper to remove case-insensitive aliases > > NFS: Fix the verifier for case sensitive filesystem in nfs_atomic_open() > > NFSv4: Allow writebacks to request 'blocks used' > > NFSv42: Fallocate and clone should also request 'blocks used' > > NFSv4: Handle case where the lookup of a directory fails > > NFSv4: nfs_atomic_open() can race when looking up a non-regular file > > > > Xiaoke Wang (1): > > nfs: nfs4clinet: check the return value of kstrdup() > > > > Xiyu Yang (1): > > net/sunrpc: fix reference count leaks in rpc_sysfs_xprt_state_change > > > > Xu Wang (1): > > sunrpc: Remove unneeded null check > > > > fs/nfs/callback.h | 2 +- > > fs/nfs/callback_proc.c | 2 +- > > fs/nfs/callback_xdr.c | 22 +++++++++++----------- > > fs/nfs/client.c | 7 +++++++ > > fs/nfs/dir.c | 146 > > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++---------------------------- > > fs/nfs/filelayout/filelayout.h | 2 +- > > fs/nfs/filelayout/filelayoutdev.c | 4 +--- > > fs/nfs/internal.h | 1 + > > fs/nfs/nfs3proc.c | 5 +++-- > > fs/nfs/nfs42proc.c | 13 ++++++++----- > > fs/nfs/nfs4_fs.h | 14 +++++++++----- > > fs/nfs/nfs4client.c | 5 ++++- > > fs/nfs/nfs4namespace.c | 19 ++++++++++++------- > > fs/nfs/nfs4proc.c | 197 > > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++----------------------------------------- > > fs/nfs/nfs4state.c | 6 +++++- > > fs/nfs/nfs4xdr.c | 49 > > ++++++++++++++++++++++++++++++++++++++++++++----- > > fs/nfs/sysfs.c | 3 ++- > > include/linux/nfs_fs.h | 10 ++++++---- > > include/linux/nfs_fs_sb.h | 4 +++- > > include/linux/nfs_xdr.h | 5 ++++- > > include/trace/events/sunrpc.h | 70 > > +++++++++++++++++++++++++++++++++++++++++++++------------------------- > > net/sunrpc/auth_gss/gss_generic_token.c | 6 ++---- > > net/sunrpc/clnt.c | 5 ++++- > > net/sunrpc/sysfs.c | 47 > > +++++++++++++++++++++++++++-------------------- > > net/sunrpc/xprtrdma/backchannel.c | 4 ---- > > net/sunrpc/xprtrdma/frwr_ops.c | 4 ---- > > net/sunrpc/xprtrdma/rpc_rdma.c | 4 ---- > > net/sunrpc/xprtrdma/transport.c | 4 ---- > > net/sunrpc/xprtrdma/verbs.c | 23 ----------------------- > > net/sunrpc/xprtsock.c | 2 +- > > 30 files changed, 476 insertions(+), 209 deletions(-)
On Tue, Jan 25, 2022 at 8:01 PM Anna Schumaker <anna.schumaker@netapp.com> wrote: > > I'm still not seeing this in your tree. Was there something wrong with > the pull request? What can I do to fix it? Hmm. It looks like these were all caught in the gmail spam filter, and while I go look at my spam folder regularly, I don't exactly go through it with a fine comb. If nothing stands out to me, it all goes into the great big bit-bucket in the sky. And the reason gmail considers it spam seems to be that your email is misconfigured. You have a "from:" field using netapp.com, but you don't seem to use the proper netapp smtp server, so you don't get the netapp DKIM signature, resulting in dmarc=fail (p=QUARANTINE sp=QUARANTINE dis=QUARANTINE) header.from=netapp.com and that's quite the spam-trigger. In fact, from the headers it looks like you're using gmail to deliver the email using your schumakeranna@gmail.com gmail account, but then you have that "From:" having that "netapp.com" from address. Naughty, naughty. Even if gmail receives it, gmail will then notice that the from address has been faked, and will not deliver it to me. That whole "send email using another delivery thing than the one you claim it is from" is how most spam is sent, and it used to work. It doesn't work any more in a world where people actually check DKIM information, and netapp.com does have DKIM enabled. So you have to use the real netapp SMPT server if you send emails that claim to come from netapp. You could just use your actual normal gmail.com address - that works fine, and I'll see the signed tag, and the kernel.org address, and I'll trust it that way. Linus
The pull request you sent on Wed, 19 Jan 2022 15:47:05 -0500:
> git://git.linux-nfs.org/projects/anna/linux-nfs.git tags/nfs-for-5.17-1
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/0280e3c58f92b2fe0e8fbbdf8d386449168de4a8
Thank you!
Hi Linus, > From: Linus Torvalds <torvalds@linux-foundation.org> > Sent: Tuesday, January 25, 2022 1:23 PM > To: Schumaker, Anna <Anna.Schumaker@netapp.com> > Cc: Linux NFS Mailing List <linux-nfs@vger.kernel.org> > Subject: Re: [GIT PULL] Please pull NFS Client Updates for 5.17 > > NetApp Security WARNING: This is an external email. Do not click links or open attachments unless you recognize the sender and know the content is safe. > > > > > On Tue, Jan 25, 2022 at 8:01 PM Anna Schumaker > <anna.schumaker@netapp.com> wrote: > > > > I'm still not seeing this in your tree. Was there something wrong with > > the pull request? What can I do to fix it? > > Hmm. It looks like these were all caught in the gmail spam filter, and > while I go look at my spam folder regularly, I don't exactly go > through it with a fine comb. If nothing stands out to me, it all goes > into the great big bit-bucket in the sky. > > And the reason gmail considers it spam seems to be that your email is > misconfigured. You have a "from:" field using netapp.com, but you > don't seem to use the proper netapp smtp server, so you don't get the > netapp DKIM signature, resulting in > > dmarc=fail (p=QUARANTINE sp=QUARANTINE dis=QUARANTINE) > header.from=netapp.com > > and that's quite the spam-trigger. > > In fact, from the headers it looks like you're using gmail to deliver > the email using your schumakeranna@gmail.com gmail account, but then > you have that "From:" having that "netapp.com" from address. Naughty, > naughty. > > Even if gmail receives it, gmail will then notice that the from > address has been faked, and will not deliver it to me. > > That whole "send email using another delivery thing than the one you > claim it is from" is how most spam is sent, and it used to work. It > doesn't work any more in a world where people actually check DKIM > information, and netapp.com does have DKIM enabled. I hadn't heard of DKIM before, so thanks for educating me! I've deleted my netapp email from my gmail's "send email as" list so I won't make this mistake again in the future and I'll just send from my gmail directly. I hoped it would would be as easy way to make it look as if it came from my work email without needing to deal with the web version of outlook (which I don't trust at all to send email properly). Thank you so much for still pulling it! Anna > > So you have to use the real netapp SMPT server if you send emails that > claim to come from netapp. > > You could just use your actual normal gmail.com address - that works > fine, and I'll see the signed tag, and the kernel.org address, and > I'll trust it that way. > > Linus