From patchwork Fri Apr 9 09:53:10 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Greg KH X-Patchwork-Id: 418158 Delivered-To: patch@linaro.org Received: by 2002:a02:8562:0:0:0:0:0 with SMTP id g89csp1421338jai; Fri, 9 Apr 2021 02:55:13 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxwgu8NRLK2YmScTlEhABYL1Obhg1E3qZBKOboPpr2RzIxZEZua00vZxQwQX9bl+lhlAp/X X-Received: by 2002:a17:90a:7847:: with SMTP id y7mr13447834pjl.65.1617962112912; Fri, 09 Apr 2021 02:55:12 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1617962112; cv=none; d=google.com; s=arc-20160816; b=IcmasUT5ZmgJGD7ejW2uzBWcVnMZaC2ZjczIvuQ97dOhcBAg1j/+GRLIGyVHEOUsEK 2Q31u8E+HYLdYqeG7vP8jHFjKsqCFIxgxQF+zdXunfJkFcy87k6njfx57HSnk8paVbNG 1MSPfZwhkNRTxLHonVhNJn4R9uBlhuWXGLDKXVfPVgF+qrTS0wjZZUBhPE1chOR7hmZk XnlJka+YmuXInVMcpEXA/g30WdriqfXWUM5PZexDANmSL9z8h+MgiJMqswI8IxD/ZZRN /1k6gy+J98bQvJXLN6EAyHpIzyRpqE9GSyxeAfEwQbw87CsgNgaIcO1sCCkrzIG9geGM XnAw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:message-id:date:subject:cc:to :from:dkim-signature; bh=bKt4vJim4kK7qt0PiFpKlOE7BdPnhKVcoo3Xq14qvqs=; b=QP1w9YzFsv5McBIodLxPUf+37TOsvspmRYmkYWr/nGwrNIawjoKV+nHcPlu6wKgo/X jCmF/37eOvo16w+FFiTi8yc6p79StfXGYfRHF/Pm+WcpJIuBQtyOHclBQ2PZTTLg2cyZ McQwSwxqxlXNc3GUB4Vv3EO3K6kg/Bkr8EppvEEdse4FmGgUD1ZeWDT9khKNhORUl0vV QbNcoqzhJWjgVAJSkjlTqeWdQUGfnVG3P8yWhyG3n9INsRQTGnB7g+vrtJgaW8QyMtFC cj1N+rrlTltqj7HDoXN7CgIPR5VUrVPl3CDRYoo3saAAwCrwbGnxAPPEDgcDLXB6wVl2 PHgQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=MQTWNr1f; spf=pass (google.com: domain of stable-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=stable-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id v3si2031855plo.430.2021.04.09.02.55.12; Fri, 09 Apr 2021 02:55:12 -0700 (PDT) Received-SPF: pass (google.com: domain of stable-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=MQTWNr1f; spf=pass (google.com: domain of stable-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=stable-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233461AbhDIJzX (ORCPT + 12 others); Fri, 9 Apr 2021 05:55:23 -0400 Received: from mail.kernel.org ([198.145.29.99]:42858 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233369AbhDIJzQ (ORCPT ); Fri, 9 Apr 2021 05:55:16 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id 020F7611C0; Fri, 9 Apr 2021 09:54:59 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1617962100; bh=mGIK2BwVvX8Fl3XDAr452fbkcDbKapAu60q+46qrF0Y=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=MQTWNr1fNlVArmkvOWlEM6mjwgffDVwS4WHLL53EBVZL9VJJKTCde1H62BNFYIyTe d12lTaaiGZeIvoO+fMhdlg8DNICDhPyBB8iaOzV+axOBIj5D02ouSa2C1m6zwSiqPI D2/k3zA8qPcloGGAlbdi9DAjt9+n/DemZLyTH/8I= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Arnd Bergmann , Ingo Molnar , Sasha Levin Subject: [PATCH 4.4 04/20] x86/build: Turn off -fcf-protection for realmode targets Date: Fri, 9 Apr 2021 11:53:10 +0200 Message-Id: <20210409095300.095843008@linuxfoundation.org> X-Mailer: git-send-email 2.31.1 In-Reply-To: <20210409095259.957388690@linuxfoundation.org> References: <20210409095259.957388690@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org From: Arnd Bergmann [ Upstream commit 9fcb51c14da2953de585c5c6e50697b8a6e91a7b ] The new Ubuntu GCC packages turn on -fcf-protection globally, which causes a build failure in the x86 realmode code: cc1: error: ‘-fcf-protection’ is not compatible with this target Turn it off explicitly on compilers that understand this option. Signed-off-by: Arnd Bergmann Signed-off-by: Ingo Molnar Link: https://lore.kernel.org/r/20210323124846.1584944-1-arnd@kernel.org Signed-off-by: Sasha Levin --- arch/x86/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) -- 2.30.2 diff --git a/arch/x86/Makefile b/arch/x86/Makefile index 5fece9334f12..2b3adb3008c3 100644 --- a/arch/x86/Makefile +++ b/arch/x86/Makefile @@ -34,7 +34,7 @@ REALMODE_CFLAGS := $(M16_CFLAGS) -g -Os -D__KERNEL__ \ -DDISABLE_BRANCH_PROFILING \ -Wall -Wstrict-prototypes -march=i386 -mregparm=3 \ -fno-strict-aliasing -fomit-frame-pointer -fno-pic \ - -mno-mmx -mno-sse + -mno-mmx -mno-sse $(call cc-option,-fcf-protection=none) REALMODE_CFLAGS += $(call __cc-option, $(CC), $(REALMODE_CFLAGS), -ffreestanding) REALMODE_CFLAGS += $(call __cc-option, $(CC), $(REALMODE_CFLAGS), -fno-stack-protector) From patchwork Fri Apr 9 09:53:11 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Greg KH X-Patchwork-Id: 418804 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=-18.8 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_CR_TRAILER, INCLUDES_PATCH, MAILING_LIST_MULTI, SPF_HELO_NONE, SPF_PASS, URIBL_BLOCKED, 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 A3423C433ED for ; Fri, 9 Apr 2021 09:55:11 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 7CA36611C0 for ; Fri, 9 Apr 2021 09:55:11 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233450AbhDIJzX (ORCPT ); Fri, 9 Apr 2021 05:55:23 -0400 Received: from mail.kernel.org ([198.145.29.99]:42952 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233367AbhDIJzQ (ORCPT ); Fri, 9 Apr 2021 05:55:16 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id A38DC61182; Fri, 9 Apr 2021 09:55:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1617962103; bh=thzlBdQTm6kBHFLZwJ3xYYwDep6WuCb71RWS9w5rrAA=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=XJ5HkM7Ry0hr5Ao7PqzNWW44/96o4cMvHXpJrs1ejNQSVs0uMt8aphHla7ZeBduLm xosxllbsWVAXf9OXUpPjBNcLdRvzI0s1M5vzbsMuzrAwzduPD6B6eBT5pcFbVN14VI +k2BbHgNYlkjm9NBcSeKamJwi/9yLEREFL9v3I00= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Sergei Trofimovich , Andrew Morton , Linus Torvalds , Sasha Levin Subject: [PATCH 4.4 05/20] ia64: mca: allocate early mca with GFP_ATOMIC Date: Fri, 9 Apr 2021 11:53:11 +0200 Message-Id: <20210409095300.125834106@linuxfoundation.org> X-Mailer: git-send-email 2.31.1 In-Reply-To: <20210409095259.957388690@linuxfoundation.org> References: <20210409095259.957388690@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org From: Sergei Trofimovich [ Upstream commit f2a419cf495f95cac49ea289318b833477e1a0e2 ] The sleep warning happens at early boot right at secondary CPU activation bootup: smp: Bringing up secondary CPUs ... BUG: sleeping function called from invalid context at mm/page_alloc.c:4942 in_atomic(): 0, irqs_disabled(): 1, non_block: 0, pid: 0, name: swapper/1 CPU: 1 PID: 0 Comm: swapper/1 Not tainted 5.12.0-rc2-00007-g79e228d0b611-dirty #99 .. Call Trace: show_stack+0x90/0xc0 dump_stack+0x150/0x1c0 ___might_sleep+0x1c0/0x2a0 __might_sleep+0xa0/0x160 __alloc_pages_nodemask+0x1a0/0x600 alloc_page_interleave+0x30/0x1c0 alloc_pages_current+0x2c0/0x340 __get_free_pages+0x30/0xa0 ia64_mca_cpu_init+0x2d0/0x3a0 cpu_init+0x8b0/0x1440 start_secondary+0x60/0x700 start_ap+0x750/0x780 Fixed BSP b0 value from CPU 1 As I understand interrupts are not enabled yet and system has a lot of memory. There is little chance to sleep and switch to GFP_ATOMIC should be a no-op. Link: https://lkml.kernel.org/r/20210315085045.204414-1-slyfox@gentoo.org Signed-off-by: Sergei Trofimovich Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin --- arch/ia64/kernel/mca.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/ia64/kernel/mca.c b/arch/ia64/kernel/mca.c index 2889412e03eb..0d5b64ddcdd1 100644 --- a/arch/ia64/kernel/mca.c +++ b/arch/ia64/kernel/mca.c @@ -1858,7 +1858,7 @@ ia64_mca_cpu_init(void *cpu_data) data = mca_bootmem(); first_time = 0; } else - data = (void *)__get_free_pages(GFP_KERNEL, + data = (void *)__get_free_pages(GFP_ATOMIC, get_order(sz)); if (!data) panic("Could not allocate MCA memory for cpu %d\n", From patchwork Fri Apr 9 09:53:12 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Greg KH X-Patchwork-Id: 418803 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=-18.8 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_CR_TRAILER, INCLUDES_PATCH, MAILING_LIST_MULTI, SPF_HELO_NONE, SPF_PASS, URIBL_BLOCKED, 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 4CA0DC433B4 for ; Fri, 9 Apr 2021 09:55:20 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 2D23561220 for ; Fri, 9 Apr 2021 09:55:20 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232892AbhDIJzb (ORCPT ); Fri, 9 Apr 2021 05:55:31 -0400 Received: from mail.kernel.org ([198.145.29.99]:42520 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233393AbhDIJzS (ORCPT ); Fri, 9 Apr 2021 05:55:18 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id 51C36611C9; Fri, 9 Apr 2021 09:55:05 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1617962105; bh=0RBDfPzse0lPNKnF11S3FUX0jLutKPef6deINcgCkDc=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=EXnRmu0iQTsg6U3zvTLnX8U5MlkUqNB+ij19ZEYdhSgk1SakOYGXkiezdFKkyhkMX XVnbYMXlK3M5KJbXjEYFjCr9qeUPgI9/TSNXx04O0lVpfL9rwP8yQUHqYuRH4fVTI3 6F7iZdv6snfyySElW1smzm4SpSQf1tdY0cPmonSs= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Ronnie Sahlberg , "Paulo Alcantara (SUSE)" , Steve French , Sasha Levin Subject: [PATCH 4.4 06/20] cifs: revalidate mapping when we open files for SMB1 POSIX Date: Fri, 9 Apr 2021 11:53:12 +0200 Message-Id: <20210409095300.155554868@linuxfoundation.org> X-Mailer: git-send-email 2.31.1 In-Reply-To: <20210409095259.957388690@linuxfoundation.org> References: <20210409095259.957388690@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org From: Ronnie Sahlberg [ Upstream commit cee8f4f6fcabfdf229542926128e9874d19016d5 ] RHBZ: 1933527 Under SMB1 + POSIX, if an inode is reused on a server after we have read and cached a part of a file, when we then open the new file with the re-cycled inode there is a chance that we may serve the old data out of cache to the application. This only happens for SMB1 (deprecated) and when posix are used. The simplest solution to avoid this race is to force a revalidate on smb1-posix open. Signed-off-by: Ronnie Sahlberg Reviewed-by: Paulo Alcantara (SUSE) Signed-off-by: Steve French Signed-off-by: Sasha Levin --- fs/cifs/file.c | 1 + 1 file changed, 1 insertion(+) diff --git a/fs/cifs/file.c b/fs/cifs/file.c index b5a05092f862..5bc617cb7721 100644 --- a/fs/cifs/file.c +++ b/fs/cifs/file.c @@ -163,6 +163,7 @@ int cifs_posix_open(char *full_path, struct inode **pinode, goto posix_open_ret; } } else { + cifs_revalidate_mapping(*pinode); cifs_fattr_to_inode(*pinode, &fattr); } From patchwork Fri Apr 9 09:53:14 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Greg KH X-Patchwork-Id: 418802 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=-18.8 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_CR_TRAILER, INCLUDES_PATCH, MAILING_LIST_MULTI, SPF_HELO_NONE, SPF_PASS, URIBL_BLOCKED, 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 1FAF9C43461 for ; Fri, 9 Apr 2021 09:55:28 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id E5390611ED for ; Fri, 9 Apr 2021 09:55:27 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233439AbhDIJzj (ORCPT ); Fri, 9 Apr 2021 05:55:39 -0400 Received: from mail.kernel.org ([198.145.29.99]:42952 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233363AbhDIJzX (ORCPT ); Fri, 9 Apr 2021 05:55:23 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id 54EA7611BF; Fri, 9 Apr 2021 09:55:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1617962110; bh=ovDwYAwD2+TQre+qlj1tNAN7ysSInboCTEDkWatq4vA=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=bp46cina91o2BXXRUCHNDczUF9tDAi73RlkexYHUsC/2Lw0xPS9KJAGJbDXCnoi3b roasxGuk0iDjaZ8xKA/cHe6TVvLvS9yv4gSU/ZCqDCwPxcfWl9dbRRduUbaRA3CXn+ jYrKhUm6JzITSUvWmauVoCOebyENu0bGVNJ875ls= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Piotr Krysiuk , Daniel Borkmann Subject: [PATCH 4.4 08/20] bpf, x86: Validate computation of branch displacements for x86-64 Date: Fri, 9 Apr 2021 11:53:14 +0200 Message-Id: <20210409095300.215978921@linuxfoundation.org> X-Mailer: git-send-email 2.31.1 In-Reply-To: <20210409095259.957388690@linuxfoundation.org> References: <20210409095259.957388690@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org From: Piotr Krysiuk commit e4d4d456436bfb2fe412ee2cd489f7658449b098 upstream. The branch displacement logic in the BPF JIT compilers for x86 assumes that, for any generated branch instruction, the distance cannot increase between optimization passes. But this assumption can be violated due to how the distances are computed. Specifically, whenever a backward branch is processed in do_jit(), the distance is computed by subtracting the positions in the machine code from different optimization passes. This is because part of addrs[] is already updated for the current optimization pass, before the branch instruction is visited. And so the optimizer can expand blocks of machine code in some cases. This can confuse the optimizer logic, where it assumes that a fixed point has been reached for all machine code blocks once the total program size stops changing. And then the JIT compiler can output abnormal machine code containing incorrect branch displacements. To mitigate this issue, we assert that a fixed point is reached while populating the output image. This rejects any problematic programs. The issue affects both x86-32 and x86-64. We mitigate separately to ease backporting. Signed-off-by: Piotr Krysiuk Reviewed-by: Daniel Borkmann Signed-off-by: Daniel Borkmann Signed-off-by: Greg Kroah-Hartman --- arch/x86/net/bpf_jit_comp.c | 11 ++++++++++- 1 file changed, 10 insertions(+), 1 deletion(-) --- a/arch/x86/net/bpf_jit_comp.c +++ b/arch/x86/net/bpf_jit_comp.c @@ -1038,7 +1038,16 @@ common_load: } if (image) { - if (unlikely(proglen + ilen > oldproglen)) { + /* + * When populating the image, assert that: + * + * i) We do not write beyond the allocated space, and + * ii) addrs[i] did not change from the prior run, in order + * to validate assumptions made for computing branch + * displacements. + */ + if (unlikely(proglen + ilen > oldproglen || + proglen + ilen != addrs[i])) { pr_err("bpf_jit_compile fatal error\n"); return -EFAULT; } From patchwork Fri Apr 9 09:53:18 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Greg KH X-Patchwork-Id: 418810 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=-18.8 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_CR_TRAILER, INCLUDES_PATCH, MAILING_LIST_MULTI, SPF_HELO_NONE, SPF_PASS, URIBL_BLOCKED, 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 D719AC433B4 for ; Fri, 9 Apr 2021 09:54:34 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id A9EFC6115C for ; Fri, 9 Apr 2021 09:54:34 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232796AbhDIJyq (ORCPT ); Fri, 9 Apr 2021 05:54:46 -0400 Received: from mail.kernel.org ([198.145.29.99]:42178 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232813AbhDIJyp (ORCPT ); Fri, 9 Apr 2021 05:54:45 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id D0DE76115B; Fri, 9 Apr 2021 09:54:31 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1617962072; bh=1hcmPV7M7pj+OmYX4U8CBCcpTLcE8MXBAC5Zii/IDIY=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=vej9WMZ0h8PxIdNDU0KpreZJ3pdYplW9Ru/B4pxv/5CtH0KMIepkGOXdwF8PI42mE Z5VSaBV2kA45Uo0qv2RypqJj8MZGuI18SPgfD+GrqHDe1eGzxkuuB00St3xcHs+n/U +45zGAz5X4mothCK3ZPMIV9rmsocjx9wNyuoXnoQ= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Miquel Raynal , Sudip Mukherjee Subject: [PATCH 4.4 12/20] mtd: rawnand: sharpsl: Fix the probe error path Date: Fri, 9 Apr 2021 11:53:18 +0200 Message-Id: <20210409095300.346284263@linuxfoundation.org> X-Mailer: git-send-email 2.31.1 In-Reply-To: <20210409095259.957388690@linuxfoundation.org> References: <20210409095259.957388690@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org From: Miquel Raynal commit 0f44b3275b3798ccb97a2f51ac85871c30d6fbbc upstream nand_release() is supposed be called after MTD device registration. Here, only nand_scan() happened, so use nand_cleanup() instead. There is no Fixes tag applying here as the use of nand_release() in this driver predates by far the introduction of nand_cleanup() in commit d44154f969a4 ("mtd: nand: Provide nand_cleanup() function to free NAND related resources") which makes this change possible. However, pointing this commit as the culprit for backporting purposes makes sense. Fixes: d44154f969a4 ("mtd: nand: Provide nand_cleanup() function to free NAND related resources") Signed-off-by: Miquel Raynal Cc: stable@vger.kernel.org Link: https://lore.kernel.org/linux-mtd/20200519130035.1883-49-miquel.raynal@bootlin.com [sudip: manual backport to old file] Signed-off-by: Sudip Mukherjee Signed-off-by: Greg Kroah-Hartman --- drivers/mtd/nand/sharpsl.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/mtd/nand/sharpsl.c +++ b/drivers/mtd/nand/sharpsl.c @@ -189,7 +189,7 @@ static int sharpsl_nand_probe(struct pla return 0; err_add: - nand_release(&sharpsl->mtd); + nand_cleanup(this); err_scan: iounmap(sharpsl->io); From patchwork Fri Apr 9 09:53:19 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Greg KH X-Patchwork-Id: 418809 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=-18.8 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_CR_TRAILER, INCLUDES_PATCH, MAILING_LIST_MULTI, SPF_HELO_NONE, SPF_PASS, URIBL_BLOCKED, 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 87B67C43462 for ; Fri, 9 Apr 2021 09:54:36 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 63AEE61181 for ; Fri, 9 Apr 2021 09:54:36 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232835AbhDIJyr (ORCPT ); Fri, 9 Apr 2021 05:54:47 -0400 Received: from mail.kernel.org ([198.145.29.99]:42206 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232878AbhDIJyr (ORCPT ); Fri, 9 Apr 2021 05:54:47 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id 3FE8A6115B; Fri, 9 Apr 2021 09:54:34 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1617962074; bh=n44tlIutih1PyfYdW+eMYw3ybCdE79skxT9oGoHWpEE=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=HqLQC+qVMCpdfrRwhWNmalrWHrnbK8Q4KFgVHzvHYI1WYyqpMVwMxpMv+WLaFvAE+ AB4RXNVck5nF4tz9F5hI5rc+h7a68NsiTG2UGu9FMRUHJLnc4daDrpGJuPcAvTcsrZ h9RG5EKL1b85LfQXlWMRpWVKM8cTiIQ7I6ymhf3g= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Miquel Raynal , Sudip Mukherjee Subject: [PATCH 4.4 13/20] mtd: rawnand: plat_nand: Fix the probe error path Date: Fri, 9 Apr 2021 11:53:19 +0200 Message-Id: <20210409095300.377944697@linuxfoundation.org> X-Mailer: git-send-email 2.31.1 In-Reply-To: <20210409095259.957388690@linuxfoundation.org> References: <20210409095259.957388690@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org From: Miquel Raynal commit 5284024b4dac5e94f7f374ca905c7580dbc455e9 upstream nand_release() is supposed be called after MTD device registration. Here, only nand_scan() happened, so use nand_cleanup() instead. There is no real Fixes tag applying here as the use of nand_release() in this driver predates by far the introduction of nand_cleanup() in commit d44154f969a4 ("mtd: nand: Provide nand_cleanup() function to free NAND related resources") which makes this change possible, hence pointing it as the commit to fix for backporting purposes, even if this commit is not introducing any bug. Fixes: d44154f969a4 ("mtd: nand: Provide nand_cleanup() function to free NAND related resources") Signed-off-by: Miquel Raynal Cc: stable@vger.kernel.org Link: https://lore.kernel.org/linux-mtd/20200519130035.1883-43-miquel.raynal@bootlin.com [sudip: manual backport to old file] Signed-off-by: Sudip Mukherjee Signed-off-by: Greg Kroah-Hartman --- drivers/mtd/nand/plat_nand.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/mtd/nand/plat_nand.c +++ b/drivers/mtd/nand/plat_nand.c @@ -102,7 +102,7 @@ static int plat_nand_probe(struct platfo if (!err) return err; - nand_release(&data->mtd); + nand_cleanup(&data->chip); out: if (pdata->ctrl.remove) pdata->ctrl.remove(pdev); From patchwork Fri Apr 9 09:53:21 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Greg KH X-Patchwork-Id: 418808 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=-18.8 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_CR_TRAILER, INCLUDES_PATCH, MAILING_LIST_MULTI, SPF_HELO_NONE, SPF_PASS, URIBL_BLOCKED, 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 CF081C433B4 for ; Fri, 9 Apr 2021 09:54:45 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id AB534611F1 for ; Fri, 9 Apr 2021 09:54:45 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231638AbhDIJy5 (ORCPT ); Fri, 9 Apr 2021 05:54:57 -0400 Received: from mail.kernel.org ([198.145.29.99]:42360 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233008AbhDIJyw (ORCPT ); Fri, 9 Apr 2021 05:54:52 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id CCEED61182; Fri, 9 Apr 2021 09:54:38 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1617962079; bh=rtQqADye2j3uJ6LFp6KqltEYymbd/4R/x1yJHqHTBQo=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=WZN7TpRZW3oPhbf7zW2ZUNr+k3ZlFvfg4ui7dB8PcWD8M1KuHD59MJShydYVTG6rS pj2iWTujOppLldQHikzMaSBRRZcNOZod8vBe+IKnax7t1fsEv4qk/cIcxfQtNFjLQU 8/HtxPnSARvwLoazwKrjY3oSKzMZRM+SOoQuL7EQ= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Miquel Raynal , Sudip Mukherjee Subject: [PATCH 4.4 15/20] mtd: rawnand: orion: Fix the probe error path Date: Fri, 9 Apr 2021 11:53:21 +0200 Message-Id: <20210409095300.442861650@linuxfoundation.org> X-Mailer: git-send-email 2.31.1 In-Reply-To: <20210409095259.957388690@linuxfoundation.org> References: <20210409095259.957388690@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org From: Miquel Raynal commit be238fbf78e4c7c586dac235ab967d3e565a4d1a upstream nand_release() is supposed be called after MTD device registration. Here, only nand_scan() happened, so use nand_cleanup() instead. There is no real Fixes tag applying here as the use of nand_release() in this driver predates by far the introduction of nand_cleanup() in commit d44154f969a4 ("mtd: nand: Provide nand_cleanup() function to free NAND related resources") which makes this change possible. However, pointing this commit as the culprit for backporting purposes makes sense even if this commit is not introducing any bug. Fixes: d44154f969a4 ("mtd: nand: Provide nand_cleanup() function to free NAND related resources") Signed-off-by: Miquel Raynal Cc: stable@vger.kernel.org Link: https://lore.kernel.org/linux-mtd/20200519130035.1883-34-miquel.raynal@bootlin.com [sudip: manual backport to old file] Signed-off-by: Sudip Mukherjee Signed-off-by: Greg Kroah-Hartman --- drivers/mtd/nand/orion_nand.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/mtd/nand/orion_nand.c +++ b/drivers/mtd/nand/orion_nand.c @@ -165,7 +165,7 @@ static int __init orion_nand_probe(struc ret = mtd_device_parse_register(mtd, NULL, &ppdata, board->parts, board->nr_parts); if (ret) { - nand_release(mtd); + nand_cleanup(nc); goto no_dev; } From patchwork Fri Apr 9 09:53:23 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Greg KH X-Patchwork-Id: 418807 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=-18.8 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_CR_TRAILER, INCLUDES_PATCH, MAILING_LIST_MULTI, SPF_HELO_NONE, SPF_PASS, URIBL_BLOCKED, 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 A19FDC43462 for ; Fri, 9 Apr 2021 09:54:50 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 72E3D611CA for ; Fri, 9 Apr 2021 09:54:50 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233108AbhDIJzB (ORCPT ); Fri, 9 Apr 2021 05:55:01 -0400 Received: from mail.kernel.org ([198.145.29.99]:42476 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233060AbhDIJy5 (ORCPT ); Fri, 9 Apr 2021 05:54:57 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id 125996103E; Fri, 9 Apr 2021 09:54:43 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1617962084; bh=TM8BCZMEboIO7AG6IihOKSJ0I9UXln3Zgh6Nlyuj9y8=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=mrhgW60F8bMsjfk9RYGoyqoMo3+P4dyfWpYw8AQnq1aUGypQ+OroTtzVxS7Or7/5s EjXSoGYX3IU6A3A10TvfFzWl+EMwF9zgOyz0/POqtA0KlR/R2/vQaiXOEPznlQLAcH eBIEu4OI2y2MI2s+J224WqRmW5CNEr/PKlsq885M= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, "Tzvetomir Stoyanov (VMware)" , Joerg Roedel , "Steven Rostedt (VMware)" , Sudip Mukherjee Subject: [PATCH 4.4 17/20] tracing: Add a vmalloc_sync_mappings() for safe measure Date: Fri, 9 Apr 2021 11:53:23 +0200 Message-Id: <20210409095300.501289932@linuxfoundation.org> X-Mailer: git-send-email 2.31.1 In-Reply-To: <20210409095259.957388690@linuxfoundation.org> References: <20210409095259.957388690@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org From: "Steven Rostedt (VMware)" commit 11f5efc3ab66284f7aaacc926e9351d658e2577b upstream x86_64 lazily maps in the vmalloc pages, and the way this works with per_cpu areas can be complex, to say the least. Mappings may happen at boot up, and if nothing synchronizes the page tables, those page mappings may not be synced till they are used. This causes issues for anything that might touch one of those mappings in the path of the page fault handler. When one of those unmapped mappings is touched in the page fault handler, it will cause another page fault, which in turn will cause a page fault, and leave us in a loop of page faults. Commit 763802b53a42 ("x86/mm: split vmalloc_sync_all()") split vmalloc_sync_all() into vmalloc_sync_unmappings() and vmalloc_sync_mappings(), as on system exit, it did not need to do a full sync on x86_64 (although it still needed to be done on x86_32). By chance, the vmalloc_sync_all() would synchronize the page mappings done at boot up and prevent the per cpu area from being a problem for tracing in the page fault handler. But when that synchronization in the exit of a task became a nop, it caused the problem to appear. Link: https://lore.kernel.org/r/20200429054857.66e8e333@oasis.local.home Cc: stable@vger.kernel.org Fixes: 737223fbca3b1 ("tracing: Consolidate buffer allocation code") Reported-by: "Tzvetomir Stoyanov (VMware)" Suggested-by: Joerg Roedel Signed-off-by: Steven Rostedt (VMware) [sudip: add header] Signed-off-by: Sudip Mukherjee Signed-off-by: Greg Kroah-Hartman --- kernel/trace/trace.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+) --- a/kernel/trace/trace.c +++ b/kernel/trace/trace.c @@ -26,6 +26,7 @@ #include #include #include +#include #include #include #include @@ -6626,6 +6627,19 @@ static int allocate_trace_buffers(struct */ allocate_snapshot = false; #endif + + /* + * Because of some magic with the way alloc_percpu() works on + * x86_64, we need to synchronize the pgd of all the tables, + * otherwise the trace events that happen in x86_64 page fault + * handlers can't cope with accessing the chance that a + * alloc_percpu()'d memory might be touched in the page fault trace + * event. Oh, and we need to audit all other alloc_percpu() and vmalloc() + * calls in tracing, because something might get triggered within a + * page fault trace event! + */ + vmalloc_sync_mappings(); + return 0; } From patchwork Fri Apr 9 09:53:25 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Greg KH X-Patchwork-Id: 418806 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=-18.8 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_CR_TRAILER, INCLUDES_PATCH, MAILING_LIST_MULTI, SPF_HELO_NONE, SPF_PASS, URIBL_BLOCKED, 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 A8951C43460 for ; Fri, 9 Apr 2021 09:54:57 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 80E306120C for ; Fri, 9 Apr 2021 09:54:57 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233175AbhDIJzI (ORCPT ); Fri, 9 Apr 2021 05:55:08 -0400 Received: from mail.kernel.org ([198.145.29.99]:42590 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232964AbhDIJzF (ORCPT ); Fri, 9 Apr 2021 05:55:05 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id 93F8E611C9; Fri, 9 Apr 2021 09:54:49 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1617962090; bh=55GvB+ZBPGH92rbkSluyz0cHnOKe5To3V3NJBZFj5zA=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=1P9nRXYXNW2Da+Ap2VrCXO1jp6FgdPfQztyLdtwcHc8jRoeWKh5t+YX26bTXdMEmP U/4hF2PFSxuptGGKqPgWFmByw+e+F1mworLd8aiHoVyvjG/kpZG97weInBIS54dJYk W9ClMZAHz26NnQNYhGmOzTwuheqOzfpHKNbSNZ6w= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, kernel test robot , Arnd Bergmann , Heiko Carstens , Guenter Roeck Subject: [PATCH 4.4 19/20] init/Kconfig: make COMPILE_TEST depend on !S390 Date: Fri, 9 Apr 2021 11:53:25 +0200 Message-Id: <20210409095300.561096141@linuxfoundation.org> X-Mailer: git-send-email 2.31.1 In-Reply-To: <20210409095259.957388690@linuxfoundation.org> References: <20210409095259.957388690@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org From: Heiko Carstens commit 334ef6ed06fa1a54e35296b77b693bcf6d63ee9e upstream. While allmodconfig and allyesconfig build for s390 there are also various bots running compile tests with randconfig, where PCI is disabled. This reveals that a lot of drivers should actually depend on HAS_IOMEM. Adding this to each device driver would be a never ending story, therefore just disable COMPILE_TEST for s390. The reasoning is more or less the same as described in commit bc083a64b6c0 ("init/Kconfig: make COMPILE_TEST depend on !UML"). Reported-by: kernel test robot Suggested-by: Arnd Bergmann Signed-off-by: Heiko Carstens Cc: Guenter Roeck Signed-off-by: Greg Kroah-Hartman --- init/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/init/Kconfig +++ b/init/Kconfig @@ -65,7 +65,7 @@ config CROSS_COMPILE config COMPILE_TEST bool "Compile also drivers which will not load" - depends on !UML + depends on !UML && !S390 default n help Some drivers can be compiled on a different platform than they are From patchwork Fri Apr 9 09:53:26 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Greg KH X-Patchwork-Id: 418805 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=-18.8 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_CR_TRAILER, INCLUDES_PATCH, MAILING_LIST_MULTI, SPF_HELO_NONE, SPF_PASS, URIBL_BLOCKED, 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 4F4F7C43460 for ; Fri, 9 Apr 2021 09:55:06 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 2F015611BF for ; Fri, 9 Apr 2021 09:55:06 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233380AbhDIJzR (ORCPT ); Fri, 9 Apr 2021 05:55:17 -0400 Received: from mail.kernel.org ([198.145.29.99]:42520 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233054AbhDIJzI (ORCPT ); Fri, 9 Apr 2021 05:55:08 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id 74EF5611BE; Fri, 9 Apr 2021 09:54:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1617962094; bh=aasq1UfykmEKZrVsIOCgwB7zHlTo7HeqhamPExmYheM=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=KzgC+4n3yz+0jd34uVxYyt4JLd10ct+u0k/cy7kH+oUgSpzfWG8ObBukyRZ51xv7C vAC5HxCEWglv0K37BifW8hSi+WHejqUtfSU1EC7u4U3JW8o3HLUXlhK3nSPGRbJR3D Wb5bTUmDXlSX3UpLMjSoshC9wt5J1Vq0xpiW+W3I= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Masahiro Yamada , Heiko Carstens , Guenter Roeck , Arnd Bergmann , Kees Cook , Daniel Borkmann , Johannes Weiner , KP Singh , Nathan Chancellor , Nick Terrell , Quentin Perret , Valentin Schneider , "Enrico Weigelt, metux IT consult" , Andrew Morton , Linus Torvalds Subject: [PATCH 4.4 20/20] init/Kconfig: make COMPILE_TEST depend on HAS_IOMEM Date: Fri, 9 Apr 2021 11:53:26 +0200 Message-Id: <20210409095300.593326120@linuxfoundation.org> X-Mailer: git-send-email 2.31.1 In-Reply-To: <20210409095259.957388690@linuxfoundation.org> References: <20210409095259.957388690@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org From: Masahiro Yamada commit ea29b20a828511de3348334e529a3d046a180416 upstream. I read the commit log of the following two: - bc083a64b6c0 ("init/Kconfig: make COMPILE_TEST depend on !UML") - 334ef6ed06fa ("init/Kconfig: make COMPILE_TEST depend on !S390") Both are talking about HAS_IOMEM dependency missing in many drivers. So, 'depends on HAS_IOMEM' seems the direct, sensible solution to me. This does not change the behavior of UML. UML still cannot enable COMPILE_TEST because it does not provide HAS_IOMEM. The current dependency for S390 is too strong. Under the condition of CONFIG_PCI=y, S390 provides HAS_IOMEM, hence can enable COMPILE_TEST. I also removed the meaningless 'default n'. Link: https://lkml.kernel.org/r/20210224140809.1067582-1-masahiroy@kernel.org Signed-off-by: Masahiro Yamada Cc: Heiko Carstens Cc: Guenter Roeck Cc: Arnd Bergmann Cc: Kees Cook Cc: Daniel Borkmann Cc: Johannes Weiner Cc: KP Singh Cc: Nathan Chancellor Cc: Nick Terrell Cc: Quentin Perret Cc: Valentin Schneider Cc: "Enrico Weigelt, metux IT consult" Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Cc: Guenter Roeck Signed-off-by: Greg Kroah-Hartman --- init/Kconfig | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) --- a/init/Kconfig +++ b/init/Kconfig @@ -65,8 +65,7 @@ config CROSS_COMPILE config COMPILE_TEST bool "Compile also drivers which will not load" - depends on !UML && !S390 - default n + depends on HAS_IOMEM help Some drivers can be compiled on a different platform than they are intended to be run on. Despite they cannot be loaded there (or even