submission for 5.4 LTS

submission for 5.4 LTS

[Mike Marshall]

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

Thanks!

-Mike

Re: submission for 5.4 LTS

[Greg KH]

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!

greg k-h

Re: submission for 5.4 LTS

[Greg KH]

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