Received: by 2002:a25:ab43:0:0:0:0:0 with SMTP id u61csp6460417ybi; Wed, 29 May 2019 08:09:44 -0700 (PDT) X-Google-Smtp-Source: APXvYqwGWeb8Qj7VnW0gSfcc5P8E0UFPhXJ8FCR1FGe90DIQ6O0qO+7Wej1j4OjqW1WU5deUgkc5 X-Received: by 2002:a17:90a:1ac5:: with SMTP id p63mr13134533pjp.8.1559142584708; Wed, 29 May 2019 08:09:44 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1559142584; cv=none; d=google.com; s=arc-20160816; b=YcuyxM0S42zyWgsZ9HmCmR9tfhUCUcGXVqLDyt4a8PyCeiCH/C/xfTO4I+VXkqkPwS nUBbZ+odnJDG4DFfEKdlWQU78Ws58p0A5y0/Xj0veY1o8slnVV6Au/DwHCiqZKTN7GzX qiVPMGcO58Jkys/OL2Lo89XBZouvVJ0rsuGzu2TcYy47uax9v7i0MnauIORir+GDPPxH ktivD8ZcFfj+xcWu0fW+nuQ6+liKN3KlVQ27fa6DmP24SQIqGHOR1Ah1VExearD2rzRT Gde1/XadJ1SZjZi9q593i1voxSwU5V/NoVw3iWP1I5k5zR2C1ZvbmJoDu7NjNjaBcyZR vaHw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:message-id:date:subject:to :from; bh=Hf36IezWBu45sOhvz31/zTLcOh2d7Zrs6ZvgFNR0qm4=; b=YU0BzVRYbWhO14KM0vbCj4nelj+78ZO1BkOrewJvpPm6ULrUXhd/zUnz5Se1RFVL+Y 2R2CcbTimxocMWTi+qc2/BSRMxnIdw5S7u4Y/ZpaBHaIM4Trh3GZTqw9dDX7Z3ROE5ON 4hytxRTVRuJIYJoe5+XSEiSvLtWBGRHHLUaiK7RpL7jHgEaIDwYRwaD0RMJkJkiDcXYO 3JexoU3K1B0U4DyAJAbrG9xwnnBMNS4WwXxvxfUWLUyD2qMa/iEJNYh7Ni3q+RW4KCfB pX04Q7MtoSWbCTjzWT44t5XW+TIPh4AqonKMmaJ1jpUXWjUKtA514HbQ92IJ5gRMcxHs 3guA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-nfs-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-nfs-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id z6si24368007pgp.35.2019.05.29.08.09.16; Wed, 29 May 2019 08:09:44 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-nfs-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-nfs-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-nfs-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726323AbfE2PIq (ORCPT + 99 others); Wed, 29 May 2019 11:08:46 -0400 Received: from mx1.redhat.com ([209.132.183.28]:58688 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725914AbfE2PIq (ORCPT ); Wed, 29 May 2019 11:08:46 -0400 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id B2E7319CF89 for ; Wed, 29 May 2019 15:08:46 +0000 (UTC) Received: from [10.10.66.3] (ovpn-66-3.rdu2.redhat.com [10.10.66.3]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 7BC385D704 for ; Wed, 29 May 2019 15:08:46 +0000 (UTC) From: "Benjamin Coddington" To: "Linux NFS Mailing List" Subject: client lookup_revalidate bug Date: Wed, 29 May 2019 11:08:45 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Scanned-By: MIMEDefang 2.79 on 10.5.11.15 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.29]); Wed, 29 May 2019 15:08:46 +0000 (UTC) Sender: linux-nfs-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-nfs@vger.kernel.org Hey, here's an interesting one, this seems wrong: [root@fedora27_c2_v5 ~]# mkdir /mnt/one [root@fedora27_c2_v5 ~]# mkdir /mnt/two [root@fedora27_c2_v5 ~]# mount -t nfs -ov4,noac,sec=sys,nosharecache 192.168.122.50:/exports /mnt/one [root@fedora27_c2_v5 ~]# mount -t nfs -ov4,noac,sec=sys,nosharecache 192.168.122.50:/exports /mnt/two [root@fedora27_c2_v5 ~]# mkdir /mnt/one/A [root@fedora27_c2_v5 ~]# mkdir /mnt/one/B [root@fedora27_c2_v5 ~]# touch /mnt/one/A/foo [root@fedora27_c2_v5 ~]# cat /mnt/two/A/foo [root@fedora27_c2_v5 ~]# mv /mnt/two/A/foo /mnt/two/B/foo [root@fedora27_c2_v5 ~]# mv /mnt/one/B/foo /mnt/one/A/foo [root@fedora27_c2_v5 ~]# cat /mnt/two/A/foo [root@fedora27_c2_v5 ~]# stat /mnt/two/B/foo File: /mnt/two/B/foo Size: 0 Blocks: 0 IO Block: 262144 regular empty file Device: 2fh/47d Inode: 439603 Links: 1 Access: (0644/-rw-r--r--) Uid: ( 0/ root) Gid: ( 0/ root) Context: system_u:object_r:nfs_t:s0 Access: 2019-05-28 14:00:18.929663705 -0400 Modify: 2019-05-28 14:00:18.929663705 -0400 Change: 2019-05-28 14:00:58.990124573 -0400 Birth: - ^^ that lstat should return -ENOENT. I think we detect a stale directory by comparing the directory's change_attr with the dentry's d_time. But, here's a case where they are the same! Am I wrong about this, or any clever ideas to catch this case? Ben