copy_file_range(2) stuck in infinite loop

4.12-rc1 regression Eryu Guan 2 participants 2 messages May 16, 2017

Subsystems (2)

NFS client NFS server

lore

Share & tools

lore

Eryu Guan

author

2017-05-16 14:10 UTC #0 lore raw

Hi all,

fstests test generic/430 would hang when testing NFSv4.2 using 4.12-rc1 kernel based client. And this is a regression, 4.11 kernel has no problem. A simple reproducer is like:

# mount -t nfs -o vers=4.2 nfs-server:/export /mnt/nfs
# xfs_io -fc "pwrite 0 4k" /mnt/nfs/testfile
# xfs_io -fc "copy_range /mnt/nfs/testfile" /mnt/nfs/testfile.copy

The last copy_range command never returns, and xfs_io process is in D state. Some kernel debug code shows that it stuck in infinite loop in nfs42_proc_copy(), _nfs42_proc_copy() always returns -EAGAIN.

So this looks like a problem introduced by this commit

commit e092693443b995c8e3a565a73b5fdb05f1260f9b

Author: Olga Kornievskaia <[email protected]>
Date:   Mon May 8 18:02:24 2017 -0400

NFS append COMMIT after synchronous COPY

Instead of messing with the commit path which has been causing issues, add a COMMIT op after the COPY and ask for stable copies in the first space.

It saves a round trip, since after the COPY, the client sends a COMMIT anyway.

Signed-off-by Olga Kornievskaia <[email protected]>

Signed-off-by Trond Myklebust <[email protected]>

Reverting this patch did solve the problem. If you need more info please let me know.

Thanks,
Eryu

Olga Kornievskaia

2017-05-16 15:59 UTC #1 lore raw

Quoted 26 lines · Eryu Guan

Hi all,
fstests test generic/430 would hang when testing NFSv4.2 using 4.12-rc1 kernel based client. And this is a regression, 4.11 kernel has no problem. A simple reproducer is like:
# mount -t nfs -o vers=4.2 nfs-server:/export /mnt/nfs
# xfs_io -fc "pwrite 0 4k" /mnt/nfs/testfile
# xfs_io -fc "copy_range /mnt/nfs/testfile" /mnt/nfs/testfile.copy
The last copy_range command never returns, and xfs_io process is in D state. Some kernel debug code shows that it stuck in infinite loop in nfs42_proc_copy(), _nfs42_proc_copy() always returns -EAGAIN.
So this looks like a problem introduced by this commit
commit e092693443b995c8e3a565a73b5fdb05f1260f9b
Author: Olga Kornievskaia <[email protected]>
Date:   Mon May 8 18:02:24 2017 -0400
NFS append COMMIT after synchronous COPY
Instead of messing with the commit path which has been causing issues, add a COMMIT op after the COPY and ask for stable copies in the first space.

Quoted 8 lines

It saves a round trip, since after the COPY, the client sends a COMMIT anyway.
Signed-off-by Olga Kornievskaia <[email protected]>
Signed-off-by Trond Myklebust <[email protected]>
Reverting this patch did solve the problem. If you need more info please let me know.

Thank you. That was a big typo. Should be if (nfs_write_verifier_cmp) and not if (!). Sending a fix.

Quoted 7 lines

Thanks,
Eryu
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html