<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel.git/fs/nfs, branch linux-5.3.y</title>
<subtitle>Hosts the 0x221E linux distro kernel.
</subtitle>
<id>https://git.0xinfinity.dev/distro/kernel.git/atom?h=linux-5.3.y</id>
<link rel='self' href='https://git.0xinfinity.dev/distro/kernel.git/atom?h=linux-5.3.y'/>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/'/>
<updated>2019-11-12T18:28:18Z</updated>
<entry>
<title>NFSv4: Don't allow a cached open with a revoked delegation</title>
<updated>2019-11-12T18:28:18Z</updated>
<author>
<name>Trond Myklebust</name>
</author>
<published>2019-10-31T22:40:32Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=5beaffd786a5cb964a52309b4377aed5a496b7b4'/>
<id>urn:sha1:5beaffd786a5cb964a52309b4377aed5a496b7b4</id>
<content type='text'>
[ Upstream commit be3df3dd4c70ee020587a943a31b98a0fb4b6424 ]

If the delegation is marked as being revoked, we must not use it
for cached opens.

Fixes: 869f9dfa4d6d ("NFSv4: Fix races between nfs_remove_bad_delegation() and delegation return")
Signed-off-by: Trond Myklebust &lt;trond.myklebust@hammerspace.com&gt;
Signed-off-by: Anna Schumaker &lt;Anna.Schumaker@Netapp.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>NFS: Fix an RCU lock leak in nfs4_refresh_delegation_stateid()</title>
<updated>2019-11-06T12:09:24Z</updated>
<author>
<name>Trond Myklebust</name>
</author>
<published>2019-10-31T22:40:33Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=b60ec67f67f6cb034a1b8ee00573c6edd7f153a7'/>
<id>urn:sha1:b60ec67f67f6cb034a1b8ee00573c6edd7f153a7</id>
<content type='text'>
commit 79cc55422ce99be5964bde208ba8557174720893 upstream.

A typo in nfs4_refresh_delegation_stateid() means we're leaking an
RCU lock, and always returning a value of 'false'. As the function
description states, we were always supposed to return 'true' if a
matching delegation was found.

Fixes: 12f275cdd163 ("NFSv4: Retry CLOSE and DELEGRETURN on NFS4ERR_OLD_STATEID.")
Cc: stable@vger.kernel.org # v4.15+
Signed-off-by: Trond Myklebust &lt;trond.myklebust@hammerspace.com&gt;
Signed-off-by: Anna Schumaker &lt;Anna.Schumaker@Netapp.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>NFSv4: Fix leak of clp-&gt;cl_acceptor string</title>
<updated>2019-11-06T12:08:45Z</updated>
<author>
<name>Chuck Lever</name>
</author>
<published>2019-10-04T13:58:54Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=fd51ff093de45f54052ba65b90886a2868779fc5'/>
<id>urn:sha1:fd51ff093de45f54052ba65b90886a2868779fc5</id>
<content type='text'>
[ Upstream commit 1047ec868332034d1fbcb2fae19fe6d4cb869ff2 ]

Our client can issue multiple SETCLIENTID operations to the same
server in some circumstances. Ensure that calls to
nfs4_proc_setclientid() after the first one do not overwrite the
previously allocated cl_acceptor string.

unreferenced object 0xffff888461031800 (size 32):
  comm "mount.nfs", pid 2227, jiffies 4294822467 (age 1407.749s)
  hex dump (first 32 bytes):
    6e 66 73 40 6b 6c 69 6d 74 2e 69 62 2e 31 30 31  nfs@klimt.ib.101
    35 67 72 61 6e 67 65 72 2e 6e 65 74 00 00 00 00  5granger.net....
  backtrace:
    [&lt;00000000ab820188&gt;] __kmalloc+0x128/0x176
    [&lt;00000000eeaf4ec8&gt;] gss_stringify_acceptor+0xbd/0x1a7 [auth_rpcgss]
    [&lt;00000000e85e3382&gt;] nfs4_proc_setclientid+0x34e/0x46c [nfsv4]
    [&lt;000000003d9cf1fa&gt;] nfs40_discover_server_trunking+0x7a/0xed [nfsv4]
    [&lt;00000000b81c3787&gt;] nfs4_discover_server_trunking+0x81/0x244 [nfsv4]
    [&lt;000000000801b55f&gt;] nfs4_init_client+0x1b0/0x238 [nfsv4]
    [&lt;00000000977daf7f&gt;] nfs4_set_client+0xfe/0x14d [nfsv4]
    [&lt;0000000053a68a2a&gt;] nfs4_create_server+0x107/0x1db [nfsv4]
    [&lt;0000000088262019&gt;] nfs4_remote_mount+0x2c/0x59 [nfsv4]
    [&lt;00000000e84a2fd0&gt;] legacy_get_tree+0x2d/0x4c
    [&lt;00000000797e947c&gt;] vfs_get_tree+0x20/0xc7
    [&lt;00000000ecabaaa8&gt;] fc_mount+0xe/0x36
    [&lt;00000000f15fafc2&gt;] vfs_kern_mount+0x74/0x8d
    [&lt;00000000a3ff4e26&gt;] nfs_do_root_mount+0x8a/0xa3 [nfsv4]
    [&lt;00000000d1c2b337&gt;] nfs4_try_mount+0x58/0xad [nfsv4]
    [&lt;000000004c9bddee&gt;] nfs_fs_mount+0x820/0x869 [nfs]

Fixes: f11b2a1cfbf5 ("nfs4: copy acceptor name from context ... ")
Signed-off-by: Chuck Lever &lt;chuck.lever@oracle.com&gt;
Signed-off-by: Anna Schumaker &lt;Anna.Schumaker@Netapp.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>nfs: Fix nfsi-&gt;nrequests count error on nfs_inode_remove_request</title>
<updated>2019-11-06T12:08:04Z</updated>
<author>
<name>ZhangXiaoxu</name>
</author>
<published>2019-09-26T06:29:38Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=7cf53aa7c03db767909beefa32143b8042837578'/>
<id>urn:sha1:7cf53aa7c03db767909beefa32143b8042837578</id>
<content type='text'>
[ Upstream commit 33ea5aaa87cdae0f9af4d6b7ee4f650a1a36fd1d ]

When xfstests testing, there are some WARNING as below:

WARNING: CPU: 0 PID: 6235 at fs/nfs/inode.c:122 nfs_clear_inode+0x9c/0xd8
Modules linked in:
CPU: 0 PID: 6235 Comm: umount.nfs
Hardware name: linux,dummy-virt (DT)
pstate: 60000005 (nZCv daif -PAN -UAO)
pc : nfs_clear_inode+0x9c/0xd8
lr : nfs_evict_inode+0x60/0x78
sp : fffffc000f68fc00
x29: fffffc000f68fc00 x28: fffffe00c53155c0
x27: fffffe00c5315000 x26: fffffc0009a63748
x25: fffffc000f68fd18 x24: fffffc000bfaaf40
x23: fffffc000936d3c0 x22: fffffe00c4ff5e20
x21: fffffc000bfaaf40 x20: fffffe00c4ff5d10
x19: fffffc000c056000 x18: 000000000000003c
x17: 0000000000000000 x16: 0000000000000000
x15: 0000000000000040 x14: 0000000000000228
x13: fffffc000c3a2000 x12: 0000000000000045
x11: 0000000000000000 x10: 0000000000000000
x9 : 0000000000000000 x8 : 0000000000000000
x7 : 0000000000000000 x6 : fffffc00084b027c
x5 : fffffc0009a64000 x4 : fffffe00c0e77400
x3 : fffffc000c0563a8 x2 : fffffffffffffffb
x1 : 000000000000764e x0 : 0000000000000001
Call trace:
 nfs_clear_inode+0x9c/0xd8
 nfs_evict_inode+0x60/0x78
 evict+0x108/0x380
 dispose_list+0x70/0xa0
 evict_inodes+0x194/0x210
 generic_shutdown_super+0xb0/0x220
 nfs_kill_super+0x40/0x88
 deactivate_locked_super+0xb4/0x120
 deactivate_super+0x144/0x160
 cleanup_mnt+0x98/0x148
 __cleanup_mnt+0x38/0x50
 task_work_run+0x114/0x160
 do_notify_resume+0x2f8/0x308
 work_pending+0x8/0x14

The nrequest should be increased/decreased only if PG_INODE_REF flag
was setted.

But in the nfs_inode_remove_request function, it maybe decrease when
no PG_INODE_REF flag, this maybe lead nrequests count error.

Reported-by: Hulk Robot &lt;hulkci@huawei.com&gt;
Signed-off-by: ZhangXiaoxu &lt;zhangxiaoxu5@huawei.com&gt;
Signed-off-by: Anna Schumaker &lt;Anna.Schumaker@Netapp.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>NFS: Fix O_DIRECT accounting of number of bytes read/written</title>
<updated>2019-10-17T20:47:26Z</updated>
<author>
<name>Trond Myklebust</name>
</author>
<published>2019-09-30T18:02:56Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=5ee51346c7cef7817cd91f91a7e04c04066db3c0'/>
<id>urn:sha1:5ee51346c7cef7817cd91f91a7e04c04066db3c0</id>
<content type='text'>
commit 031d73ed768a40684f3ca21992265ffdb6a270bf upstream.

When a series of O_DIRECT reads or writes are truncated, either due to
eof or due to an error, then we should return the number of contiguous
bytes that were received/sent starting at the offset specified by the
application.

Currently, we are failing to correctly check contiguity, and so we're
failing the generic/465 in xfstests when the race between the read
and write RPCs causes the file to get extended while the 2 reads are
outstanding. If the first read RPC call wins the race and returns with
eof set, we should treat the second read RPC as being truncated.

Reported-by: Su Yanjun &lt;suyj.fnst@cn.fujitsu.com&gt;
Fixes: 1ccbad9f9f9bd ("nfs: fix DIO good bytes calculation")
Cc: stable@vger.kernel.org # 4.1+
Signed-off-by: Trond Myklebust &lt;trond.myklebust@hammerspace.com&gt;
Signed-off-by: Anna Schumaker &lt;Anna.Schumaker@Netapp.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>pNFS: Ensure we do clear the return-on-close layout stateid on fatal errors</title>
<updated>2019-10-11T16:36:36Z</updated>
<author>
<name>Trond Myklebust</name>
</author>
<published>2019-09-20T11:23:40Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=647d64dca599b25fa8982de75ff83a4b599ab897'/>
<id>urn:sha1:647d64dca599b25fa8982de75ff83a4b599ab897</id>
<content type='text'>
[ Upstream commit 9c47b18cf722184f32148784189fca945a7d0561 ]

IF the server rejected our layout return with a state error such as
NFS4ERR_BAD_STATEID, or even a stale inode error, then we do want
to clear out all the remaining layout segments and mark that stateid
as invalid.

Fixes: 1c5bd76d17cca ("pNFS: Enable layoutreturn operation for...")
Signed-off-by: Trond Myklebust &lt;trond.myklebust@hammerspace.com&gt;
Signed-off-by: Anna Schumaker &lt;Anna.Schumaker@Netapp.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>fs: nfs: Fix possible null-pointer dereferences in encode_attrs()</title>
<updated>2019-10-11T16:36:27Z</updated>
<author>
<name>Jia-Ju Bai</name>
</author>
<published>2019-07-26T07:48:53Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=902003c34a9dc1aa9a3177224879ef402426c5a3'/>
<id>urn:sha1:902003c34a9dc1aa9a3177224879ef402426c5a3</id>
<content type='text'>
[ Upstream commit e2751463eaa6f9fec8fea80abbdc62dbc487b3c5 ]

In encode_attrs(), there is an if statement on line 1145 to check
whether label is NULL:
    if (label &amp;&amp; (attrmask[2] &amp; FATTR4_WORD2_SECURITY_LABEL))

When label is NULL, it is used on lines 1178-1181:
    *p++ = cpu_to_be32(label-&gt;lfs);
    *p++ = cpu_to_be32(label-&gt;pi);
    *p++ = cpu_to_be32(label-&gt;len);
    p = xdr_encode_opaque_fixed(p, label-&gt;label, label-&gt;len);

To fix these bugs, label is checked before being used.

These bugs are found by a static analysis tool STCheck written by us.

Signed-off-by: Jia-Ju Bai &lt;baijiaju1990@gmail.com&gt;
Signed-off-by: Anna Schumaker &lt;Anna.Schumaker@Netapp.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>NFS: Fix inode fileid checks in attribute revalidation code</title>
<updated>2019-09-02T17:10:19Z</updated>
<author>
<name>Trond Myklebust</name>
</author>
<published>2019-08-28T15:26:13Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=eb3d8f42231aec65b64b079dd17bd6c008a3fe29'/>
<id>urn:sha1:eb3d8f42231aec65b64b079dd17bd6c008a3fe29</id>
<content type='text'>
We want to throw out the attrbute if it refers to the mounted on fileid,
and not the real fileid. However we do not want to block cache consistency
updates from NFSv4 writes.

Reported-by: Murphy Zhou &lt;jencce.kernel@gmail.com&gt;
Fixes: 7e10cc25bfa0 ("NFS: Don't refresh attributes with mounted-on-file...")
Signed-off-by: Trond Myklebust &lt;trond.myklebust@hammerspace.com&gt;
</content>
</entry>
<entry>
<title>NFS: remove set but not used variable 'mapping'</title>
<updated>2019-08-27T14:24:56Z</updated>
<author>
<name>YueHaibing</name>
</author>
<published>2019-08-27T07:16:36Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=99300a85260c2b7febd57082a617d1062532067e'/>
<id>urn:sha1:99300a85260c2b7febd57082a617d1062532067e</id>
<content type='text'>
Fixes gcc '-Wunused-but-set-variable' warning:

fs/nfs/write.c: In function nfs_page_async_flush:
fs/nfs/write.c:609:24: warning: variable mapping set but not used [-Wunused-but-set-variable]

It is not use since commit aefb623c422e ("NFS: Fix
writepage(s) error handling to not report errors twice")

Reported-by: Hulk Robot &lt;hulkci@huawei.com&gt;
Signed-off-by: YueHaibing &lt;yuehaibing@huawei.com&gt;
Signed-off-by: Trond Myklebust &lt;trond.myklebust@hammerspace.com&gt;
</content>
</entry>
<entry>
<title>NFSv2: Fix write regression</title>
<updated>2019-08-27T14:24:56Z</updated>
<author>
<name>Trond Myklebust</name>
</author>
<published>2019-08-27T11:03:28Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=d33d4beb522987d1c305c12500796f9be3687dee'/>
<id>urn:sha1:d33d4beb522987d1c305c12500796f9be3687dee</id>
<content type='text'>
Ensure we update the write result count on success, since the
RPC call itself does not do so.

Reported-by: Jan Stancek &lt;jstancek@redhat.com&gt;
Reported-by: Naresh Kamboju &lt;naresh.kamboju@linaro.org&gt;
Signed-off-by: Trond Myklebust &lt;trond.myklebust@hammerspace.com&gt;
Tested-by: Jan Stancek &lt;jstancek@redhat.com&gt;
</content>
</entry>
</feed>
