Received: by 10.223.185.116 with SMTP id b49csp6382352wrg; Wed, 28 Feb 2018 08:30:11 -0800 (PST) X-Google-Smtp-Source: AH8x227s2C412Jc0JYofSeB6Il3dO/3H3pzlGNsONCUa/dECpd2C+1VDg1B+AqnAK8JTgdptAQ3w X-Received: by 10.99.114.24 with SMTP id n24mr13998349pgc.400.1519835411036; Wed, 28 Feb 2018 08:30:11 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1519835410; cv=none; d=google.com; s=arc-20160816; b=H4ojh8qOWUmlC4lk8S04+1mZ+ftUOghvOIjp+z9GUBuhivMlHHsLPOkNSudb/J0I1x 1T0mqBz8bofYLFD3yYFYmganDuaxjjxnpgox5DRbIUjmUrVgHqOmPdE2nA3+PfFEZB9U N/QsIHhGop46njfhUPrceJYz8PIFITI+QQgsSo+9rURHmWqTCZeq8q8JU7Q1coJh7GKs 6ei5ZlTU9br8aU8v5tYZXkaOeN5XixUeD8N1Ait5PgO+G6UYBqc+K9j0KCZRvEsVhmaU 4KdewA2ifuaDdjXtKLdL77O9OCbnW/JONVslZcJHWXa5xxasqWIq8YzUsSAtG+y1L0TC hBHA== 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=DgWvcQ/TjMycpAP+3jGt7qS5tiiLZnz0ZWwwfWuzbeI=; b=nAQ/YJvsb5434ipnqkPMgfhWv7sWIZEaY9XeSl8eDD8fg0uOKDmhMM9eEXoG80Nkeo Gq4uXsXKH2ffeOFw2yh2hVLrsgXihH6zvcuJFUxA5lTO9GCKstz8FeS3hG/x4cAMmLw0 s5p6CQ5Fin1rikevqiYdcYft1WzbdXzTqfNjZN8Pnnl/FgE89ISLEm63l4Y5PaQZcrza F0l1Tjw5hCdoE34kpGcGrc60BQ9wyFwwJCOeP18f2+VvFolxsbD1/TTMMdp2uU67Xo4j soCeI9aIIQ6NQN1a7OFYYSnCDd294UC8V0R9vFduF3XjkeWsyMocu0S2dH+wvcG4ZNIt ACew== 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 k67si1457697pfj.298.2018.02.28.08.29.55; Wed, 28 Feb 2018 08:30:10 -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 S934831AbeB1QP0 (ORCPT + 99 others); Wed, 28 Feb 2018 11:15:26 -0500 Received: from shadbolt.e.decadent.org.uk ([88.96.1.126]:35175 "EHLO shadbolt.e.decadent.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S934816AbeB1QPX (ORCPT ); Wed, 28 Feb 2018 11:15:23 -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 1er3Yv-0006Xb-G8; Wed, 28 Feb 2018 15:22:33 +0000 Received: from ben by deadeye with local (Exim 4.90_1) (envelope-from ) id 1er3Yc-0008L6-LL; Wed, 28 Feb 2018 15:22:14 +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, "Greg Kroah-Hartman" , "Takashi Iwai" Date: Wed, 28 Feb 2018 15:20:18 +0000 Message-ID: X-Mailer: LinuxStableQueue (scripts by bwh) Subject: [PATCH 3.16 001/254] ALSA: seq: Fix regression by incorrect ioctl_mutex usages 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.16.55-rc1 review patch. If anyone has any objections, please let me know. ------------------ From: Takashi Iwai This is the revised backport of the upstream commit b3defb791b26ea0683a93a4f49c77ec45ec96f10 We had another backport (e.g. 623e5c8ae32b in 4.4.115), but it applies the new mutex also to the code paths that are invoked via faked kernel-to-kernel ioctls. As reported recently, this leads to a deadlock at suspend (or other scenarios triggering the kernel sequencer client). This patch addresses the issue by taking the mutex only in the code paths invoked by user-space, just like the original fix patch does. Reported-and-tested-by: Andres Bertens Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman Signed-off-by: Ben Hutchings --- sound/core/seq/seq_clientmgr.c | 15 +++++++-------- 1 file changed, 7 insertions(+), 8 deletions(-) --- a/sound/core/seq/seq_clientmgr.c +++ b/sound/core/seq/seq_clientmgr.c @@ -2201,7 +2201,6 @@ static int snd_seq_do_ioctl(struct snd_s void __user *arg) { struct seq_ioctl_table *p; - int ret; switch (cmd) { case SNDRV_SEQ_IOCTL_PVERSION: @@ -2215,12 +2214,8 @@ static int snd_seq_do_ioctl(struct snd_s if (! arg) return -EFAULT; for (p = ioctl_tables; p->cmd; p++) { - if (p->cmd == cmd) { - mutex_lock(&client->ioctl_mutex); - ret = p->func(client, arg); - mutex_unlock(&client->ioctl_mutex); - return ret; - } + if (p->cmd == cmd) + return p->func(client, arg); } pr_debug("ALSA: seq unknown ioctl() 0x%x (type='%c', number=0x%02x)\n", cmd, _IOC_TYPE(cmd), _IOC_NR(cmd)); @@ -2231,11 +2226,15 @@ static int snd_seq_do_ioctl(struct snd_s static long snd_seq_ioctl(struct file *file, unsigned int cmd, unsigned long arg) { struct snd_seq_client *client = file->private_data; + long ret; if (snd_BUG_ON(!client)) return -ENXIO; - return snd_seq_do_ioctl(client, cmd, (void __user *) arg); + mutex_lock(&client->ioctl_mutex); + ret = snd_seq_do_ioctl(client, cmd, (void __user *) arg); + mutex_unlock(&client->ioctl_mutex); + return ret; } #ifdef CONFIG_COMPAT