From patchwork Mon Aug 24 08:31:03 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Greg KH X-Patchwork-Id: 265066 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=-13.7 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_PATCH, MAILING_LIST_MULTI, SIGNED_OFF_BY, SPF_HELO_NONE, SPF_PASS, USER_AGENT_GIT autolearn=unavailable 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 21B01C433E3 for ; Mon, 24 Aug 2020 09:28:58 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id E9FFD207DF for ; Mon, 24 Aug 2020 09:28:57 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1598261338; bh=29g9Wr5ormSMSU1CxWGIebP4jV1FGScQfXafSepgtas=; h=From:To:Cc:Subject:Date:In-Reply-To:References:List-ID:From; b=SywpWvkhZKykFGZVhvWTXVMXMnADxZCZ2f+LJDHYt8/PuQaZJuibgrwSSFUTfgvKx GAQ3jHQvimm98l3lGBsM3lp/GFh6ecQ4455g4drZSWFRHwHFN0riwfkVKXf/4r6Tpg CwvJEK/50uQlGPVALQMwPbDhAPrwcfMHhYvLOP4E= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729897AbgHXIvT (ORCPT ); Mon, 24 Aug 2020 04:51:19 -0400 Received: from mail.kernel.org ([198.145.29.99]:56192 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728968AbgHXIvS (ORCPT ); Mon, 24 Aug 2020 04:51:18 -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 7B799204FD; Mon, 24 Aug 2020 08:51:17 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1598259078; bh=29g9Wr5ormSMSU1CxWGIebP4jV1FGScQfXafSepgtas=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=GjNSpcvNaID04avLTrAt8isfwDZjrTcTBewR1GEGdr+Yf/i2uTF308CB8I0qWw+Ic uDDbUpMaJbrjXVtG9U2IbCrphVI+ZwRJUlHtm9TdsvW37jUquJ2k1X2jFidJWNetMu M2+cCh0+ndOn8MvaUDwYGH7bAfMTtgyLWLhgQptY= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Masami Hiramatsu , Srikar Dronamraju , Andi Kleen , Oleg Nesterov , Arnaldo Carvalho de Melo , Sasha Levin Subject: [PATCH 4.9 04/39] perf probe: Fix memory leakage when the probe point is not found Date: Mon, 24 Aug 2020 10:31:03 +0200 Message-Id: <20200824082348.697579083@linuxfoundation.org> X-Mailer: git-send-email 2.28.0 In-Reply-To: <20200824082348.445866152@linuxfoundation.org> References: <20200824082348.445866152@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: Masami Hiramatsu [ Upstream commit 12d572e785b15bc764e956caaa8a4c846fd15694 ] Fix the memory leakage in debuginfo__find_trace_events() when the probe point is not found in the debuginfo. If there is no probe point found in the debuginfo, debuginfo__find_probes() will NOT return -ENOENT, but 0. Thus the caller of debuginfo__find_probes() must check the tf.ntevs and release the allocated memory for the array of struct probe_trace_event. The current code releases the memory only if the debuginfo__find_probes() hits an error but not checks tf.ntevs. In the result, the memory allocated on *tevs are not released if tf.ntevs == 0. This fixes the memory leakage by checking tf.ntevs == 0 in addition to ret < 0. Fixes: ff741783506c ("perf probe: Introduce debuginfo to encapsulate dwarf information") Signed-off-by: Masami Hiramatsu Reviewed-by: Srikar Dronamraju Cc: Andi Kleen Cc: Oleg Nesterov Cc: stable@vger.kernel.org Link: http://lore.kernel.org/lkml/159438668346.62703.10887420400718492503.stgit@devnote2 Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin --- tools/perf/util/probe-finder.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/perf/util/probe-finder.c b/tools/perf/util/probe-finder.c index 7d0d44b4f3d5c..863f668a07355 100644 --- a/tools/perf/util/probe-finder.c +++ b/tools/perf/util/probe-finder.c @@ -1351,7 +1351,7 @@ int debuginfo__find_trace_events(struct debuginfo *dbg, tf.ntevs = 0; ret = debuginfo__find_probes(dbg, &tf.pf); - if (ret < 0) { + if (ret < 0 || tf.ntevs == 0) { for (i = 0; i < tf.ntevs; i++) clear_probe_trace_event(&tf.tevs[i]); zfree(tevs); From patchwork Mon Aug 24 08:31:08 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Greg KH X-Patchwork-Id: 265141 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=-13.7 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_PATCH, MAILING_LIST_MULTI, SIGNED_OFF_BY, SPF_HELO_NONE, 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 C2D09C433E3 for ; Mon, 24 Aug 2020 08:52:03 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id A26C22075B for ; Mon, 24 Aug 2020 08:52:03 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1598259123; bh=sUOG9rffSGekvZ1pjLm7i1hfi3HowdlJF8EY5e/9Qjc=; h=From:To:Cc:Subject:Date:In-Reply-To:References:List-ID:From; b=mtRQf3FaXwAUA7AaSbBhQzF3OOuXBPtmOQkvY/oNOiS5SVjz3ukF3x4iT1TrDwRxG 5P9NtqLcslbOSHT7pNTEWF5d0b+drqNLEO6SZ+JWuvfi0X3991DWSlYyB77pMYj3ia j9j/1HsyqyvtkF/c6PLfQjo40s7Uk+oKDSBxbesk= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730035AbgHXIwC (ORCPT ); Mon, 24 Aug 2020 04:52:02 -0400 Received: from mail.kernel.org ([198.145.29.99]:57682 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729782AbgHXIwC (ORCPT ); Mon, 24 Aug 2020 04:52:02 -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 D54152072D; Mon, 24 Aug 2020 08:52:00 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1598259121; bh=sUOG9rffSGekvZ1pjLm7i1hfi3HowdlJF8EY5e/9Qjc=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=fr9lcEfMhIonoEosTvjk4df2TKeGkW6NwFfWJmnhyu1vBqvmOfcDRVDIaWQuXA0Ba e3C2AprCw4SbnV3cDKE/JV3GMt610mOYVbFMt/TXwSxpvzE+03KS/TP2903OJHHhZp +pcJp/kTn1J30T7wWtK3Ql1epPT284raTQuDadH4= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Marcos Paulo de Souza , David Sterba , Sasha Levin Subject: [PATCH 4.9 09/39] btrfs: export helpers for subvolume name/id resolution Date: Mon, 24 Aug 2020 10:31:08 +0200 Message-Id: <20200824082348.945938078@linuxfoundation.org> X-Mailer: git-send-email 2.28.0 In-Reply-To: <20200824082348.445866152@linuxfoundation.org> References: <20200824082348.445866152@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: Marcos Paulo de Souza [ Upstream commit c0c907a47dccf2cf26251a8fb4a8e7a3bf79ce84 ] The functions will be used outside of export.c and super.c to allow resolving subvolume name from a given id, eg. for subvolume deletion by id ioctl. Signed-off-by: Marcos Paulo de Souza Reviewed-by: David Sterba [ split from the next patch ] Signed-off-by: David Sterba Signed-off-by: Sasha Levin --- fs/btrfs/ctree.h | 2 ++ fs/btrfs/export.c | 8 ++++---- fs/btrfs/export.h | 5 +++++ fs/btrfs/super.c | 8 ++++---- 4 files changed, 15 insertions(+), 8 deletions(-) diff --git a/fs/btrfs/ctree.h b/fs/btrfs/ctree.h index 2bc37d03d4075..abfc090510480 100644 --- a/fs/btrfs/ctree.h +++ b/fs/btrfs/ctree.h @@ -3261,6 +3261,8 @@ ssize_t btrfs_listxattr(struct dentry *dentry, char *buffer, size_t size); int btrfs_parse_options(struct btrfs_root *root, char *options, unsigned long new_flags); int btrfs_sync_fs(struct super_block *sb, int wait); +char *btrfs_get_subvol_name_from_objectid(struct btrfs_fs_info *fs_info, + u64 subvol_objectid); static inline __printf(2, 3) void btrfs_no_printk(const struct btrfs_fs_info *fs_info, const char *fmt, ...) diff --git a/fs/btrfs/export.c b/fs/btrfs/export.c index 2513a7f533342..92f80ed642194 100644 --- a/fs/btrfs/export.c +++ b/fs/btrfs/export.c @@ -55,9 +55,9 @@ static int btrfs_encode_fh(struct inode *inode, u32 *fh, int *max_len, return type; } -static struct dentry *btrfs_get_dentry(struct super_block *sb, u64 objectid, - u64 root_objectid, u32 generation, - int check_generation) +struct dentry *btrfs_get_dentry(struct super_block *sb, u64 objectid, + u64 root_objectid, u32 generation, + int check_generation) { struct btrfs_fs_info *fs_info = btrfs_sb(sb); struct btrfs_root *root; @@ -150,7 +150,7 @@ static struct dentry *btrfs_fh_to_dentry(struct super_block *sb, struct fid *fh, return btrfs_get_dentry(sb, objectid, root_objectid, generation, 1); } -static struct dentry *btrfs_get_parent(struct dentry *child) +struct dentry *btrfs_get_parent(struct dentry *child) { struct inode *dir = d_inode(child); struct btrfs_root *root = BTRFS_I(dir)->root; diff --git a/fs/btrfs/export.h b/fs/btrfs/export.h index 074348a95841f..7a305e5549991 100644 --- a/fs/btrfs/export.h +++ b/fs/btrfs/export.h @@ -16,4 +16,9 @@ struct btrfs_fid { u64 parent_root_objectid; } __attribute__ ((packed)); +struct dentry *btrfs_get_dentry(struct super_block *sb, u64 objectid, + u64 root_objectid, u32 generation, + int check_generation); +struct dentry *btrfs_get_parent(struct dentry *child); + #endif diff --git a/fs/btrfs/super.c b/fs/btrfs/super.c index 9286603a6a98b..af5be060c651f 100644 --- a/fs/btrfs/super.c +++ b/fs/btrfs/super.c @@ -948,8 +948,8 @@ out: return error; } -static char *get_subvol_name_from_objectid(struct btrfs_fs_info *fs_info, - u64 subvol_objectid) +char *btrfs_get_subvol_name_from_objectid(struct btrfs_fs_info *fs_info, + u64 subvol_objectid) { struct btrfs_root *root = fs_info->tree_root; struct btrfs_root *fs_root; @@ -1430,8 +1430,8 @@ static struct dentry *mount_subvol(const char *subvol_name, u64 subvol_objectid, goto out; } } - subvol_name = get_subvol_name_from_objectid(btrfs_sb(mnt->mnt_sb), - subvol_objectid); + subvol_name = btrfs_get_subvol_name_from_objectid( + btrfs_sb(mnt->mnt_sb), subvol_objectid); if (IS_ERR(subvol_name)) { root = ERR_CAST(subvol_name); subvol_name = NULL; From patchwork Mon Aug 24 08:31:09 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Greg KH X-Patchwork-Id: 265070 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=-13.7 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_PATCH, MAILING_LIST_MULTI, SIGNED_OFF_BY, SPF_HELO_NONE, SPF_PASS, USER_AGENT_GIT autolearn=unavailable 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 85BB8C433E3 for ; Mon, 24 Aug 2020 09:27:54 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 647DC2074D for ; Mon, 24 Aug 2020 09:27:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1598261274; bh=uWAVItaEtN1KbR+X2t+2V6dYQWvx+SdeH4DwBSc9XsQ=; h=From:To:Cc:Subject:Date:In-Reply-To:References:List-ID:From; b=r7qcUP5fOlpgtHv3IyQHuGTQQa3+TJbPJzg3WxtvccsVz8J6PHroyMxSOHND3lmKN 9z7/rh5HHK9Thm/zdlt67i1Lg/AIqV4G+9BsXP/UYcoe2SBpml9VyYPXJr1jAJQOcs wEMkXRbOzufq1OiRm+s3P5OKYl1Oi20gFovfxdqQ= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730042AbgHXIwG (ORCPT ); Mon, 24 Aug 2020 04:52:06 -0400 Received: from mail.kernel.org ([198.145.29.99]:57834 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730039AbgHXIwE (ORCPT ); Mon, 24 Aug 2020 04:52:04 -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 076B92075B; Mon, 24 Aug 2020 08:52:03 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1598259124; bh=uWAVItaEtN1KbR+X2t+2V6dYQWvx+SdeH4DwBSc9XsQ=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=rC0tJ4XyniN45EvVCsZveOk9+9J+ewcU2LCQoufTuO0Ju3eghmgXvAIWFrA+95Z1e K93VY4N8dV+rgHxfQl3S3yrqkQSeBydOv2CSb2FhXJj/gp1YhBLjfrv4YVw1Ji9bae hnjzHof05Yz2PGLFZgsaASJ0b2W8ptdLNwE7UuuE= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Chris Murphy , Josef Bacik , David Sterba , Sasha Levin Subject: [PATCH 4.9 10/39] btrfs: dont show full path of bind mounts in subvol= Date: Mon, 24 Aug 2020 10:31:09 +0200 Message-Id: <20200824082348.996775982@linuxfoundation.org> X-Mailer: git-send-email 2.28.0 In-Reply-To: <20200824082348.445866152@linuxfoundation.org> References: <20200824082348.445866152@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: Josef Bacik [ Upstream commit 3ef3959b29c4a5bd65526ab310a1a18ae533172a ] Chris Murphy reported a problem where rpm ostree will bind mount a bunch of things for whatever voodoo it's doing. But when it does this /proc/mounts shows something like /dev/sda /mnt/test btrfs rw,relatime,subvolid=256,subvol=/foo 0 0 /dev/sda /mnt/test/baz btrfs rw,relatime,subvolid=256,subvol=/foo/bar 0 0 Despite subvolid=256 being subvol=/foo. This is because we're just spitting out the dentry of the mount point, which in the case of bind mounts is the source path for the mountpoint. Instead we should spit out the path to the actual subvol. Fix this by looking up the name for the subvolid we have mounted. With this fix the same test looks like this /dev/sda /mnt/test btrfs rw,relatime,subvolid=256,subvol=/foo 0 0 /dev/sda /mnt/test/baz btrfs rw,relatime,subvolid=256,subvol=/foo 0 0 Reported-by: Chris Murphy CC: stable@vger.kernel.org # 4.4+ Signed-off-by: Josef Bacik Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Sasha Levin --- fs/btrfs/super.c | 10 ++++++++-- 1 file changed, 8 insertions(+), 2 deletions(-) diff --git a/fs/btrfs/super.c b/fs/btrfs/super.c index af5be060c651f..3a0cb745164f8 100644 --- a/fs/btrfs/super.c +++ b/fs/btrfs/super.c @@ -1225,6 +1225,7 @@ static int btrfs_show_options(struct seq_file *seq, struct dentry *dentry) struct btrfs_fs_info *info = btrfs_sb(dentry->d_sb); struct btrfs_root *root = info->tree_root; char *compress_type; + const char *subvol_name; if (btrfs_test_opt(info, DEGRADED)) seq_puts(seq, ",degraded"); @@ -1311,8 +1312,13 @@ static int btrfs_show_options(struct seq_file *seq, struct dentry *dentry) #endif seq_printf(seq, ",subvolid=%llu", BTRFS_I(d_inode(dentry))->root->root_key.objectid); - seq_puts(seq, ",subvol="); - seq_dentry(seq, dentry, " \t\n\\"); + subvol_name = btrfs_get_subvol_name_from_objectid(info, + BTRFS_I(d_inode(dentry))->root->root_key.objectid); + if (!IS_ERR(subvol_name)) { + seq_puts(seq, ",subvol="); + seq_escape(seq, subvol_name, " \t\n\\"); + kfree(subvol_name); + } return 0; } From patchwork Mon Aug 24 08:31:12 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Greg KH X-Patchwork-Id: 265140 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=-10.7 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI, SIGNED_OFF_BY,SPF_HELO_NONE,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 ECBB8C433E1 for ; Mon, 24 Aug 2020 08:52:16 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id CAC8A2075B for ; Mon, 24 Aug 2020 08:52:16 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1598259136; bh=0B0DRFdWdWQdHL0+g7iBEWqDYDKRRqAchK9/0m+Xyfo=; h=From:To:Cc:Subject:Date:In-Reply-To:References:List-ID:From; b=cbfKcTN/twA1EzF8eoXHXiaQuNGIz9EzvmZwC9KPJG2xdzTeOiOeiasS8lSYXkqZw cGhnmnlj+mDxqgrV/2VdIWwMDHsxsNt3ff8CMat0UZSSqyLLIQ4FqZf5vfB5mFV3q3 KVb7PxhQz3/MxIekLtA6jGPXqp3LbD23yqxgReo4= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730068AbgHXIwP (ORCPT ); Mon, 24 Aug 2020 04:52:15 -0400 Received: from mail.kernel.org ([198.145.29.99]:58044 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729494AbgHXIwM (ORCPT ); Mon, 24 Aug 2020 04:52:12 -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 23A5C204FD; Mon, 24 Aug 2020 08:52:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1598259131; bh=0B0DRFdWdWQdHL0+g7iBEWqDYDKRRqAchK9/0m+Xyfo=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=bUM9PzMqm2n1R9bcwUPT+BURm02o0TFAneooc8nBvwyJbLzfiOb5opr5/x/LP7HUC ibwNZJRCW/4IGXR6uvf2WMjKopfiyI11jnQN2m/qtBT5Vm6c3D9lycJDvh6m43KmDV Hr5NvISEkUs9yo+y/zns+4q4f0NEIRGShR+fpNCA= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Doug Berger , Andrew Morton , Michal Hocko , Jason Baron , David Rientjes , "Kirill A. Shutemov" , Linus Torvalds Subject: [PATCH 4.9 13/39] mm: include CMA pages in lowmem_reserve at boot Date: Mon, 24 Aug 2020 10:31:12 +0200 Message-Id: <20200824082349.153225426@linuxfoundation.org> X-Mailer: git-send-email 2.28.0 In-Reply-To: <20200824082348.445866152@linuxfoundation.org> References: <20200824082348.445866152@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: Doug Berger commit e08d3fdfe2dafa0331843f70ce1ff6c1c4900bf4 upstream. The lowmem_reserve arrays provide a means of applying pressure against allocations from lower zones that were targeted at higher zones. Its values are a function of the number of pages managed by higher zones and are assigned by a call to the setup_per_zone_lowmem_reserve() function. The function is initially called at boot time by the function init_per_zone_wmark_min() and may be called later by accesses of the /proc/sys/vm/lowmem_reserve_ratio sysctl file. The function init_per_zone_wmark_min() was moved up from a module_init to a core_initcall to resolve a sequencing issue with khugepaged. Unfortunately this created a sequencing issue with CMA page accounting. The CMA pages are added to the managed page count of a zone when cma_init_reserved_areas() is called at boot also as a core_initcall. This makes it uncertain whether the CMA pages will be added to the managed page counts of their zones before or after the call to init_per_zone_wmark_min() as it becomes dependent on link order. With the current link order the pages are added to the managed count after the lowmem_reserve arrays are initialized at boot. This means the lowmem_reserve values at boot may be lower than the values used later if /proc/sys/vm/lowmem_reserve_ratio is accessed even if the ratio values are unchanged. In many cases the difference is not significant, but for example an ARM platform with 1GB of memory and the following memory layout cma: Reserved 256 MiB at 0x0000000030000000 Zone ranges: DMA [mem 0x0000000000000000-0x000000002fffffff] Normal empty HighMem [mem 0x0000000030000000-0x000000003fffffff] would result in 0 lowmem_reserve for the DMA zone. This would allow userspace to deplete the DMA zone easily. Funnily enough $ cat /proc/sys/vm/lowmem_reserve_ratio would fix up the situation because as a side effect it forces setup_per_zone_lowmem_reserve. This commit breaks the link order dependency by invoking init_per_zone_wmark_min() as a postcore_initcall so that the CMA pages have the chance to be properly accounted in their zone(s) and allowing the lowmem_reserve arrays to receive consistent values. Fixes: bc22af74f271 ("mm: update min_free_kbytes from khugepaged after core initialization") Signed-off-by: Doug Berger Signed-off-by: Andrew Morton Acked-by: Michal Hocko Cc: Jason Baron Cc: David Rientjes Cc: "Kirill A. Shutemov" Cc: Link: http://lkml.kernel.org/r/1597423766-27849-1-git-send-email-opendmb@gmail.com Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman --- mm/page_alloc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/mm/page_alloc.c +++ b/mm/page_alloc.c @@ -6782,7 +6782,7 @@ int __meminit init_per_zone_wmark_min(vo return 0; } -core_initcall(init_per_zone_wmark_min) +postcore_initcall(init_per_zone_wmark_min) /* * min_free_kbytes_sysctl_handler - just a wrapper around proc_dointvec() so From patchwork Mon Aug 24 08:31:13 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Greg KH X-Patchwork-Id: 265071 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=-10.7 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI, SIGNED_OFF_BY, SPF_HELO_NONE, SPF_PASS, USER_AGENT_GIT autolearn=unavailable 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 AE7F1C433E1 for ; Mon, 24 Aug 2020 09:27:34 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 816982074D for ; Mon, 24 Aug 2020 09:27:34 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1598261254; bh=Tt0oAXWRf5+Ttfk1X82OJ9XAYKwy9lkTMfu3XrypqKw=; h=From:To:Cc:Subject:Date:In-Reply-To:References:List-ID:From; b=K4pVtWoS/LncxPZKyCkzwE1iinNFBj8/PYfSjlwXA1osLJFkl+sd0ei+tSWC3x2Tq JshgXsOQZNZEaWAO7SeWAO37dda6s4EW78irH8RByE/vFvVlSoKbNZIQ/k5nd450a/ WoW5OmG0eIERh8aVtCO42djY+KhKHwQGOJNSw91A= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730073AbgHXIwQ (ORCPT ); Mon, 24 Aug 2020 04:52:16 -0400 Received: from mail.kernel.org ([198.145.29.99]:58182 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728832AbgHXIwP (ORCPT ); Mon, 24 Aug 2020 04:52:15 -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 C57D1207D3; Mon, 24 Aug 2020 08:52:13 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1598259134; bh=Tt0oAXWRf5+Ttfk1X82OJ9XAYKwy9lkTMfu3XrypqKw=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=Jb+UC9k7PC5l0XLk9e5yU68qhvS+xRuUOOEeT2HSyNylQ31JE26X/hlor3y12JHIA 4TMPm+X7Iea1ltjCjgi5s2QQ8CPAmMG0sJ41ycBKBRs/vQ3ukspqaIE3C12R+zlnUS CBZLJ5cWBUCvjzABnQufQvqUOc6XDWScUpyZ95g4= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Charan Teja Reddy , Andrew Morton , David Hildenbrand , David Rientjes , Michal Hocko , Vlastimil Babka , Vinayak Menon , Linus Torvalds Subject: [PATCH 4.9 14/39] mm, page_alloc: fix core hung in free_pcppages_bulk() Date: Mon, 24 Aug 2020 10:31:13 +0200 Message-Id: <20200824082349.214880399@linuxfoundation.org> X-Mailer: git-send-email 2.28.0 In-Reply-To: <20200824082348.445866152@linuxfoundation.org> References: <20200824082348.445866152@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: Charan Teja Reddy commit 88e8ac11d2ea3acc003cf01bb5a38c8aa76c3cfd upstream. The following race is observed with the repeated online, offline and a delay between two successive online of memory blocks of movable zone. P1 P2 Online the first memory block in the movable zone. The pcp struct values are initialized to default values,i.e., pcp->high = 0 & pcp->batch = 1. Allocate the pages from the movable zone. Try to Online the second memory block in the movable zone thus it entered the online_pages() but yet to call zone_pcp_update(). This process is entered into the exit path thus it tries to release the order-0 pages to pcp lists through free_unref_page_commit(). As pcp->high = 0, pcp->count = 1 proceed to call the function free_pcppages_bulk(). Update the pcp values thus the new pcp values are like, say, pcp->high = 378, pcp->batch = 63. Read the pcp's batch value using READ_ONCE() and pass the same to free_pcppages_bulk(), pcp values passed here are, batch = 63, count = 1. Since num of pages in the pcp lists are less than ->batch, then it will stuck in while(list_empty(list)) loop with interrupts disabled thus a core hung. Avoid this by ensuring free_pcppages_bulk() is called with proper count of pcp list pages. The mentioned race is some what easily reproducible without [1] because pcp's are not updated for the first memory block online and thus there is a enough race window for P2 between alloc+free and pcp struct values update through onlining of second memory block. With [1], the race still exists but it is very narrow as we update the pcp struct values for the first memory block online itself. This is not limited to the movable zone, it could also happen in cases with the normal zone (e.g., hotplug to a node that only has DMA memory, or no other memory yet). [1]: https://patchwork.kernel.org/patch/11696389/ Fixes: 5f8dcc21211a ("page-allocator: split per-cpu list into one-list-per-migrate-type") Signed-off-by: Charan Teja Reddy Signed-off-by: Andrew Morton Acked-by: David Hildenbrand Acked-by: David Rientjes Acked-by: Michal Hocko Cc: Michal Hocko Cc: Vlastimil Babka Cc: Vinayak Menon Cc: [2.6+] Link: http://lkml.kernel.org/r/1597150703-19003-1-git-send-email-charante@codeaurora.org Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman --- mm/page_alloc.c | 5 +++++ 1 file changed, 5 insertions(+) --- a/mm/page_alloc.c +++ b/mm/page_alloc.c @@ -1116,6 +1116,11 @@ static void free_pcppages_bulk(struct zo if (nr_scanned) __mod_node_page_state(zone->zone_pgdat, NR_PAGES_SCANNED, -nr_scanned); + /* + * Ensure proper count is passed which otherwise would stuck in the + * below while (list_empty(list)) loop. + */ + count = min(pcp->count, count); while (count) { struct page *page; struct list_head *list; From patchwork Mon Aug 24 08:31:15 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Greg KH X-Patchwork-Id: 265144 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=-13.7 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_PATCH, MAILING_LIST_MULTI, SIGNED_OFF_BY, SPF_HELO_NONE, 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 0D3F0C433DF for ; Mon, 24 Aug 2020 08:51:35 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id E26C82072D for ; Mon, 24 Aug 2020 08:51:34 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1598259094; bh=nC8NZqLMbKGC1b1B62iictftXYj2AuovET5e6dcqmfk=; h=From:To:Cc:Subject:Date:In-Reply-To:References:List-ID:From; b=L+QYKydQjgVnD4O8sE5JyU68RERLJzDUccY/U6UvUqkYrGAY1TVWSp0EcYbUC3xBC 8H5RlHniWtiH8UU6z2y7TouwVXLF1MKGNXzvtL1f+zsSXPNwJCWQ2P9gqiCOtrvMi4 E5/c76dHr+XNn7+i6Ymh6LJUe0/vjY7UNvVmW1xQ= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729706AbgHXIvc (ORCPT ); Mon, 24 Aug 2020 04:51:32 -0400 Received: from mail.kernel.org ([198.145.29.99]:56560 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729254AbgHXIva (ORCPT ); Mon, 24 Aug 2020 04:51:30 -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 D142A207D3; Mon, 24 Aug 2020 08:51:28 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1598259089; bh=nC8NZqLMbKGC1b1B62iictftXYj2AuovET5e6dcqmfk=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=x7paNuEmc6OXf5EgVkO5Bps0exayXnP5WhaaN4aTRVbLOsPS2+HxKbVSLgHo5IUYb NsY920TOcgYP9DKgNKUFKfep312hAXnfpFbuRIawjDQSIIgxXuZPpK/i2+iFk9L36m uQKDM/5sGtEG3gZxx8WoBq37VCRrUa06or+oQmz0= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Eric Biggers , Theodore Tso , Sasha Levin Subject: [PATCH 4.9 16/39] ext4: clean up ext4_match() and callers Date: Mon, 24 Aug 2020 10:31:15 +0200 Message-Id: <20200824082349.319235024@linuxfoundation.org> X-Mailer: git-send-email 2.28.0 In-Reply-To: <20200824082348.445866152@linuxfoundation.org> References: <20200824082348.445866152@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: Eric Biggers [ Upstream commit d9b9f8d5a88cb7881d9f1c2b7e9de9a3fe1dc9e2 ] When ext4 encryption was originally merged, we were encrypting the user-specified filename in ext4_match(), introducing a lot of additional complexity into ext4_match() and its callers. This has since been changed to encrypt the filename earlier, so we can remove the gunk that's no longer needed. This more or less reverts ext4_search_dir() and ext4_find_dest_de() to the way they were in the v4.0 kernel. Signed-off-by: Eric Biggers Signed-off-by: Theodore Ts'o Signed-off-by: Sasha Levin --- fs/ext4/namei.c | 81 +++++++++++++++---------------------------------- 1 file changed, 25 insertions(+), 56 deletions(-) diff --git a/fs/ext4/namei.c b/fs/ext4/namei.c index 6225ce9f1884c..dd42d533d2816 100644 --- a/fs/ext4/namei.c +++ b/fs/ext4/namei.c @@ -1251,19 +1251,18 @@ static void dx_insert_block(struct dx_frame *frame, u32 hash, ext4_lblk_t block) } /* - * NOTE! unlike strncmp, ext4_match returns 1 for success, 0 for failure. + * Test whether a directory entry matches the filename being searched for. * - * `len <= EXT4_NAME_LEN' is guaranteed by caller. - * `de != NULL' is guaranteed by caller. + * Return: %true if the directory entry matches, otherwise %false. */ -static inline int ext4_match(struct ext4_filename *fname, - struct ext4_dir_entry_2 *de) +static inline bool ext4_match(const struct ext4_filename *fname, + const struct ext4_dir_entry_2 *de) { const void *name = fname_name(fname); u32 len = fname_len(fname); if (!de->inode) - return 0; + return false; #ifdef CONFIG_EXT4_FS_ENCRYPTION if (unlikely(!name)) { @@ -1295,48 +1294,31 @@ int ext4_search_dir(struct buffer_head *bh, char *search_buf, int buf_size, struct ext4_dir_entry_2 * de; char * dlimit; int de_len; - int res; de = (struct ext4_dir_entry_2 *)search_buf; dlimit = search_buf + buf_size; while ((char *) de < dlimit) { /* this code is executed quadratically often */ /* do minimal checking `by hand' */ - if ((char *) de + de->name_len <= dlimit) { - res = ext4_match(fname, de); - if (res < 0) { - res = -1; - goto return_result; - } - if (res > 0) { - /* found a match - just to be sure, do - * a full check */ - if (ext4_check_dir_entry(dir, NULL, de, bh, - bh->b_data, - bh->b_size, offset)) { - res = -1; - goto return_result; - } - *res_dir = de; - res = 1; - goto return_result; - } - + if ((char *) de + de->name_len <= dlimit && + ext4_match(fname, de)) { + /* found a match - just to be sure, do + * a full check */ + if (ext4_check_dir_entry(dir, NULL, de, bh, bh->b_data, + bh->b_size, offset)) + return -1; + *res_dir = de; + return 1; } /* prevent looping on a bad block */ de_len = ext4_rec_len_from_disk(de->rec_len, dir->i_sb->s_blocksize); - if (de_len <= 0) { - res = -1; - goto return_result; - } + if (de_len <= 0) + return -1; offset += de_len; de = (struct ext4_dir_entry_2 *) ((char *) de + de_len); } - - res = 0; -return_result: - return res; + return 0; } static int is_dx_internal_node(struct inode *dir, ext4_lblk_t block, @@ -1853,24 +1835,15 @@ int ext4_find_dest_de(struct inode *dir, struct inode *inode, int nlen, rlen; unsigned int offset = 0; char *top; - int res; de = (struct ext4_dir_entry_2 *)buf; top = buf + buf_size - reclen; while ((char *) de <= top) { if (ext4_check_dir_entry(dir, NULL, de, bh, - buf, buf_size, offset)) { - res = -EFSCORRUPTED; - goto return_result; - } - /* Provide crypto context and crypto buffer to ext4 match */ - res = ext4_match(fname, de); - if (res < 0) - goto return_result; - if (res > 0) { - res = -EEXIST; - goto return_result; - } + buf, buf_size, offset)) + return -EFSCORRUPTED; + if (ext4_match(fname, de)) + return -EEXIST; nlen = EXT4_DIR_REC_LEN(de->name_len); rlen = ext4_rec_len_from_disk(de->rec_len, buf_size); if ((de->inode ? rlen - nlen : rlen) >= reclen) @@ -1878,15 +1851,11 @@ int ext4_find_dest_de(struct inode *dir, struct inode *inode, de = (struct ext4_dir_entry_2 *)((char *)de + rlen); offset += rlen; } - if ((char *) de > top) - res = -ENOSPC; - else { - *dest_de = de; - res = 0; - } -return_result: - return res; + return -ENOSPC; + + *dest_de = de; + return 0; } int ext4_insert_dentry(struct inode *dir, From patchwork Mon Aug 24 08:31:16 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Greg KH X-Patchwork-Id: 265143 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=-13.7 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_PATCH, MAILING_LIST_MULTI, SIGNED_OFF_BY, SPF_HELO_NONE, 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 B50DDC433E4 for ; Mon, 24 Aug 2020 08:51:36 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 893DE2072D for ; Mon, 24 Aug 2020 08:51:36 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1598259096; bh=iHH4nZ5FG3boYaQ8vKMw6bTqrFWc4XVPyANRtbbiWDc=; h=From:To:Cc:Subject:Date:In-Reply-To:References:List-ID:From; b=xN9l1GdP3EumvHMLIe87EHK6uAaX+lI3GaowKqKUFiGWaXMdScCXm8Koxyf31f21I ehE5CssSGd6qZSD+OVHSwMHie4k0UCaYVC9FZ3zzlYxgKrt7HxNBAKjyAscMOE8VKL KqVxaO6pyPqyrNgM0FDhs1jZW6biDXSUFa/wY0iE= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729668AbgHXIvf (ORCPT ); Mon, 24 Aug 2020 04:51:35 -0400 Received: from mail.kernel.org ([198.145.29.99]:56664 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729941AbgHXIvc (ORCPT ); Mon, 24 Aug 2020 04:51:32 -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 A306E2072D; Mon, 24 Aug 2020 08:51:31 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1598259092; bh=iHH4nZ5FG3boYaQ8vKMw6bTqrFWc4XVPyANRtbbiWDc=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=gUSzrZ8T/SKtB5rGbisYx+W9mNEojrr2QZrfCL90tewtaQOllblN1apTGdYBjerMi 6hVp39olgzaKXh2Wz4lczSL8Gpb7ssFFxZUjSLQ0BCOlmanTHYWX6oT1kXoeoOKiiq y0tyu7mVAxEZ0bmgdmK8kNtlscdd4k/HKAN3NPks= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Jan Kara , Theodore Tso , Sasha Levin Subject: [PATCH 4.9 17/39] ext4: fix checking of directory entry validity for inline directories Date: Mon, 24 Aug 2020 10:31:16 +0200 Message-Id: <20200824082349.386545159@linuxfoundation.org> X-Mailer: git-send-email 2.28.0 In-Reply-To: <20200824082348.445866152@linuxfoundation.org> References: <20200824082348.445866152@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: Jan Kara [ Upstream commit 7303cb5bfe845f7d43cd9b2dbd37dbb266efda9b ] ext4_search_dir() and ext4_generic_delete_entry() can be called both for standard director blocks and for inline directories stored inside inode or inline xattr space. For the second case we didn't call ext4_check_dir_entry() with proper constraints that could result in accepting corrupted directory entry as well as false positive filesystem errors like: EXT4-fs error (device dm-0): ext4_search_dir:1395: inode #28320400: block 113246792: comm dockerd: bad entry in directory: directory entry too close to block end - offset=0, inode=28320403, rec_len=32, name_len=8, size=4096 Fix the arguments passed to ext4_check_dir_entry(). Fixes: 109ba779d6cc ("ext4: check for directory entries too close to block end") CC: stable@vger.kernel.org Signed-off-by: Jan Kara Link: https://lore.kernel.org/r/20200731162135.8080-1-jack@suse.cz Signed-off-by: Theodore Ts'o Signed-off-by: Sasha Levin --- fs/ext4/namei.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/fs/ext4/namei.c b/fs/ext4/namei.c index dd42d533d2816..2d918b43b536e 100644 --- a/fs/ext4/namei.c +++ b/fs/ext4/namei.c @@ -1304,8 +1304,8 @@ int ext4_search_dir(struct buffer_head *bh, char *search_buf, int buf_size, ext4_match(fname, de)) { /* found a match - just to be sure, do * a full check */ - if (ext4_check_dir_entry(dir, NULL, de, bh, bh->b_data, - bh->b_size, offset)) + if (ext4_check_dir_entry(dir, NULL, de, bh, search_buf, + buf_size, offset)) return -1; *res_dir = de; return 1; @@ -2344,7 +2344,7 @@ int ext4_generic_delete_entry(handle_t *handle, de = (struct ext4_dir_entry_2 *)entry_buf; while (i < buf_size - csum_size) { if (ext4_check_dir_entry(dir, NULL, de, bh, - bh->b_data, bh->b_size, i)) + entry_buf, buf_size, i)) return -EFSCORRUPTED; if (de == de_del) { if (pde) From patchwork Mon Aug 24 08:31:20 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Greg KH X-Patchwork-Id: 265067 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=-13.7 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_PATCH, MAILING_LIST_MULTI, SIGNED_OFF_BY, SPF_HELO_NONE, 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 DDA7CC433E4 for ; Mon, 24 Aug 2020 09:28:31 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id B177E2075B for ; Mon, 24 Aug 2020 09:28:31 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1598261311; bh=lw1yL5+D0GFS7k/22hM9f0lnHRnDEgM0C2akrp065PU=; h=From:To:Cc:Subject:Date:In-Reply-To:References:List-ID:From; b=AKpjL5Etx5bHOWcdEvfPW5eRjWjPYLhsKkqNX1KkLXskh6qaBxTFsqfFLaVQTHg7X +thSa2HvZjlq33nwqU6DuGGpB0QTMbZ3PdJfQjRK7PjNlP53cSQ1rU99zs9zQ0NNOr S34ixxSPXS8CJ/LTZVFPUejTbyMzpRefNb8BJmCo= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726008AbgHXJ2a (ORCPT ); Mon, 24 Aug 2020 05:28:30 -0400 Received: from mail.kernel.org ([198.145.29.99]:56994 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729735AbgHXIvn (ORCPT ); Mon, 24 Aug 2020 04:51:43 -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 CBF122072D; Mon, 24 Aug 2020 08:51:42 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1598259103; bh=lw1yL5+D0GFS7k/22hM9f0lnHRnDEgM0C2akrp065PU=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=rTxJq/d81hVEiiVF/pfhiw7VpBaoHL9nLBNY/Zj7oMD9Bv2TmyOK1Ze/Y3mD2Naa+ gUgj+drG7br0e42Fb7gUuncNW9gMfD9QsFZGUbeplP3JxzHoXWIJDRiAFHZI47WJGg ENvVmKpEFeg16E88JaqwQtIytVTkpWfvj85C2HHQ= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Xiongfeng Wang , Dmitry Torokhov , Sasha Levin Subject: [PATCH 4.9 21/39] Input: psmouse - add a newline when printing proto by sysfs Date: Mon, 24 Aug 2020 10:31:20 +0200 Message-Id: <20200824082349.630552055@linuxfoundation.org> X-Mailer: git-send-email 2.28.0 In-Reply-To: <20200824082348.445866152@linuxfoundation.org> References: <20200824082348.445866152@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: Xiongfeng Wang [ Upstream commit 4aec14de3a15cf9789a0e19c847f164776f49473 ] When I cat parameter 'proto' by sysfs, it displays as follows. It's better to add a newline for easy reading. root@syzkaller:~# cat /sys/module/psmouse/parameters/proto autoroot@syzkaller:~# Signed-off-by: Xiongfeng Wang Link: https://lore.kernel.org/r/20200720073846.120724-1-wangxiongfeng2@huawei.com Signed-off-by: Dmitry Torokhov Signed-off-by: Sasha Levin --- drivers/input/mouse/psmouse-base.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/input/mouse/psmouse-base.c b/drivers/input/mouse/psmouse-base.c index 5cbf17aa84439..597ecae02c405 100644 --- a/drivers/input/mouse/psmouse-base.c +++ b/drivers/input/mouse/psmouse-base.c @@ -1909,7 +1909,7 @@ static int psmouse_get_maxproto(char *buffer, const struct kernel_param *kp) { int type = *((unsigned int *)kp->arg); - return sprintf(buffer, "%s", psmouse_protocol_by_type(type)->name); + return sprintf(buffer, "%s\n", psmouse_protocol_by_type(type)->name); } static int __init psmouse_init(void) From patchwork Mon Aug 24 08:31:21 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Greg KH X-Patchwork-Id: 265068 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=-13.7 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_PATCH, MAILING_LIST_MULTI, SIGNED_OFF_BY, SPF_HELO_NONE, SPF_PASS, USER_AGENT_GIT autolearn=unavailable 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 C41C0C433DF for ; Mon, 24 Aug 2020 09:28:24 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 954FC2074D for ; Mon, 24 Aug 2020 09:28:24 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1598261304; bh=6aHggL1RkTAzBEHv4FvfQ9+Mk3/6PJyf2EJjPbmIUQE=; h=From:To:Cc:Subject:Date:In-Reply-To:References:List-ID:From; b=il4f9KEJXIupBaIkwZ9B9cphcWsFHVmxwtljY8eiFZ6fjnFdO7LeZxQiVD2y/NHZO Qzm9pK1lfp7PzSkDM3cKBbvOE3NG7FLGHW4crKlrd+2u2Mptfk2hGN7aDvpPcP9kTQ SR/UBEt/hUiMWmVo3RIFca9px2T0Z/B0PCXnVQzI= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729983AbgHXIvq (ORCPT ); Mon, 24 Aug 2020 04:51:46 -0400 Received: from mail.kernel.org ([198.145.29.99]:57040 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729978AbgHXIvq (ORCPT ); Mon, 24 Aug 2020 04:51: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 2BC9C2075B; Mon, 24 Aug 2020 08:51:45 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1598259105; bh=6aHggL1RkTAzBEHv4FvfQ9+Mk3/6PJyf2EJjPbmIUQE=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=APzmcX5ibV+TXN/HuNjRlCNf5/AW7EtqnqkfXb2NxkueEUzGaFriOqF8igl2N4thu pv7o7gzX2uBvqMaqEe+FAmstQux0bDNO3SNbDv6ubNbhcK1/+qNYw3svZ7SUfWhcYm 4zNZ40DuygdZ3jL6m5dVTf9eRf9OlkxXc7whryUA= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Greg Ungerer , Sasha Levin Subject: [PATCH 4.9 22/39] m68knommu: fix overwriting of bits in ColdFire V3 cache control Date: Mon, 24 Aug 2020 10:31:21 +0200 Message-Id: <20200824082349.687014923@linuxfoundation.org> X-Mailer: git-send-email 2.28.0 In-Reply-To: <20200824082348.445866152@linuxfoundation.org> References: <20200824082348.445866152@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: Greg Ungerer [ Upstream commit bdee0e793cea10c516ff48bf3ebb4ef1820a116b ] The Cache Control Register (CACR) of the ColdFire V3 has bits that control high level caching functions, and also enable/disable the use of the alternate stack pointer register (the EUSP bit) to provide separate supervisor and user stack pointer registers. The code as it is today will blindly clear the EUSP bit on cache actions like invalidation. So it is broken for this case - and that will result in failed booting (interrupt entry and exit processing will be completely hosed). This only affects ColdFire V3 parts that support the alternate stack register (like the 5329 for example) - generally speaking new parts do, older parts don't. It has no impact on ColdFire V3 parts with the single stack pointer, like the 5307 for example. Fix the cache bit defines used, so they maintain the EUSP bit when carrying out cache actions through the CACR register. Signed-off-by: Greg Ungerer Signed-off-by: Sasha Levin --- arch/m68k/include/asm/m53xxacr.h | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/arch/m68k/include/asm/m53xxacr.h b/arch/m68k/include/asm/m53xxacr.h index 3177ce8331d69..baee0c77b9818 100644 --- a/arch/m68k/include/asm/m53xxacr.h +++ b/arch/m68k/include/asm/m53xxacr.h @@ -88,9 +88,9 @@ * coherency though in all cases. And for copyback caches we will need * to push cached data as well. */ -#define CACHE_INIT CACR_CINVA -#define CACHE_INVALIDATE CACR_CINVA -#define CACHE_INVALIDATED CACR_CINVA +#define CACHE_INIT (CACHE_MODE + CACR_CINVA - CACR_EC) +#define CACHE_INVALIDATE (CACHE_MODE + CACR_CINVA) +#define CACHE_INVALIDATED (CACHE_MODE + CACR_CINVA) #define ACR0_MODE ((CONFIG_RAMBASE & 0xff000000) + \ (0x000f0000) + \ From patchwork Mon Aug 24 08:31:23 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Greg KH X-Patchwork-Id: 265142 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=-13.7 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_PATCH, MAILING_LIST_MULTI, SIGNED_OFF_BY, SPF_HELO_NONE, 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 5F085C433DF for ; Mon, 24 Aug 2020 08:51:55 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 402932072D for ; Mon, 24 Aug 2020 08:51:55 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1598259115; bh=gz1Ql6wLuLKli3sxEIWh60v0JCTWQm0FhUAHNyRqBJY=; h=From:To:Cc:Subject:Date:In-Reply-To:References:List-ID:From; b=dYNWBc+kG2mTkG1L6gFQGnQCc8dBBvjOBqE/1zQGP8KlpbskA11Mxrxj+vXRpuZRz PUv1tDypvffUVnzgcVGmhGIKgN3+vFOJOr2A7D/+jPaZpNfhM/2A18xQ1zpLyiR/mP t4F+9iYVZBjGOttS4X3J8Qc0WbpR364CVCd4Hki0= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729771AbgHXIvx (ORCPT ); Mon, 24 Aug 2020 04:51:53 -0400 Received: from mail.kernel.org ([198.145.29.99]:57256 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730004AbgHXIvv (ORCPT ); Mon, 24 Aug 2020 04:51:51 -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 580212072D; Mon, 24 Aug 2020 08:51:50 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1598259110; bh=gz1Ql6wLuLKli3sxEIWh60v0JCTWQm0FhUAHNyRqBJY=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=b5Blo2f5PpFMtGh6p8YYXMhzsMJLE1cWPZrDUBfsr4KAZjuitSXn4OhkTgLG21Dv4 agRCSAQxAHgccZT2U0/6INFMeg93+61PDNWE4Rl1a0yMD46ix5oVsNyObdCFOIClCL 4Pb6BElEcOWLZDlMlMc+cfKM8vLagYv9YuFkuCDI= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Zhe Li , Hou Tao , Richard Weinberger , Sasha Levin Subject: [PATCH 4.9 24/39] jffs2: fix UAF problem Date: Mon, 24 Aug 2020 10:31:23 +0200 Message-Id: <20200824082349.783160086@linuxfoundation.org> X-Mailer: git-send-email 2.28.0 In-Reply-To: <20200824082348.445866152@linuxfoundation.org> References: <20200824082348.445866152@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: Zhe Li [ Upstream commit 798b7347e4f29553db4b996393caf12f5b233daf ] The log of UAF problem is listed below. BUG: KASAN: use-after-free in jffs2_rmdir+0xa4/0x1cc [jffs2] at addr c1f165fc Read of size 4 by task rm/8283 ============================================================================= BUG kmalloc-32 (Tainted: P B O ): kasan: bad access detected ----------------------------------------------------------------------------- INFO: Allocated in 0xbbbbbbbb age=3054364 cpu=0 pid=0 0xb0bba6ef jffs2_write_dirent+0x11c/0x9c8 [jffs2] __slab_alloc.isra.21.constprop.25+0x2c/0x44 __kmalloc+0x1dc/0x370 jffs2_write_dirent+0x11c/0x9c8 [jffs2] jffs2_do_unlink+0x328/0x5fc [jffs2] jffs2_rmdir+0x110/0x1cc [jffs2] vfs_rmdir+0x180/0x268 do_rmdir+0x2cc/0x300 ret_from_syscall+0x0/0x3c INFO: Freed in 0x205b age=3054364 cpu=0 pid=0 0x2e9173 jffs2_add_fd_to_list+0x138/0x1dc [jffs2] jffs2_add_fd_to_list+0x138/0x1dc [jffs2] jffs2_garbage_collect_dirent.isra.3+0x21c/0x288 [jffs2] jffs2_garbage_collect_live+0x16bc/0x1800 [jffs2] jffs2_garbage_collect_pass+0x678/0x11d4 [jffs2] jffs2_garbage_collect_thread+0x1e8/0x3b0 [jffs2] kthread+0x1a8/0x1b0 ret_from_kernel_thread+0x5c/0x64 Call Trace: [c17ddd20] [c02452d4] kasan_report.part.0+0x298/0x72c (unreliable) [c17ddda0] [d2509680] jffs2_rmdir+0xa4/0x1cc [jffs2] [c17dddd0] [c026da04] vfs_rmdir+0x180/0x268 [c17dde00] [c026f4e4] do_rmdir+0x2cc/0x300 [c17ddf40] [c001a658] ret_from_syscall+0x0/0x3c The root cause is that we don't get "jffs2_inode_info.sem" before we scan list "jffs2_inode_info.dents" in function jffs2_rmdir. This patch add codes to get "jffs2_inode_info.sem" before we scan "jffs2_inode_info.dents" to slove the UAF problem. Signed-off-by: Zhe Li Reviewed-by: Hou Tao Signed-off-by: Richard Weinberger Signed-off-by: Sasha Levin --- fs/jffs2/dir.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/fs/jffs2/dir.c b/fs/jffs2/dir.c index e5a6deb38e1e1..f4a5ec92f5dc7 100644 --- a/fs/jffs2/dir.c +++ b/fs/jffs2/dir.c @@ -590,10 +590,14 @@ static int jffs2_rmdir (struct inode *dir_i, struct dentry *dentry) int ret; uint32_t now = get_seconds(); + mutex_lock(&f->sem); for (fd = f->dents ; fd; fd = fd->next) { - if (fd->ino) + if (fd->ino) { + mutex_unlock(&f->sem); return -ENOTEMPTY; + } } + mutex_unlock(&f->sem); ret = jffs2_do_unlink(c, dir_f, dentry->d_name.name, dentry->d_name.len, f, now); From patchwork Mon Aug 24 08:31:24 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Greg KH X-Patchwork-Id: 265069 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=-13.7 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_PATCH, MAILING_LIST_MULTI, SIGNED_OFF_BY, SPF_HELO_NONE, SPF_PASS, USER_AGENT_GIT autolearn=unavailable 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 EDAACC433DF for ; Mon, 24 Aug 2020 09:28:05 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id BDED92074D for ; Mon, 24 Aug 2020 09:28:05 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1598261285; bh=5nk3NJXNopBSzjnj7Lpg8MhVeJiX9H+Pd26H61xczsw=; h=From:To:Cc:Subject:Date:In-Reply-To:References:List-ID:From; b=0XzsoXV6jOZ9alotNmT1hKu5heDDDL58vE4lNBdADBPTHk7KzIz8Kr4xpbax0md/t kEfRVvHaMbYermc4P2zbcMxv+MqG4MpnY1a7OquMoD/ZmktQ6h+i6xSF2r4V83WUoP HGxCkpZSxWXNhodhRLvvhgvAMpBoxDzkm/1CisvA= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729503AbgHXIv5 (ORCPT ); Mon, 24 Aug 2020 04:51:57 -0400 Received: from mail.kernel.org ([198.145.29.99]:57446 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730018AbgHXIv4 (ORCPT ); Mon, 24 Aug 2020 04:51:56 -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 7C7E22072D; Mon, 24 Aug 2020 08:51:55 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1598259116; bh=5nk3NJXNopBSzjnj7Lpg8MhVeJiX9H+Pd26H61xczsw=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=f6QjgZ6MsLrvuI14TG3qh/hL2qiOpOp9FETNgsy6ZkEV9Mm2WsJbmrIqMFfwZuDuL UOJtzGxKhPnydpE9u/B66sU57GNX9x/3aCLfiOdglj6Wq3KXLRD69HCfxu9lVamPPP pQBxH6vJVTDBGuaj+MZpeAI4WRwN5TuKfSOaYj5U= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Girish Basrur , Santosh Vernekar , Saurav Kashyap , Shyam Sundar , Javed Hasan , "Martin K. Petersen" , Sasha Levin Subject: [PATCH 4.9 25/39] scsi: libfc: Free skb in fc_disc_gpn_id_resp() for valid cases Date: Mon, 24 Aug 2020 10:31:24 +0200 Message-Id: <20200824082349.828559262@linuxfoundation.org> X-Mailer: git-send-email 2.28.0 In-Reply-To: <20200824082348.445866152@linuxfoundation.org> References: <20200824082348.445866152@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: Javed Hasan [ Upstream commit ec007ef40abb6a164d148b0dc19789a7a2de2cc8 ] In fc_disc_gpn_id_resp(), skb is supposed to get freed in all cases except for PTR_ERR. However, in some cases it didn't. This fix is to call fc_frame_free(fp) before function returns. Link: https://lore.kernel.org/r/20200729081824.30996-2-jhasan@marvell.com Reviewed-by: Girish Basrur Reviewed-by: Santosh Vernekar Reviewed-by: Saurav Kashyap Reviewed-by: Shyam Sundar Signed-off-by: Javed Hasan Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin --- drivers/scsi/libfc/fc_disc.c | 12 +++++++++--- 1 file changed, 9 insertions(+), 3 deletions(-) diff --git a/drivers/scsi/libfc/fc_disc.c b/drivers/scsi/libfc/fc_disc.c index 880a9068ca126..ef06af4e3611d 100644 --- a/drivers/scsi/libfc/fc_disc.c +++ b/drivers/scsi/libfc/fc_disc.c @@ -595,8 +595,12 @@ static void fc_disc_gpn_id_resp(struct fc_seq *sp, struct fc_frame *fp, mutex_lock(&disc->disc_mutex); if (PTR_ERR(fp) == -FC_EX_CLOSED) goto out; - if (IS_ERR(fp)) - goto redisc; + if (IS_ERR(fp)) { + mutex_lock(&disc->disc_mutex); + fc_disc_restart(disc); + mutex_unlock(&disc->disc_mutex); + goto out; + } cp = fc_frame_payload_get(fp, sizeof(*cp)); if (!cp) @@ -621,7 +625,7 @@ static void fc_disc_gpn_id_resp(struct fc_seq *sp, struct fc_frame *fp, new_rdata->disc_id = disc->disc_id; lport->tt.rport_login(new_rdata); } - goto out; + goto free_fp; } rdata->disc_id = disc->disc_id; lport->tt.rport_login(rdata); @@ -635,6 +639,8 @@ static void fc_disc_gpn_id_resp(struct fc_seq *sp, struct fc_frame *fp, redisc: fc_disc_restart(disc); } +free_fp: + fc_frame_free(fp); out: mutex_unlock(&disc->disc_mutex); kref_put(&rdata->kref, lport->tt.rport_destroy); From patchwork Mon Aug 24 08:31:27 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Greg KH X-Patchwork-Id: 265072 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=-13.7 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_PATCH, MAILING_LIST_MULTI, SIGNED_OFF_BY, SPF_HELO_NONE, SPF_PASS, USER_AGENT_GIT autolearn=unavailable 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 D83C8C433E3 for ; Mon, 24 Aug 2020 09:27:19 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id B8DA92074D for ; Mon, 24 Aug 2020 09:27:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1598261239; bh=4hK1erPQRlP1+oL9gdRiB7F0rzjISyPy6USi40HgIjg=; h=From:To:Cc:Subject:Date:In-Reply-To:References:List-ID:From; b=j1nSGS4Lk+FayS5pF6yLBx6LwX0D7/l04pg7Fu5aUf1utQVNi1QbE33Nue+hVuTzb uI6ZxRPklCgg+ae96XE97U5/E8dC0aXSi/F9wWfGYbf2epPxHKdaPba61sxjxFKHjJ eq1SQjtPdY11A+MZIp8Uuv+mA6imR3e60v97Y09w= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728969AbgHXJ1P (ORCPT ); Mon, 24 Aug 2020 05:27:15 -0400 Received: from mail.kernel.org ([198.145.29.99]:58904 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730101AbgHXIwd (ORCPT ); Mon, 24 Aug 2020 04:52:33 -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 220C020FC3; Mon, 24 Aug 2020 08:52:32 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1598259152; bh=4hK1erPQRlP1+oL9gdRiB7F0rzjISyPy6USi40HgIjg=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=0CQDzscgn1P3sfLLVJDl9VoIJZ7NJ7Kz7gfVne8C5rCLI04X1zhCiRsXlT5JFQzh0 pGx7f1opQzqGq1DplT3W83Vjt453te5OzNd1jZBK0ZL8kpc6EH6xcNS0IohbWH9oQ2 /MC3oKdVwYDAOU4znPdgvXcSSPVX2MXhE+kSqFyg= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, kernel test robot , Luc Van Oostenryck , Andrew Morton , Richard Henderson , Ivan Kokshaysky , Matt Turner , Stephen Boyd , Arnd Bergmann , Linus Torvalds , Sasha Levin Subject: [PATCH 4.9 28/39] alpha: fix annotation of io{read, write}{16, 32}be() Date: Mon, 24 Aug 2020 10:31:27 +0200 Message-Id: <20200824082349.976616110@linuxfoundation.org> X-Mailer: git-send-email 2.28.0 In-Reply-To: <20200824082348.445866152@linuxfoundation.org> References: <20200824082348.445866152@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: Luc Van Oostenryck [ Upstream commit bd72866b8da499e60633ff28f8a4f6e09ca78efe ] These accessors must be used to read/write a big-endian bus. The value returned or written is native-endian. However, these accessors are defined using be{16,32}_to_cpu() or cpu_to_be{16,32}() to make the endian conversion but these expect a __be{16,32} when none is present. Keeping them would need a force cast that would solve nothing at all. So, do the conversion using swab{16,32}, like done in asm-generic for similar situations. Reported-by: kernel test robot Signed-off-by: Luc Van Oostenryck Signed-off-by: Andrew Morton Cc: Richard Henderson Cc: Ivan Kokshaysky Cc: Matt Turner Cc: Stephen Boyd Cc: Arnd Bergmann Link: http://lkml.kernel.org/r/20200622114232.80039-1-luc.vanoostenryck@gmail.com Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin --- arch/alpha/include/asm/io.h | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/arch/alpha/include/asm/io.h b/arch/alpha/include/asm/io.h index ff4049155c840..355aec0867f4d 100644 --- a/arch/alpha/include/asm/io.h +++ b/arch/alpha/include/asm/io.h @@ -491,10 +491,10 @@ extern inline void writeq(u64 b, volatile void __iomem *addr) } #endif -#define ioread16be(p) be16_to_cpu(ioread16(p)) -#define ioread32be(p) be32_to_cpu(ioread32(p)) -#define iowrite16be(v,p) iowrite16(cpu_to_be16(v), (p)) -#define iowrite32be(v,p) iowrite32(cpu_to_be32(v), (p)) +#define ioread16be(p) swab16(ioread16(p)) +#define ioread32be(p) swab32(ioread32(p)) +#define iowrite16be(v,p) iowrite16(swab16(v), (p)) +#define iowrite32be(v,p) iowrite32(swab32(v), (p)) #define inb_p inb #define inw_p inw From patchwork Mon Aug 24 08:31:32 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Greg KH X-Patchwork-Id: 265074 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=-13.7 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_PATCH, MAILING_LIST_MULTI, SIGNED_OFF_BY, SPF_HELO_NONE, SPF_PASS, USER_AGENT_GIT autolearn=unavailable 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 B9EFFC433DF for ; Mon, 24 Aug 2020 09:27:02 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 964DD2075B for ; Mon, 24 Aug 2020 09:27:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1598261222; bh=Okk13ya5vY/zxAdaG1dG8uTrUbWIRUGPqbRNUa/aJjw=; h=From:To:Cc:Subject:Date:In-Reply-To:References:List-ID:From; b=vzVTGC17Lz/5+gV1HBA7CudC6Vc20650MmSysHSq7L5dHS54zpqf9KlWOKis0YECT bUH+TUzhjSrLRx+P75Uehhht4xyd7k6lowrGhh4AFyE8FJGEqmANWwvqb6rd8rX2B6 2JmVj6APRSwu0OlYrPJx+QwQ2vGFV9kwALMMWSpI= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729588AbgHXJ05 (ORCPT ); Mon, 24 Aug 2020 05:26:57 -0400 Received: from mail.kernel.org ([198.145.29.99]:59306 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729656AbgHXIwp (ORCPT ); Mon, 24 Aug 2020 04:52:45 -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 9BDBE204FD; Mon, 24 Aug 2020 08:52:44 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1598259165; bh=Okk13ya5vY/zxAdaG1dG8uTrUbWIRUGPqbRNUa/aJjw=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=TIT6kKsNqB95VWbaYvVEK2YwGRzUXmzAHwqx00blmOzFlSjKspr8g8+qalhtBByFY K6qq1nKhD7Lv9xqnEJrnByrxJvNoXwrrTQFzMTKpjFjmyZyQ2GptGyNtdLkYpY/yp1 ukpcb+U8McWC4bWunnYO51X1xXwqT6ttHxHvi1fM= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Tom Rix , Florian Fainelli , "David S. Miller" , Sasha Levin Subject: [PATCH 4.9 33/39] net: dsa: b53: check for timeout Date: Mon, 24 Aug 2020 10:31:32 +0200 Message-Id: <20200824082350.220310354@linuxfoundation.org> X-Mailer: git-send-email 2.28.0 In-Reply-To: <20200824082348.445866152@linuxfoundation.org> References: <20200824082348.445866152@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: Tom Rix [ Upstream commit 774d977abfd024e6f73484544b9abe5a5cd62de7 ] clang static analysis reports this problem b53_common.c:1583:13: warning: The left expression of the compound assignment is an uninitialized value. The computed value will also be garbage ent.port &= ~BIT(port); ~~~~~~~~ ^ ent is set by a successful call to b53_arl_read(). Unsuccessful calls are caught by an switch statement handling specific returns. b32_arl_read() calls b53_arl_op_wait() which fails with the unhandled -ETIMEDOUT. So add -ETIMEDOUT to the switch statement. Because b53_arl_op_wait() already prints out a message, do not add another one. Fixes: 1da6df85c6fb ("net: dsa: b53: Implement ARL add/del/dump operations") Signed-off-by: Tom Rix Acked-by: Florian Fainelli Signed-off-by: David S. Miller Signed-off-by: Sasha Levin --- drivers/net/dsa/b53/b53_common.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/net/dsa/b53/b53_common.c b/drivers/net/dsa/b53/b53_common.c index 060f9b1769298..c387be5c926b7 100644 --- a/drivers/net/dsa/b53/b53_common.c +++ b/drivers/net/dsa/b53/b53_common.c @@ -1175,6 +1175,8 @@ static int b53_arl_op(struct b53_device *dev, int op, int port, return ret; switch (ret) { + case -ETIMEDOUT: + return ret; case -ENOSPC: dev_dbg(dev->dev, "{%pM,%.4d} no space left in ARL\n", addr, vid); From patchwork Mon Aug 24 08:31:33 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Greg KH X-Patchwork-Id: 265075 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=-10.7 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI, SIGNED_OFF_BY, SPF_HELO_NONE, SPF_PASS, USER_AGENT_GIT autolearn=unavailable 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 C0F72C433E3 for ; Mon, 24 Aug 2020 09:26:54 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 9C6FB2074D for ; Mon, 24 Aug 2020 09:26:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1598261214; bh=k4RwoxkCN8nskMAMp2RfPf26Rb+qQSGzvcCGXFVAIdI=; h=From:To:Cc:Subject:Date:In-Reply-To:References:List-ID:From; b=RLw135lYH9b8a2oazx7V+BHZ03riEXFtN3b0YvH58mPrZ2/90IhYLXXFx4CqFhDq6 hzzLn8PN2Q2dvl96re8sSqpzVpPp6PzUbunnCsEM1fWpWF2PPtA8wIBBuc/aSO3bAA ZFNjADhLgFS8Eaaqs21dHHQ4kQUC74xIIhZt6TkM= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730110AbgHXIwt (ORCPT ); Mon, 24 Aug 2020 04:52:49 -0400 Received: from mail.kernel.org ([198.145.29.99]:59416 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730102AbgHXIwr (ORCPT ); Mon, 24 Aug 2020 04:52:47 -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 F1B182075B; Mon, 24 Aug 2020 08:52:46 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1598259167; bh=k4RwoxkCN8nskMAMp2RfPf26Rb+qQSGzvcCGXFVAIdI=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=hakRlGnQrDRfX7ZlAtUzJX/farWgKns4ZDH4A87kYuk9Tw2I32KPt39JVcBiU+q3D xMIkhfcsr+S1Ux5LkOYmH/zYrc47WfW5fcmzZBk6kYG5LXDshsHhXsFD3X+Z9ZnThG F0sX75TMd7k1MOyJjf+y4x3PTYCvJ1iNxBWRMbms= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Vasant Hegde , Michael Ellerman Subject: [PATCH 4.9 34/39] powerpc/pseries: Do not initiate shutdown when system is running on UPS Date: Mon, 24 Aug 2020 10:31:33 +0200 Message-Id: <20200824082350.272665157@linuxfoundation.org> X-Mailer: git-send-email 2.28.0 In-Reply-To: <20200824082348.445866152@linuxfoundation.org> References: <20200824082348.445866152@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: Vasant Hegde commit 90a9b102eddf6a3f987d15f4454e26a2532c1c98 upstream. As per PAPR we have to look for both EPOW sensor value and event modifier to identify the type of event and take appropriate action. In LoPAPR v1.1 section 10.2.2 includes table 136 "EPOW Action Codes": SYSTEM_SHUTDOWN 3 The system must be shut down. An EPOW-aware OS logs the EPOW error log information, then schedules the system to be shut down to begin after an OS defined delay internal (default is 10 minutes.) Then in section 10.3.2.2.8 there is table 146 "Platform Event Log Format, Version 6, EPOW Section", which includes the "EPOW Event Modifier": For EPOW sensor value = 3 0x01 = Normal system shutdown with no additional delay 0x02 = Loss of utility power, system is running on UPS/Battery 0x03 = Loss of system critical functions, system should be shutdown 0x04 = Ambient temperature too high All other values = reserved We have a user space tool (rtas_errd) on LPAR to monitor for EPOW_SHUTDOWN_ON_UPS. Once it gets an event it initiates shutdown after predefined time. It also starts monitoring for any new EPOW events. If it receives "Power restored" event before predefined time it will cancel the shutdown. Otherwise after predefined time it will shutdown the system. Commit 79872e35469b ("powerpc/pseries: All events of EPOW_SYSTEM_SHUTDOWN must initiate shutdown") changed our handling of the "on UPS/Battery" case, to immediately shutdown the system. This breaks existing setups that rely on the userspace tool to delay shutdown and let the system run on the UPS. Fixes: 79872e35469b ("powerpc/pseries: All events of EPOW_SYSTEM_SHUTDOWN must initiate shutdown") Cc: stable@vger.kernel.org # v4.0+ Signed-off-by: Vasant Hegde [mpe: Massage change log and add PAPR references] Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20200820061844.306460-1-hegdevasant@linux.vnet.ibm.com Signed-off-by: Greg Kroah-Hartman --- arch/powerpc/platforms/pseries/ras.c | 1 - 1 file changed, 1 deletion(-) --- a/arch/powerpc/platforms/pseries/ras.c +++ b/arch/powerpc/platforms/pseries/ras.c @@ -101,7 +101,6 @@ static void handle_system_shutdown(char case EPOW_SHUTDOWN_ON_UPS: pr_emerg("Loss of system power detected. System is running on" " UPS/battery. Check RTAS error log for details\n"); - orderly_poweroff(true); break; case EPOW_SHUTDOWN_LOSS_OF_CRITICAL_FUNCTIONS: From patchwork Mon Aug 24 08:31:34 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Greg KH X-Patchwork-Id: 265137 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=-10.7 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI, SIGNED_OFF_BY,SPF_HELO_NONE,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 0399FC433E1 for ; Mon, 24 Aug 2020 08:52:56 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id D114C204FD for ; Mon, 24 Aug 2020 08:52:55 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1598259175; bh=KI4nHsoMqAoZx3i9lJvTrT3QIhvE7d2/J9/s0nvnO98=; h=From:To:Cc:Subject:Date:In-Reply-To:References:List-ID:From; b=pSZo9IBQ7MoH7HdM1lt2Ir7f25kH/q66jLUOiDnCZf8JbIr8J8/eTGQ9f2DQXPAwB xBxNPHOMGJiGhPm2Reb2JyBaQBfyW/D9/Rf4GKe72osdChXkO4jq/2nkJwnXFDkk3E VRS+KzBgTXSd8wDMeUwO99RqMXR9zwWvteBTgg4I= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730116AbgHXIwy (ORCPT ); Mon, 24 Aug 2020 04:52:54 -0400 Received: from mail.kernel.org ([198.145.29.99]:59498 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730087AbgHXIwv (ORCPT ); Mon, 24 Aug 2020 04:52:51 -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 5E91C204FD; Mon, 24 Aug 2020 08:52:49 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1598259169; bh=KI4nHsoMqAoZx3i9lJvTrT3QIhvE7d2/J9/s0nvnO98=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=qRu7tNs4zWj31Pr3homwSzFGb20fz4PhK23GOucVSTXZ08/cVGt30lQhBm7wW9Kc6 LeQuTGEnxqmnTXBm3F/zmOw7LIV+RGM/Np8biIVG4PSXPEnGWoOMhRLZ0MMhboQt6e ebkY4AHzHfTJVnX3BPm3jeQNepLieQtOx+KqqE5Y= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Tom Lane , Daniel Axtens , Michael Ellerman Subject: [PATCH 4.9 35/39] powerpc: Allow 4224 bytes of stack expansion for the signal frame Date: Mon, 24 Aug 2020 10:31:34 +0200 Message-Id: <20200824082350.324302199@linuxfoundation.org> X-Mailer: git-send-email 2.28.0 In-Reply-To: <20200824082348.445866152@linuxfoundation.org> References: <20200824082348.445866152@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: Michael Ellerman commit 63dee5df43a31f3844efabc58972f0a206ca4534 upstream. We have powerpc specific logic in our page fault handling to decide if an access to an unmapped address below the stack pointer should expand the stack VMA. The code was originally added in 2004 "ported from 2.4". The rough logic is that the stack is allowed to grow to 1MB with no extra checking. Over 1MB the access must be within 2048 bytes of the stack pointer, or be from a user instruction that updates the stack pointer. The 2048 byte allowance below the stack pointer is there to cover the 288 byte "red zone" as well as the "about 1.5kB" needed by the signal delivery code. Unfortunately since then the signal frame has expanded, and is now 4224 bytes on 64-bit kernels with transactional memory enabled. This means if a process has consumed more than 1MB of stack, and its stack pointer lies less than 4224 bytes from the next page boundary, signal delivery will fault when trying to expand the stack and the process will see a SEGV. The total size of the signal frame is the size of struct rt_sigframe (which includes the red zone) plus __SIGNAL_FRAMESIZE (128 bytes on 64-bit). The 2048 byte allowance was correct until 2008 as the signal frame was: struct rt_sigframe { struct ucontext uc; /* 0 1440 */ /* --- cacheline 11 boundary (1408 bytes) was 32 bytes ago --- */ long unsigned int _unused[2]; /* 1440 16 */ unsigned int tramp[6]; /* 1456 24 */ struct siginfo * pinfo; /* 1480 8 */ void * puc; /* 1488 8 */ struct siginfo info; /* 1496 128 */ /* --- cacheline 12 boundary (1536 bytes) was 88 bytes ago --- */ char abigap[288]; /* 1624 288 */ /* size: 1920, cachelines: 15, members: 7 */ /* padding: 8 */ }; 1920 + 128 = 2048 Then in commit ce48b2100785 ("powerpc: Add VSX context save/restore, ptrace and signal support") (Jul 2008) the signal frame expanded to 2304 bytes: struct rt_sigframe { struct ucontext uc; /* 0 1696 */ <-- /* --- cacheline 13 boundary (1664 bytes) was 32 bytes ago --- */ long unsigned int _unused[2]; /* 1696 16 */ unsigned int tramp[6]; /* 1712 24 */ struct siginfo * pinfo; /* 1736 8 */ void * puc; /* 1744 8 */ struct siginfo info; /* 1752 128 */ /* --- cacheline 14 boundary (1792 bytes) was 88 bytes ago --- */ char abigap[288]; /* 1880 288 */ /* size: 2176, cachelines: 17, members: 7 */ /* padding: 8 */ }; 2176 + 128 = 2304 At this point we should have been exposed to the bug, though as far as I know it was never reported. I no longer have a system old enough to easily test on. Then in 2010 commit 320b2b8de126 ("mm: keep a guard page below a grow-down stack segment") caused our stack expansion code to never trigger, as there was always a VMA found for a write up to PAGE_SIZE below r1. That meant the bug was hidden as we continued to expand the signal frame in commit 2b0a576d15e0 ("powerpc: Add new transactional memory state to the signal context") (Feb 2013): struct rt_sigframe { struct ucontext uc; /* 0 1696 */ /* --- cacheline 13 boundary (1664 bytes) was 32 bytes ago --- */ struct ucontext uc_transact; /* 1696 1696 */ <-- /* --- cacheline 26 boundary (3328 bytes) was 64 bytes ago --- */ long unsigned int _unused[2]; /* 3392 16 */ unsigned int tramp[6]; /* 3408 24 */ struct siginfo * pinfo; /* 3432 8 */ void * puc; /* 3440 8 */ struct siginfo info; /* 3448 128 */ /* --- cacheline 27 boundary (3456 bytes) was 120 bytes ago --- */ char abigap[288]; /* 3576 288 */ /* size: 3872, cachelines: 31, members: 8 */ /* padding: 8 */ /* last cacheline: 32 bytes */ }; 3872 + 128 = 4000 And commit 573ebfa6601f ("powerpc: Increase stack redzone for 64-bit userspace to 512 bytes") (Feb 2014): struct rt_sigframe { struct ucontext uc; /* 0 1696 */ /* --- cacheline 13 boundary (1664 bytes) was 32 bytes ago --- */ struct ucontext uc_transact; /* 1696 1696 */ /* --- cacheline 26 boundary (3328 bytes) was 64 bytes ago --- */ long unsigned int _unused[2]; /* 3392 16 */ unsigned int tramp[6]; /* 3408 24 */ struct siginfo * pinfo; /* 3432 8 */ void * puc; /* 3440 8 */ struct siginfo info; /* 3448 128 */ /* --- cacheline 27 boundary (3456 bytes) was 120 bytes ago --- */ char abigap[512]; /* 3576 512 */ <-- /* size: 4096, cachelines: 32, members: 8 */ /* padding: 8 */ }; 4096 + 128 = 4224 Then finally in 2017, commit 1be7107fbe18 ("mm: larger stack guard gap, between vmas") exposed us to the existing bug, because it changed the stack VMA to be the correct/real size, meaning our stack expansion code is now triggered. Fix it by increasing the allowance to 4224 bytes. Hard-coding 4224 is obviously unsafe against future expansions of the signal frame in the same way as the existing code. We can't easily use sizeof() because the signal frame structure is not in a header. We will either fix that, or rip out all the custom stack expansion checking logic entirely. Fixes: ce48b2100785 ("powerpc: Add VSX context save/restore, ptrace and signal support") Cc: stable@vger.kernel.org # v2.6.27+ Reported-by: Tom Lane Tested-by: Daniel Axtens Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20200724092528.1578671-2-mpe@ellerman.id.au Signed-off-by: Daniel Axtens Signed-off-by: Greg Kroah-Hartman --- arch/powerpc/mm/fault.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) --- a/arch/powerpc/mm/fault.c +++ b/arch/powerpc/mm/fault.c @@ -192,6 +192,9 @@ static int mm_fault_error(struct pt_regs return MM_FAULT_CONTINUE; } +// This comes from 64-bit struct rt_sigframe + __SIGNAL_FRAMESIZE +#define SIGFRAME_MAX_SIZE (4096 + 128) + /* * For 600- and 800-family processors, the error_code parameter is DSISR * for a data fault, SRR1 for an instruction fault. For 400-family processors @@ -341,7 +344,7 @@ retry: /* * N.B. The POWER/Open ABI allows programs to access up to * 288 bytes below the stack pointer. - * The kernel signal delivery code writes up to about 1.5kB + * The kernel signal delivery code writes up to about 4kB * below the stack pointer (r1) before decrementing it. * The exec code can write slightly over 640kB to the stack * before setting the user r1. Thus we allow the stack to @@ -365,7 +368,7 @@ retry: * between the last mapped region and the stack will * expand the stack rather than segfaulting. */ - if (address + 2048 < uregs->gpr[1] && !store_update_sp) + if (address + SIGFRAME_MAX_SIZE < uregs->gpr[1] && !store_update_sp) goto bad_area; } if (expand_stack(vma, address)) From patchwork Mon Aug 24 08:31:35 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Greg KH X-Patchwork-Id: 265139 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=-10.7 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI, SIGNED_OFF_BY,SPF_HELO_NONE,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 70645C433E1 for ; Mon, 24 Aug 2020 08:52:29 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 4183D2075B for ; Mon, 24 Aug 2020 08:52:29 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1598259149; bh=AFq2eiQEON9yvH4IRXSOgBm1oiC5Gj5b7q5M/mEJfy8=; h=From:To:Cc:Subject:Date:In-Reply-To:References:List-ID:From; b=pGvRYuyc1RLOROJZYe1rYwTEexDFdWImtAJgeMevBo4RSc7RdrcmXyMI2BhvdLSvK 06Tk643UM5qnCejrR73n8o4lxl8aULm8/X42UWWPJ8O/xB33bCGMrC6EwLpCpcaARz n/ZYqOElKlmrP/TlpoRFqLVCCaJZRwR1lubEcipc= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729690AbgHXIwZ (ORCPT ); Mon, 24 Aug 2020 04:52:25 -0400 Received: from mail.kernel.org ([198.145.29.99]:58490 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730087AbgHXIwX (ORCPT ); Mon, 24 Aug 2020 04:52:23 -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 1ADF62075B; Mon, 24 Aug 2020 08:52:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1598259142; bh=AFq2eiQEON9yvH4IRXSOgBm1oiC5Gj5b7q5M/mEJfy8=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=YjRQxXwkaN7uTmf4KxZOMSeLNhfEBoMba1CjfUE53EQHuZAPkNUGAHjMGgAPLui7Z XwMmalrVXLZn561DYOU4b5Y/Ox6tLo04HJD/zG3Oo37h/W93LQtAwdBd/JTaMZ3y2J kafU7K6gx4xydqA9mKwMgYYFWc/jkmc0fRhUtG8A= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Marc Zyngier , Al Viro Subject: [PATCH 4.9 36/39] epoll: Keep a reference on files added to the check list Date: Mon, 24 Aug 2020 10:31:35 +0200 Message-Id: <20200824082350.379244679@linuxfoundation.org> X-Mailer: git-send-email 2.28.0 In-Reply-To: <20200824082348.445866152@linuxfoundation.org> References: <20200824082348.445866152@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: Marc Zyngier commit a9ed4a6560b8562b7e2e2bed9527e88001f7b682 upstream. When adding a new fd to an epoll, and that this new fd is an epoll fd itself, we recursively scan the fds attached to it to detect cycles, and add non-epool files to a "check list" that gets subsequently parsed. However, this check list isn't completely safe when deletions can happen concurrently. To sidestep the issue, make sure that a struct file placed on the check list sees its f_count increased, ensuring that a concurrent deletion won't result in the file disapearing from under our feet. Cc: stable@vger.kernel.org Signed-off-by: Marc Zyngier Signed-off-by: Al Viro Signed-off-by: Marc Zyngier Signed-off-by: Greg Kroah-Hartman --- fs/eventpoll.c | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-) --- a/fs/eventpoll.c +++ b/fs/eventpoll.c @@ -1747,9 +1747,11 @@ static int ep_loop_check_proc(void *priv * not already there, and calling reverse_path_check() * during ep_insert(). */ - if (list_empty(&epi->ffd.file->f_tfile_llink)) + if (list_empty(&epi->ffd.file->f_tfile_llink)) { + get_file(epi->ffd.file); list_add(&epi->ffd.file->f_tfile_llink, &tfile_check_list); + } } } mutex_unlock(&ep->mtx); @@ -1793,6 +1795,7 @@ static void clear_tfile_check_list(void) file = list_first_entry(&tfile_check_list, struct file, f_tfile_llink); list_del_init(&file->f_tfile_llink); + fput(file); } INIT_LIST_HEAD(&tfile_check_list); } @@ -1947,9 +1950,11 @@ SYSCALL_DEFINE4(epoll_ctl, int, epfd, in clear_tfile_check_list(); goto error_tgt_fput; } - } else + } else { + get_file(tf.file); list_add(&tf.file->f_tfile_llink, &tfile_check_list); + } mutex_lock_nested(&ep->mtx, 0); if (is_file_epoll(tf.file)) { tep = tf.file->private_data; From patchwork Mon Aug 24 08:31:37 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Greg KH X-Patchwork-Id: 265138 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=-10.7 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI, SIGNED_OFF_BY,SPF_HELO_NONE,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 51A7DC433E1 for ; Mon, 24 Aug 2020 08:52:32 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 3157521775 for ; Mon, 24 Aug 2020 08:52:32 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1598259152; bh=dOuvFQoLG2+iBcwFTac/uZ5LdgTProqLm/wMU2a01nU=; h=From:To:Cc:Subject:Date:In-Reply-To:References:List-ID:From; b=jFtfvxjVp8QCRS7rTfvKAzoLwlUQBNJTBuLkUqo+lncE1uZsjsHhcFFLtLMBE13/F sVLtJPT6gF31EUN3AQOH3Xgr1OesDNM1RDHua8ZcZCbYnenyX3dyTNvYGwrHOThq1X Zno4tHFi/9QKKKeNaPoA2ItrwCFzSz06F/fM/Bbk= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730094AbgHXIwa (ORCPT ); Mon, 24 Aug 2020 04:52:30 -0400 Received: from mail.kernel.org ([198.145.29.99]:58680 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729534AbgHXIw2 (ORCPT ); Mon, 24 Aug 2020 04:52:28 -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 1EB7A208E4; Mon, 24 Aug 2020 08:52:26 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1598259147; bh=dOuvFQoLG2+iBcwFTac/uZ5LdgTProqLm/wMU2a01nU=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=FK/PFkNbuL10Y6kUK4LCJ/4IwGeG7BlfjKY6vW6pZU24NeEidE6eTAWYGRC3Rmcij kUlCSCYJMtOkYIJ5Cc2e3fpMQ9Ii5mePo9K8s7xhXfZrnUQJw+8A9bBHw7yvx8/c3S jPcnMz4K0rcgybiisseLRwOdzqZ6d4ugcKEsDbHU= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Peter Xu , Andrew Morton , Mike Kravetz , Andrea Arcangeli , Matthew Wilcox , Linus Torvalds Subject: [PATCH 4.9 38/39] mm/hugetlb: fix calculation of adjust_range_if_pmd_sharing_possible Date: Mon, 24 Aug 2020 10:31:37 +0200 Message-Id: <20200824082350.486010746@linuxfoundation.org> X-Mailer: git-send-email 2.28.0 In-Reply-To: <20200824082348.445866152@linuxfoundation.org> References: <20200824082348.445866152@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: Peter Xu commit 75802ca66354a39ab8e35822747cd08b3384a99a upstream. This is found by code observation only. Firstly, the worst case scenario should assume the whole range was covered by pmd sharing. The old algorithm might not work as expected for ranges like (1g-2m, 1g+2m), where the adjusted range should be (0, 1g+2m) but the expected range should be (0, 2g). Since at it, remove the loop since it should not be required. With that, the new code should be faster too when the invalidating range is huge. Mike said: : With range (1g-2m, 1g+2m) within a vma (0, 2g) the existing code will only : adjust to (0, 1g+2m) which is incorrect. : : We should cc stable. The original reason for adjusting the range was to : prevent data corruption (getting wrong page). Since the range is not : always adjusted correctly, the potential for corruption still exists. : : However, I am fairly confident that adjust_range_if_pmd_sharing_possible : is only gong to be called in two cases: : : 1) for a single page : 2) for range == entire vma : : In those cases, the current code should produce the correct results. : : To be safe, let's just cc stable. Fixes: 017b1660df89 ("mm: migration: fix migration of huge PMD shared pages") Signed-off-by: Peter Xu Signed-off-by: Andrew Morton Reviewed-by: Mike Kravetz Cc: Andrea Arcangeli Cc: Matthew Wilcox Cc: Link: http://lkml.kernel.org/r/20200730201636.74778-1-peterx@redhat.com Signed-off-by: Linus Torvalds Signed-off-by: Mike Kravetz Signed-off-by: Greg Kroah-Hartman --- mm/hugetlb.c | 24 ++++++++++-------------- 1 file changed, 10 insertions(+), 14 deletions(-) --- a/mm/hugetlb.c +++ b/mm/hugetlb.c @@ -4380,25 +4380,21 @@ static bool vma_shareable(struct vm_area void adjust_range_if_pmd_sharing_possible(struct vm_area_struct *vma, unsigned long *start, unsigned long *end) { - unsigned long check_addr = *start; + unsigned long a_start, a_end; if (!(vma->vm_flags & VM_MAYSHARE)) return; - for (check_addr = *start; check_addr < *end; check_addr += PUD_SIZE) { - unsigned long a_start = check_addr & PUD_MASK; - unsigned long a_end = a_start + PUD_SIZE; + /* Extend the range to be PUD aligned for a worst case scenario */ + a_start = ALIGN_DOWN(*start, PUD_SIZE); + a_end = ALIGN(*end, PUD_SIZE); - /* - * If sharing is possible, adjust start/end if necessary. - */ - if (range_in_vma(vma, a_start, a_end)) { - if (a_start < *start) - *start = a_start; - if (a_end > *end) - *end = a_end; - } - } + /* + * Intersect the range with the vma range, since pmd sharing won't be + * across vma after all + */ + *start = max(vma->vm_start, a_start); + *end = min(vma->vm_end, a_end); } /* From patchwork Mon Aug 24 08:31:38 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Greg KH X-Patchwork-Id: 265073 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=-10.7 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI, SIGNED_OFF_BY, SPF_HELO_NONE, SPF_PASS, USER_AGENT_GIT autolearn=unavailable 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 3B505C433E1 for ; Mon, 24 Aug 2020 09:27:05 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 137AF2177B for ; Mon, 24 Aug 2020 09:27:05 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1598261225; bh=Ugp5lYXLez/YXQk+NIdZCZFpUpaFzz9EnvVK/Mz/9/o=; h=From:To:Cc:Subject:Date:In-Reply-To:References:List-ID:From; b=IuVAjqZaDf2uGzyln2l5Qz8z2TVZE7lb4c+Y/F6CoB03nwcgxOpTNUqVitIABimiN NAQ6r5lvz+5Ggu1OVp1U7NbzhgoJKTrVsZpJk0rC9RiZ9d6rB1mO4zoCZkLUZQHtBg tsCOmcmKmkMOadanNjtd6pJxGiEG7da9aUJsJe3s= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730106AbgHXIwi (ORCPT ); Mon, 24 Aug 2020 04:52:38 -0400 Received: from mail.kernel.org ([198.145.29.99]:58798 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730096AbgHXIwb (ORCPT ); Mon, 24 Aug 2020 04:52:31 -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 CCE35204FD; Mon, 24 Aug 2020 08:52:29 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1598259150; bh=Ugp5lYXLez/YXQk+NIdZCZFpUpaFzz9EnvVK/Mz/9/o=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=FThjYJu80c3+APTjDJtimhguCryfGbH7fU6EKjLxMpzRfTkrm4RTJQzTjKp0ANZ87 8tZGWeudqw+amd2fb3aUqEnLyqwgBiTMd39v8WaceObJoH98MTIGWbkX1CkUC12rsp AIgNp08QEIFMcDfXrVirWpEL/4x4Yzbj4ZdiMbvM= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Greg Kroah-Hartman , Sarah Newman , Juergen Gross , Chris Brannon Subject: [PATCH 4.9 39/39] xen: dont reschedule in preemption off sections Date: Mon, 24 Aug 2020 10:31:38 +0200 Message-Id: <20200824082350.536997077@linuxfoundation.org> X-Mailer: git-send-email 2.28.0 In-Reply-To: <20200824082348.445866152@linuxfoundation.org> References: <20200824082348.445866152@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: Juergen Gross For support of long running hypercalls xen_maybe_preempt_hcall() is calling cond_resched() in case a hypercall marked as preemptible has been interrupted. Normally this is no problem, as only hypercalls done via some ioctl()s are marked to be preemptible. In rare cases when during such a preemptible hypercall an interrupt occurs and any softirq action is started from irq_exit(), a further hypercall issued by the softirq handler will be regarded to be preemptible, too. This might lead to rescheduling in spite of the softirq handler potentially having set preempt_disable(), leading to splats like: BUG: sleeping function called from invalid context at drivers/xen/preempt.c:37 in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 20775, name: xl INFO: lockdep is turned off. CPU: 1 PID: 20775 Comm: xl Tainted: G D W 5.4.46-1_prgmr_debug.el7.x86_64 #1 Call Trace: dump_stack+0x8f/0xd0 ___might_sleep.cold.76+0xb2/0x103 xen_maybe_preempt_hcall+0x48/0x70 xen_do_hypervisor_callback+0x37/0x40 RIP: e030:xen_hypercall_xen_version+0xa/0x20 Code: ... RSP: e02b:ffffc900400dcc30 EFLAGS: 00000246 RAX: 000000000004000d RBX: 0000000000000200 RCX: ffffffff8100122a RDX: ffff88812e788000 RSI: 0000000000000000 RDI: 0000000000000000 RBP: ffffffff83ee3ad0 R08: 0000000000000001 R09: 0000000000000001 R10: 0000000000000000 R11: 0000000000000246 R12: ffff8881824aa0b0 R13: 0000000865496000 R14: 0000000865496000 R15: ffff88815d040000 ? xen_hypercall_xen_version+0xa/0x20 ? xen_force_evtchn_callback+0x9/0x10 ? check_events+0x12/0x20 ? xen_restore_fl_direct+0x1f/0x20 ? _raw_spin_unlock_irqrestore+0x53/0x60 ? debug_dma_sync_single_for_cpu+0x91/0xc0 ? _raw_spin_unlock_irqrestore+0x53/0x60 ? xen_swiotlb_sync_single_for_cpu+0x3d/0x140 ? mlx4_en_process_rx_cq+0x6b6/0x1110 [mlx4_en] ? mlx4_en_poll_rx_cq+0x64/0x100 [mlx4_en] ? net_rx_action+0x151/0x4a0 ? __do_softirq+0xed/0x55b ? irq_exit+0xea/0x100 ? xen_evtchn_do_upcall+0x2c/0x40 ? xen_do_hypervisor_callback+0x29/0x40 ? xen_hypercall_domctl+0xa/0x20 ? xen_hypercall_domctl+0x8/0x20 ? privcmd_ioctl+0x221/0x990 [xen_privcmd] ? do_vfs_ioctl+0xa5/0x6f0 ? ksys_ioctl+0x60/0x90 ? trace_hardirqs_off_thunk+0x1a/0x20 ? __x64_sys_ioctl+0x16/0x20 ? do_syscall_64+0x62/0x250 ? entry_SYSCALL_64_after_hwframe+0x49/0xbe Fix that by testing preempt_count() before calling cond_resched(). In kernel 5.8 this can't happen any more due to the entry code rework (more than 100 patches, so not a candidate for backporting). The issue was introduced in kernel 4.3, so this patch should go into all stable kernels in [4.3 ... 5.7]. Reported-by: Sarah Newman Fixes: 0fa2f5cb2b0ecd8 ("sched/preempt, xen: Use need_resched() instead of should_resched()") Cc: Sarah Newman Cc: stable@vger.kernel.org Signed-off-by: Juergen Gross Tested-by: Chris Brannon Signed-off-by: Greg Kroah-Hartman --- drivers/xen/preempt.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/xen/preempt.c +++ b/drivers/xen/preempt.c @@ -31,7 +31,7 @@ EXPORT_SYMBOL_GPL(xen_in_preemptible_hca asmlinkage __visible void xen_maybe_preempt_hcall(void) { if (unlikely(__this_cpu_read(xen_in_preemptible_hcall) - && need_resched())) { + && need_resched() && !preempt_count())) { /* * Clear flag as we may be rescheduled on a different * cpu.