<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel.git/fs/nfs/callback_proc.c, branch linux-4.19.y</title>
<subtitle>Hosts the 0x221E linux distro kernel.
</subtitle>
<id>https://git.0xinfinity.dev/distro/kernel.git/atom?h=linux-4.19.y</id>
<link rel='self' href='https://git.0xinfinity.dev/distro/kernel.git/atom?h=linux-4.19.y'/>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/'/>
<updated>2022-04-15T12:14:53Z</updated>
<entry>
<title>NFSv4/pNFS: Fix another issue with a list iterator pointing to the head</title>
<updated>2022-04-15T12:14:53Z</updated>
<author>
<name>Trond Myklebust</name>
</author>
<published>2022-03-28T12:36:34Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=f8b746f5cf7c601f8b8a59d097efb4ef24eb1b3b'/>
<id>urn:sha1:f8b746f5cf7c601f8b8a59d097efb4ef24eb1b3b</id>
<content type='text'>
[ Upstream commit 7c9d845f0612e5bcd23456a2ec43be8ac43458f1 ]

In nfs4_callback_devicenotify(), if we don't find a matching entry for
the deviceid, we're left with a pointer to 'struct nfs_server' that
actually points to the list of super blocks associated with our struct
nfs_client.
Furthermore, even if we have a valid pointer, nothing pins the super
block, and so the struct nfs_server could end up getting freed while
we're using it.

Since all we want is a pointer to the struct pnfs_layoutdriver_type,
let's skip all the iteration over super blocks, and just use APIs to
find the layout driver directly.

Reported-by: Xiaomeng Tong &lt;xiam0nd.tong@gmail.com&gt;
Fixes: 1be5683b03a7 ("pnfs: CB_NOTIFY_DEVICEID")
Signed-off-by: Trond Myklebust &lt;trond.myklebust@hammerspace.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>NFSv4.1: Fix uninitialised variable in devicenotify</title>
<updated>2022-02-16T11:51:44Z</updated>
<author>
<name>Trond Myklebust</name>
</author>
<published>2022-01-03T19:50:16Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=e6b0f9177c43ff9ad0f1a6dd3639c383373911b7'/>
<id>urn:sha1:e6b0f9177c43ff9ad0f1a6dd3639c383373911b7</id>
<content type='text'>
[ Upstream commit b05bf5c63b326ce1da84ef42498d8e0e292e694c ]

When decode_devicenotify_args() exits with no entries, we need to
ensure that the struct cb_devicenotifyargs is initialised to
{ 0, NULL } in order to avoid problems in
nfs4_callback_devicenotify().

Reported-by: &lt;rtm@csail.mit.edu&gt;
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>NFSv4/pnfs: Return valid stateids in nfs_layout_find_inode_by_stateid()</title>
<updated>2020-04-23T08:30:18Z</updated>
<author>
<name>Trond Myklebust</name>
</author>
<published>2020-02-27T16:01:12Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=401876dbcf6be94b31a957ccccb8e028e9d3d9cc'/>
<id>urn:sha1:401876dbcf6be94b31a957ccccb8e028e9d3d9cc</id>
<content type='text'>
[ Upstream commit d911c57a19551c6bef116a3b55c6b089901aacb0 ]

Make sure to test the stateid for validity so that we catch instances
where the server may have been reusing stateids in
nfs_layout_find_inode_by_stateid().

Fixes: 7b410d9ce460 ("pNFS: Delay getting the layout header in CB_LAYOUTRECALL handlers")
Signed-off-by: Trond Myklebust &lt;trond.myklebust@hammerspace.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>NFSv4.2 copy do not allocate memory under the lock</title>
<updated>2018-12-13T08:16:14Z</updated>
<author>
<name>Olga Kornievskaia</name>
</author>
<published>2018-11-21T16:24:22Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=07b92c224d5ca13aa07dd1c31908dfa19400df3e'/>
<id>urn:sha1:07b92c224d5ca13aa07dd1c31908dfa19400df3e</id>
<content type='text'>
[ Upstream commit 99f2c55591fb5c1b536263970d98c2ebc2089906 ]

Bruce pointed out that we shouldn't allocate memory while holding
a lock in the nfs4_callback_offload() and handle_async_copy()
that deal with a racing CB_OFFLOAD and reply to COPY case.

Signed-off-by: Olga Kornievskaia &lt;kolga@netapp.com&gt;
Signed-off-by: Trond Myklebust &lt;trond.myklebust@hammerspace.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>NFSv4: Fix an Oops during delegation callbacks</title>
<updated>2018-12-01T08:37:33Z</updated>
<author>
<name>Trond Myklebust</name>
</author>
<published>2018-11-13T21:37:54Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=b5ccf0038f34a5a207d9c33d8cc1e40b2faf6725'/>
<id>urn:sha1:b5ccf0038f34a5a207d9c33d8cc1e40b2faf6725</id>
<content type='text'>
[ Upstream commit e39d8a186ed002854196668cb7562ffdfbc6d379 ]

If the server sends a CB_GETATTR or a CB_RECALL while the filesystem is
being unmounted, then we can Oops when releasing the inode in
nfs4_callback_getattr() and nfs4_callback_recall().

Signed-off-by: Trond Myklebust &lt;trond.myklebust@hammerspace.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>NFSv4: Fix a sleep in atomic context in nfs4_callback_sequence()</title>
<updated>2018-08-15T16:05:15Z</updated>
<author>
<name>Trond Myklebust</name>
</author>
<published>2018-08-14T21:55:56Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=8618289c46556fd4dd259a1af02ccc448032f48d'/>
<id>urn:sha1:8618289c46556fd4dd259a1af02ccc448032f48d</id>
<content type='text'>
We must drop the lock before we can sleep in referring_call_exists().

Reported-by: Jia-Ju Bai &lt;baijiaju1990@gmail.com&gt;
Fixes: 045d2a6d076a ("NFSv4.1: Delay callback processing...")
Cc: stable@vger.kernel.org # v4.9+
Signed-off-by: Trond Myklebust &lt;trond.myklebust@hammerspace.com&gt;
Signed-off-by: Anna Schumaker &lt;Anna.Schumaker@Netapp.com&gt;
</content>
</entry>
<entry>
<title>NFS handle COPY reply CB_OFFLOAD call race</title>
<updated>2018-08-09T16:56:39Z</updated>
<author>
<name>Olga Kornievskaia</name>
</author>
<published>2018-07-09T19:13:32Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=bc0c9079b48ddcf1f8a6e1aaa277288b263c78d8'/>
<id>urn:sha1:bc0c9079b48ddcf1f8a6e1aaa277288b263c78d8</id>
<content type='text'>
It's possible that server replies back with CB_OFFLOAD call and
COPY reply at the same time such that client will process
CB_OFFLOAD before reply to COPY. For that keep a list of pending
callback stateids received and then before waiting on completion
check the pending list.

Cleanup any pending copies on the client shutdown.

Signed-off-by: Olga Kornievskaia &lt;kolga@netapp.com&gt;
Signed-off-by: Anna Schumaker &lt;Anna.Schumaker@Netapp.com&gt;
</content>
</entry>
<entry>
<title>NFS add support for asynchronous COPY</title>
<updated>2018-08-09T16:56:39Z</updated>
<author>
<name>Olga Kornievskaia</name>
</author>
<published>2018-07-09T19:13:31Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=62164f317972fcd36590578888f33a1994dda519'/>
<id>urn:sha1:62164f317972fcd36590578888f33a1994dda519</id>
<content type='text'>
Change xdr to always send COPY asynchronously.

Keep the list copies send in a list under a server structure.
Once copy is sent, it waits on a completion structure that will
be signalled by the callback thread that receives CB_OFFLOAD.

If CB_OFFLOAD returned an error and even if it returned partial
bytes, ignore them (as we can't commit without a verifier to
match) and return an error.

Signed-off-by: Olga Kornievskaia &lt;kolga@netapp.com&gt;
Signed-off-by: Anna Schumaker &lt;Anna.Schumaker@Netapp.com&gt;
</content>
</entry>
<entry>
<title>NFS CB_OFFLOAD xdr</title>
<updated>2018-08-09T16:56:38Z</updated>
<author>
<name>Olga Kornievskaia</name>
</author>
<published>2018-07-09T19:13:28Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=5178a125f6d5fb0720315ea4f7cca642fb936031'/>
<id>urn:sha1:5178a125f6d5fb0720315ea4f7cca642fb936031</id>
<content type='text'>
Signed-off-by: Olga Kornievskaia &lt;kolga@netapp.com&gt;
Signed-off-by: Anna Schumaker &lt;Anna.Schumaker@Netapp.com&gt;
</content>
</entry>
<entry>
<title>NFSv4.1: Fix a potential layoutget/layoutrecall deadlock</title>
<updated>2018-07-26T20:25:25Z</updated>
<author>
<name>Trond Myklebust</name>
</author>
<published>2018-07-12T18:19:03Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=bd3d16a887b0c19a2a20d35ffed499e3a3637feb'/>
<id>urn:sha1:bd3d16a887b0c19a2a20d35ffed499e3a3637feb</id>
<content type='text'>
If the client is sending a layoutget, but the server issues a callback
to recall what it thinks may be an outstanding layout, then we may find
an uninitialised layout attached to the inode due to the layoutget.
In that case, it is appropriate to return NFS4ERR_NOMATCHING_LAYOUT
rather than NFS4ERR_DELAY, as the latter can end up deadlocking.

Signed-off-by: Trond Myklebust &lt;trond.myklebust@hammerspace.com&gt;
</content>
</entry>
</feed>
