From patchwork Fri Apr 9 09:53:33 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Greg KH X-Patchwork-Id: 418773 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 8837CC43470 for ; Fri, 9 Apr 2021 09:59:37 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 33A2B6124A for ; Fri, 9 Apr 2021 09:59:37 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233781AbhDIJ7s (ORCPT ); Fri, 9 Apr 2021 05:59:48 -0400 Received: from mail.kernel.org ([198.145.29.99]:44896 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233333AbhDIJ60 (ORCPT ); Fri, 9 Apr 2021 05:58:26 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id 6584661181; Fri, 9 Apr 2021 09:58:05 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1617962286; bh=WzFfUneWrJcCpACw3LjmPTmDA21G2SDGS3pXZ15Tmt0=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=FtDQrMdZnheDKteDWHE3xvJGv0MbZTLtuwskTWd8Shxl+9/248gdumTwC0gWYO9ET gTNOQtL6Atux6LLdnjLeazjrTKti6hJzIHNeP8SKsNGsY5rTd3XQlQ+OXcfZLS/oOd IzW0B9aodGZ5lGWT7ArV5XbiLW25C9+TsHVIdMR8= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Alban Bedel , Alexander Kobel , Hans de Goede , Sasha Levin Subject: [PATCH 5.4 03/23] platform/x86: intel-hid: Support Lenovo ThinkPad X1 Tablet Gen 2 Date: Fri, 9 Apr 2021 11:53:33 +0200 Message-Id: <20210409095303.005801726@linuxfoundation.org> X-Mailer: git-send-email 2.31.1 In-Reply-To: <20210409095302.894568462@linuxfoundation.org> References: <20210409095302.894568462@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org From: Alban Bedel [ Upstream commit 56678a5f44ef5f0ad9a67194bbee2280c6286534 ] Like a few other system the Lenovo ThinkPad X1 Tablet Gen 2 miss the HEBC method, which prevent the power button from working. Add a quirk to enable the button array on this system family and fix the power button. Signed-off-by: Alban Bedel Tested-by: Alexander Kobel Link: https://lore.kernel.org/r/20210222141559.3775-1-albeu@free.fr Signed-off-by: Hans de Goede Signed-off-by: Sasha Levin --- drivers/platform/x86/intel-hid.c | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/drivers/platform/x86/intel-hid.c b/drivers/platform/x86/intel-hid.c index ad1399dcb21f..164bebbfea21 100644 --- a/drivers/platform/x86/intel-hid.c +++ b/drivers/platform/x86/intel-hid.c @@ -84,6 +84,13 @@ static const struct dmi_system_id button_array_table[] = { DMI_MATCH(DMI_PRODUCT_NAME, "HP Spectre x2 Detachable"), }, }, + { + .ident = "Lenovo ThinkPad X1 Tablet Gen 2", + .matches = { + DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"), + DMI_MATCH(DMI_PRODUCT_FAMILY, "ThinkPad X1 Tablet Gen 2"), + }, + }, { } }; From patchwork Fri Apr 9 09:53:34 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Greg KH X-Patchwork-Id: 418772 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 86863C43462 for ; Fri, 9 Apr 2021 09:59:38 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 4ECEC6124A for ; Fri, 9 Apr 2021 09:59:38 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233554AbhDIJ7t (ORCPT ); Fri, 9 Apr 2021 05:59:49 -0400 Received: from mail.kernel.org ([198.145.29.99]:43734 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232990AbhDIJ61 (ORCPT ); Fri, 9 Apr 2021 05:58:27 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id 00158611BF; Fri, 9 Apr 2021 09:58:07 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1617962288; bh=h7zk+jQc323KneHrpBxAOOGs0ESphvR3hizQ5+p77qQ=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=ZvDgQPVATo4awKWWL6CIEGYzpwbs1kMHz9bzGU7Fc7A8NsTdKhw2SW+974+7RtN8i DJcPn0raLwDmaV4o8seuriaXLq0rsran5IRyV7tjFU89nvhNKYJJTt1+qeG80tKzsB Pe0/IFIgXK98Jp24cPgmmK45rj2lemfnCAftPhOY= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Yonghong Song , Alexei Starovoitov , Daniel Borkmann , Sasha Levin Subject: [PATCH 5.4 04/23] bpf, x86: Use kvmalloc_array instead kmalloc_array in bpf_jit_comp Date: Fri, 9 Apr 2021 11:53:34 +0200 Message-Id: <20210409095303.036637946@linuxfoundation.org> X-Mailer: git-send-email 2.31.1 In-Reply-To: <20210409095302.894568462@linuxfoundation.org> References: <20210409095302.894568462@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org From: Yonghong Song [ Upstream commit de920fc64cbaa031f947e9be964bda05fd090380 ] x86 bpf_jit_comp.c used kmalloc_array to store jited addresses for each bpf insn. With a large bpf program, we have see the following allocation failures in our production server: page allocation failure: order:5, mode:0x40cc0(GFP_KERNEL|__GFP_COMP), nodemask=(null),cpuset=/,mems_allowed=0" Call Trace: dump_stack+0x50/0x70 warn_alloc.cold.120+0x72/0xd2 ? __alloc_pages_direct_compact+0x157/0x160 __alloc_pages_slowpath+0xcdb/0xd00 ? get_page_from_freelist+0xe44/0x1600 ? vunmap_page_range+0x1ba/0x340 __alloc_pages_nodemask+0x2c9/0x320 kmalloc_order+0x18/0x80 kmalloc_order_trace+0x1d/0xa0 bpf_int_jit_compile+0x1e2/0x484 ? kmalloc_order_trace+0x1d/0xa0 bpf_prog_select_runtime+0xc3/0x150 bpf_prog_load+0x480/0x720 ? __mod_memcg_lruvec_state+0x21/0x100 __do_sys_bpf+0xc31/0x2040 ? close_pdeo+0x86/0xe0 do_syscall_64+0x42/0x110 entry_SYSCALL_64_after_hwframe+0x44/0xa9 RIP: 0033:0x7f2f300f7fa9 Code: Bad RIP value. Dumped assembly: ffffffff810b6d70 : ; { ffffffff810b6d70: e8 eb a5 b4 00 callq 0xffffffff81c01360 <__fentry__> ffffffff810b6d75: 41 57 pushq %r15 ... ffffffff810b6f39: e9 72 fe ff ff jmp 0xffffffff810b6db0 ; addrs = kmalloc_array(prog->len + 1, sizeof(*addrs), GFP_KERNEL); ffffffff810b6f3e: 8b 45 0c movl 12(%rbp), %eax ; return __kmalloc(bytes, flags); ffffffff810b6f41: be c0 0c 00 00 movl $3264, %esi ; addrs = kmalloc_array(prog->len + 1, sizeof(*addrs), GFP_KERNEL); ffffffff810b6f46: 8d 78 01 leal 1(%rax), %edi ; if (unlikely(check_mul_overflow(n, size, &bytes))) ffffffff810b6f49: 48 c1 e7 02 shlq $2, %rdi ; return __kmalloc(bytes, flags); ffffffff810b6f4d: e8 8e 0c 1d 00 callq 0xffffffff81287be0 <__kmalloc> ; if (!addrs) { ffffffff810b6f52: 48 85 c0 testq %rax, %rax Change kmalloc_array() to kvmalloc_array() to avoid potential allocation error for big bpf programs. Signed-off-by: Yonghong Song Signed-off-by: Alexei Starovoitov Signed-off-by: Daniel Borkmann Link: https://lore.kernel.org/bpf/20210309015647.3657852-1-yhs@fb.com Signed-off-by: Sasha Levin --- arch/x86/net/bpf_jit_comp.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/x86/net/bpf_jit_comp.c b/arch/x86/net/bpf_jit_comp.c index 18936533666e..44c7d7aef8c1 100644 --- a/arch/x86/net/bpf_jit_comp.c +++ b/arch/x86/net/bpf_jit_comp.c @@ -1118,7 +1118,7 @@ struct bpf_prog *bpf_int_jit_compile(struct bpf_prog *prog) extra_pass = true; goto skip_init_addrs; } - addrs = kmalloc_array(prog->len + 1, sizeof(*addrs), GFP_KERNEL); + addrs = kvmalloc_array(prog->len + 1, sizeof(*addrs), GFP_KERNEL); if (!addrs) { prog = orig_prog; goto out_addrs; @@ -1195,7 +1195,7 @@ struct bpf_prog *bpf_int_jit_compile(struct bpf_prog *prog) if (image) bpf_prog_fill_jited_linfo(prog, addrs + 1); out_addrs: - kfree(addrs); + kvfree(addrs); kfree(jit_data); prog->aux->jit_data = NULL; } From patchwork Fri Apr 9 09:53:36 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Greg KH X-Patchwork-Id: 418771 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 79624C433ED for ; Fri, 9 Apr 2021 09:59:50 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 402E661286 for ; Fri, 9 Apr 2021 09:59:50 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233830AbhDIKAA (ORCPT ); Fri, 9 Apr 2021 06:00:00 -0400 Received: from mail.kernel.org ([198.145.29.99]:46030 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233774AbhDIJ6f (ORCPT ); Fri, 9 Apr 2021 05:58:35 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id CF920611F0; Fri, 9 Apr 2021 09:58:13 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1617962294; bh=Tb3hmGaH6p9+t6S8cZ02jNBpQmnLki+Aj0AsSD5Ju3g=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=GKHdwQmnaLg4ASXCpabrQPwN543ri0kx/azgwr2BrhO6AjJhtbqKfwBvEmXE7IcD3 eUDX/SQZwBhMOLc7BuqQgQ2tdloeUkxit2oX6ifa7gdCOjkCSKZNgB9HvWRXsC4uRl ZlodusNxqy7eFmJr7yMriL+HVga93C6jycayZiVk= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Pavel Andrianov , "David S. Miller" , Sasha Levin Subject: [PATCH 5.4 06/23] net: pxa168_eth: Fix a potential data race in pxa168_eth_remove Date: Fri, 9 Apr 2021 11:53:36 +0200 Message-Id: <20210409095303.107903042@linuxfoundation.org> X-Mailer: git-send-email 2.31.1 In-Reply-To: <20210409095302.894568462@linuxfoundation.org> References: <20210409095302.894568462@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org From: Pavel Andrianov [ Upstream commit 0571a753cb07982cc82f4a5115e0b321da89e1f3 ] pxa168_eth_remove() firstly calls unregister_netdev(), then cancels a timeout work. unregister_netdev() shuts down a device interface and removes it from the kernel tables. If the timeout occurs in parallel, the timeout work (pxa168_eth_tx_timeout_task) performs stop and open of the device. It may lead to an inconsistent state and memory leaks. Found by Linux Driver Verification project (linuxtesting.org). Signed-off-by: Pavel Andrianov Signed-off-by: David S. Miller Signed-off-by: Sasha Levin --- drivers/net/ethernet/marvell/pxa168_eth.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/ethernet/marvell/pxa168_eth.c b/drivers/net/ethernet/marvell/pxa168_eth.c index 51b77c2de400..235bbb2940a8 100644 --- a/drivers/net/ethernet/marvell/pxa168_eth.c +++ b/drivers/net/ethernet/marvell/pxa168_eth.c @@ -1554,8 +1554,8 @@ static int pxa168_eth_remove(struct platform_device *pdev) mdiobus_unregister(pep->smi_bus); mdiobus_free(pep->smi_bus); - unregister_netdev(dev); cancel_work_sync(&pep->tx_timeout_task); + unregister_netdev(dev); free_netdev(dev); return 0; } From patchwork Fri Apr 9 09:53:38 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Greg KH X-Patchwork-Id: 418770 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 81BEAC433B4 for ; Fri, 9 Apr 2021 10:00:07 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 5AE07611BE for ; Fri, 9 Apr 2021 10:00:07 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233857AbhDIKAR (ORCPT ); Fri, 9 Apr 2021 06:00:17 -0400 Received: from mail.kernel.org ([198.145.29.99]:45122 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233511AbhDIJ6q (ORCPT ); Fri, 9 Apr 2021 05:58:46 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id D33F3611BE; Fri, 9 Apr 2021 09:58:18 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1617962299; bh=PEsWAovB893nxOhB0lObleZhDaezFPfqrvJWImgeMPc=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=JtzefQIofkDJSeyJodM7WDViCBYafTEXxnaepTyhHwO9LusSLTsuPkDsFSVhyYVQ5 1vX4nRtV0z1VneQoszIfyRkoaFbIWs+58aKr9Kgw45NoeEoiehN/ll4qF8uGx4rMNc CHiqPjdfFvRzWQlOmOmywGyH33rJfskNAYrFokK4= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Karthikeyan Kathirvel , Johannes Berg , Sasha Levin Subject: [PATCH 5.4 08/23] mac80211: choose first enabled channel for monitor Date: Fri, 9 Apr 2021 11:53:38 +0200 Message-Id: <20210409095303.168335295@linuxfoundation.org> X-Mailer: git-send-email 2.31.1 In-Reply-To: <20210409095302.894568462@linuxfoundation.org> References: <20210409095302.894568462@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org From: Karthikeyan Kathirvel [ Upstream commit 041c881a0ba8a75f71118bd9766b78f04beed469 ] Even if the first channel from sband channel list is invalid or disabled mac80211 ends up choosing it as the default channel for monitor interfaces, making them not usable. Fix this by assigning the first available valid or enabled channel instead. Signed-off-by: Karthikeyan Kathirvel Link: https://lore.kernel.org/r/1615440547-7661-1-git-send-email-kathirve@codeaurora.org [reword commit message, comment, code cleanups] Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin --- net/mac80211/main.c | 13 ++++++++++++- 1 file changed, 12 insertions(+), 1 deletion(-) diff --git a/net/mac80211/main.c b/net/mac80211/main.c index 3e8561c3b0e7..5b3189a37680 100644 --- a/net/mac80211/main.c +++ b/net/mac80211/main.c @@ -954,8 +954,19 @@ int ieee80211_register_hw(struct ieee80211_hw *hw) continue; if (!dflt_chandef.chan) { + /* + * Assign the first enabled channel to dflt_chandef + * from the list of channels + */ + for (i = 0; i < sband->n_channels; i++) + if (!(sband->channels[i].flags & + IEEE80211_CHAN_DISABLED)) + break; + /* if none found then use the first anyway */ + if (i == sband->n_channels) + i = 0; cfg80211_chandef_create(&dflt_chandef, - &sband->channels[0], + &sband->channels[i], NL80211_CHAN_NO_HT); /* init channel we're on */ if (!local->use_chanctx && !local->_oper_chandef.chan) { From patchwork Fri Apr 9 09:53:40 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Greg KH X-Patchwork-Id: 418780 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 A79BAC433B4 for ; Fri, 9 Apr 2021 09:58:25 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 8102461207 for ; Fri, 9 Apr 2021 09:58:25 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233517AbhDIJ6h (ORCPT ); Fri, 9 Apr 2021 05:58:37 -0400 Received: from mail.kernel.org ([198.145.29.99]:44346 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233785AbhDIJ5l (ORCPT ); Fri, 9 Apr 2021 05:57:41 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id 49E2A61209; Fri, 9 Apr 2021 09:57:27 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1617962247; bh=4Ec/QfZsmhDmWj+2nCwATss9P+aU2FPa9MFw0FFo6WU=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=T6UkqvuKlsgC2LVO/46+1qTgfpO+uD0Xo2DzYE4bvLTODd+qJuTHdyLtMm/A1ph/B Zzw2xgpqk65BZEmzIPb8kTQix4z5hFT+im6kE54xG3xSp1gPuTMe0Zp9GJCsJrKZ2J Tq1Cu1pIGBKgCLHhRh3fsir3G+hhbY9PuzyAt/Bc= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Rob Clark , Douglas Anderson , Sasha Levin Subject: [PATCH 5.4 10/23] drm/msm: Ratelimit invalid-fence message Date: Fri, 9 Apr 2021 11:53:40 +0200 Message-Id: <20210409095303.228694300@linuxfoundation.org> X-Mailer: git-send-email 2.31.1 In-Reply-To: <20210409095302.894568462@linuxfoundation.org> References: <20210409095302.894568462@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org From: Rob Clark [ Upstream commit 7ad48d27a2846bfda29214fb454d001c3e02b9e7 ] We have seen a couple cases where low memory situations cause something bad to happen, followed by a flood of these messages obscuring the root cause. Lets ratelimit the dmesg spam so that next time it happens we don't lose the kernel traces leading up to this. Signed-off-by: Rob Clark Reviewed-by: Douglas Anderson Signed-off-by: Sasha Levin --- drivers/gpu/drm/msm/msm_fence.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/msm/msm_fence.c b/drivers/gpu/drm/msm/msm_fence.c index ad2703698b05..cd59a5918038 100644 --- a/drivers/gpu/drm/msm/msm_fence.c +++ b/drivers/gpu/drm/msm/msm_fence.c @@ -45,7 +45,7 @@ int msm_wait_fence(struct msm_fence_context *fctx, uint32_t fence, int ret; if (fence > fctx->last_fence) { - DRM_ERROR("%s: waiting on invalid fence: %u (of %u)\n", + DRM_ERROR_RATELIMITED("%s: waiting on invalid fence: %u (of %u)\n", fctx->name, fence, fctx->last_fence); return -EINVAL; } From patchwork Fri Apr 9 09:53:42 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Greg KH X-Patchwork-Id: 418779 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 8F61BC433B4 for ; Fri, 9 Apr 2021 09:58:37 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 6116861207 for ; Fri, 9 Apr 2021 09:58:37 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233864AbhDIJ6s (ORCPT ); Fri, 9 Apr 2021 05:58:48 -0400 Received: from mail.kernel.org ([198.145.29.99]:45194 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233554AbhDIJ5p (ORCPT ); Fri, 9 Apr 2021 05:57:45 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id 45FB66120B; Fri, 9 Apr 2021 09:57:32 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1617962252; bh=qCzbvsEKO4mJgVpn+5ElMocKhP7Xnv1t0QhDnNpV4DY=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=c5pAcJbmsRRcca3klpCTOZscL8q506BXQe+Y2OvphAfQSQttUgt5ViHTZCUw5hdiZ jDt9NJiOhKDvHCcRljnnwmv45PxOKWvlaFQGiXsLULZaytr+WEsE0BFcil3kOGPGvU 3olfW05RT/0+0EyFuA9nDgULwKk7Ol2lhsvBE5qE= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Esteve Varela Colominas , Hans de Goede , Sasha Levin Subject: [PATCH 5.4 12/23] platform/x86: thinkpad_acpi: Allow the FnLock LED to change state Date: Fri, 9 Apr 2021 11:53:42 +0200 Message-Id: <20210409095303.288476839@linuxfoundation.org> X-Mailer: git-send-email 2.31.1 In-Reply-To: <20210409095302.894568462@linuxfoundation.org> References: <20210409095302.894568462@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org From: Esteve Varela Colominas [ Upstream commit 3d677f12ea3a2097a16ded570623567403dea959 ] On many recent ThinkPad laptops, there's a new LED next to the ESC key, that indicates the FnLock status. When the Fn+ESC combo is pressed, FnLock is toggled, which causes the Media Key functionality to change, making it so that the media keys either perform their media key function, or function as an F-key by default. The Fn key can be used the access the alternate function at any time. With the current linux kernel, the LED doens't change state if you press the Fn+ESC key combo. However, the media key functionality *does* change. This is annoying, since the LED will stay on if it was on during bootup, and it makes it hard to keep track what the current state of the FnLock is. This patch calls an ACPI function, that gets the current media key state, when the Fn+ESC key combo is pressed. Through testing it was discovered that this function causes the LED to update correctly to reflect the current state when this function is called. The relevant ACPI calls are the following: \_SB_.PCI0.LPC0.EC0_.HKEY.GMKS: Get media key state, returns 0x603 if the FnLock mode is enabled, and 0x602 if it's disabled. \_SB_.PCI0.LPC0.EC0_.HKEY.SMKS: Set media key state, sending a 1 will enable FnLock mode, and a 0 will disable it. Relevant discussion: https://bugzilla.kernel.org/show_bug.cgi?id=207841 https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1881015 Signed-off-by: Esteve Varela Colominas Link: https://lore.kernel.org/r/20210315195823.23212-1-esteve.varela@gmail.com Signed-off-by: Hans de Goede Signed-off-by: Sasha Levin --- drivers/platform/x86/thinkpad_acpi.c | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/drivers/platform/x86/thinkpad_acpi.c b/drivers/platform/x86/thinkpad_acpi.c index 8c54d3707fba..e8257de495fd 100644 --- a/drivers/platform/x86/thinkpad_acpi.c +++ b/drivers/platform/x86/thinkpad_acpi.c @@ -4089,13 +4089,19 @@ static bool hotkey_notify_6xxx(const u32 hkey, case TP_HKEY_EV_KEY_NUMLOCK: case TP_HKEY_EV_KEY_FN: - case TP_HKEY_EV_KEY_FN_ESC: /* key press events, we just ignore them as long as the EC * is still reporting them in the normal keyboard stream */ *send_acpi_ev = false; *ignore_acpi_ev = true; return true; + case TP_HKEY_EV_KEY_FN_ESC: + /* Get the media key status to foce the status LED to update */ + acpi_evalf(hkey_handle, NULL, "GMKS", "v"); + *send_acpi_ev = false; + *ignore_acpi_ev = true; + return true; + case TP_HKEY_EV_TABLET_CHANGED: tpacpi_input_send_tabletsw(); hotkey_tablet_mode_notify_change(); From patchwork Fri Apr 9 09:53:43 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Greg KH X-Patchwork-Id: 418162 Delivered-To: patch@linaro.org Received: by 2002:a02:8562:0:0:0:0:0 with SMTP id g89csp1423536jai; Fri, 9 Apr 2021 02:58:49 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwMTin/jjibfufFDRzXIL2ZzV6uf8GMj3g4ELgKku9eiTz78m/5KINdfJU5Ymo2wGbT9iUU X-Received: by 2002:a62:db43:0:b029:244:3c4c:6b90 with SMTP id f64-20020a62db430000b02902443c4c6b90mr7638413pfg.59.1617962329387; Fri, 09 Apr 2021 02:58:49 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1617962329; cv=none; d=google.com; s=arc-20160816; b=GScp610Z9tVJYp9worAzWAGOIE1GYWXCdIcUfuYB+00/fy7B9UAEoMdkzISybscPeO HlkRexmOEJZOH5bK4wOjOHe71QaSNr+JyuGqoI/Iuzny22+K92ERdTLFpgHvwz928GF4 Bn0an1ERtcDt4VqxgF+efep2RevgNzGEedp54ok6ioa7NYcLkoEgR3uH0lj5dEfkY2ua 4sJAbUcZGtGoiDTdrdEcDslPLytKGnPpHHYj+pgZbSOiSrI8C7BftZxsuIMQPvg0CJ6c goJZ2n0/L0OuHi7mt1wZNnenpBYqj2+UiSuB2rTQn5VrnXgH8qlnJ4Jzm0CwwrtKGNWW EnMA== 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=kZQlqv2sD2TielZTlEpO6hhf14yReqq5Lx2RPmks3nk=; b=uyBFmcmBhnyK9ONVdfXi/cJfpGRluk++9ZFui7fnffWF33qSDIDRFyM5SFkYBGTflW aZgSIBRc5g/LSYYIFIk78jwELuXj7d7avRfbS2/ZTGTmCy4ueO9uzxMP6lPLomvF8+fr MGP2Kuw1GZSd12F03P5VbjdMDI3b0TxU/QivnCwiClwNqD+sA0oMQA5Z0JOp5D/GPRk8 3dMpcdzfvyjm1xAVTIfENSZT/lnNy82tDGnkGXDmwHdRKEierEhbb4mdJmmPbb7RsnZ5 MM5pi58FHNKBZJPEUEaLR0Fm9VLGttoiZWl4xACN97lWcKIgGbx9s32JXROMv32+Ompx tB4Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=X4lELQr8; 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 x12si1777130pfn.318.2021.04.09.02.58.49; Fri, 09 Apr 2021 02:58:49 -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=X4lELQr8; 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 S232964AbhDIJ7A (ORCPT + 12 others); Fri, 9 Apr 2021 05:59:00 -0400 Received: from mail.kernel.org ([198.145.29.99]:45290 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233440AbhDIJ6D (ORCPT ); Fri, 9 Apr 2021 05:58:03 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id B330161221; Fri, 9 Apr 2021 09:57:34 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1617962255; bh=6ZGOqPJK9NlLnjRB08jhmZBf6echVbUhN2/g6d51iB4=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=X4lELQr8jArDwR3R8wE/iTExZOZsjRcZGzrQf9Vn+aCNeiydB84GqPERFIQ1Rfe5+ QFl/GDgzlvS3FgBi5lxSL68/5HKUdmuyJ41W/qyK5xYII2J/0Qz/FxuBxxfyYZHBlp PvG50w57OBjzdKd1MBsU+8ZUDXU2jju3+9yWcSTc= 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 5.4 13/23] x86/build: Turn off -fcf-protection for realmode targets Date: Fri, 9 Apr 2021 11:53:43 +0200 Message-Id: <20210409095303.318804236@linuxfoundation.org> X-Mailer: git-send-email 2.31.1 In-Reply-To: <20210409095302.894568462@linuxfoundation.org> References: <20210409095302.894568462@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 8ca3cf7c5ec9..59942e349e5f 100644 --- a/arch/x86/Makefile +++ b/arch/x86/Makefile @@ -34,7 +34,7 @@ M16_CFLAGS := $(call cc-option, -m16, $(CODE16GCC_CFLAGS)) REALMODE_CFLAGS := $(M16_CFLAGS) -g -Os -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:44 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Greg KH X-Patchwork-Id: 418778 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 11AF1C433B4 for ; Fri, 9 Apr 2021 09:58:59 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id B6A8B61209 for ; Fri, 9 Apr 2021 09:58:58 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233651AbhDIJ7B (ORCPT ); Fri, 9 Apr 2021 05:59:01 -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 S233529AbhDIJ6D (ORCPT ); Fri, 9 Apr 2021 05:58:03 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id B6918611C1; Fri, 9 Apr 2021 09:57:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1617962258; bh=bZUR+AGcK3wJczJCdStno/gi7WG9zLTQOK9WOmqVbl8=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=piVS9NSQnKuKoMYqesCRFwL3xwhGQ3A1N+Wux+v0aLBv9z4GOjfLfsANYYzo8Y1nD 9+Yv1btSvWztM2KMsl7yCi0dK3S41HqmG4gGG8tZX+ucn2N4kA5KpctGiyzfSJp8Op weOvdLkues1T4cqPMUnllZSsu5yd+uS0p6cIrbJk= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Christoph Hellwig , Lee Duncan , Martin Wilck , "Martin K. Petersen" , Sasha Levin Subject: [PATCH 5.4 14/23] scsi: target: pscsi: Clean up after failure in pscsi_map_sg() Date: Fri, 9 Apr 2021 11:53:44 +0200 Message-Id: <20210409095303.350012583@linuxfoundation.org> X-Mailer: git-send-email 2.31.1 In-Reply-To: <20210409095302.894568462@linuxfoundation.org> References: <20210409095302.894568462@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org From: Martin Wilck [ Upstream commit 36fa766faa0c822c860e636fe82b1affcd022974 ] If pscsi_map_sg() fails, make sure to drop references to already allocated bios. Link: https://lore.kernel.org/r/20210323212431.15306-2-mwilck@suse.com Reviewed-by: Christoph Hellwig Reviewed-by: Lee Duncan Signed-off-by: Martin Wilck Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin --- drivers/target/target_core_pscsi.c | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/drivers/target/target_core_pscsi.c b/drivers/target/target_core_pscsi.c index c9d92b3e777d..5a047ce77bc0 100644 --- a/drivers/target/target_core_pscsi.c +++ b/drivers/target/target_core_pscsi.c @@ -939,6 +939,14 @@ pscsi_map_sg(struct se_cmd *cmd, struct scatterlist *sgl, u32 sgl_nents, return 0; fail: + if (bio) + bio_put(bio); + while (req->bio) { + bio = req->bio; + req->bio = bio->bi_next; + bio_put(bio); + } + req->biotail = NULL; return TCM_LOGICAL_UNIT_COMMUNICATION_FAILURE; } From patchwork Fri Apr 9 09:53:46 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Greg KH X-Patchwork-Id: 418777 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 C0FF5C43461 for ; Fri, 9 Apr 2021 09:58:59 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 88EA661289 for ; Fri, 9 Apr 2021 09:58:59 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233483AbhDIJ7K (ORCPT ); Fri, 9 Apr 2021 05:59:10 -0400 Received: from mail.kernel.org ([198.145.29.99]:45430 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233678AbhDIJ6G (ORCPT ); Fri, 9 Apr 2021 05:58:06 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id 7D86B6120F; Fri, 9 Apr 2021 09:57:42 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1617962263; bh=zBxvGtJmvHoaAo7R7ymWv4eLPi0x11uTP1qOZ1aLXFw=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=G/GE1EIPyNa1Nj8X2baobjGQtIhWYTjZX0um8TyrOR1kwulq01taxJ0WUb11egSHq BJpbWggAxu4VdwObAxeyg7yfXGFuqUdmZpeIGNq/llDHPVaGpXl2MFMZSfZnX8+d0+ KFyMHhRCynhcapqEN3EIoX4IWxRxsgC6i8dGnIms= 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 5.4 16/23] ia64: fix format strings for err_inject Date: Fri, 9 Apr 2021 11:53:46 +0200 Message-Id: <20210409095303.410914832@linuxfoundation.org> X-Mailer: git-send-email 2.31.1 In-Reply-To: <20210409095302.894568462@linuxfoundation.org> References: <20210409095302.894568462@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 95d44a470a6814207d52dd6312203b0f4ef12710 ] Fix warning with %lx / u64 mismatch: arch/ia64/kernel/err_inject.c: In function 'show_resources': arch/ia64/kernel/err_inject.c:62:22: warning: format '%lx' expects argument of type 'long unsigned int', but argument 3 has type 'u64' {aka 'long long unsigned int'} 62 | return sprintf(buf, "%lx", name[cpu]); \ | ^~~~~~~ Link: https://lkml.kernel.org/r/20210313104312.1548232-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/err_inject.c | 22 +++++++++++----------- 1 file changed, 11 insertions(+), 11 deletions(-) diff --git a/arch/ia64/kernel/err_inject.c b/arch/ia64/kernel/err_inject.c index 8b5b8e6bc9d9..dd5bfed52031 100644 --- a/arch/ia64/kernel/err_inject.c +++ b/arch/ia64/kernel/err_inject.c @@ -59,7 +59,7 @@ show_##name(struct device *dev, struct device_attribute *attr, \ char *buf) \ { \ u32 cpu=dev->id; \ - return sprintf(buf, "%lx\n", name[cpu]); \ + return sprintf(buf, "%llx\n", name[cpu]); \ } #define store(name) \ @@ -86,9 +86,9 @@ store_call_start(struct device *dev, struct device_attribute *attr, #ifdef ERR_INJ_DEBUG printk(KERN_DEBUG "pal_mc_err_inject for cpu%d:\n", cpu); - printk(KERN_DEBUG "err_type_info=%lx,\n", err_type_info[cpu]); - printk(KERN_DEBUG "err_struct_info=%lx,\n", err_struct_info[cpu]); - printk(KERN_DEBUG "err_data_buffer=%lx, %lx, %lx.\n", + printk(KERN_DEBUG "err_type_info=%llx,\n", err_type_info[cpu]); + printk(KERN_DEBUG "err_struct_info=%llx,\n", err_struct_info[cpu]); + printk(KERN_DEBUG "err_data_buffer=%llx, %llx, %llx.\n", err_data_buffer[cpu].data1, err_data_buffer[cpu].data2, err_data_buffer[cpu].data3); @@ -117,8 +117,8 @@ store_call_start(struct device *dev, struct device_attribute *attr, #ifdef ERR_INJ_DEBUG printk(KERN_DEBUG "Returns: status=%d,\n", (int)status[cpu]); - printk(KERN_DEBUG "capabilities=%lx,\n", capabilities[cpu]); - printk(KERN_DEBUG "resources=%lx\n", resources[cpu]); + printk(KERN_DEBUG "capabilities=%llx,\n", capabilities[cpu]); + printk(KERN_DEBUG "resources=%llx\n", resources[cpu]); #endif return size; } @@ -131,7 +131,7 @@ show_virtual_to_phys(struct device *dev, struct device_attribute *attr, char *buf) { unsigned int cpu=dev->id; - return sprintf(buf, "%lx\n", phys_addr[cpu]); + return sprintf(buf, "%llx\n", phys_addr[cpu]); } static ssize_t @@ -145,7 +145,7 @@ store_virtual_to_phys(struct device *dev, struct device_attribute *attr, ret = get_user_pages_fast(virt_addr, 1, FOLL_WRITE, NULL); if (ret<=0) { #ifdef ERR_INJ_DEBUG - printk("Virtual address %lx is not existing.\n",virt_addr); + printk("Virtual address %llx is not existing.\n", virt_addr); #endif return -EINVAL; } @@ -163,7 +163,7 @@ show_err_data_buffer(struct device *dev, { unsigned int cpu=dev->id; - return sprintf(buf, "%lx, %lx, %lx\n", + return sprintf(buf, "%llx, %llx, %llx\n", err_data_buffer[cpu].data1, err_data_buffer[cpu].data2, err_data_buffer[cpu].data3); @@ -178,13 +178,13 @@ store_err_data_buffer(struct device *dev, int ret; #ifdef ERR_INJ_DEBUG - printk("write err_data_buffer=[%lx,%lx,%lx] on cpu%d\n", + printk("write err_data_buffer=[%llx,%llx,%llx] on cpu%d\n", err_data_buffer[cpu].data1, err_data_buffer[cpu].data2, err_data_buffer[cpu].data3, cpu); #endif - ret=sscanf(buf, "%lx, %lx, %lx", + ret = sscanf(buf, "%llx, %llx, %llx", &err_data_buffer[cpu].data1, &err_data_buffer[cpu].data2, &err_data_buffer[cpu].data3); From patchwork Fri Apr 9 09:53:47 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Greg KH X-Patchwork-Id: 418776 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 EDD82C433ED for ; Fri, 9 Apr 2021 09:59:06 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id BC0056120F for ; Fri, 9 Apr 2021 09:59:06 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233583AbhDIJ7R (ORCPT ); Fri, 9 Apr 2021 05:59:17 -0400 Received: from mail.kernel.org ([198.145.29.99]:44698 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233680AbhDIJ6N (ORCPT ); Fri, 9 Apr 2021 05:58:13 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id 2B0D0611EF; Fri, 9 Apr 2021 09:57:44 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1617962265; bh=bMO7+OlXtqhwxjryLT2BUHdvTX1FUX8IwS06ZC+aIag=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=MWnO+hCfvXd2vTh7q/bMBnI9pytyQ4Ss52GWoNfygYMENdlLaRw7t5Rd7jWO0FMqZ TjsqUheQ3bkql+bFYdl4Z23Vn39pL+PyfO4blEFimd+9hVP/aqvfr0j9tBWyHGOK/R Uze3vbJMp5wB8rv0HE4a0SqUU+hrpEO7PLmexJBc= 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 5.4 17/23] cifs: revalidate mapping when we open files for SMB1 POSIX Date: Fri, 9 Apr 2021 11:53:47 +0200 Message-Id: <20210409095303.442894853@linuxfoundation.org> X-Mailer: git-send-email 2.31.1 In-Reply-To: <20210409095302.894568462@linuxfoundation.org> References: <20210409095302.894568462@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 31d578739341..1aac8d38f887 100644 --- a/fs/cifs/file.c +++ b/fs/cifs/file.c @@ -164,6 +164,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:49 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Greg KH X-Patchwork-Id: 418775 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 89970C43460 for ; Fri, 9 Apr 2021 09:59:18 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 435926121D for ; Fri, 9 Apr 2021 09:59:18 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233753AbhDIJ73 (ORCPT ); Fri, 9 Apr 2021 05:59:29 -0400 Received: from mail.kernel.org ([198.145.29.99]:45618 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233609AbhDIJ6R (ORCPT ); Fri, 9 Apr 2021 05:58:17 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id 27149611ED; Fri, 9 Apr 2021 09:57:50 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1617962270; bh=s85p77OcQwPWo1UzKkyxbKC8HoOdSwFTGCwgKYgsNXY=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=oG8hrXBo5QeLkQTNgs+YNQkkaaJsMoHOEKArhQB17WUkTkS2jbrDCej2xG+VveUtt atLAe0Ad1YAR1eX8wXNs3QFpzSCE/QrzJ1yygNRhc0l2uFMaXgfgYHwDnFG+YWoZXn ma+4EuONpi4wU9NLgdCKMLf7WcAQ5Jw03rRvXJw0= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Piotr Krysiuk , Daniel Borkmann Subject: [PATCH 5.4 19/23] bpf, x86: Validate computation of branch displacements for x86-64 Date: Fri, 9 Apr 2021 11:53:49 +0200 Message-Id: <20210409095303.505232339@linuxfoundation.org> X-Mailer: git-send-email 2.31.1 In-Reply-To: <20210409095302.894568462@linuxfoundation.org> References: <20210409095302.894568462@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 @@ -1050,7 +1050,16 @@ emit_jmp: } 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: fatal error\n"); return -EFAULT; } From patchwork Fri Apr 9 09:53:51 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Greg KH X-Patchwork-Id: 418774 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 44CF4C433ED for ; Fri, 9 Apr 2021 09:59:21 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 11B696135B for ; Fri, 9 Apr 2021 09:59:21 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233949AbhDIJ7c (ORCPT ); Fri, 9 Apr 2021 05:59:32 -0400 Received: from mail.kernel.org ([198.145.29.99]:45704 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233456AbhDIJ6T (ORCPT ); Fri, 9 Apr 2021 05:58:19 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id 135606120C; Fri, 9 Apr 2021 09:57:57 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1617962278; bh=XshjBLknayHbHFmkAvURjiRedqLlrTg93sVjlQjzWEw=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=p67aLcZeq7P9MoHtNeKX0VmHLo+h4jUMGk5lHmolvlKDnCdETLu+OXlPTcUU7o30d WxOsexwFTRBSM+JVDoz90IoWQmGb+2rBHYfm/qmrYZfxvy77uzj80T9kpVZH97U4ix X0TVpo952ZqZKpPPBYkfbVo8qaILC/4PmhkbjoSE= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Greg Kroah-Hartman , Sagi Grimberg Subject: [PATCH 5.4 21/23] nvme-mpath: replace direct_make_request with generic_make_request Date: Fri, 9 Apr 2021 11:53:51 +0200 Message-Id: <20210409095303.569029742@linuxfoundation.org> X-Mailer: git-send-email 2.31.1 In-Reply-To: <20210409095302.894568462@linuxfoundation.org> References: <20210409095302.894568462@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org From: Sagi Grimberg The below patches caused a regression in a multipath setup: Fixes: 9f98772ba307 ("nvme-rdma: fix controller reset hang during traffic") Fixes: 2875b0aecabe ("nvme-tcp: fix controller reset hang during traffic") These patches on their own are correct because they fixed a controller reset regression. When we reset/teardown a controller, we must freeze and quiesce the namespaces request queues to make sure that we safely stop inflight I/O submissions. Freeze is mandatory because if our hctx map changed between reconnects, blk_mq_update_nr_hw_queues will immediately attempt to freeze the queue, and if it still has pending submissions (that are still quiesced) it will hang. This is what the above patches fixed. However, by freezing the namespaces request queues, and only unfreezing them when we successfully reconnect, inflight submissions that are running concurrently can now block grabbing the nshead srcu until either we successfully reconnect or ctrl_loss_tmo expired (or the user explicitly disconnected). This caused a deadlock [1] when a different controller (different path on the same subsystem) became live (i.e. optimized/non-optimized). This is because nvme_mpath_set_live needs to synchronize the nshead srcu before requeueing I/O in order to make sure that current_path is visible to future (re)submisions. However the srcu lock is taken by a blocked submission on a frozen request queue, and we have a deadlock. In recent kernels (v5.9+) direct_make_request was replaced by submit_bio_noacct which does not have this issue because it bio_list will be active when nvme-mpath calls submit_bio_noacct on the bottom device (because it was populated when submit_bio was triggered on it. Hence, we need to fix all the kernels that were before submit_bio_noacct was introduced. [1]: Workqueue: nvme-wq nvme_tcp_reconnect_ctrl_work [nvme_tcp] Call Trace: __schedule+0x293/0x730 schedule+0x33/0xa0 schedule_timeout+0x1d3/0x2f0 wait_for_completion+0xba/0x140 __synchronize_srcu.part.21+0x91/0xc0 synchronize_srcu_expedited+0x27/0x30 synchronize_srcu+0xce/0xe0 nvme_mpath_set_live+0x64/0x130 [nvme_core] nvme_update_ns_ana_state+0x2c/0x30 [nvme_core] nvme_update_ana_state+0xcd/0xe0 [nvme_core] nvme_parse_ana_log+0xa1/0x180 [nvme_core] nvme_read_ana_log+0x76/0x100 [nvme_core] nvme_mpath_init+0x122/0x180 [nvme_core] nvme_init_identify+0x80e/0xe20 [nvme_core] nvme_tcp_setup_ctrl+0x359/0x660 [nvme_tcp] nvme_tcp_reconnect_ctrl_work+0x24/0x70 [nvme_tcp] Signed-off-by: Sagi Grimberg Signed-off-by: Greg Kroah-Hartman --- drivers/nvme/host/multipath.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/nvme/host/multipath.c +++ b/drivers/nvme/host/multipath.c @@ -330,7 +330,7 @@ static blk_qc_t nvme_ns_head_make_reques trace_block_bio_remap(bio->bi_disk->queue, bio, disk_devt(ns->head->disk), bio->bi_iter.bi_sector); - ret = direct_make_request(bio); + ret = generic_make_request(bio); } else if (nvme_available_path(head)) { dev_warn_ratelimited(dev, "no usable path - requeuing I/O\n");