From patchwork Tue Jul 7 15:16:26 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Greg KH X-Patchwork-Id: 235017 Delivered-To: patch@linaro.org Received: by 2002:a54:2c11:0:0:0:0:0 with SMTP id g17csp304181ecp; Tue, 7 Jul 2020 08:23:12 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwKmZLlxF7u6C4CCbzc+wNFaSOiagvV/cqOZtqhsE/G7TtLEj0UGPvNEqvEqHW3nIv92NOC X-Received: by 2002:a05:6402:2cb:: with SMTP id b11mr56821315edx.66.1594135392441; Tue, 07 Jul 2020 08:23:12 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1594135392; cv=none; d=google.com; s=arc-20160816; b=z1M3mpQNrTQBIe6nmDyPJXuGZTasvVXKTpryketzRA9WybgL2W7o1YnuQRKpuzebU4 WBF9M6xKzN554RujMNjVNjjPwGYJK1e/D3QiB55CH47G5Uf4rLqi0nC+mBTpOb7ON0tN yRCyMS6jjfWjkDI8tjVJBbpC6WgcmErbMtX3s44vf42tfAEGzqgP5IRbWodGbpYpBDkS WTRJPbR7reZSvEsrKWSGgJE8R6I3DPYLRLvEgyKk1TI/W15jkR1I6bSV4j+/omFqeWrt qBzbAwL/A7q5MtAonBz0P0wS0yRcy2qvp7tqGS9boyAQYr+h03AmIEVM+XwiL0gTRpSN hjVw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:message-id:date:subject:cc:to :from:dkim-signature; bh=qEXaeO/RBCE4gxY1zUzUaGeK5kTxbPVf9w68DVQb/Ww=; b=VBGpS74+HnIilryAfdViYYRkjw4ODi0cydsz/SzeLRgA2Gi5JtkgQbUouLJTt3RsSX /LJAKL+TRiocV3PnySiAKtpLt6Fho/N/mlSbyro8o+mPvmx6NzD2aqMb924dtFvRvDAP sdj98PdrNVNDJr5H6sOQWY5JWV4pmr/fp0zvBSaGAq4zSPhua5dSBXT/TWANE6+i/hH8 rMlXD6gA4+7e0ruRYHtOBk7JszBHM5DWQRsulEd/3iDOa0LK8tCb6b8kC9CaiIqapZlS 5UR/27FDfG8SYt1eYuvAsm9TBXz5PQflq3T5AmDGIEZBppdP8NXg8GPU01dOpEdOrEMn HPnw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=ww75triT; spf=pass (google.com: domain of stable-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=stable-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 y17si14932695edw.91.2020.07.07.08.23.12; Tue, 07 Jul 2020 08:23:12 -0700 (PDT) Received-SPF: pass (google.com: domain of stable-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=ww75triT; spf=pass (google.com: domain of stable-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=stable-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729941AbgGGPXK (ORCPT + 15 others); Tue, 7 Jul 2020 11:23:10 -0400 Received: from mail.kernel.org ([198.145.29.99]:36096 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729950AbgGGPXK (ORCPT ); Tue, 7 Jul 2020 11:23:10 -0400 Received: from localhost (83-86-89-107.cable.dynamic.v4.ziggo.nl [83.86.89.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id DE16B207CD; Tue, 7 Jul 2020 15:23:08 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1594135389; bh=t48+Xhwq9/p8QGgsPqjcI4Z6WeMmsCy0ku+QepkjvXw=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=ww75triTQgAHN1JQZlS7oCve4Mw5O51C7dvlpVr34Cy2g1e0gJN2sao9ZSksI8DoD 2VbSIjz/RSjrPBHVwDk2p5bLpScrUl7ps/AYlbXEuRRbPu196ssG35gfWU6wIpRNIo X3LeD7/obuIAIA7Z0UKORme9v4x7h5YUAw9ElNFo= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Tero Kristo , Santosh Shilimkar , Tony Lindgren , Sasha Levin Subject: [PATCH 5.7 021/112] soc: ti: omap-prm: use atomic iopoll instead of sleeping one Date: Tue, 7 Jul 2020 17:16:26 +0200 Message-Id: <20200707145801.997136149@linuxfoundation.org> X-Mailer: git-send-email 2.27.0 In-Reply-To: <20200707145800.925304888@linuxfoundation.org> References: <20200707145800.925304888@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Sender: stable-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org From: Tero Kristo [ Upstream commit 98ece19f247159a51003796ede7112fef2df5d7f ] The reset handling APIs for omap-prm can be invoked PM runtime which runs in atomic context. For this to work properly, switch to atomic iopoll version instead of the current which can sleep. Otherwise, this throws a "BUG: scheduling while atomic" warning. Issue is seen rather easily when CONFIG_PREEMPT is enabled. Signed-off-by: Tero Kristo Acked-by: Santosh Shilimkar Signed-off-by: Tony Lindgren Signed-off-by: Sasha Levin --- drivers/soc/ti/omap_prm.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) -- 2.25.1 diff --git a/drivers/soc/ti/omap_prm.c b/drivers/soc/ti/omap_prm.c index 96c6f777519c0..c9b3f9ebf0bbf 100644 --- a/drivers/soc/ti/omap_prm.c +++ b/drivers/soc/ti/omap_prm.c @@ -256,10 +256,10 @@ static int omap_reset_deassert(struct reset_controller_dev *rcdev, goto exit; /* wait for the status to be set */ - ret = readl_relaxed_poll_timeout(reset->prm->base + - reset->prm->data->rstst, - v, v & BIT(st_bit), 1, - OMAP_RESET_MAX_WAIT); + ret = readl_relaxed_poll_timeout_atomic(reset->prm->base + + reset->prm->data->rstst, + v, v & BIT(st_bit), 1, + OMAP_RESET_MAX_WAIT); if (ret) pr_err("%s: timedout waiting for %s:%lu\n", __func__, reset->prm->data->name, id); From patchwork Tue Jul 7 15:17:52 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Greg KH X-Patchwork-Id: 235018 Delivered-To: patch@linaro.org Received: by 2002:a54:2c11:0:0:0:0:0 with SMTP id g17csp306885ecp; Tue, 7 Jul 2020 08:26:54 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyQ0W+SrbW4j0QejkPYjsm0Y29FLF4bwu2dkLxyldhs4fOxnDj7N+9BgCgYd2Gs8LckYhoa X-Received: by 2002:a17:906:a459:: with SMTP id cb25mr47501988ejb.234.1594135614618; Tue, 07 Jul 2020 08:26:54 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1594135614; cv=none; d=google.com; s=arc-20160816; b=o6W4plsQqsL+qcEIXONTUmp+IO0+c6A2IU395eHErI1M/q1cEz97IpviZHFO5Pw8nB oOasvVHLMhKI3HDKwGHlsZUrrfhFseVBVhy6iXGNJjAR8XEfnZlrydKIF50P40E0nGsm ly6S3iYRQOPDIN0m1USG81GShJ1qlSdo5ERmc4KRz8PpE3mr9HGgn8W+eDC2PBucwug3 0vmO50h/F/W0qRBFWBxTkJEFu0EdNH4iXyLPqDxudWrBKxq8CGHX+3MZ+4irEn15PPZa 1MqNXJo0e3qU4Fpb5VWCW7a/VVOKvcvtR3m2JcaYw91D5LaE5agYWkHRyLPVzbsbo163 0q1g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:message-id:date:subject:cc:to :from:dkim-signature; bh=zPhKdBGQ1NOZFJWDThQIj+3U/w6NeCsm+T2krskVREk=; b=hl86zANPk0KW4qXUrIe+meLjrAl8mM+QTquKVSRA8QO4mxSVrHFTtNhql04VPH9uVp vQXHKJrsdWVf7DxG276KWOlM2l28Zz9M7aclKQEWbUV5DGdkajzteOOKgW+IzFUjbWXi GjlHb+5zCKHtokL26gHdDCyMf7Aec326Cuwkw461Ejg8UBW4w0QuR0IAQ+rt8plx0N0T TrJ0ugsJ3YGD0lWJVT90OkrcB1SLJavAgFtzk57+vm3rlPX6F/rYFJaw5TALoIH4+RUs whKw78jxF3/s3Sc47Eb9n78mbAgGNuMEjkW+gbI2QRzsWbOTZOxmRuqVTELYLzvwsq5L DUog== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=vjXTO3dB; spf=pass (google.com: domain of stable-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=stable-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 l6si14592321ejx.493.2020.07.07.08.26.54; Tue, 07 Jul 2020 08:26:54 -0700 (PDT) Received-SPF: pass (google.com: domain of stable-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=vjXTO3dB; spf=pass (google.com: domain of stable-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=stable-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730314AbgGGP0x (ORCPT + 15 others); Tue, 7 Jul 2020 11:26:53 -0400 Received: from mail.kernel.org ([198.145.29.99]:41066 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730302AbgGGP0q (ORCPT ); Tue, 7 Jul 2020 11:26:46 -0400 Received: from localhost (83-86-89-107.cable.dynamic.v4.ziggo.nl [83.86.89.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id C21972078D; Tue, 7 Jul 2020 15:26:44 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1594135605; bh=tsP8O2XrM6avr/0AZZLaqustfwT7bO1HRrcl6qYXHwE=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=vjXTO3dBsG7ESoofPKwdivqlE+VelHY13tZ7oo8jJQjBieft0vOflkqk5vUkEtcx6 s2dpbox14RrrzBwS9ucR+WPH03rBNFt6U1PDVrKxh1PzZlxjIUQpZiS2WF8Pa4HpO1 asqIl7JNiFERq85h0y6cguSnYg0dxNZzDVQYz6+Q= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, syzbot+3643a18836bce555bff6@syzkaller.appspotmail.com, Arnd Bergmann , Charan Teja Reddy , Sumit Semwal Subject: [PATCH 5.7 107/112] dma-buf: Move dma_buf_release() from fops to dentry_ops Date: Tue, 7 Jul 2020 17:17:52 +0200 Message-Id: <20200707145806.061508327@linuxfoundation.org> X-Mailer: git-send-email 2.27.0 In-Reply-To: <20200707145800.925304888@linuxfoundation.org> References: <20200707145800.925304888@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Sender: stable-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org From: Sumit Semwal commit 4ab59c3c638c6c8952bf07739805d20eb6358a4d upstream. Charan Teja reported a 'use-after-free' in dmabuffs_dname [1], which happens if the dma_buf_release() is called while the userspace is accessing the dma_buf pseudo fs's dmabuffs_dname() in another process, and dma_buf_release() releases the dmabuf object when the last reference to the struct file goes away. I discussed with Arnd Bergmann, and he suggested that rather than tying the dma_buf_release() to the file_operations' release(), we can tie it to the dentry_operations' d_release(), which will be called when the last ref to the dentry is removed. The path exercised by __fput() calls f_op->release() first, and then calls dput, which eventually calls d_op->d_release(). In the 'normal' case, when no userspace access is happening via dma_buf pseudo fs, there should be exactly one fd, file, dentry and inode, so closing the fd will kill of everything right away. In the presented case, the dentry's d_release() will be called only when the dentry's last ref is released. Therefore, lets move dma_buf_release() from fops->release() to d_ops->d_release() Many thanks to Arnd for his FS insights :) [1]: https://lore.kernel.org/patchwork/patch/1238278/ Fixes: bb2bb9030425 ("dma-buf: add DMA_BUF_SET_NAME ioctls") Reported-by: syzbot+3643a18836bce555bff6@syzkaller.appspotmail.com Cc: [5.3+] Cc: Arnd Bergmann Reported-by: Charan Teja Reddy Reviewed-by: Arnd Bergmann Signed-off-by: Sumit Semwal Tested-by: Charan Teja Reddy Link: https://patchwork.freedesktop.org/patch/msgid/20200611114418.19852-1-sumit.semwal@linaro.org Signed-off-by: Greg Kroah-Hartman --- drivers/dma-buf/dma-buf.c | 54 +++++++++++++++++++++------------------------- 1 file changed, 25 insertions(+), 29 deletions(-) --- a/drivers/dma-buf/dma-buf.c +++ b/drivers/dma-buf/dma-buf.c @@ -54,37 +54,11 @@ static char *dmabuffs_dname(struct dentr dentry->d_name.name, ret > 0 ? name : ""); } -static const struct dentry_operations dma_buf_dentry_ops = { - .d_dname = dmabuffs_dname, -}; - -static struct vfsmount *dma_buf_mnt; - -static int dma_buf_fs_init_context(struct fs_context *fc) -{ - struct pseudo_fs_context *ctx; - - ctx = init_pseudo(fc, DMA_BUF_MAGIC); - if (!ctx) - return -ENOMEM; - ctx->dops = &dma_buf_dentry_ops; - return 0; -} - -static struct file_system_type dma_buf_fs_type = { - .name = "dmabuf", - .init_fs_context = dma_buf_fs_init_context, - .kill_sb = kill_anon_super, -}; - -static int dma_buf_release(struct inode *inode, struct file *file) +static void dma_buf_release(struct dentry *dentry) { struct dma_buf *dmabuf; - if (!is_dma_buf_file(file)) - return -EINVAL; - - dmabuf = file->private_data; + dmabuf = dentry->d_fsdata; BUG_ON(dmabuf->vmapping_counter); @@ -110,9 +84,32 @@ static int dma_buf_release(struct inode module_put(dmabuf->owner); kfree(dmabuf->name); kfree(dmabuf); +} + +static const struct dentry_operations dma_buf_dentry_ops = { + .d_dname = dmabuffs_dname, + .d_release = dma_buf_release, +}; + +static struct vfsmount *dma_buf_mnt; + +static int dma_buf_fs_init_context(struct fs_context *fc) +{ + struct pseudo_fs_context *ctx; + + ctx = init_pseudo(fc, DMA_BUF_MAGIC); + if (!ctx) + return -ENOMEM; + ctx->dops = &dma_buf_dentry_ops; return 0; } +static struct file_system_type dma_buf_fs_type = { + .name = "dmabuf", + .init_fs_context = dma_buf_fs_init_context, + .kill_sb = kill_anon_super, +}; + static int dma_buf_mmap_internal(struct file *file, struct vm_area_struct *vma) { struct dma_buf *dmabuf; @@ -412,7 +409,6 @@ static void dma_buf_show_fdinfo(struct s } static const struct file_operations dma_buf_fops = { - .release = dma_buf_release, .mmap = dma_buf_mmap_internal, .llseek = dma_buf_llseek, .poll = dma_buf_poll,