On Tue, Aug 18, 2020 at 07:16:46PM +0200, Greg KH wrote:
On Tue, Aug 18, 2020 at 11:49:29AM -0400, Mike Marshall wrote:
upstream commit id: ec95f1dedc9c64ac5a8b0bdb7c276936c70fdedd
I verified that ec95f1de "orangefs: get rid of knob code..." will apply to 5.4 and I compiled and ran a patched 5.4 kernel against my normal xfstests... I wish that ec95f1de could be in the 5.4 long term stable kernel.
ec95f1de went upstream in 5.7. When I sent up the patch it was just a theoretical race condition to me: I accepted what Christoph said about it. We now have experienced in-the-real-world how important the patch is...
Someone was trying to read a whole large (more than 100 meg) file from orangefs into some kind of cloud bucket. The resulting read failed with a "Bad address" error. I immediately thought of this patch. I reproduced the "Bad address" error with dd in kernel versions that lack ec95f1de. The "Bad address" error does not occur in kernels that include ec95f1de:
5.7.11-100.fc31.x86_64:
$ ./wr.sh 10000000 > /pvfsmnt/wr.10000000 $ dd if=/pvfsmnt/wr.10000000 of=/tmp/wr.10000000 count=10 bs=419430400 $ ls -l /pvfsmnt/wr.10000000 /tmp/wr.10000000 -rw-rw-r--. 1 hubcap hubcap 498888897 Aug 14 15:41 /pvfsmnt/wr.10000000 -rw-rw-r--. 1 hubcap hubcap 498888897 Aug 14 16:51 /tmp/wr.10000000 $ md5sum /pvfsmnt/wr.10000000 /tmp/wr.10000000 669daa04f91f561f5fb2851fb30e4ffe /pvfsmnt/wr.10000000 669daa04f91f561f5fb2851fb30e4ffe /tmp/wr.10000000
5.6.0hubcap:
$ ./wr.sh 10000000 > /pvfsmnt/wr.10000000 $ dd if=/pvfsmnt/wr.10000000 of=/tmp/wr.10000000 count=10 bs=419430400 dd: error reading '/pvfsmnt/wr.10000000': Bad address 0+0 records in 0+0 records out 0 bytes copied, 10.3365 s, 0.0 kB/s
Sounds reasonable, I'll queue this up after this next round of releases in the next few days, thanks!
Now queued up, thanks.
greg k-h