Received: by 10.223.185.116 with SMTP id b49csp824806wrg; Sat, 10 Feb 2018 21:16:31 -0800 (PST) X-Google-Smtp-Source: AH8x224JcYEGjZasJPlvD0HBZSGFGQY1epoB6Wv/bkpPfEkDZ1orMAPtXQF7qq5WSwBSkKHw2veS X-Received: by 2002:a17:902:27e6:: with SMTP id i35-v6mr7196964plg.441.1518326191044; Sat, 10 Feb 2018 21:16:31 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1518326191; cv=none; d=google.com; s=arc-20160816; b=n5gVkfWgRFgc8oZPmagoJKRVOhm5CYP8xNmlGbZiL0XeO2cJKSe3IvtA9OLZThi28U vfJnV/gyCPMB9ynDbnQXo/goHICDXXBgIFs4mJkKQJo0EkPkiyT9UZV+69uc2sNvYJXR EXe0uE64Tnu9ipaeQqmMclcPerpqAm37Zs2tPwWKihM+DyGCHb0MAVrbilM5/NBuuTPa apQFtee/tYNncWvH6bakekZIa/aLMoIiM6GI2fd1QSKDbPRMr1gqoOitXemL+oKfwo67 bqlTwyXCpFczBYkxermmTCpxNIf4813UFwZYO5YJ9o3zdcIhSLUcu/DtM+KJ0gD3wQ+l 95Fw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:subject:message-id:date:cc:to :from:mime-version:content-transfer-encoding:content-disposition :arc-authentication-results; bh=bz7RY+J4nbHl+RQN/vtY+CZtb3+Duycr5U5TFqY+2g0=; b=GBlum++ZWTp3g+BAU/f77CA/YWRpWB3B4u1NG9aNLxRVz9T5WfQBo00bdo0QIpkMzL dETgQQisuil8ZG4PgiV6jvyonl7IS07eTyx/zdd+iJyu6/XX+1tMwNE8r7oYFIbq0Q3k a+mRKTK+RI4bGdXzXP5oSdeu861fEylXNhUEUPmhfGw4BFLafpERykde8gRB9dUe/ZmD 3nmd2Bz9+gsc5pk19KSkZHYOQk5+mAGTJJfUgcU4So7hG3aNkEZ1mr+3sEv1EkxVZQwL LmdUm+gSZ/3kf/xvVcweWX16wJQjsCWeU3P7HVdE8e/BZGVtaefCjuqbPiwIjnVMwini /j5A== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id o18si4295902pfa.407.2018.02.10.21.16.17; Sat, 10 Feb 2018 21:16:31 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-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-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932078AbeBKFOY (ORCPT + 99 others); Sun, 11 Feb 2018 00:14:24 -0500 Received: from shadbolt.e.decadent.org.uk ([88.96.1.126]:41383 "EHLO shadbolt.e.decadent.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752611AbeBKEdl (ORCPT ); Sat, 10 Feb 2018 23:33:41 -0500 Received: from [2a02:8011:400e:2:6f00:88c8:c921:d332] (helo=deadeye) by shadbolt.decadent.org.uk with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1ekjKd-0002hC-RR; Sun, 11 Feb 2018 04:33:39 +0000 Received: from ben by deadeye with local (Exim 4.90) (envelope-from ) id 1ekjKY-0004VN-AU; Sun, 11 Feb 2018 04:33:34 +0000 Content-Type: text/plain; charset="UTF-8" Content-Disposition: inline Content-Transfer-Encoding: 8bit MIME-Version: 1.0 From: Ben Hutchings To: linux-kernel@vger.kernel.org, stable@vger.kernel.org CC: akpm@linux-foundation.org, "Ian Kent" , "Al Viro" Date: Sun, 11 Feb 2018 04:20:06 +0000 Message-ID: X-Mailer: LinuxStableQueue (scripts by bwh) Subject: [PATCH 3.2 49/79] autofs4: autofs4_wait() vs. autofs4_catatonic_mode() race In-Reply-To: X-SA-Exim-Connect-IP: 2a02:8011:400e:2:6f00:88c8:c921:d332 X-SA-Exim-Mail-From: ben@decadent.org.uk X-SA-Exim-Scanned: No (on shadbolt.decadent.org.uk); SAEximRunCond expanded to false Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 3.2.99-rc1 review patch. If anyone has any objections, please let me know. ------------------ From: Al Viro commit 4041bcdc7bef06a2fb29c57394c713a74bd13b08 upstream. We need to recheck ->catatonic after autofs4_wait() got ->wq_mutex for good, or we might end up with wq inserted into queue after autofs4_catatonic_mode() had done its thing. It will stick there forever, since there won't be anything to clear its ->name.name. A bit of a complication: validate_request() drops and regains ->wq_mutex. It actually ends up the most convenient place to stick the check into... Acked-by: Ian Kent Signed-off-by: Al Viro Signed-off-by: Ben Hutchings --- fs/autofs4/waitq.c | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) --- a/fs/autofs4/waitq.c +++ b/fs/autofs4/waitq.c @@ -257,6 +257,9 @@ static int validate_request(struct autof struct autofs_wait_queue *wq; struct autofs_info *ino; + if (sbi->catatonic) + return -ENOENT; + /* Wait in progress, continue; */ wq = autofs4_find_wait(sbi, qstr); if (wq) { @@ -289,6 +292,9 @@ static int validate_request(struct autof if (mutex_lock_interruptible(&sbi->wq_mutex)) return -EINTR; + if (sbi->catatonic) + return -ENOENT; + wq = autofs4_find_wait(sbi, qstr); if (wq) { *wait = wq; @@ -389,7 +395,7 @@ int autofs4_wait(struct autofs_sb_info * ret = validate_request(&wq, sbi, &qstr, dentry, notify); if (ret <= 0) { - if (ret == 0) + if (ret != -EINTR) mutex_unlock(&sbi->wq_mutex); kfree(qstr.name); return ret;