From patchwork Mon Dec 16 17:47:47 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Greg Kroah-Hartman X-Patchwork-Id: 181778 Delivered-To: patch@linaro.org Received: by 2002:a92:3001:0:0:0:0:0 with SMTP id x1csp4663250ile; Mon, 16 Dec 2019 10:14:53 -0800 (PST) X-Google-Smtp-Source: APXvYqyGqHjlnOjjv5SKNT7On1bE1itIe3MWRCTP8rw6wyjiymTkH236aLtKddvbD+kRGGaa+Xw4 X-Received: by 2002:aca:5117:: with SMTP id f23mr236694oib.50.1576520093691; Mon, 16 Dec 2019 10:14:53 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1576520093; cv=none; d=google.com; s=arc-20160816; b=EUR777mL0eQBAia+/VeHNjwNveiXEiiu4WAPmMfeSQu0YJtOz/ToXxj0gNOrgN3pIQ q+omYfylxkWWA8WQ5lqgjCA+ZbIa5D+XZwHPcVZxrGDsPyXzp5vN5D8xCr9C1dMnYDU8 vFbtnaN1uRNK6YnsYTAG59LekX6+fUE1LbCnNpJzo3qKC3+OtnQ35cAkt5KTbBOxBiYT KSbn+dhYsKAyuHQNPd8qRwNuBj87ySn9REC3gr8QwwZF4SqbS3koxp+MZhewjKX/es+X Hmba302opAQMwgKQQfHOHUFqHsqSRthEo7FuSGUWVRf2NGsG6/ryaQBT+DWYPydFWqWd PLVg== 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=EM7iVA8l/6MKz4M1aHFVzsjvDxxB8/BHd8i5nRxB/t4=; b=xCShfMRWmUHSHwA2tHfPE1kZsOVK76Gm/oCt5qOOVMHO4GgHqIC04qupF82ncz8Hym GBePDirHsJwwrDXLYQf1DKKnLskeva80MbNWRm9pMHMAA1I1qcG2F7b0ykQq5ev4nLA0 HDrIcZFmA2hKDz4eDeOPHadPhkMXmZhoV8jMi4xwpD1VPqzeOgeCjkv0tnRqNFjrtpq5 leZV+Tuogowr8J9H5jJC7A13Dg5w39zyIb2vZiJ1ot+tVciZEFx1IYH0Tf5UgY05Aica PiRfDzP99hPVS1KET8w9dQiLdApQb//6s+orLyssn7oszIPWuhFTb56toDpApx6vmdLo SB/w== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=YNApgVVB; spf=pass (google.com: best guess record for domain of stable-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=stable-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 w11si10151684oig.45.2019.12.16.10.14.53; Mon, 16 Dec 2019 10:14:53 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of stable-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=YNApgVVB; spf=pass (google.com: best guess record for domain of stable-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=stable-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1731286AbfLPSOw (ORCPT + 14 others); Mon, 16 Dec 2019 13:14:52 -0500 Received: from mail.kernel.org ([198.145.29.99]:34628 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1731274AbfLPSOr (ORCPT ); Mon, 16 Dec 2019 13:14:47 -0500 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 00968206B7; Mon, 16 Dec 2019 18:14:45 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1576520086; bh=7yDn2V6zu56CJCV4PFrB+CcvjiJrjdv3u4o/Atw8PsM=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=YNApgVVBC7mKVFKUf9rRMSfW+CFYeZqJKYiJ389noSEENbxzejYL8sml/NF/c+tyB fS25xpJi0VhNO+GNMUDQUtYbSkjWJ/q/dMqNJAv+gea0W82W0En4POtL6onRfdtn3Y M+YsTSMR0VoLe7x9VlNrfPeXKnm8vctzHHvFGvp8= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Arnd Bergmann Subject: [PATCH 5.4 011/177] compat_ioctl: add compat_ptr_ioctl() Date: Mon, 16 Dec 2019 18:47:47 +0100 Message-Id: <20191216174815.127036832@linuxfoundation.org> X-Mailer: git-send-email 2.24.1 In-Reply-To: <20191216174811.158424118@linuxfoundation.org> References: <20191216174811.158424118@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: Arnd Bergmann commit 2952db0fd51b0890f728df94ac563c21407f4f43 upstream. Many drivers have ioctl() handlers that are completely compatible between 32-bit and 64-bit architectures, except for the argument that is passed down from user space and may have to be passed through compat_ptr() in order to become a valid 64-bit pointer. Using ".compat_ptr = compat_ptr_ioctl" in file operations should let us simplify a lot of those drivers to avoid #ifdef checks, and convert additional drivers that don't have proper compat handling yet. On most architectures, the compat_ptr_ioctl() just passes all arguments to the corresponding ->ioctl handler. The exception is arch/s390, where compat_ptr() clears the top bit of a 32-bit pointer value, so user space pointers to the second 2GB alias the first 2GB, as is the case for native 32-bit s390 user space. The compat_ptr_ioctl() function must therefore be used only with ioctl functions that either ignore the argument or pass a pointer to a compatible data type. If any ioctl command handled by fops->unlocked_ioctl passes a plain integer instead of a pointer, or any of the passed data types is incompatible between 32-bit and 64-bit architectures, a proper handler is required instead of compat_ptr_ioctl. Signed-off-by: Arnd Bergmann --- v3: add a better description v2: use compat_ptr_ioctl instead of generic_compat_ioctl_ptrarg, as suggested by Al Viro Signed-off-by: Greg Kroah-Hartman --- fs/ioctl.c | 35 +++++++++++++++++++++++++++++++++++ include/linux/fs.h | 7 +++++++ 2 files changed, 42 insertions(+) --- a/fs/ioctl.c +++ b/fs/ioctl.c @@ -8,6 +8,7 @@ #include #include #include +#include #include #include #include @@ -719,3 +720,37 @@ SYSCALL_DEFINE3(ioctl, unsigned int, fd, { return ksys_ioctl(fd, cmd, arg); } + +#ifdef CONFIG_COMPAT +/** + * compat_ptr_ioctl - generic implementation of .compat_ioctl file operation + * + * This is not normally called as a function, but instead set in struct + * file_operations as + * + * .compat_ioctl = compat_ptr_ioctl, + * + * On most architectures, the compat_ptr_ioctl() just passes all arguments + * to the corresponding ->ioctl handler. The exception is arch/s390, where + * compat_ptr() clears the top bit of a 32-bit pointer value, so user space + * pointers to the second 2GB alias the first 2GB, as is the case for + * native 32-bit s390 user space. + * + * The compat_ptr_ioctl() function must therefore be used only with ioctl + * functions that either ignore the argument or pass a pointer to a + * compatible data type. + * + * If any ioctl command handled by fops->unlocked_ioctl passes a plain + * integer instead of a pointer, or any of the passed data types + * is incompatible between 32-bit and 64-bit architectures, a proper + * handler is required instead of compat_ptr_ioctl. + */ +long compat_ptr_ioctl(struct file *file, unsigned int cmd, unsigned long arg) +{ + if (!file->f_op->unlocked_ioctl) + return -ENOIOCTLCMD; + + return file->f_op->unlocked_ioctl(file, cmd, (unsigned long)compat_ptr(arg)); +} +EXPORT_SYMBOL(compat_ptr_ioctl); +#endif --- a/include/linux/fs.h +++ b/include/linux/fs.h @@ -1727,6 +1727,13 @@ int vfs_mkobj(struct dentry *, umode_t, extern long vfs_ioctl(struct file *file, unsigned int cmd, unsigned long arg); +#ifdef CONFIG_COMPAT +extern long compat_ptr_ioctl(struct file *file, unsigned int cmd, + unsigned long arg); +#else +#define compat_ptr_ioctl NULL +#endif + /* * VFS file helper functions. */ From patchwork Mon Dec 16 17:47:48 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Greg Kroah-Hartman X-Patchwork-Id: 181777 Delivered-To: patch@linaro.org Received: by 2002:a92:3001:0:0:0:0:0 with SMTP id x1csp4663225ile; Mon, 16 Dec 2019 10:14:52 -0800 (PST) X-Google-Smtp-Source: APXvYqxzdXKonQukg8cm0d5vuJTmjWqk6CLbAvsjw6r7cz7j4UMz2EJFV1iWMB7Pps2EkDXple1s X-Received: by 2002:aca:5582:: with SMTP id j124mr249579oib.20.1576520092597; Mon, 16 Dec 2019 10:14:52 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1576520092; cv=none; d=google.com; s=arc-20160816; b=zPECbofDfxGerI3yLp15NSaE0tpUW+SQgrkAuzDycgiv++ON9iof+22mV7ww47Pe6R 5QpdvxReWEFIQ7aMx2OIFVCkHsUF3MhEi+VBzCJW3bPcTnkiuQKx1tvzWC0h3/js4bT+ rJ+OdZI/QJgJSBPLnWy0kHIbOrSbqEUUUzLeDF9aFSm/knQqXGGE1HQIkn7RSrFq5cOJ IMEYgwsMw1mgZqvC5Lk7mIuc8Eq+IYHzV5yXLhrPPdlv25On7L86KfAKQHXt79dDY+09 9ogiirJbetK9D91eeJhl1Wdam5WYkjQnEAXITRoGpsQczCXQ3q4y80Ol7WmJ6ECdFudT L+sw== 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=iyjZME+lw7IsPYqyZ0lf+oZ8erQKFAibjhO6aCA+oRk=; b=yvp5ygA5s8LtBx+wHQ6R0KzgF0Zbw1T6W4dtD8D9xUmRIuJ3YMGu43x2tF9eAaGpOH Fmn0ngzl9QBMZpEUa2LGbaIN9dPeqgFKdxek7zHg+w8yYvjS/fqCTa7ARVaFNhR7yBWU jNjQ8M6m3vJY/wpaGNlYoNwQpfZNkO5Olyr+qSgZlYwFb/FgWZfY6x5byhEo8YmUe4a9 +tUIS7SDVAq/eRyqivleQEfRBU/SY7/Taiu2Fi2Hx0tiSR4DsGgFeneyTK02BzwBfaUu /jRQewcwR+0hNV8S2mdyIwu5IFfhSA8egYmLB9+XPd4LWOAVQIVD0kdSrZ9ACX83Lu/f TXyw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=HcwkN8dR; spf=pass (google.com: best guess record for domain of stable-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=stable-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 w11si10151684oig.45.2019.12.16.10.14.52; Mon, 16 Dec 2019 10:14:52 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of stable-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=HcwkN8dR; spf=pass (google.com: best guess record for domain of stable-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=stable-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730995AbfLPSOv (ORCPT + 14 others); Mon, 16 Dec 2019 13:14:51 -0500 Received: from mail.kernel.org ([198.145.29.99]:34728 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730990AbfLPSOt (ORCPT ); Mon, 16 Dec 2019 13:14:49 -0500 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 67E0C206E0; Mon, 16 Dec 2019 18:14:48 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1576520088; bh=LlivjxT72g1WSfdls0+LCRODihuebIfcJGAQ7u9gnkA=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=HcwkN8dRxop8xzX2uZSQX96MJG5wp7ElVjcGEX0uYYR4hdk55tTQjVN+VlD6f8Sk5 AFlciW72Hg9GbGt6iEnSyPX647vpeaMxmvTeCaK3UWGkeQQ4stgvHxqfy6/KVj6ImN Cek7t+PU2gABsdbI2NU3AaElZmrd1msQW/tciaic= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, "Yan, Zheng" , Arnd Bergmann Subject: [PATCH 5.4 012/177] ceph: fix compat_ioctl for ceph_dir_operations Date: Mon, 16 Dec 2019 18:47:48 +0100 Message-Id: <20191216174815.527496174@linuxfoundation.org> X-Mailer: git-send-email 2.24.1 In-Reply-To: <20191216174811.158424118@linuxfoundation.org> References: <20191216174811.158424118@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: Arnd Bergmann commit 18bd6caaef4021803dd0d031dc37c2d001d18a5b upstream. The ceph_ioctl function is used both for files and directories, but only the files support doing that in 32-bit compat mode. On the s390 architecture, there is also a problem with invalid 31-bit pointers that need to be passed through compat_ptr(). Use the new compat_ptr_ioctl() to address both issues. Note: When backporting this patch to stable kernels, "compat_ioctl: add compat_ptr_ioctl()" is needed as well. Reviewed-by: "Yan, Zheng" Cc: stable@vger.kernel.org Signed-off-by: Arnd Bergmann Signed-off-by: Greg Kroah-Hartman --- fs/ceph/dir.c | 1 + fs/ceph/file.c | 2 +- 2 files changed, 2 insertions(+), 1 deletion(-) --- a/fs/ceph/dir.c +++ b/fs/ceph/dir.c @@ -1809,6 +1809,7 @@ const struct file_operations ceph_dir_fo .open = ceph_open, .release = ceph_release, .unlocked_ioctl = ceph_ioctl, + .compat_ioctl = compat_ptr_ioctl, .fsync = ceph_fsync, .lock = ceph_lock, .flock = ceph_flock, --- a/fs/ceph/file.c +++ b/fs/ceph/file.c @@ -2188,7 +2188,7 @@ const struct file_operations ceph_file_f .splice_read = generic_file_splice_read, .splice_write = iter_file_splice_write, .unlocked_ioctl = ceph_ioctl, - .compat_ioctl = ceph_ioctl, + .compat_ioctl = compat_ptr_ioctl, .fallocate = ceph_fallocate, .copy_file_range = ceph_copy_file_range, }; From patchwork Mon Dec 16 17:49:06 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Greg Kroah-Hartman X-Patchwork-Id: 181783 Delivered-To: patch@linaro.org Received: by 2002:a92:3001:0:0:0:0:0 with SMTP id x1csp4669234ile; Mon, 16 Dec 2019 10:19:46 -0800 (PST) X-Google-Smtp-Source: APXvYqwACa7S0lj7IOUcPyOlu24fO2g1WgO6J7uyfIjqzoplUz9hETESBewOowedD9YQF+WPYAA0 X-Received: by 2002:a9d:6e12:: with SMTP id e18mr31351410otr.47.1576520386203; Mon, 16 Dec 2019 10:19:46 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1576520386; cv=none; d=google.com; s=arc-20160816; b=f4T8gl5SHLKKbIXKW0yOlriIbyEeOAIs0NnutmErhDwGCsOCuaFTma6RChVp0I0L4w iFooo2daDM+h6CRMDFfmMX+5utyiGgd1EkPPZd7nRAiQeAEJCbf4d5AghzsL71eM/pxw 4vBiIhU0cl09BU1cm2Mb7w5cncDyFqjwAFVrXUO+dNFMTg8bDIOUiOCWKQYO4pV9UW1o TtsK0xYRWeInlhYGWzPBseeV+/GYhGvnqRAEGHi5Je3E030RbdD9Cz/TWiXLMANeOv4d AclM2VBuKzc3m971BVVoT059+lN744KGcuJqZp+W0pryUOs5VGXe9ZcaCI27pX5dz+Gl psNw== 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=lJluwGm3tA+cF4KJsGnFV0z8itdNWl1ACtASmGzKe/E=; b=txWBpNzDER7XglDonF3apU92N5Uf9hbp7dx9lKESQ8eh20ehtV1J8ngopcx8fQQN/K ezJfhCzrrIWUauzeZblNvURt59bzfnTpnTbf0qaLvKCJfO/mAFCGS39XQx2IVkDXd5PG LuQNpnDtwzyXbVdR7buoXgHATBnYQGTe4ped0boKOtcO3HaDac0g0E3M0cjIGai7+Hbs ptR91zsFN5NPmk8XWHuACixIi/+yfoG6zzr4Jrwxy0JKA19oNWcj/JYgT2shpG1w9Ehs dKD5z52YOtPuAn4dS+vpmXXlHoV6JjLsQFa2pBeuQZwv+jQVNs3Mj/u0G+V2FV+z9V+L 11uQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=UZOr5Lk4; spf=pass (google.com: best guess record for domain of stable-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=stable-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 u12si10931474otq.51.2019.12.16.10.19.46; Mon, 16 Dec 2019 10:19:46 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of stable-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=UZOr5Lk4; spf=pass (google.com: best guess record for domain of stable-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=stable-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1731837AbfLPSTo (ORCPT + 14 others); Mon, 16 Dec 2019 13:19:44 -0500 Received: from mail.kernel.org ([198.145.29.99]:48356 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1731968AbfLPSTl (ORCPT ); Mon, 16 Dec 2019 13:19:41 -0500 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 A6B00207FF; Mon, 16 Dec 2019 18:19:40 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1576520381; bh=ykyXuBjdrvDsfkhIUrb1x8jlBJIu+YyjtsYEWvJ6v0M=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=UZOr5Lk4qOIc2nvxIJxRYk2dD2L96sYASTtCda+BPDF/UihAxGcHQ2DTTBLDwOOg7 n58gBQbX1xbnULzGCTF33qPLv9du8VDQ9zOZ1Cg0xZqaSUjyyQ85OSm0S+Z3rVTlsi QWoNQDgHZYbn0ih98BIV1oiE19r6ACKXTKiICyAU= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Shengjiu Wang , Nicolin Chen , Daniel Baluta , Mark Brown Subject: [PATCH 5.4 090/177] ASoC: fsl_audmix: Add spin lock to protect tdms Date: Mon, 16 Dec 2019 18:49:06 +0100 Message-Id: <20191216174839.092227511@linuxfoundation.org> X-Mailer: git-send-email 2.24.1 In-Reply-To: <20191216174811.158424118@linuxfoundation.org> References: <20191216174811.158424118@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: Shengjiu Wang commit fe965096c9495ddcf78ec163348105e2baf8d185 upstream. Audmix support two substream, When two substream start to run, the trigger function may be called by two substream in same time, that the priv->tdms may be updated wrongly. The expected priv->tdms is 0x3, but sometimes the result is 0x2, or 0x1. Fixes: be1df61cf06e ("ASoC: fsl: Add Audio Mixer CPU DAI driver") Signed-off-by: Shengjiu Wang Acked-by: Nicolin Chen Reviewed-by: Daniel Baluta Link: https://lore.kernel.org/r/1e706afe53fdd1fbbbc79277c48a98f8416ba873.1573458378.git.shengjiu.wang@nxp.com Signed-off-by: Mark Brown Cc: Signed-off-by: Greg Kroah-Hartman --- sound/soc/fsl/fsl_audmix.c | 6 ++++++ sound/soc/fsl/fsl_audmix.h | 1 + 2 files changed, 7 insertions(+) --- a/sound/soc/fsl/fsl_audmix.c +++ b/sound/soc/fsl/fsl_audmix.c @@ -286,6 +286,7 @@ static int fsl_audmix_dai_trigger(struct struct snd_soc_dai *dai) { struct fsl_audmix *priv = snd_soc_dai_get_drvdata(dai); + unsigned long lock_flags; /* Capture stream shall not be handled */ if (substream->stream == SNDRV_PCM_STREAM_CAPTURE) @@ -295,12 +296,16 @@ static int fsl_audmix_dai_trigger(struct case SNDRV_PCM_TRIGGER_START: case SNDRV_PCM_TRIGGER_RESUME: case SNDRV_PCM_TRIGGER_PAUSE_RELEASE: + spin_lock_irqsave(&priv->lock, lock_flags); priv->tdms |= BIT(dai->driver->id); + spin_unlock_irqrestore(&priv->lock, lock_flags); break; case SNDRV_PCM_TRIGGER_STOP: case SNDRV_PCM_TRIGGER_SUSPEND: case SNDRV_PCM_TRIGGER_PAUSE_PUSH: + spin_lock_irqsave(&priv->lock, lock_flags); priv->tdms &= ~BIT(dai->driver->id); + spin_unlock_irqrestore(&priv->lock, lock_flags); break; default: return -EINVAL; @@ -491,6 +496,7 @@ static int fsl_audmix_probe(struct platf return PTR_ERR(priv->ipg_clk); } + spin_lock_init(&priv->lock); platform_set_drvdata(pdev, priv); pm_runtime_enable(dev); --- a/sound/soc/fsl/fsl_audmix.h +++ b/sound/soc/fsl/fsl_audmix.h @@ -96,6 +96,7 @@ struct fsl_audmix { struct platform_device *pdev; struct regmap *regmap; struct clk *ipg_clk; + spinlock_t lock; /* Protect tdms */ u8 tdms; }; From patchwork Mon Dec 16 17:50:20 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Greg Kroah-Hartman X-Patchwork-Id: 181784 Delivered-To: patch@linaro.org Received: by 2002:a92:3001:0:0:0:0:0 with SMTP id x1csp4670750ile; Mon, 16 Dec 2019 10:21:06 -0800 (PST) X-Google-Smtp-Source: APXvYqzprcsQeIRobVwHCAIbqn0dIVx/UvZLWfoVELQwgo9sI8tmPDt8qgUP4ZqxmamcKPQRWKf0 X-Received: by 2002:aca:b04:: with SMTP id 4mr189140oil.151.1576520465811; Mon, 16 Dec 2019 10:21:05 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1576520465; cv=none; d=google.com; s=arc-20160816; b=NKmXfhD3N3AwYcIR2BdH9yQGQncwpXnuE0eH5NMMDMDBwaK/ZjGyVqi2oCbu5fk6Ag h//wc1KBBTjXyt+6h+qnmogCAKdprTaZfL098vTUjga5ePXbDaPQKYXX4Nc9PI7TMVSX V4x4CTRMMiU/xpbQ7TsI46GfRPb5X4417r6PhxS3Qo+/iLSZ0ZJhPll3k49RG/X73H4E +lvN20wZUD/xSR6cf8a5S5Gyx55yRpNapS76/l+Qc4sZPF+WDsVLKMYbHu8lw5yUXs7k ziGmMsByot6pmEkplCfV35wmA2/bHt+RtHhC/maexGnemn5DRVPiQXeDrA4SyVhfQTFu 0wVw== 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=0TM2IdAYgtmg1IH4Y3EfYz1rH2KO8pxU3aeN3MEt1Fk=; b=wqPyBILHUbyQZ2usEPs4eK6DACW/jWbAobiEpTdEolcQMTsIPt2MZg9QZo8k1NChtx 0NIU0PzP6RKSu2/47vxgJcBqb7+G9T7kmNdibnmfdKcZOy6jO5hrz0sTR3LGbee2eAW+ VorUhxDN0wjqpFV0IKVsZSuYId8EdV7eT/+x2cwwh+o/g8ZIKxBy9PZTyScGahVxjjA8 gg/xWXFNKRhN63mBd+rAJBd9TPZ24J5EVnKXJh5VPaYcr/qCEWdq7zZM+sZywbr5PIZH gnFCEmPkAQW2x3ekbODZUHOvPFFF1wjtUX+PEtdFGu29Na/BCdz7I+uGV6MCxQFNTd8S 4C1Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=NlbFjfDU; spf=pass (google.com: best guess record for domain of stable-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=stable-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 p124si632904oig.195.2019.12.16.10.21.05; Mon, 16 Dec 2019 10:21:05 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of stable-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=NlbFjfDU; spf=pass (google.com: best guess record for domain of stable-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=stable-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1732192AbfLPSVE (ORCPT + 14 others); Mon, 16 Dec 2019 13:21:04 -0500 Received: from mail.kernel.org ([198.145.29.99]:53516 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1732183AbfLPSVE (ORCPT ); Mon, 16 Dec 2019 13:21:04 -0500 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 AD5252166E; Mon, 16 Dec 2019 18:21:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1576520463; bh=Uv07aAKk39n58UabQhF6Iu9klPWARZ2sCElrDYxIY9k=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=NlbFjfDUSI/z1+yS/mjcv0oZIoKMS800oD7IJA7L8zniNR8dRk79gK5C4wAZMF8xB V2xaTkxNtgDT6R5uAO2aAZ11k5t7T1aQoLullll2EMQw+uIt4bm+o0g6f7O9dIwz2Z NjgRhSxVyklgPNt3zo+tZbAzWQgncqgtgw4rikUs= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Nicolas Geoffray , "Joel Fernandes (Google)" , Hugh Dickins , Shuah Khan , Andrew Morton , Linus Torvalds Subject: [PATCH 5.4 164/177] mm, memfd: fix COW issue on MAP_PRIVATE and F_SEAL_FUTURE_WRITE mappings Date: Mon, 16 Dec 2019 18:50:20 +0100 Message-Id: <20191216174849.586463116@linuxfoundation.org> X-Mailer: git-send-email 2.24.1 In-Reply-To: <20191216174811.158424118@linuxfoundation.org> References: <20191216174811.158424118@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: Nicolas Geoffray commit 05d351102dbe4e103d6bdac18b1122cd3cd04925 upstream. F_SEAL_FUTURE_WRITE has unexpected behavior when used with MAP_PRIVATE: A private mapping created after the memfd file that gets sealed with F_SEAL_FUTURE_WRITE loses the copy-on-write at fork behavior, meaning children and parent share the same memory, even though the mapping is private. The reason for this is due to the code below: static int shmem_mmap(struct file *file, struct vm_area_struct *vma) { struct shmem_inode_info *info = SHMEM_I(file_inode(file)); if (info->seals & F_SEAL_FUTURE_WRITE) { /* * New PROT_WRITE and MAP_SHARED mmaps are not allowed when * "future write" seal active. */ if ((vma->vm_flags & VM_SHARED) && (vma->vm_flags & VM_WRITE)) return -EPERM; /* * Since the F_SEAL_FUTURE_WRITE seals allow for a MAP_SHARED * read-only mapping, take care to not allow mprotect to revert * protections. */ vma->vm_flags &= ~(VM_MAYWRITE); } ... } And for the mm to know if a mapping is copy-on-write: static inline bool is_cow_mapping(vm_flags_t flags) { return (flags & (VM_SHARED | VM_MAYWRITE)) == VM_MAYWRITE; } The patch fixes the issue by making the mprotect revert protection happen only for shared mappings. For private mappings, using mprotect will have no effect on the seal behavior. The F_SEAL_FUTURE_WRITE feature was introduced in v5.1 so v5.3.x stable kernels would need a backport. [akpm@linux-foundation.org: reflow comment, per Christoph] Link: http://lkml.kernel.org/r/20191107195355.80608-1-joel@joelfernandes.org Fixes: ab3948f58ff84 ("mm/memfd: add an F_SEAL_FUTURE_WRITE seal to memfd") Signed-off-by: Nicolas Geoffray Signed-off-by: Joel Fernandes (Google) Cc: Hugh Dickins Cc: Shuah Khan Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman --- mm/shmem.c | 11 +++++++---- 1 file changed, 7 insertions(+), 4 deletions(-) --- a/mm/shmem.c +++ b/mm/shmem.c @@ -2213,11 +2213,14 @@ static int shmem_mmap(struct file *file, return -EPERM; /* - * Since the F_SEAL_FUTURE_WRITE seals allow for a MAP_SHARED - * read-only mapping, take care to not allow mprotect to revert - * protections. + * Since an F_SEAL_FUTURE_WRITE sealed memfd can be mapped as + * MAP_SHARED and read-only, take care to not allow mprotect to + * revert protections on such mappings. Do this only for shared + * mappings. For private mappings, don't need to mask + * VM_MAYWRITE as we still want them to be COW-writable. */ - vma->vm_flags &= ~(VM_MAYWRITE); + if (vma->vm_flags & VM_SHARED) + vma->vm_flags &= ~(VM_MAYWRITE); } file_accessed(file);