Bug 1349647
| Summary: | NFS client may keep phantom directory entry in dcache when rename is canceled | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 7 | Reporter: | Frank Sorenson <fsorenso> |
| Component: | kernel | Assignee: | Benjamin Coddington <bcodding> |
| kernel sub component: | NFS | QA Contact: | JianHong Yin <jiyin> |
| Status: | CLOSED ERRATA | Docs Contact: | |
| Severity: | medium | ||
| Priority: | medium | CC: | bcodding, dwysocha, eguan, jiyin, jlayton, swhiteho, yoyang |
| Version: | 7.2 | Keywords: | Reproducer |
| Target Milestone: | rc | ||
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | kernel-3.10.0-658.el7 | Doc Type: | If docs needed, set a value |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2017-08-01 20:12:35 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | |||
| Bug Blocks: | 1298243, 1385242 | ||
|
Description
Frank Sorenson
2016-06-23 21:13:57 UTC
Reproduced by beaker auto test job: :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: :: [ LOG ] :: do-client-Test-3 :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: [05:40:13 root@ ~~]# rhts-sync-block -s servReady hp-bl660cgen8-01.rhts.eng.bos.redhat.com servReady :: [ PASS ] :: Running 'rhts-sync-block -s servReady hp-bl660cgen8-01.rhts.eng.bos.redhat.com' (Expected 0, got 0) -------------------------------------------------------------------------------- [05:40:27 root@ ~~]# mount -o vers=3 hp-bl660cgen8-01.rhts.eng.bos.redhat.com:/exportdir-bz1349647 /mnt/nfsmp-bz1349647 -------------------------------------------------------------------------------- /mnt/nfsmp-bz1349647 /mnt/tests/kernel/filesystems/nfs/regression/bz1349647-NFS-client-may-keep-phantom-directory-entry-in-dcache [05:40:28 root@ /mnt/nfsmp-bz1349647]# echo testing >f1 :: [ PASS ] :: Running 'echo testing >f1' (Expected 0, got 0) -------------------------------------------------------------------------------- MARK-LWD-LOOP -- 2016-06-24 05:42:38 -- cp: skipping file ‘f1’, as it was replaced while being copied No screen session found. [05:46:38 root@ /mnt/nfsmp-bz1349647]# test $(stat -c %i f1) -ne $(stat -c %i f2) :: [ FAIL ] :: Running 'test $(stat -c %i f1) -ne $(stat -c %i f2)' (Expected 0, got 1) -------------------------------------------------------------------------------- [05:46:38 root@ /mnt/nfsmp-bz1349647]# ls -l total 8 ----------. 1 root root 8 Jun 24 05:46 f1 -rw-r--r--. 1 root root 66 Jun 24 05:46 stderr.log -------------------------------------------------------------------------------- [05:46:38 root@ /mnt/nfsmp-bz1349647]# ls -li f1 f2 234981382 ----------. 1 root root 8 Jun 24 05:46 f1 234981382 ----------. 1 root root 8 Jun 24 05:46 f2 -------------------------------------------------------------------------------- [05:46:38 root@ /mnt/nfsmp-bz1349647]# ssh $SERVER ls -li $expdir total 8 234981382 ----------. 1 root root 8 Jun 24 05:46 f1 234981381 -rw-r--r--. 1 root root 66 Jun 24 05:46 stderr.log Is it possible to do something about this I wonder? Not sure how much the protocol might be an issue here. Here's a more reliable single-system reproducer - but it relies on the 'netem' kernel modules to introduce a network delay in order to signal the process while it waits in the rename's __rpc_wait_for_completion_task(): #!/bin/bash TESTDIR=/mnt/fedora/bz1349647 touch ${TESTDIR}/f1 tc qdisc add dev lo root netem delay 200ms sleep 1 mv -f ${TESTDIR}/f{1,2} & pid=$! sleep .5 kill $pid; tc qdisc del dev lo root netem After this, ${TESTDIR}/f1 will be the left-behind dentry. Proposed fix upstream posting: http://marc.info/?l=linux-nfs&m=148181328615582&w=2 upstream v2: http://marc.info/?l=linux-nfs&m=148594600229049&w=2 Patch(es) committed on kernel repository and an interim kernel build is undergoing testing Patch(es) available on kernel-3.10.0-616.el7 This one needs a follow-up fix. The patch that was added to fix this problem will rehash the old dentry after a rename, so an open by the old name will succeed when it should fail. The fix is upstream: d4ea7e3c5c0e NFS: Fix old dentry rehash after move Patch(es) committed on kernel repository and an interim kernel build is undergoing testing Patch(es) available on kernel-3.10.0-658.el7 Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHSA-2017:1842 Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHSA-2017:1842 |