From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-9.0 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_PASS,USER_AGENT_GIT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 865B9C10F11 for ; Thu, 11 Apr 2019 03:24:59 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 604F92133D for ; Thu, 11 Apr 2019 03:24:59 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726694AbfDKDY7 (ORCPT ); Wed, 10 Apr 2019 23:24:59 -0400 Received: from youngberry.canonical.com ([91.189.89.112]:40011 "EHLO youngberry.canonical.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726230AbfDKDY6 (ORCPT ); Wed, 10 Apr 2019 23:24:58 -0400 Received: from mail-pf1-f198.google.com ([209.85.210.198]) by youngberry.canonical.com with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.76) (envelope-from ) id 1hEQKe-0007Kl-4m for stable@vger.kernel.org; Thu, 11 Apr 2019 03:24:56 +0000 Received: by mail-pf1-f198.google.com with SMTP id b12so3350311pfj.5 for ; Wed, 10 Apr 2019 20:24:56 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=wVREWW4qQrma2AKTD8kVMgQYHNy+vUlr2JMQqPX7IR0=; b=sII8ZbMARyN0Z8c0DqxUVixN1PGL871rmeBWIK32citCylN6e2xZilxkf8yIB355L4 xwhFrSUJZiESRRWPxvQSHTYC1WTrYA97I05YXSp5wbV7tayebkTeuA7dJUZtCtwdaWWg K9WSKxX4sO+K3ODoddppnm1VTNhX1G06jXKWsxdP1dBREyOKkP9iEW+bxZ7MqVg2jTmY TnM8hrOxKViH5/R0ck3eNG9GK+UAkXdEa6p+3oU1MmGPtkVR++P+Cgi9bRT1QO+UbFLM 18wSerabmjZ1Aq/KtmVl15C5p+D8tGAHsN3g7wuI1QZOccBpCFu/UpetvHTbZe2pEbx4 tO4g== X-Gm-Message-State: APjAAAVV8E58Ld+Lm8CWUiMDHnruqvWRZT0KwIb8mSbiAlOytRf/Li5Q 8jILpJ8zoNlCLiHY7T2Ejr4bnhHf4vUjO3x41hTQH+/B5pkTPeP7V361hy1FOSqv1gmE0CZPWxC OSaHDCiU7lmmQuDbqwKegjGCtbq9cwfdEAg== X-Received: by 2002:a63:6a43:: with SMTP id f64mr12264871pgc.366.1554953094532; Wed, 10 Apr 2019 20:24:54 -0700 (PDT) X-Google-Smtp-Source: APXvYqzrqj8d1d+5gppH/HXXITJiE4ljkdGlXKWaqU1qV7zIyYyk6Gf55nsxr+Ksmts6hculRn9j7Q== X-Received: by 2002:a63:6a43:: with SMTP id f64mr12264862pgc.366.1554953094376; Wed, 10 Apr 2019 20:24:54 -0700 (PDT) Received: from localhost.localdomain (222-154-101-5-fibre.sparkbb.co.nz. [222.154.101.5]) by smtp.gmail.com with ESMTPSA id s16sm50747170pgo.69.2019.04.10.20.24.52 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 10 Apr 2019 20:24:53 -0700 (PDT) From: Matthew Ruffell To: stable@vger.kernel.org Subject: [PATCH 4.9 3/3] fanotify: Release SRCU lock when waiting for userspace response Date: Thu, 11 Apr 2019 15:24:30 +1200 Message-Id: <20190411032430.17353-4-matthew.ruffell@canonical.com> X-Mailer: git-send-email 2.19.1 In-Reply-To: <20190411032430.17353-1-matthew.ruffell@canonical.com> References: <20190411032430.17353-1-matthew.ruffell@canonical.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: stable-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org From: Jan Kara commit 05f0e38724e8449184acd8fbf0473ee5a07adc6c upstream. When userspace task processing fanotify permission events screws up and does not respond, fsnotify_mark_srcu SRCU is held indefinitely which causes further hangs in the whole notification subsystem. Although we cannot easily solve the problem of operations blocked waiting for response from userspace, we can at least somewhat localize the damage by dropping SRCU lock before waiting for userspace response and reacquiring it when userspace responds. Reviewed-by: Miklos Szeredi Reviewed-by: Amir Goldstein Signed-off-by: Jan Kara [mruffell: cherry picked] Signed-off-by: Matthew Ruffell --- fs/notify/fanotify/fanotify.c | 17 +++++++++++++++-- 1 file changed, 15 insertions(+), 2 deletions(-) diff --git a/fs/notify/fanotify/fanotify.c b/fs/notify/fanotify/fanotify.c index 4944956cdbd9..eeb5cc1f6978 100644 --- a/fs/notify/fanotify/fanotify.c +++ b/fs/notify/fanotify/fanotify.c @@ -61,14 +61,26 @@ static int fanotify_merge(struct list_head *list, struct fsnotify_event *event) #ifdef CONFIG_FANOTIFY_ACCESS_PERMISSIONS static int fanotify_get_response(struct fsnotify_group *group, - struct fanotify_perm_event_info *event) + struct fanotify_perm_event_info *event, + struct fsnotify_iter_info *iter_info) { int ret; pr_debug("%s: group=%p event=%p\n", __func__, group, event); + /* + * fsnotify_prepare_user_wait() fails if we race with mark deletion. + * Just let the operation pass in that case. + */ + if (!fsnotify_prepare_user_wait(iter_info)) { + event->response = FAN_ALLOW; + goto out; + } + wait_event(group->fanotify_data.access_waitq, event->response); + fsnotify_finish_user_wait(iter_info); +out: /* userspace responded, convert to something usable */ switch (event->response) { case FAN_ALLOW: @@ -216,7 +228,8 @@ static int fanotify_handle_event(struct fsnotify_group *group, #ifdef CONFIG_FANOTIFY_ACCESS_PERMISSIONS if (mask & FAN_ALL_PERM_EVENTS) { - ret = fanotify_get_response(group, FANOTIFY_PE(fsn_event)); + ret = fanotify_get_response(group, FANOTIFY_PE(fsn_event), + iter_info); fsnotify_destroy_event(group, fsn_event); } #endif -- 2.19.1