<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git, branch v5.7.7</title>
<subtitle>Linux kernel stable tree (mirror)</subtitle>
<id>https://git.radix-linux.su/kernel/linux.git/atom?h=v5.7.7</id>
<link rel='self' href='https://git.radix-linux.su/kernel/linux.git/atom?h=v5.7.7'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/'/>
<updated>2020-06-30T20:21:22+00:00</updated>
<entry>
<title>Linux 5.7.7</title>
<updated>2020-06-30T20:21:22+00:00</updated>
<author>
<name>Sasha Levin</name>
<email>sashal@kernel.org</email>
</author>
<published>2020-06-30T20:21:22+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=fb6c7905238010236cf0750b209ce9162222eb97'/>
<id>urn:sha1:fb6c7905238010236cf0750b209ce9162222eb97</id>
<content type='text'>
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>Revert "tty: hvc: Fix data abort due to race in hvc_open"</title>
<updated>2020-06-30T19:36:31+00:00</updated>
<author>
<name>Greg Kroah-Hartman</name>
<email>gregkh@linuxfoundation.org</email>
</author>
<published>2020-05-12T08:22:44+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=feb6c2d13de3ad161c867c7e01c85f40e8bf18e9'/>
<id>urn:sha1:feb6c2d13de3ad161c867c7e01c85f40e8bf18e9</id>
<content type='text'>
commit cf9c94456ebafc6d75a834e58dfdc8ae71a3acbc upstream.

This reverts commit e2bd1dcbe1aa34ff5570b3427c530e4332ecf0fe.

In discussion on the mailing list, it has been determined that this is
not the correct type of fix for this issue.  Revert it so that we can do
this correctly.

Reported-by: Jiri Slaby &lt;jslaby@suse.cz&gt;
Reported-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
Link: https://lore.kernel.org/r/20200428032601.22127-1-rananta@codeaurora.org
Cc: Raghavendra Rao Ananta &lt;rananta@codeaurora.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>dm writecache: add cond_resched to loop in persistent_memory_claim()</title>
<updated>2020-06-30T19:36:31+00:00</updated>
<author>
<name>Mikulas Patocka</name>
<email>mpatocka@redhat.com</email>
</author>
<published>2020-06-19T15:51:34+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=edb930b4eaa735d31d8b7b7d2497b9c51e451d5f'/>
<id>urn:sha1:edb930b4eaa735d31d8b7b7d2497b9c51e451d5f</id>
<content type='text'>
commit d35bd764e6899a7bea71958f08d16cea5bfa1919 upstream.

Add cond_resched() to a loop that fills in the mapper memory area
because the loop can be executed many times.

Fixes: 48debafe4f2fe ("dm: add writecache target")
Cc: stable@vger.kernel.org
Signed-off-by: Mikulas Patocka &lt;mpatocka@redhat.com&gt;
Signed-off-by: Mike Snitzer &lt;snitzer@redhat.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>dm writecache: correct uncommitted_block when discarding uncommitted entry</title>
<updated>2020-06-30T19:36:31+00:00</updated>
<author>
<name>Huaisheng Ye</name>
<email>yehs1@lenovo.com</email>
</author>
<published>2020-06-12T15:59:11+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=22551da148c98636fe91b66b8dba3a1d1e1e46cc'/>
<id>urn:sha1:22551da148c98636fe91b66b8dba3a1d1e1e46cc</id>
<content type='text'>
commit 39495b12ef1cf602e6abd350dce2ef4199906531 upstream.

When uncommitted entry has been discarded, correct wc-&gt;uncommitted_block
for getting the exact number.

Fixes: 48debafe4f2fe ("dm: add writecache target")
Cc: stable@vger.kernel.org
Signed-off-by: Huaisheng Ye &lt;yehs1@lenovo.com&gt;
Acked-by: Mikulas Patocka &lt;mpatocka@redhat.com&gt;
Signed-off-by: Mike Snitzer &lt;snitzer@redhat.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>xprtrdma: Fix handling of RDMA_ERROR replies</title>
<updated>2020-06-30T19:36:31+00:00</updated>
<author>
<name>Chuck Lever</name>
<email>chuck.lever@oracle.com</email>
</author>
<published>2020-06-15T13:21:13+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=301cca2f313a0b6167e9b033bdd25a258c202693'/>
<id>urn:sha1:301cca2f313a0b6167e9b033bdd25a258c202693</id>
<content type='text'>
commit 7b2182ec381f8ea15c7eb1266d6b5d7da620ad93 upstream.

The RPC client currently doesn't handle ERR_CHUNK replies correctly.
rpcrdma_complete_rqst() incorrectly passes a negative number to
xprt_complete_rqst() as the number of bytes copied. Instead, set
task-&gt;tk_status to the error value, and return zero bytes copied.

In these cases, return -EIO rather than -EREMOTEIO. The RPC client's
finite state machine doesn't know what to do with -EREMOTEIO.

Additional clean ups:
- Don't double-count RDMA_ERROR replies
- Remove a stale comment

Signed-off-by: Chuck Lever &lt;chuck.lever@oracle.com&gt;
Cc: &lt;stable@kernel.vger.org&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>EDAC/amd64: Read back the scrub rate PCI register on F15h</title>
<updated>2020-06-30T19:36:31+00:00</updated>
<author>
<name>Borislav Petkov</name>
<email>bp@suse.de</email>
</author>
<published>2020-06-18T18:25:25+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=9e2f2568552cee6344d886d29700691fbc72b842'/>
<id>urn:sha1:9e2f2568552cee6344d886d29700691fbc72b842</id>
<content type='text'>
commit ee470bb25d0dcdf126f586ec0ae6dca66cb340a4 upstream.

Commit:

  da92110dfdfa ("EDAC, amd64_edac: Extend scrub rate support to F15hM60h")

added support for F15h, model 0x60 CPUs but in doing so, missed to read
back SCRCTRL PCI config register on F15h CPUs which are *not* model
0x60. Add that read so that doing

  $ cat /sys/devices/system/edac/mc/mc0/sdram_scrub_rate

can show the previously set DRAM scrub rate.

Fixes: da92110dfdfa ("EDAC, amd64_edac: Extend scrub rate support to F15hM60h")
Reported-by: Anders Andersson &lt;pipatron@gmail.com&gt;
Signed-off-by: Borislav Petkov &lt;bp@suse.de&gt;
Cc: &lt;stable@vger.kernel.org&gt; #v4.4..
Link: https://lkml.kernel.org/r/CAKkunMbNWppx_i6xSdDHLseA2QQmGJqj_crY=NF-GZML5np4Vw@mail.gmail.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>NFSv4 fix CLOSE not waiting for direct IO compeletion</title>
<updated>2020-06-30T19:36:30+00:00</updated>
<author>
<name>Olga Kornievskaia</name>
<email>olga.kornievskaia@gmail.com</email>
</author>
<published>2020-06-24T17:54:08+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=7f7f6661674f16f02cc7ac0a4a245a42cf8f52f1'/>
<id>urn:sha1:7f7f6661674f16f02cc7ac0a4a245a42cf8f52f1</id>
<content type='text'>
commit d03727b248d0dae6199569a8d7b629a681154633 upstream.

Figuring out the root case for the REMOVE/CLOSE race and
suggesting the solution was done by Neil Brown.

Currently what happens is that direct IO calls hold a reference
on the open context which is decremented as an asynchronous task
in the nfs_direct_complete(). Before reference is decremented,
control is returned to the application which is free to close the
file. When close is being processed, it decrements its reference
on the open_context but since directIO still holds one, it doesn't
sent a close on the wire. It returns control to the application
which is free to do other operations. For instance, it can delete a
file. Direct IO is finally releasing its reference and triggering
an asynchronous close. Which races with the REMOVE. On the server,
REMOVE can be processed before the CLOSE, failing the REMOVE with
EACCES as the file is still opened.

Signed-off-by: Olga Kornievskaia &lt;kolga@netapp.com&gt;
Suggested-by: Neil Brown &lt;neilb@suse.com&gt;
CC: stable@vger.kernel.org
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/flexfiles: Fix list corruption if the mirror count changes</title>
<updated>2020-06-30T19:36:30+00:00</updated>
<author>
<name>Trond Myklebust</name>
<email>trond.myklebust@hammerspace.com</email>
</author>
<published>2020-06-22T19:04:15+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=0f1ce854d7cb2c8b4840449e5b1d63410c16d0aa'/>
<id>urn:sha1:0f1ce854d7cb2c8b4840449e5b1d63410c16d0aa</id>
<content type='text'>
commit 8b04013737341442ed914b336cde866b902664ae upstream.

If the mirror count changes in the new layout we pick up inside
ff_layout_pg_init_write(), then we can end up adding the
request to the wrong mirror and corrupting the mirror-&gt;pg_list.

Fixes: d600ad1f2bdb ("NFS41: pop some layoutget errors to application")
Cc: stable@vger.kernel.org
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>SUNRPC: Properly set the @subbuf parameter of xdr_buf_subsegment()</title>
<updated>2020-06-30T19:36:30+00:00</updated>
<author>
<name>Chuck Lever</name>
<email>chuck.lever@oracle.com</email>
</author>
<published>2020-06-25T15:32:34+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=5c9ffc7750d8376db75a7c09634e1e1a590007ce'/>
<id>urn:sha1:5c9ffc7750d8376db75a7c09634e1e1a590007ce</id>
<content type='text'>
commit 89a3c9f5b9f0bcaa9aea3e8b2a616fcaea9aad78 upstream.

@subbuf is an output parameter of xdr_buf_subsegment(). A survey of
call sites shows that @subbuf is always uninitialized before
xdr_buf_segment() is invoked by callers.

There are some execution paths through xdr_buf_subsegment() that do
not set all of the fields in @subbuf, leaving some pointer fields
containing garbage addresses. Subsequent processing of that buffer
then results in a page fault.

Signed-off-by: Chuck Lever &lt;chuck.lever@oracle.com&gt;
Cc: &lt;stable@vger.kernel.org&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>sunrpc: fixed rollback in rpc_gssd_dummy_populate()</title>
<updated>2020-06-30T19:36:30+00:00</updated>
<author>
<name>Vasily Averin</name>
<email>vvs@virtuozzo.com</email>
</author>
<published>2020-06-01T08:54:57+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=3011ff95812d8e208645e89f376312234e8f6988'/>
<id>urn:sha1:3011ff95812d8e208645e89f376312234e8f6988</id>
<content type='text'>
commit b7ade38165ca0001c5a3bd5314a314abbbfbb1b7 upstream.

__rpc_depopulate(gssd_dentry) was lost on error path

cc: stable@vger.kernel.org
Fixes: commit 4b9a445e3eeb ("sunrpc: create a new dummy pipe for gssd to hold open")
Signed-off-by: Vasily Averin &lt;vvs@virtuozzo.com&gt;
Reviewed-by: Jeff Layton &lt;jlayton@redhat.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>
</feed>
