Received: by 2002:a05:6a10:9848:0:0:0:0 with SMTP id x8csp33340pxf; Wed, 7 Apr 2021 19:08:58 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzzge/oqY5RC3hHzE59Ovn0obzivGXsikKEpa23NygTdSF7zRcmZgjIo/9DPvPejBkvI0Nu X-Received: by 2002:a17:90a:d703:: with SMTP id y3mr4669628pju.57.1617847738526; Wed, 07 Apr 2021 19:08:58 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1617847738; cv=none; d=google.com; s=arc-20160816; b=qZ4okpbHiyfmkVzk8UDFvvrXWmxWpKuBXey3/DKE4M5/NqLq0f7W6921vyughEZ832 974TB8Gnpj+o08FJEPH7dB9aFbzmXUv8jlG43qK4fEG2rJxXdOSBeHLh1Uf1kCuZ4rD8 4AEM8pWpvdP+ovBbtMTP48jwZDs28VoLyX6itnvvIGJa3YanjSb/6nyjnA3mgFs7+Vu2 jiHZqfSAQ4HYW2cNGiLh8ocbVyyVowDZyDknNTh7unQTPgXqvzr5L3b5MxvbMc0QGPiG 5sB25aCfs3wFQxcwvnFNJwZj5YJF3Ug5+UHdPRd3FUYrHJs0Tzn20EgeKJUN1t/QZox6 DQUw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-disposition:mime-version :message-id:subject:cc:to:from:date; bh=QCPn30TULzE1VB61fp3/xz004bosp0rfx55C4QuLmsE=; b=TzJgXo125toHnfw1Z7aFFVnauG9Tltx1lWTZ2FF6FEQTYp2KUebSQdWBj3dlILe+Hy Ts+x2N0qgn5ClbYIhj+zcV+1+dYFIJElooNYKmhCCf8+QZlVZ6EDkk1r65c8xkW9tJK3 UEfLLJymgw3HyOdL6sHUmPTex9txg5BoBgvIdzCovMpAfSskPPDNG0NxeBx7NMB8Dj8V w5oCo208fPrJBi6ohd1fQmlR6zADX1cYPlS5AB7omMMMjoTJr3UE8dmA+XtbDrqoMUY/ UfXCaiRclIKfC2P8NQnoARIt2E625UlcowgyLxy4DF09n05gbgm7mOHyiyIVQ/0a6wdB ttsA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id z11si25588845pfk.280.2021.04.07.19.08.43; Wed, 07 Apr 2021 19:08:58 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229708AbhDHCIW (ORCPT + 99 others); Wed, 7 Apr 2021 22:08:22 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:59688 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229505AbhDHCIV (ORCPT ); Wed, 7 Apr 2021 22:08:21 -0400 Received: from zeniv-ca.linux.org.uk (zeniv-ca.linux.org.uk [IPv6:2607:5300:60:148a::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 68857C061760; Wed, 7 Apr 2021 19:08:11 -0700 (PDT) Received: from viro by zeniv-ca.linux.org.uk with local (Exim 4.94 #2 (Red Hat Linux)) id 1lUK4z-003Xtw-SQ; Thu, 08 Apr 2021 02:07:33 +0000 Date: Thu, 8 Apr 2021 02:07:33 +0000 From: Al Viro To: Linus Torvalds Cc: linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org Subject: [git pull] breakage in LOOKUP_MOUNTPOINT handling Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Sender: Al Viro Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Brown paperbag time: dumb braino in the series that went into 5.7 broke the "don't step into ->d_weak_revalidate() when umount(2) looks the victim up" behaviour. Spotted only now - saw if (!err && unlikely(nd->flags & LOOKUP_MOUNTPOINT)) { err = handle_lookup_down(nd); nd->flags &= ~LOOKUP_JUMPED; // no d_weak_revalidate(), please... } went "why do we clear that flag here - nothing below that point is going to check it anyway" / "wait a minute, what is it doing *after* complete_walk() (which is where we check that flag and call ->d_weak_revalidate())" / "how could that possibly _not_ break?", followed by reproducing the breakage and verifying that the obvious fix of that braino does, indeed, fix it. FWIW, reproducer is (assuming that $DIR exists and is exported r/w to localhost) mkdir $DIR/a mkdir /tmp/foo mount --bind /tmp/foo /tmp/foo mkdir /tmp/foo/a mkdir /tmp/foo/b mount -t nfs4 localhost:$DIR/a /tmp/foo/a mount -t nfs4 localhost:$DIR /tmp/foo/b rmdir /tmp/foo/b/a umount /tmp/foo/b umount /tmp/foo/a umount -l /tmp/foo # will get everything under /tmp/foo, no matter what Correct behaviour is successful umount; broken kernels (5.7-rc1 and later) get umount.nfs4: /tmp/foo/a: Stale file handle Note that bind mount is there to be able to recover - on broken kernels we'd get stuck with impossible-to-umount filesystem if not for that. FWIW, that braino had been posted for review back then, at least twice. Unfortunately, the call of complete_walk() was outside of diff context, so the bogosity hadn't been immediately obvious from the patch alone ;-/ The following changes since commit 7d01ef7585c07afaf487759a48486228cd065726: Make sure nd->path.mnt and nd->path.dentry are always valid pointers (2021-04-06 12:33:07 -0400) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git fixes for you to fetch changes up to 4f0ed93fb92d3528c73c80317509df3f800a222b: LOOKUP_MOUNTPOINT: we are cleaning "jumped" flag too late (2021-04-06 20:33:00 -0400) ---------------------------------------------------------------- Al Viro (1): LOOKUP_MOUNTPOINT: we are cleaning "jumped" flag too late fs/namei.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-)