From patchwork Tue Apr 7 10:21:33 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "gregkh@linuxfoundation.org" X-Patchwork-Id: 228145 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=-6.9 required=3.0 tests=DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI, SIGNED_OFF_BY, SPF_HELO_NONE, SPF_PASS, URIBL_BLOCKED, 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 2FCFDC2BB55 for ; Tue, 7 Apr 2020 10:28:57 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id F24CA20644 for ; Tue, 7 Apr 2020 10:28:56 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1586255337; bh=4nPDAK8FhaKO//oce9RzisZ2p1XmrMAHJp8g7CR2YFg=; h=From:To:Cc:Subject:Date:In-Reply-To:References:List-ID:From; b=RJQszWCcsovYvfyirG7Lt+4o448M83X+fx+8Cgnap8E4bZE5zdW+3e05N4K4spCvx ZGaIA/OU7B+GHosZ8vqp09QG0dQtSZsf7co5eVY85+gTugpkZ/7tp3KOEolDHPu6XN 5RdAhhS11tRjOPIVTRG2AZOtPP0awxL4EGte+tP4= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726725AbgDGKYh (ORCPT ); Tue, 7 Apr 2020 06:24:37 -0400 Received: from mail.kernel.org ([198.145.29.99]:34902 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728747AbgDGKYf (ORCPT ); Tue, 7 Apr 2020 06:24:35 -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 BBFC92082F; Tue, 7 Apr 2020 10:24:34 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1586255075; bh=4nPDAK8FhaKO//oce9RzisZ2p1XmrMAHJp8g7CR2YFg=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=Tmgn4Ja4jt7JbcJfJ5vIvSfQ4e/muFiJA42Pn3k39cLqScqMVzPBSWI3pyenYW3Fw XS4gdqzLKcCUqsKCbCmrl4QngF47SOOktCIUrsNSvqa02Jm+8TvvkCcyZB7eCAcjce lFpSQimGU0XDzrFifsrqpnE8W1I5c0X6tG36RiqE= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Cristian Birsan , Codrin Ciubotariu , Andrew Lunn , Florian Fainelli , "David S. Miller" Subject: [PATCH 5.5 02/46] net: dsa: ksz: Select KSZ protocol tag Date: Tue, 7 Apr 2020 12:21:33 +0200 Message-Id: <20200407101459.777473459@linuxfoundation.org> X-Mailer: git-send-email 2.26.0 In-Reply-To: <20200407101459.502593074@linuxfoundation.org> References: <20200407101459.502593074@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: Codrin Ciubotariu [ Upstream commit f772148eb757b0823fbfdc2fe592d5e06c7f19b0 ] KSZ protocol tag is needed by the KSZ DSA drivers. Fixes: 0b9f9dfbfab4 ("dsa: Allow tag drivers to be built as modules") Tested-by: Cristian Birsan Signed-off-by: Codrin Ciubotariu Reviewed-by: Andrew Lunn Reviewed-by: Florian Fainelli Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman --- drivers/net/dsa/microchip/Kconfig | 1 + 1 file changed, 1 insertion(+) --- a/drivers/net/dsa/microchip/Kconfig +++ b/drivers/net/dsa/microchip/Kconfig @@ -1,5 +1,6 @@ # SPDX-License-Identifier: GPL-2.0-only config NET_DSA_MICROCHIP_KSZ_COMMON + select NET_DSA_TAG_KSZ tristate menuconfig NET_DSA_MICROCHIP_KSZ9477 From patchwork Tue Apr 7 10:21:34 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "gregkh@linuxfoundation.org" X-Patchwork-Id: 228147 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=-6.9 required=3.0 tests=DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI, SIGNED_OFF_BY, SPF_HELO_NONE, SPF_PASS, URIBL_BLOCKED, 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 9EC78C2BB1D for ; Tue, 7 Apr 2020 10:28:46 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 6B1D02078A for ; Tue, 7 Apr 2020 10:28:46 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1586255326; bh=+9/waoq6urivDfNZvIaeIMosuJ6pHCmjRRVUUlB8Uig=; h=From:To:Cc:Subject:Date:In-Reply-To:References:List-ID:From; b=lNnDvK5OeN/I4cSgWIkQp+6LDBfcSDnHN5+/wQExD9H2a3iA3MM2O6A1SKa/pKlPw P8imCyujjK42X5nI+5sWCTR1OW6HzCErDBDayPdqt8Ipqb3QVDmo63OncH8tgHzCWe RiYVnk0IEZ7dp45kd4TvvE2iWyhw14rzmAW1nZgg= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728460AbgDGKY4 (ORCPT ); Tue, 7 Apr 2020 06:24:56 -0400 Received: from mail.kernel.org ([198.145.29.99]:35316 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728829AbgDGKY4 (ORCPT ); Tue, 7 Apr 2020 06:24: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 8BA4220644; Tue, 7 Apr 2020 10:24:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1586255095; bh=+9/waoq6urivDfNZvIaeIMosuJ6pHCmjRRVUUlB8Uig=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=uMG3VH7ScGv6b/gxvFtk1sCnJhMJ2BD+vZKMQmi0YuMCQhbVZgiio42W3oEeWNGhP yRg8lnVLycIxMODYDvub/c8+Z0BJBUZsLTx252fe/gLfpjjGh0holGH6xfrveKtbaR HXF9DIe5GC7Ta3Ro7tvBFNRfFT2Vn2a6Hq2LEsoU= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, William Dauchy , Nicolas Dichtel , "David S. Miller" Subject: [PATCH 5.5 03/46] net, ip_tunnel: fix interface lookup with no key Date: Tue, 7 Apr 2020 12:21:34 +0200 Message-Id: <20200407101459.875071972@linuxfoundation.org> X-Mailer: git-send-email 2.26.0 In-Reply-To: <20200407101459.502593074@linuxfoundation.org> References: <20200407101459.502593074@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: William Dauchy [ Upstream commit 25629fdaff2ff509dd0b3f5ff93d70a75e79e0a1 ] when creating a new ipip interface with no local/remote configuration, the lookup is done with TUNNEL_NO_KEY flag, making it impossible to match the new interface (only possible match being fallback or metada case interface); e.g: `ip link add tunl1 type ipip dev eth0` To fix this case, adding a flag check before the key comparison so we permit to match an interface with no local/remote config; it also avoids breaking possible userland tools relying on TUNNEL_NO_KEY flag and uninitialised key. context being on my side, I'm creating an extra ipip interface attached to the physical one, and moving it to a dedicated namespace. Fixes: c54419321455 ("GRE: Refactor GRE tunneling code.") Signed-off-by: William Dauchy Signed-off-by: Nicolas Dichtel Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman --- net/ipv4/ip_tunnel.c | 6 +----- 1 file changed, 1 insertion(+), 5 deletions(-) --- a/net/ipv4/ip_tunnel.c +++ b/net/ipv4/ip_tunnel.c @@ -142,11 +142,8 @@ struct ip_tunnel *ip_tunnel_lookup(struc cand = t; } - if (flags & TUNNEL_NO_KEY) - goto skip_key_lookup; - hlist_for_each_entry_rcu(t, head, hash_node) { - if (t->parms.i_key != key || + if ((!(flags & TUNNEL_NO_KEY) && t->parms.i_key != key) || t->parms.iph.saddr != 0 || t->parms.iph.daddr != 0 || !(t->dev->flags & IFF_UP)) @@ -158,7 +155,6 @@ struct ip_tunnel *ip_tunnel_lookup(struc cand = t; } -skip_key_lookup: if (cand) return cand; From patchwork Tue Apr 7 10:21:36 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "gregkh@linuxfoundation.org" X-Patchwork-Id: 228148 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=-6.9 required=3.0 tests=DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI, SIGNED_OFF_BY, SPF_HELO_NONE, SPF_PASS, URIBL_BLOCKED, 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 BC2A7C2BB86 for ; Tue, 7 Apr 2020 10:28:44 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 9306A2074B for ; Tue, 7 Apr 2020 10:28:44 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1586255324; bh=qBRidKn+v/vs6r8HKnC3Y+FH+rNp4St2BFykGlKnhaM=; h=From:To:Cc:Subject:Date:In-Reply-To:References:List-ID:From; b=S1tTmPhEjo32TFLkJkeU3YE/VVHwSy6nFAnOfdIUUja0Wv7ea10H8zBjjLPFMpeVw gpPztAJtl5PS3E0fqgSfbUiaCwGo4TwXq21KAS3uAKQStYtFTnpbhzkerQ5HmDbagn NqVt5CtZTvSHez4YELeN2hjiyLuuGB9KnHL57rCM= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728848AbgDGKZB (ORCPT ); Tue, 7 Apr 2020 06:25:01 -0400 Received: from mail.kernel.org ([198.145.29.99]:35442 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728843AbgDGKZB (ORCPT ); Tue, 7 Apr 2020 06:25:01 -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 86FB72078C; Tue, 7 Apr 2020 10:24:59 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1586255100; bh=qBRidKn+v/vs6r8HKnC3Y+FH+rNp4St2BFykGlKnhaM=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=zUAXwQlYiC4hoSKiqRat89xGGu/oQaxUoOTT6vHj7ooDlc8iipevmW+lG3vvB+u7I IF5pv/uCdTCxJA0ES7jPzPTq9m2NAFuQAbOGjcW/SEm0NtbVmQ+KVg1HPt4Lc5oahl tDgsZDw9yErr+7WKXw0lgPlF46J3gtJG+69RtpLI= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Qiujun Huang , Marcelo Ricardo Leitner , "David S. Miller" , syzbot+cea71eec5d6de256d54d@syzkaller.appspotmail.com Subject: [PATCH 5.5 05/46] sctp: fix refcount bug in sctp_wfree Date: Tue, 7 Apr 2020 12:21:36 +0200 Message-Id: <20200407101500.086085972@linuxfoundation.org> X-Mailer: git-send-email 2.26.0 In-Reply-To: <20200407101459.502593074@linuxfoundation.org> References: <20200407101459.502593074@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: Qiujun Huang [ Upstream commit 5c3e82fe159622e46e91458c1a6509c321a62820 ] We should iterate over the datamsgs to move all chunks(skbs) to newsk. The following case cause the bug: for the trouble SKB, it was in outq->transmitted list sctp_outq_sack sctp_check_transmitted SKB was moved to outq->sacked list then throw away the sack queue SKB was deleted from outq->sacked (but it was held by datamsg at sctp_datamsg_to_asoc So, sctp_wfree was not called here) then migrate happened sctp_for_each_tx_datachunk( sctp_clear_owner_w); sctp_assoc_migrate(); sctp_for_each_tx_datachunk( sctp_set_owner_w); SKB was not in the outq, and was not changed to newsk finally __sctp_outq_teardown sctp_chunk_put (for another skb) sctp_datamsg_put __kfree_skb(msg->frag_list) sctp_wfree (for SKB) SKB->sk was still oldsk (skb->sk != asoc->base.sk). Reported-and-tested-by: syzbot+cea71eec5d6de256d54d@syzkaller.appspotmail.com Signed-off-by: Qiujun Huang Acked-by: Marcelo Ricardo Leitner Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman --- net/sctp/socket.c | 31 +++++++++++++++++++++++-------- 1 file changed, 23 insertions(+), 8 deletions(-) --- a/net/sctp/socket.c +++ b/net/sctp/socket.c @@ -147,29 +147,44 @@ static void sctp_clear_owner_w(struct sc skb_orphan(chunk->skb); } +#define traverse_and_process() \ +do { \ + msg = chunk->msg; \ + if (msg == prev_msg) \ + continue; \ + list_for_each_entry(c, &msg->chunks, frag_list) { \ + if ((clear && asoc->base.sk == c->skb->sk) || \ + (!clear && asoc->base.sk != c->skb->sk)) \ + cb(c); \ + } \ + prev_msg = msg; \ +} while (0) + static void sctp_for_each_tx_datachunk(struct sctp_association *asoc, + bool clear, void (*cb)(struct sctp_chunk *)) { + struct sctp_datamsg *msg, *prev_msg = NULL; struct sctp_outq *q = &asoc->outqueue; + struct sctp_chunk *chunk, *c; struct sctp_transport *t; - struct sctp_chunk *chunk; list_for_each_entry(t, &asoc->peer.transport_addr_list, transports) list_for_each_entry(chunk, &t->transmitted, transmitted_list) - cb(chunk); + traverse_and_process(); list_for_each_entry(chunk, &q->retransmit, transmitted_list) - cb(chunk); + traverse_and_process(); list_for_each_entry(chunk, &q->sacked, transmitted_list) - cb(chunk); + traverse_and_process(); list_for_each_entry(chunk, &q->abandoned, transmitted_list) - cb(chunk); + traverse_and_process(); list_for_each_entry(chunk, &q->out_chunk_list, list) - cb(chunk); + traverse_and_process(); } static void sctp_for_each_rx_skb(struct sctp_association *asoc, struct sock *sk, @@ -9576,9 +9591,9 @@ static int sctp_sock_migrate(struct sock * paths won't try to lock it and then oldsk. */ lock_sock_nested(newsk, SINGLE_DEPTH_NESTING); - sctp_for_each_tx_datachunk(assoc, sctp_clear_owner_w); + sctp_for_each_tx_datachunk(assoc, true, sctp_clear_owner_w); sctp_assoc_migrate(assoc, newsk); - sctp_for_each_tx_datachunk(assoc, sctp_set_owner_w); + sctp_for_each_tx_datachunk(assoc, false, sctp_set_owner_w); /* If the association on the newsk is already closed before accept() * is called, set RCV_SHUTDOWN flag. From patchwork Tue Apr 7 10:21:38 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "gregkh@linuxfoundation.org" X-Patchwork-Id: 228149 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=-9.9 required=3.0 tests=DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_PATCH, MAILING_LIST_MULTI, SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,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 84BFEC2BB54 for ; Tue, 7 Apr 2020 10:28:43 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 533AA2078A for ; Tue, 7 Apr 2020 10:28:43 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1586255323; bh=Fs02QOeqFeunLDhAhOWC8FGhC42gEBQwFYKZQ5UAcC8=; h=From:To:Cc:Subject:Date:In-Reply-To:References:List-ID:From; b=IR50d/edSZYvCUn4zj99yb33SCO3CLWdHQZM0rjm7s7G//SFuOcEPXLL3KSNNiKA/ BD2YCZCq20GU5ZgvgN5/O4yH5h1N2qey/t3kCjVMZKKLz1yCz3iFwj0MAed7pnQmM0 UULjh9nvf/5UYW6QCtFMSB3Q9C66FUIZXhOk2vjA= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728866AbgDGKZG (ORCPT ); Tue, 7 Apr 2020 06:25:06 -0400 Received: from mail.kernel.org ([198.145.29.99]:35528 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728843AbgDGKZF (ORCPT ); Tue, 7 Apr 2020 06:25:05 -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 85C4820644; Tue, 7 Apr 2020 10:25:04 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1586255105; bh=Fs02QOeqFeunLDhAhOWC8FGhC42gEBQwFYKZQ5UAcC8=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=Ah5OOGzKCvaOOTCZmFdvapXOu8pnIaRaSR2cv8yPfuvLJETfcFMfJZkO2Z7wHYxQD aG+PieNbP+bPwszG3AXemGhIy7GTpWnFp6CwvtFVCbIjF9wVf3qZKjAE+PhMVv3O+x 5lrbyNL9AHjsMiIIkgHinzCDg8vQb7TDuumH03rc= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Roland Dreier , Max Gurtovoy , Christoph Hellwig , Prabhath Sajeepa , Keith Busch , Sasha Levin Subject: [PATCH 5.5 07/46] nvme-rdma: Avoid double freeing of async event data Date: Tue, 7 Apr 2020 12:21:38 +0200 Message-Id: <20200407101500.273308750@linuxfoundation.org> X-Mailer: git-send-email 2.26.0 In-Reply-To: <20200407101459.502593074@linuxfoundation.org> References: <20200407101459.502593074@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: Prabhath Sajeepa [ Upstream commit 9134ae2a2546cb96abddcd4469a79c77ee3a4480 ] The timeout of identify cmd, which is invoked as part of admin queue creation, can result in freeing of async event data both in nvme_rdma_timeout handler and error handling path of nvme_rdma_configure_admin queue thus causing NULL pointer reference. Call Trace: ? nvme_rdma_setup_ctrl+0x223/0x800 [nvme_rdma] nvme_rdma_create_ctrl+0x2ba/0x3f7 [nvme_rdma] nvmf_dev_write+0xa54/0xcc6 [nvme_fabrics] __vfs_write+0x1b/0x40 vfs_write+0xb2/0x1b0 ksys_write+0x61/0xd0 __x64_sys_write+0x1a/0x20 do_syscall_64+0x60/0x1e0 entry_SYSCALL_64_after_hwframe+0x44/0xa9 Reviewed-by: Roland Dreier Reviewed-by: Max Gurtovoy Reviewed-by: Christoph Hellwig Signed-off-by: Prabhath Sajeepa Signed-off-by: Keith Busch Signed-off-by: Sasha Levin --- drivers/nvme/host/rdma.c | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/drivers/nvme/host/rdma.c b/drivers/nvme/host/rdma.c index 3e85c5cacefd2..0fe08c4dfd2f1 100644 --- a/drivers/nvme/host/rdma.c +++ b/drivers/nvme/host/rdma.c @@ -850,9 +850,11 @@ out_free_tagset: if (new) blk_mq_free_tag_set(ctrl->ctrl.admin_tagset); out_free_async_qe: - nvme_rdma_free_qe(ctrl->device->dev, &ctrl->async_event_sqe, - sizeof(struct nvme_command), DMA_TO_DEVICE); - ctrl->async_event_sqe.data = NULL; + if (ctrl->async_event_sqe.data) { + nvme_rdma_free_qe(ctrl->device->dev, &ctrl->async_event_sqe, + sizeof(struct nvme_command), DMA_TO_DEVICE); + ctrl->async_event_sqe.data = NULL; + } out_free_queue: nvme_rdma_free_queue(&ctrl->queues[0]); return error; From patchwork Tue Apr 7 10:21:39 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: "gregkh@linuxfoundation.org" X-Patchwork-Id: 228173 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=-9.9 required=3.0 tests=DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_PATCH, MAILING_LIST_MULTI, SIGNED_OFF_BY,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 038A7C2BB1D for ; Tue, 7 Apr 2020 10:25:10 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id CA3792074B for ; Tue, 7 Apr 2020 10:25:09 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1586255109; bh=sKbjwMLJiBOphC69hyUcwuxnGfiE7NbpZaWocYhiKBI=; h=From:To:Cc:Subject:Date:In-Reply-To:References:List-ID:From; b=Reb04TVphrvSs4Y5CVASM1MDN/UB5XwTqiGZ6Cw1cwm/PnUvoo3ChLwB+T0iC6kin +suhGk++mz+Z1IcDf74EHbuDBem6cQuAyrGd9XwnrJIf83tsp5FogHc0ctfBVIOPUF 54I02XaQHlfw94rjeAc59d5oCqgP/HmkBtnWednw= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728882AbgDGKZI (ORCPT ); Tue, 7 Apr 2020 06:25:08 -0400 Received: from mail.kernel.org ([198.145.29.99]:35592 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728880AbgDGKZI (ORCPT ); Tue, 7 Apr 2020 06:25:08 -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 010182074B; Tue, 7 Apr 2020 10:25:06 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1586255107; bh=sKbjwMLJiBOphC69hyUcwuxnGfiE7NbpZaWocYhiKBI=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=IVdc99VgMFf76EWBozzgWB856yo84dwI3/Nf9OLFVAOaj9uXZeF3bxu5YViMECGD+ 7/m2oY+W+EXrpmhjBWszAbw85PpZ0PNN+SXd0RXVIsGrGmEHRCSuBjLR5IGRWmzrPa GffIvQeXbmdfl7jvQZOGu/PhKY+IZVp2ZPwnfCrs= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, =?utf-8?b?SsOpcsO0bWUgUG91aWxsZXI=?= , Sasha Levin Subject: [PATCH 5.5 08/46] staging: wfx: fix warning about freeing in-use mutex during device unregister Date: Tue, 7 Apr 2020 12:21:39 +0200 Message-Id: <20200407101500.370794039@linuxfoundation.org> X-Mailer: git-send-email 2.26.0 In-Reply-To: <20200407101459.502593074@linuxfoundation.org> References: <20200407101459.502593074@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: Jérôme Pouiller [ Upstream commit bab0a0b03442a62fe3abefcb2169e0b9ff95990c ] After hif_shutdown(), communication with the chip is no more possible. It the only request that never reply. Therefore, hif_cmd.lock is never unlocked. hif_shutdown() unlock itself hif_cmd.lock to avoid a potential warning during disposal of device. hif_cmd.key_renew_lock should also been unlocked for the same reason. Signed-off-by: Jérôme Pouiller Link: https://lore.kernel.org/r/20200310101356.182818-2-Jerome.Pouiller@silabs.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin --- drivers/staging/wfx/hif_tx.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/staging/wfx/hif_tx.c b/drivers/staging/wfx/hif_tx.c index cb7cddcb98159..16e7d190430f3 100644 --- a/drivers/staging/wfx/hif_tx.c +++ b/drivers/staging/wfx/hif_tx.c @@ -141,6 +141,7 @@ int hif_shutdown(struct wfx_dev *wdev) else control_reg_write(wdev, 0); mutex_unlock(&wdev->hif_cmd.lock); + mutex_unlock(&wdev->hif_cmd.key_renew_lock); kfree(hif); return ret; } From patchwork Tue Apr 7 10:21:41 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "gregkh@linuxfoundation.org" X-Patchwork-Id: 228178 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=-9.9 required=3.0 tests=DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_PATCH, MAILING_LIST_MULTI, SIGNED_OFF_BY,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 69DAAC2BB55 for ; Tue, 7 Apr 2020 10:24:14 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 4190A2078A for ; Tue, 7 Apr 2020 10:24:14 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1586255054; bh=mydvpf9JQotGF33zrvwujih4d2LyJw0bPk+qpk20hdk=; h=From:To:Cc:Subject:Date:In-Reply-To:References:List-ID:From; b=oIKcXTYhbLs6QWQkM0riZQxnNniFJW60TWh31tAs/WSoJcGfZrWi3xrKHt2MbzqiA 2TznrlOjqQz4UH9wHnHXWX1nqcEJfaTer7KEa5Wm0DKsKi31ypi3TmkViQdBfo3qVL DjTRd4xBr1YMEPvsMu4N6lqkRsmaTKYUq/FfWQkY= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728662AbgDGKYN (ORCPT ); Tue, 7 Apr 2020 06:24:13 -0400 Received: from mail.kernel.org ([198.145.29.99]:34286 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728304AbgDGKYL (ORCPT ); Tue, 7 Apr 2020 06:24:11 -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 334EC2078A; Tue, 7 Apr 2020 10:24:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1586255050; bh=mydvpf9JQotGF33zrvwujih4d2LyJw0bPk+qpk20hdk=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=sZmTAfeT9hWp0dfOHp3h9U4lRbv7e66rCDqjp67S70yDtoooWdrK7Cmr4Rb2Ww3q6 XQ8T3qeQhTRGVrFnFxEdsnY1B6Z8Y/BfHrirC4coHrzxAUIEVh4+TXXa5hMe+HRQfc MlsTqgMA2UdQobRRphyrurRNzUS/PtNnVrmApGmg= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Mario Kleiner , Alex Deucher , Sasha Levin Subject: [PATCH 5.5 10/46] drm/amd/display: Add link_rate quirk for Apple 15" MBP 2017 Date: Tue, 7 Apr 2020 12:21:41 +0200 Message-Id: <20200407101500.616555233@linuxfoundation.org> X-Mailer: git-send-email 2.26.0 In-Reply-To: <20200407101459.502593074@linuxfoundation.org> References: <20200407101459.502593074@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: Mario Kleiner [ Upstream commit dec9de2ada523b344eb2428abfedf9d6cd0a0029 ] This fixes a problem found on the MacBookPro 2017 Retina panel: The panel reports 10 bpc color depth in its EDID, and the firmware chooses link settings at boot which support enough bandwidth for 10 bpc (324000 kbit/sec aka LINK_RATE_RBR2 aka 0xc), but the DP_MAX_LINK_RATE dpcd register only reports 2.7 Gbps (multiplier value 0xa) as possible, in direct contradiction of what the firmware successfully set up. This restricts the panel to 8 bpc, not providing the full color depth of the panel on Linux <= 5.5. Additionally, commit '4a8ca46bae8a ("drm/amd/display: Default max bpc to 16 for eDP")' introduced into Linux 5.6-rc1 will unclamp panel depth to its full 10 bpc, thereby requiring a eDP bandwidth for all modes that exceeds the bandwidth available and causes all modes to fail validation -> No modes for the laptop panel -> failure to set any mode -> Panel goes dark. This patch adds a quirk specific to the MBP 2017 15" Retina panel to override reported max link rate to the correct maximum of 0xc = LINK_RATE_RBR2 to fix the darkness and reduced display precision. Please apply for Linux 5.6+ to avoid regressing Apple MBP panel support. Signed-off-by: Mario Kleiner Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin --- drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c | 11 +++++++++++ 1 file changed, 11 insertions(+) diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c b/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c index 504055fc70e89..6f2b3ec17e7f0 100644 --- a/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c +++ b/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c @@ -2909,6 +2909,17 @@ static bool retrieve_link_cap(struct dc_link *link) sink_id.ieee_device_id, sizeof(sink_id.ieee_device_id)); + /* Quirk Apple MBP 2017 15" Retina panel: Wrong DP_MAX_LINK_RATE */ + { + uint8_t str_mbp_2017[] = { 101, 68, 21, 101, 98, 97 }; + + if ((link->dpcd_caps.sink_dev_id == 0x0010fa) && + !memcmp(link->dpcd_caps.sink_dev_id_str, str_mbp_2017, + sizeof(str_mbp_2017))) { + link->reported_link_cap.link_rate = 0x0c; + } + } + core_link_read_dpcd( link, DP_SINK_HW_REVISION_START, From patchwork Tue Apr 7 10:21:42 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: "gregkh@linuxfoundation.org" X-Patchwork-Id: 228143 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=-9.9 required=3.0 tests=DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_PATCH, MAILING_LIST_MULTI, SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,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 63268C2BB85 for ; Tue, 7 Apr 2020 10:29:09 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 329BC20644 for ; Tue, 7 Apr 2020 10:29:09 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1586255349; bh=JZKbPbuU2UHbrb6VuFFKYu3d0IBGpuh9U6WpdN5Q95o=; h=From:To:Cc:Subject:Date:In-Reply-To:References:List-ID:From; b=DAscTS0yM72YNkl4aScUhNNVOB9X3nH7Vj5aD++tCS80Hp/SSPQ67/bnsPTXzfkUR DcbRXCqWE+T2r1KHG2B2mFfOk1F+K24BMFgYSK+9zpiJ3rrJcjBD2At8eLGUhbDS1x T1toovCvazcrwtn/k6ULn65jBWFpdq7ApHDA9qBE= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728671AbgDGKYO (ORCPT ); Tue, 7 Apr 2020 06:24:14 -0400 Received: from mail.kernel.org ([198.145.29.99]:34350 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728074AbgDGKYN (ORCPT ); Tue, 7 Apr 2020 06:24:13 -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 76E4220771; Tue, 7 Apr 2020 10:24:12 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1586255052; bh=JZKbPbuU2UHbrb6VuFFKYu3d0IBGpuh9U6WpdN5Q95o=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=TvOlca1HsKd4xEw5gsYlu9M+xYHtcKcwKN3i0rPV9UaInBJPSuQtFJMsrWbVMqTO2 qkpqw3v/SVmprwole43LJmBPyeZ9hVZ2C2jZcifh75oo9v6xYps0r/tHiAGJCG5HHD UVDqG4h/slKbxYwI/moF3TGYPSL2z/6kd6X2DSWo= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, =?utf-8?q?Marek_Marczykowski-G=C3=B3recki?= , Gerd Hoffmann , Sam Ravnborg , Sasha Levin Subject: [PATCH 5.5 11/46] drm/bochs: downgrade pci_request_region failure from error to warning Date: Tue, 7 Apr 2020 12:21:42 +0200 Message-Id: <20200407101500.722158177@linuxfoundation.org> X-Mailer: git-send-email 2.26.0 In-Reply-To: <20200407101459.502593074@linuxfoundation.org> References: <20200407101459.502593074@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: Gerd Hoffmann [ Upstream commit 8c34cd1a7f089dc03933289c5d4a4d1489549828 ] Shutdown of firmware framebuffer has a bunch of problems. Because of this the framebuffer region might still be reserved even after drm_fb_helper_remove_conflicting_pci_framebuffers() returned. Don't consider pci_request_region() failure for the framebuffer region as fatal error to workaround this issue. Reported-by: Marek Marczykowski-Górecki Signed-off-by: Gerd Hoffmann Acked-by: Sam Ravnborg Link: http://patchwork.freedesktop.org/patch/msgid/20200313084152.2734-1-kraxel@redhat.com Signed-off-by: Sasha Levin --- drivers/gpu/drm/bochs/bochs_hw.c | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/bochs/bochs_hw.c b/drivers/gpu/drm/bochs/bochs_hw.c index e567bdfa2ab8e..bb1391784caf0 100644 --- a/drivers/gpu/drm/bochs/bochs_hw.c +++ b/drivers/gpu/drm/bochs/bochs_hw.c @@ -156,10 +156,8 @@ int bochs_hw_init(struct drm_device *dev) size = min(size, mem); } - if (pci_request_region(pdev, 0, "bochs-drm") != 0) { - DRM_ERROR("Cannot request framebuffer\n"); - return -EBUSY; - } + if (pci_request_region(pdev, 0, "bochs-drm") != 0) + DRM_WARN("Cannot request framebuffer, boot fb still active?\n"); bochs->fb_map = ioremap(addr, size); if (bochs->fb_map == NULL) { From patchwork Tue Apr 7 10:21:45 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: "gregkh@linuxfoundation.org" X-Patchwork-Id: 228144 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=-9.9 required=3.0 tests=DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_PATCH, MAILING_LIST_MULTI, SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,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 04B1CC2BB1D for ; Tue, 7 Apr 2020 10:29:06 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id BFDBD20644 for ; Tue, 7 Apr 2020 10:29:05 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1586255345; bh=HDOf5iL2WzIZq9OFWuzWL8Xs5UhCelii0BSjOQdYEbQ=; h=From:To:Cc:Subject:Date:In-Reply-To:References:List-ID:From; b=nQWidHHH7c8ZIDqg16RJUAU7PRR+ALvx4cc0FFo8loO3xbaJv6RLt3qPmc3ZV1QcN A9l/gMSpX+4sQkBAO81SVs4cV7iVcIl+OgxxrbXx1B8d3BvQSXVVWiGLw3wAMO9lWI zwieBDbIfQsEtAUx5em5DyY+KbqUiN4SnH1+RFkQ= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728696AbgDGKYV (ORCPT ); Tue, 7 Apr 2020 06:24:21 -0400 Received: from mail.kernel.org ([198.145.29.99]:34562 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728074AbgDGKYU (ORCPT ); Tue, 7 Apr 2020 06:24:20 -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 CBB7D20692; Tue, 7 Apr 2020 10:24:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1586255060; bh=HDOf5iL2WzIZq9OFWuzWL8Xs5UhCelii0BSjOQdYEbQ=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=yyDX3YuJc85Y2izEL/ocJ9fXKHeyOitKkK4BJxflGWNk7v6v1wjzA+rJqw/tEhEiS EGUywrOwe4qDcBe2IKN8dIl31E98X0rduZC9lgeV7EievEda5+WRfVSek1hqWxGRXp 79XtikM4vxSF1RX0ECogDvAjvWJJW47l0vm3+VPU= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Len Brown , Sasha Levin Subject: [PATCH 5.5 14/46] tools/power turbostat: Fix gcc build warnings Date: Tue, 7 Apr 2020 12:21:45 +0200 Message-Id: <20200407101501.021916292@linuxfoundation.org> X-Mailer: git-send-email 2.26.0 In-Reply-To: <20200407101459.502593074@linuxfoundation.org> References: <20200407101459.502593074@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: Len Brown [ Upstream commit d8d005ba6afa502ca37ced5782f672c4d2fc1515 ] Warning: ‘__builtin_strncpy’ specified bound 20 equals destination size [-Wstringop-truncation] reduce param to strncpy, to guarantee that a null byte is always copied into destination buffer. Signed-off-by: Len Brown Signed-off-by: Sasha Levin --- tools/power/x86/turbostat/turbostat.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/tools/power/x86/turbostat/turbostat.c b/tools/power/x86/turbostat/turbostat.c index 5d0fddda842c4..78507cd479bb4 100644 --- a/tools/power/x86/turbostat/turbostat.c +++ b/tools/power/x86/turbostat/turbostat.c @@ -5323,9 +5323,9 @@ int add_counter(unsigned int msr_num, char *path, char *name, } msrp->msr_num = msr_num; - strncpy(msrp->name, name, NAME_BYTES); + strncpy(msrp->name, name, NAME_BYTES - 1); if (path) - strncpy(msrp->path, path, PATH_BYTES); + strncpy(msrp->path, path, PATH_BYTES - 1); msrp->width = width; msrp->type = type; msrp->format = format; From patchwork Tue Apr 7 10:21:46 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "gregkh@linuxfoundation.org" X-Patchwork-Id: 228177 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=-9.9 required=3.0 tests=DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_PATCH, MAILING_LIST_MULTI, SIGNED_OFF_BY,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 4C6BFC2BB54 for ; Tue, 7 Apr 2020 10:24:26 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 23CAD20857 for ; Tue, 7 Apr 2020 10:24:26 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1586255066; bh=WWPBWH6R7vqAyfkKB/N+fKzsFhjvBeypNxeA9gpyPj0=; h=From:To:Cc:Subject:Date:In-Reply-To:References:List-ID:From; b=myMR6NnpoVusuFbcrH/r4Js6zi8lWzxraKyI76TYfSvEcOIOCIzeqE1DEvCF9gWOV uI1z8PLqaYJUoukfi2r+3T2O/h8rDBHEQeOK1FdZdJz48Qp0RKZ0XMCWn+5SHXNt/2 vOMj1KwsMLSOXdBR40qoLQ+yIn8CceWzqP1hajtM= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728074AbgDGKYY (ORCPT ); Tue, 7 Apr 2020 06:24:24 -0400 Received: from mail.kernel.org ([198.145.29.99]:34612 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728709AbgDGKYX (ORCPT ); Tue, 7 Apr 2020 06:24: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 570FC2074F; Tue, 7 Apr 2020 10:24:22 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1586255062; bh=WWPBWH6R7vqAyfkKB/N+fKzsFhjvBeypNxeA9gpyPj0=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=Nk1obTDXVH4Ie64CB7PpUbeexPICLR2M9RjINCJFkEroumupePU8MxLalVxA45eBL grOS7Fqh6RFDScB8T+NfFtiVl3VWqN9uwrInyaDeh7ZjV8+B90K+vwl6rjEN6jrOe9 dTjggKYSXFYOjV/e9Y17ApKjl9s/nVY0wLdj9o8Q= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Len Brown , Sasha Levin Subject: [PATCH 5.5 15/46] tools/power turbostat: Fix missing SYS_LPI counter on some Chromebooks Date: Tue, 7 Apr 2020 12:21:46 +0200 Message-Id: <20200407101501.130633054@linuxfoundation.org> X-Mailer: git-send-email 2.26.0 In-Reply-To: <20200407101459.502593074@linuxfoundation.org> References: <20200407101459.502593074@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: Len Brown [ Upstream commit 1f81c5efc020314b2db30d77efe228b7e117750d ] Some Chromebook BIOS' do not export an ACPI LPIT, which is how Linux finds the residency counter for CPU and SYSTEM low power states, that is exports in /sys/devices/system/cpu/cpuidle/*residency_us When these sysfs attributes are missing, check the debugfs attrubte from the pmc_core driver, which accesses the same counter value. Signed-off-by: Len Brown Signed-off-by: Sasha Levin --- tools/power/x86/turbostat/turbostat.c | 23 ++++++++++++++--------- 1 file changed, 14 insertions(+), 9 deletions(-) diff --git a/tools/power/x86/turbostat/turbostat.c b/tools/power/x86/turbostat/turbostat.c index 78507cd479bb4..17e82eaf5c4f4 100644 --- a/tools/power/x86/turbostat/turbostat.c +++ b/tools/power/x86/turbostat/turbostat.c @@ -304,6 +304,10 @@ int *irqs_per_cpu; /* indexed by cpu_num */ void setup_all_buffers(void); +char *sys_lpi_file; +char *sys_lpi_file_sysfs = "/sys/devices/system/cpu/cpuidle/low_power_idle_system_residency_us"; +char *sys_lpi_file_debugfs = "/sys/kernel/debug/pmc_core/slp_s0_residency_usec"; + int cpu_is_not_present(int cpu) { return !CPU_ISSET_S(cpu, cpu_present_setsize, cpu_present_set); @@ -2916,8 +2920,6 @@ int snapshot_gfx_mhz(void) * * record snapshot of * /sys/devices/system/cpu/cpuidle/low_power_idle_cpu_residency_us - * - * return 1 if config change requires a restart, else return 0 */ int snapshot_cpu_lpi_us(void) { @@ -2941,17 +2943,14 @@ int snapshot_cpu_lpi_us(void) /* * snapshot_sys_lpi() * - * record snapshot of - * /sys/devices/system/cpu/cpuidle/low_power_idle_system_residency_us - * - * return 1 if config change requires a restart, else return 0 + * record snapshot of sys_lpi_file */ int snapshot_sys_lpi_us(void) { FILE *fp; int retval; - fp = fopen_or_die("/sys/devices/system/cpu/cpuidle/low_power_idle_system_residency_us", "r"); + fp = fopen_or_die(sys_lpi_file, "r"); retval = fscanf(fp, "%lld", &cpuidle_cur_sys_lpi_us); if (retval != 1) { @@ -4907,10 +4906,16 @@ void process_cpuid() else BIC_NOT_PRESENT(BIC_CPU_LPI); - if (!access("/sys/devices/system/cpu/cpuidle/low_power_idle_system_residency_us", R_OK)) + if (!access(sys_lpi_file_sysfs, R_OK)) { + sys_lpi_file = sys_lpi_file_sysfs; BIC_PRESENT(BIC_SYS_LPI); - else + } else if (!access(sys_lpi_file_debugfs, R_OK)) { + sys_lpi_file = sys_lpi_file_debugfs; + BIC_PRESENT(BIC_SYS_LPI); + } else { + sys_lpi_file_sysfs = NULL; BIC_NOT_PRESENT(BIC_SYS_LPI); + } if (!quiet) decode_misc_feature_control(); From patchwork Tue Apr 7 10:21:48 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "gregkh@linuxfoundation.org" X-Patchwork-Id: 228176 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=-9.9 required=3.0 tests=DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_PATCH, MAILING_LIST_MULTI, SIGNED_OFF_BY,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 79E6FC2BB55 for ; Tue, 7 Apr 2020 10:24:33 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 515B62082F for ; Tue, 7 Apr 2020 10:24:33 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1586255073; bh=kbZl1uDjGDqe9P85bbeC5tlO3WXKxc6I56W8sgaOY54=; h=From:To:Cc:Subject:Date:In-Reply-To:References:List-ID:From; b=Gbclay5Nm/b9SVXWDW4vET0bB/Ya/LddMPbyHK6gz4Mmuh9HI0XVv8m1l+8a+rTxJ VOvzUj8vIadqU5WxPWDGS6OPdcklvX5f/JOBkxRbz7vvp9e76sI7+DkBzCQSHeHa7d Ki/rPO85yaXRfW0Sef7LTSRXaZQqaqubl5RwR9Xs= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728736AbgDGKYc (ORCPT ); Tue, 7 Apr 2020 06:24:32 -0400 Received: from mail.kernel.org ([198.145.29.99]:34728 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728727AbgDGKY2 (ORCPT ); Tue, 7 Apr 2020 06:24: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 4BED82074F; Tue, 7 Apr 2020 10:24:27 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1586255067; bh=kbZl1uDjGDqe9P85bbeC5tlO3WXKxc6I56W8sgaOY54=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=C7ZA8P+F1wM/Zwvg3hVVuKJm40PLWedTkOn6Gb9bM4HiFDN58BDqdmr03vuIvc6/+ p25bSMeLcnhimWz25nMI5dTdw4azOVTI7tgVlhofr4J/PmYWjizdD028qsS1uozYyu LwleJr5i1bEA3hHpEKE8vWbsr5BPqk3qq1s0zS/Y= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Geert Uytterhoeven , Daniel Jordan , Herbert Xu , Steffen Klassert , linux-crypto@vger.kernel.org, Sasha Levin Subject: [PATCH 5.5 17/46] padata: fix uninitialized return value in padata_replace() Date: Tue, 7 Apr 2020 12:21:48 +0200 Message-Id: <20200407101501.345016605@linuxfoundation.org> X-Mailer: git-send-email 2.26.0 In-Reply-To: <20200407101459.502593074@linuxfoundation.org> References: <20200407101459.502593074@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: Daniel Jordan [ Upstream commit 41ccdbfd5427bbbf3ed58b16750113b38fad1780 ] According to Geert's report[0], kernel/padata.c: warning: 'err' may be used uninitialized in this function [-Wuninitialized]: => 539:2 Warning is seen only with older compilers on certain archs. The runtime effect is potentially returning garbage down the stack when padata's cpumasks are modified before any pcrypt requests have run. Simplest fix is to initialize err to the success value. [0] http://lkml.kernel.org/r/20200210135506.11536-1-geert@linux-m68k.org Reported-by: Geert Uytterhoeven Fixes: bbefa1dd6a6d ("crypto: pcrypt - Avoid deadlock by using per-instance padata queues") Signed-off-by: Daniel Jordan Cc: Herbert Xu Cc: Steffen Klassert Cc: linux-crypto@vger.kernel.org Cc: linux-kernel@vger.kernel.org Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin --- kernel/padata.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/kernel/padata.c b/kernel/padata.c index fda7a7039422d..7bd37dd9ec55b 100644 --- a/kernel/padata.c +++ b/kernel/padata.c @@ -516,7 +516,7 @@ static int padata_replace(struct padata_instance *pinst) { int notification_mask = 0; struct padata_shell *ps; - int err; + int err = 0; pinst->flags |= PADATA_RESET; From patchwork Tue Apr 7 10:21:50 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "gregkh@linuxfoundation.org" X-Patchwork-Id: 228175 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=-9.9 required=3.0 tests=DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_PATCH, MAILING_LIST_MULTI, SIGNED_OFF_BY,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 9898AC2BB54 for ; Tue, 7 Apr 2020 10:24:35 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 65A2F20936 for ; Tue, 7 Apr 2020 10:24:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1586255075; bh=MgUBkgRyGDEoet7WkJIpUu01v9uuWx0w0BQHOcz/Zoo=; h=From:To:Cc:Subject:Date:In-Reply-To:References:List-ID:From; b=JMbYNDsPzcfjx3/Mapn8r8j1NFH1CwiC9w4/v/e5aGKd8xBtvtl5/dux4ImbZmXb2 nXt0Y675AqmpRL5TtiCTdPsWAbo9zuxt1RhTdgTV8wuzIF6z8gIxokFgtv/E/Q8JrK WnZ8RwBrQKM+ubHCSv63mtEi16d5aXqxt8Wj9ksw= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728386AbgDGKYf (ORCPT ); Tue, 7 Apr 2020 06:24:35 -0400 Received: from mail.kernel.org ([198.145.29.99]:34846 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728739AbgDGKYe (ORCPT ); Tue, 7 Apr 2020 06:24:34 -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 3B92F2080C; Tue, 7 Apr 2020 10:24:32 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1586255072; bh=MgUBkgRyGDEoet7WkJIpUu01v9uuWx0w0BQHOcz/Zoo=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=a6si5W56L2IR1TdjwHMt/EjGkhtsLCqjQgOxsn4GL5T9jDj2Q66gPs7poTdbDEE7L pvxKYxvJ4rhZlw043xfLxV8NH+lZegSysyXJXlg2O4m1vkGUK7rIYchSZAvAdOx+r2 3GLc1H+lGC1DqX4gGFB+/oW2M3PfFCiFRTi6+xG8= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Jann Horn , Daniel Borkmann , Alexei Starovoitov , Sasha Levin Subject: [PATCH 5.5 19/46] bpf: Fix tnum constraints for 32-bit comparisons Date: Tue, 7 Apr 2020 12:21:50 +0200 Message-Id: <20200407101501.574740613@linuxfoundation.org> X-Mailer: git-send-email 2.26.0 In-Reply-To: <20200407101459.502593074@linuxfoundation.org> References: <20200407101459.502593074@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: Jann Horn [ Upstream commit 604dca5e3af1db98bd123b7bfc02b017af99e3a0 ] The BPF verifier tried to track values based on 32-bit comparisons by (ab)using the tnum state via 581738a681b6 ("bpf: Provide better register bounds after jmp32 instructions"). The idea is that after a check like this: if ((u32)r0 > 3) exit We can't meaningfully constrain the arithmetic-range-based tracking, but we can update the tnum state to (value=0,mask=0xffff'ffff'0000'0003). However, the implementation from 581738a681b6 didn't compute the tnum constraint based on the fixed operand, but instead derives it from the arithmetic-range-based tracking. This means that after the following sequence of operations: if (r0 >= 0x1'0000'0001) exit if ((u32)r0 > 7) exit The verifier assumed that the lower half of r0 is in the range (0, 0) and apply the tnum constraint (value=0,mask=0xffff'ffff'0000'0000) thus causing the overall tnum to be (value=0,mask=0x1'0000'0000), which was incorrect. Provide a fixed implementation. Fixes: 581738a681b6 ("bpf: Provide better register bounds after jmp32 instructions") Signed-off-by: Jann Horn Signed-off-by: Daniel Borkmann Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20200330160324.15259-3-daniel@iogearbox.net Signed-off-by: Sasha Levin --- kernel/bpf/verifier.c | 108 ++++++++++++++++++++++++++++-------------- 1 file changed, 72 insertions(+), 36 deletions(-) diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c index 79f38a281390d..f6476c4e9037a 100644 --- a/kernel/bpf/verifier.c +++ b/kernel/bpf/verifier.c @@ -5550,6 +5550,70 @@ static bool cmp_val_with_extended_s64(s64 sval, struct bpf_reg_state *reg) reg->smax_value <= 0 && reg->smin_value >= S32_MIN); } +/* Constrain the possible values of @reg with unsigned upper bound @bound. + * If @is_exclusive, @bound is an exclusive limit, otherwise it is inclusive. + * If @is_jmp32, @bound is a 32-bit value that only constrains the low 32 bits + * of @reg. + */ +static void set_upper_bound(struct bpf_reg_state *reg, u64 bound, bool is_jmp32, + bool is_exclusive) +{ + if (is_exclusive) { + /* There are no values for `reg` that make `reg<0` true. */ + if (bound == 0) + return; + bound--; + } + if (is_jmp32) { + /* Constrain the register's value in the tnum representation. + * For 64-bit comparisons this happens later in + * __reg_bound_offset(), but for 32-bit comparisons, we can be + * more precise than what can be derived from the updated + * numeric bounds. + */ + struct tnum t = tnum_range(0, bound); + + t.mask |= ~0xffffffffULL; /* upper half is unknown */ + reg->var_off = tnum_intersect(reg->var_off, t); + + /* Compute the 64-bit bound from the 32-bit bound. */ + bound += gen_hi_max(reg->var_off); + } + reg->umax_value = min(reg->umax_value, bound); +} + +/* Constrain the possible values of @reg with unsigned lower bound @bound. + * If @is_exclusive, @bound is an exclusive limit, otherwise it is inclusive. + * If @is_jmp32, @bound is a 32-bit value that only constrains the low 32 bits + * of @reg. + */ +static void set_lower_bound(struct bpf_reg_state *reg, u64 bound, bool is_jmp32, + bool is_exclusive) +{ + if (is_exclusive) { + /* There are no values for `reg` that make `reg>MAX` true. */ + if (bound == (is_jmp32 ? U32_MAX : U64_MAX)) + return; + bound++; + } + if (is_jmp32) { + /* Constrain the register's value in the tnum representation. + * For 64-bit comparisons this happens later in + * __reg_bound_offset(), but for 32-bit comparisons, we can be + * more precise than what can be derived from the updated + * numeric bounds. + */ + struct tnum t = tnum_range(bound, U32_MAX); + + t.mask |= ~0xffffffffULL; /* upper half is unknown */ + reg->var_off = tnum_intersect(reg->var_off, t); + + /* Compute the 64-bit bound from the 32-bit bound. */ + bound += gen_hi_min(reg->var_off); + } + reg->umin_value = max(reg->umin_value, bound); +} + /* Adjusts the register min/max values in the case that the dst_reg is the * variable register that we are working on, and src_reg is a constant or we're * simply doing a BPF_K check. @@ -5605,15 +5669,8 @@ static void reg_set_min_max(struct bpf_reg_state *true_reg, case BPF_JGE: case BPF_JGT: { - u64 false_umax = opcode == BPF_JGT ? val : val - 1; - u64 true_umin = opcode == BPF_JGT ? val + 1 : val; - - if (is_jmp32) { - false_umax += gen_hi_max(false_reg->var_off); - true_umin += gen_hi_min(true_reg->var_off); - } - false_reg->umax_value = min(false_reg->umax_value, false_umax); - true_reg->umin_value = max(true_reg->umin_value, true_umin); + set_upper_bound(false_reg, val, is_jmp32, opcode == BPF_JGE); + set_lower_bound(true_reg, val, is_jmp32, opcode == BPF_JGT); break; } case BPF_JSGE: @@ -5634,15 +5691,8 @@ static void reg_set_min_max(struct bpf_reg_state *true_reg, case BPF_JLE: case BPF_JLT: { - u64 false_umin = opcode == BPF_JLT ? val : val + 1; - u64 true_umax = opcode == BPF_JLT ? val - 1 : val; - - if (is_jmp32) { - false_umin += gen_hi_min(false_reg->var_off); - true_umax += gen_hi_max(true_reg->var_off); - } - false_reg->umin_value = max(false_reg->umin_value, false_umin); - true_reg->umax_value = min(true_reg->umax_value, true_umax); + set_lower_bound(false_reg, val, is_jmp32, opcode == BPF_JLE); + set_upper_bound(true_reg, val, is_jmp32, opcode == BPF_JLT); break; } case BPF_JSLE: @@ -5717,15 +5767,8 @@ static void reg_set_min_max_inv(struct bpf_reg_state *true_reg, case BPF_JGE: case BPF_JGT: { - u64 false_umin = opcode == BPF_JGT ? val : val + 1; - u64 true_umax = opcode == BPF_JGT ? val - 1 : val; - - if (is_jmp32) { - false_umin += gen_hi_min(false_reg->var_off); - true_umax += gen_hi_max(true_reg->var_off); - } - false_reg->umin_value = max(false_reg->umin_value, false_umin); - true_reg->umax_value = min(true_reg->umax_value, true_umax); + set_lower_bound(false_reg, val, is_jmp32, opcode == BPF_JGE); + set_upper_bound(true_reg, val, is_jmp32, opcode == BPF_JGT); break; } case BPF_JSGE: @@ -5743,15 +5786,8 @@ static void reg_set_min_max_inv(struct bpf_reg_state *true_reg, case BPF_JLE: case BPF_JLT: { - u64 false_umax = opcode == BPF_JLT ? val : val - 1; - u64 true_umin = opcode == BPF_JLT ? val + 1 : val; - - if (is_jmp32) { - false_umax += gen_hi_max(false_reg->var_off); - true_umin += gen_hi_min(true_reg->var_off); - } - false_reg->umax_value = min(false_reg->umax_value, false_umax); - true_reg->umin_value = max(true_reg->umin_value, true_umin); + set_upper_bound(false_reg, val, is_jmp32, opcode == BPF_JLE); + set_lower_bound(true_reg, val, is_jmp32, opcode == BPF_JLT); break; } case BPF_JSLE: From patchwork Tue Apr 7 10:21:54 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "gregkh@linuxfoundation.org" X-Patchwork-Id: 228174 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=-6.9 required=3.0 tests=DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI, SIGNED_OFF_BY, 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 B358DC2BB55 for ; Tue, 7 Apr 2020 10:24:48 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 8AC5B2078C for ; Tue, 7 Apr 2020 10:24:48 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1586255088; bh=hFSSaaFZs7iS34JeOV/LO3xxtt/qCl6SQ6F3A3HPIlg=; h=From:To:Cc:Subject:Date:In-Reply-To:References:List-ID:From; b=vbgAgv6JQwa8I1QS6QtQ/xq/PkXKlNFSVn9Tc/Z6N6ryIeIFbB9Cu30QSjVfpAf4D +r/F2kT6MVFk3iTua9jljV7FAMDI5TfhIbfql5kCdLFAGGXNKxM+bsUsmNh01X6d46 crTOejNPbX4gfydOFYAEqtLVNg5EAZCLBgSAZjW0= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728747AbgDGKYr (ORCPT ); Tue, 7 Apr 2020 06:24:47 -0400 Received: from mail.kernel.org ([198.145.29.99]:35100 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728776AbgDGKYq (ORCPT ); Tue, 7 Apr 2020 06:24: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 995BF2080C; Tue, 7 Apr 2020 10:24:44 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1586255085; bh=hFSSaaFZs7iS34JeOV/LO3xxtt/qCl6SQ6F3A3HPIlg=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=P2iIPHSW+XUIoOQQRoFSPUFx1EvZwE4fgpjoKmc+oq3UrZBnK1zUXSKgf/c86+Tzr 7gam58cjoQeIqwKv6//W7LxfBy19H1W6zTmHZT7Smb8eH7xyowOuMa6k2Fn3IUo2Z+ GSoO+meAVAvVKZDLSr1dQvS6n/5ARm5OSETZgaxw= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Kishon Vijay Abraham I , Lorenzo Pieralisi Subject: [PATCH 5.5 23/46] misc: pci_endpoint_test: Avoid using module parameter to determine irqtype Date: Tue, 7 Apr 2020 12:21:54 +0200 Message-Id: <20200407101501.970264355@linuxfoundation.org> X-Mailer: git-send-email 2.26.0 In-Reply-To: <20200407101459.502593074@linuxfoundation.org> References: <20200407101459.502593074@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: Kishon Vijay Abraham I commit b2ba9225e0313b1de631a44b7b48c109032bffec upstream. commit e03327122e2c ("pci_endpoint_test: Add 2 ioctl commands") uses module parameter 'irqtype' in pci_endpoint_test_set_irq() to check if IRQ vectors of a particular type (MSI or MSI-X or LEGACY) is already allocated. However with multi-function devices, 'irqtype' will not correctly reflect the IRQ type of the PCI device. Fix it here by adding 'irqtype' for each PCI device to show the IRQ type of a particular PCI device. Fixes: e03327122e2c ("pci_endpoint_test: Add 2 ioctl commands") Signed-off-by: Kishon Vijay Abraham I Signed-off-by: Lorenzo Pieralisi Cc: stable@vger.kernel.org # v4.19+ Signed-off-by: Greg Kroah-Hartman --- drivers/misc/pci_endpoint_test.c | 12 +++++++++--- 1 file changed, 9 insertions(+), 3 deletions(-) --- a/drivers/misc/pci_endpoint_test.c +++ b/drivers/misc/pci_endpoint_test.c @@ -98,6 +98,7 @@ struct pci_endpoint_test { struct completion irq_raised; int last_irq; int num_irqs; + int irq_type; /* mutex to protect the ioctls */ struct mutex mutex; struct miscdevice miscdev; @@ -157,6 +158,7 @@ static void pci_endpoint_test_free_irq_v struct pci_dev *pdev = test->pdev; pci_free_irq_vectors(pdev); + test->irq_type = IRQ_TYPE_UNDEFINED; } static bool pci_endpoint_test_alloc_irq_vectors(struct pci_endpoint_test *test, @@ -191,6 +193,8 @@ static bool pci_endpoint_test_alloc_irq_ irq = 0; res = false; } + + test->irq_type = type; test->num_irqs = irq; return res; @@ -330,6 +334,7 @@ static bool pci_endpoint_test_copy(struc dma_addr_t orig_dst_phys_addr; size_t offset; size_t alignment = test->alignment; + int irq_type = test->irq_type; u32 src_crc32; u32 dst_crc32; @@ -426,6 +431,7 @@ static bool pci_endpoint_test_write(stru dma_addr_t orig_phys_addr; size_t offset; size_t alignment = test->alignment; + int irq_type = test->irq_type; u32 crc32; if (size > SIZE_MAX - alignment) @@ -494,6 +500,7 @@ static bool pci_endpoint_test_read(struc dma_addr_t orig_phys_addr; size_t offset; size_t alignment = test->alignment; + int irq_type = test->irq_type; u32 crc32; if (size > SIZE_MAX - alignment) @@ -555,7 +562,7 @@ static bool pci_endpoint_test_set_irq(st return false; } - if (irq_type == req_irq_type) + if (test->irq_type == req_irq_type) return true; pci_endpoint_test_release_irq(test); @@ -567,12 +574,10 @@ static bool pci_endpoint_test_set_irq(st if (!pci_endpoint_test_request_irq(test)) goto err; - irq_type = req_irq_type; return true; err: pci_endpoint_test_free_irq_vectors(test); - irq_type = IRQ_TYPE_UNDEFINED; return false; } @@ -652,6 +657,7 @@ static int pci_endpoint_test_probe(struc test->test_reg_bar = 0; test->alignment = 0; test->pdev = pdev; + test->irq_type = IRQ_TYPE_UNDEFINED; if (no_msi) irq_type = IRQ_TYPE_LEGACY; From patchwork Tue Apr 7 10:21:55 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "gregkh@linuxfoundation.org" X-Patchwork-Id: 228146 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=-6.9 required=3.0 tests=DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI, SIGNED_OFF_BY, SPF_HELO_NONE, SPF_PASS, URIBL_BLOCKED, 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 8F0B0C2BB55 for ; Tue, 7 Apr 2020 10:28:51 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 66C4120644 for ; Tue, 7 Apr 2020 10:28:51 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1586255331; bh=xmrT11w54ApBz4oohIkiyxhRNgVs9VCTrvI+89Llllc=; h=From:To:Cc:Subject:Date:In-Reply-To:References:List-ID:From; b=i1f5ZYO5C1U40NRk1n69P0KRLHKX0H6rpEf4aNZDee2nMYSY+44dCzhMp55aC+QmV o4J++w2uGCfumUvYbSJjdv/NWagPoucqO80lidXo8S3os771LnF9P1A12HXrZgv4M5 RAyLlib5OjdCNebEUlC3ykcqu3koLNPlD3G9mWOo= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728799AbgDGKYs (ORCPT ); Tue, 7 Apr 2020 06:24:48 -0400 Received: from mail.kernel.org ([198.145.29.99]:35140 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728794AbgDGKYs (ORCPT ); Tue, 7 Apr 2020 06:24:48 -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 177B620644; Tue, 7 Apr 2020 10:24:46 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1586255087; bh=xmrT11w54ApBz4oohIkiyxhRNgVs9VCTrvI+89Llllc=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=vofYaROWb4ihJ2e7KbU91cY0MGYvnbFWQvxSMnXmakhDhFBzzrAfgGywz8GHu4ZVh DyX06QxuuDsvJfwFXtwqWgohjTl36NiKt6xDcZ5OMhUHV2dftIxT0Rx388ETCBKtFu WdtsKNIL8nL8RZudOOy9ZANiIto34KTO8u13aIJ4= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Kelsey Skunberg , Bjorn Helgaas Subject: [PATCH 5.5 24/46] PCI: sysfs: Revert "rescan" file renames Date: Tue, 7 Apr 2020 12:21:55 +0200 Message-Id: <20200407101502.114243463@linuxfoundation.org> X-Mailer: git-send-email 2.26.0 In-Reply-To: <20200407101459.502593074@linuxfoundation.org> References: <20200407101459.502593074@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: Kelsey Skunberg commit bd641fd8303a371e789e924291086268256766b0 upstream. We changed these sysfs filenames: .../pci_bus//rescan -> .../pci_bus//bus_rescan ...//rescan -> ...//dev_rescan and Ruslan reported [1] that this broke a userspace application. Revert these name changes so both files are named "rescan" again. Note that we have to use __ATTR() to assign custom C symbols, i.e., "struct device_attribute ". [1] https://lore.kernel.org/r/CAB=otbSYozS-ZfxB0nCiNnxcbqxwrHOSYxJJtDKa63KzXbXgpw@mail.gmail.com [bhelgaas: commit log, use __ATTR() both places so we don't have to rename the attributes] Fixes: 8bdfa145f582 ("PCI: sysfs: Define device attributes with DEVICE_ATTR*()") Fixes: 4e2b79436e4f ("PCI: sysfs: Change DEVICE_ATTR() to DEVICE_ATTR_WO()") Link: https://lore.kernel.org/r/20200325151708.32612-1-skunberg.kelsey@gmail.com Signed-off-by: Kelsey Skunberg Signed-off-by: Bjorn Helgaas Reviewed-by: Greg Kroah-Hartman Cc: stable@vger.kernel.org # v5.4+ Signed-off-by: Greg Kroah-Hartman --- drivers/pci/pci-sysfs.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) --- a/drivers/pci/pci-sysfs.c +++ b/drivers/pci/pci-sysfs.c @@ -464,7 +464,8 @@ static ssize_t dev_rescan_store(struct d } return count; } -static DEVICE_ATTR_WO(dev_rescan); +static struct device_attribute dev_attr_dev_rescan = __ATTR(rescan, 0200, NULL, + dev_rescan_store); static ssize_t remove_store(struct device *dev, struct device_attribute *attr, const char *buf, size_t count) @@ -501,7 +502,8 @@ static ssize_t bus_rescan_store(struct d } return count; } -static DEVICE_ATTR_WO(bus_rescan); +static struct device_attribute dev_attr_bus_rescan = __ATTR(rescan, 0200, NULL, + bus_rescan_store); #if defined(CONFIG_PM) && defined(CONFIG_ACPI) static ssize_t d3cold_allowed_store(struct device *dev, From patchwork Tue Apr 7 10:21:58 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "gregkh@linuxfoundation.org" X-Patchwork-Id: 228156 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=-6.9 required=3.0 tests=DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI, SIGNED_OFF_BY, SPF_HELO_NONE, SPF_PASS, URIBL_BLOCKED, 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 72458C2BB55 for ; Tue, 7 Apr 2020 10:28:03 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 3E9DB20644 for ; Tue, 7 Apr 2020 10:28:03 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1586255283; bh=TorpH4uEST+U3yxKOkCZL/m53n9xz2lDBNqCEdKUsyA=; h=From:To:Cc:Subject:Date:In-Reply-To:References:List-ID:From; b=J+Gd3GGs2qI3E78cIJ93IMfzlCXqth8KiOxhrDLaM9uIEnS34Jbpyf8JfT572oUKd xM7qqWW/S156PPp5jXis9H/dlE1NNf3SnVVN/9x245pF6zTqEsY4YKFP9COQigvneE Yp9ok+X5x6g/p4eIkAAC+milY6CJE/ToecRKw+es= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729068AbgDGK0D (ORCPT ); Tue, 7 Apr 2020 06:26:03 -0400 Received: from mail.kernel.org ([198.145.29.99]:36862 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728303AbgDGK0C (ORCPT ); Tue, 7 Apr 2020 06:26: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 4A49F2082D; Tue, 7 Apr 2020 10:26:01 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1586255161; bh=TorpH4uEST+U3yxKOkCZL/m53n9xz2lDBNqCEdKUsyA=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=prSI+ab112bbw4dTnIPAXRWID7LqEeq8w1y44QgJnsxtTUqVm2GBxYxxE30p+3Lch FJ2FXftIukuLnP9wy11gHya54ztFJ4H/lIk9OAxoOiU4rpIEwrgWeiKnz/T9m6f+61 qOvhx2mLemAdYAAabFdx7QAiDbVYyhj7I9DP7l2U= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Nicholas Johnson , Srinivas Kandagatla Subject: [PATCH 5.5 27/46] nvmem: check for NULL reg_read and reg_write before dereferencing Date: Tue, 7 Apr 2020 12:21:58 +0200 Message-Id: <20200407101502.416106818@linuxfoundation.org> X-Mailer: git-send-email 2.26.0 In-Reply-To: <20200407101459.502593074@linuxfoundation.org> References: <20200407101459.502593074@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: Nicholas Johnson commit 3c91ef69a3e94f78546b246225ed573fbf1735b4 upstream. Return -EPERM if reg_read is NULL in bin_attr_nvmem_read() or if reg_write is NULL in bin_attr_nvmem_write(). This prevents NULL dereferences such as the one described in 03cd45d2e219 ("thunderbolt: Prevent crash if non-active NVMem file is read") Signed-off-by: Nicholas Johnson Cc: stable Signed-off-by: Srinivas Kandagatla Link: https://lore.kernel.org/r/20200310132257.23358-10-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman --- drivers/nvmem/nvmem-sysfs.c | 6 ++++++ 1 file changed, 6 insertions(+) --- a/drivers/nvmem/nvmem-sysfs.c +++ b/drivers/nvmem/nvmem-sysfs.c @@ -56,6 +56,9 @@ static ssize_t bin_attr_nvmem_read(struc count = round_down(count, nvmem->word_size); + if (!nvmem->reg_read) + return -EPERM; + rc = nvmem->reg_read(nvmem->priv, pos, buf, count); if (rc) @@ -90,6 +93,9 @@ static ssize_t bin_attr_nvmem_write(stru count = round_down(count, nvmem->word_size); + if (!nvmem->reg_write) + return -EPERM; + rc = nvmem->reg_write(nvmem->priv, pos, buf, count); if (rc) From patchwork Tue Apr 7 10:21:59 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "gregkh@linuxfoundation.org" X-Patchwork-Id: 228172 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=-6.9 required=3.0 tests=DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI, SIGNED_OFF_BY, 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 08332C2BB55 for ; Tue, 7 Apr 2020 10:25:20 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id CE23220936 for ; Tue, 7 Apr 2020 10:25:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1586255119; bh=zMvRv1xvSRez/I8XS6dOdstcuN71d0iQj0e9cGUUUMI=; h=From:To:Cc:Subject:Date:In-Reply-To:References:List-ID:From; b=HDfGru8f+78iPINuhxQRx4udy0EUfmS5bkZhT70zdYpRJcdKL0Vu1CK+7X4xvrhNs IlsA99sy2cUhlkS6gDiwQJkFvLcW8y9G8j2E+DggU/8EYSeD8eg7sqDec4a6FOVG3l WAQsUshmGNjf4yoS3dZTP7k/n5q2Q5XHLBW2TOHo= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728494AbgDGKZS (ORCPT ); Tue, 7 Apr 2020 06:25:18 -0400 Received: from mail.kernel.org ([198.145.29.99]:35732 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728907AbgDGKZP (ORCPT ); Tue, 7 Apr 2020 06:25: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 7AE7E2074B; Tue, 7 Apr 2020 10:25:14 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1586255115; bh=zMvRv1xvSRez/I8XS6dOdstcuN71d0iQj0e9cGUUUMI=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=RviyVA1F8wLV9ZCRmEGoPw7v07uQ98W5w5eGn4wi+IY52lYG6zrzsfjBhAp7B0STq wd4Bs2fLxUMmaUdCpN6xAs2nfWC0K+eycY3htFiRjEZmK6Bz3iX17O5ZBNStxB2OmR I+Rz4wz5R9YB0u+XBBbxVlbI3ixdhTPFswVR00hU= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Freeman Liu , Baolin Wang , Srinivas Kandagatla Subject: [PATCH 5.5 28/46] nvmem: sprd: Fix the block lock operation Date: Tue, 7 Apr 2020 12:21:59 +0200 Message-Id: <20200407101502.527377529@linuxfoundation.org> X-Mailer: git-send-email 2.26.0 In-Reply-To: <20200407101459.502593074@linuxfoundation.org> References: <20200407101459.502593074@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: Freeman Liu commit c66ebde4d988b592e8f0008e04c47cc4950a49d3 upstream. According to the Spreadtrum eFuse specification, we should write 0 to the block to trigger the lock operation. Fixes: 096030e7f449 ("nvmem: sprd: Add Spreadtrum SoCs eFuse support") Cc: stable Signed-off-by: Freeman Liu Signed-off-by: Baolin Wang Signed-off-by: Srinivas Kandagatla Link: https://lore.kernel.org/r/20200323150007.7487-2-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman --- drivers/nvmem/sprd-efuse.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/nvmem/sprd-efuse.c +++ b/drivers/nvmem/sprd-efuse.c @@ -239,7 +239,7 @@ static int sprd_efuse_raw_prog(struct sp ret = -EBUSY; } else { sprd_efuse_set_prog_lock(efuse, lock); - writel(*data, efuse->base + SPRD_EFUSE_MEM(blk)); + writel(0, efuse->base + SPRD_EFUSE_MEM(blk)); sprd_efuse_set_prog_lock(efuse, false); } From patchwork Tue Apr 7 10:22:01 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "gregkh@linuxfoundation.org" X-Patchwork-Id: 228153 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=-6.9 required=3.0 tests=DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI, SIGNED_OFF_BY, SPF_HELO_NONE, SPF_PASS, URIBL_BLOCKED, 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 05E5BC2BB54 for ; Tue, 7 Apr 2020 10:28:14 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id C6D7620644 for ; Tue, 7 Apr 2020 10:28:13 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1586255293; bh=4pHLwaftfoue1jLFWgtZnNla0KEbD+Y0nes/UYDUXW8=; h=From:To:Cc:Subject:Date:In-Reply-To:References:List-ID:From; b=wrFtil7sEufIi+pgGtoyY73tDl721KT6318E/07RNwcvbS2OINpsHpN1ZRHjHh2x7 fUl6QHDbtupGQhxHSCaUPs+hgK083MUPNqviOrdtvC8IlFbvuoCffeSR0dh+moiFca sxIWwjG9itWjHLMM1RbKDBfriCFJUtPvI6O2DV8w= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729018AbgDGKZq (ORCPT ); Tue, 7 Apr 2020 06:25:46 -0400 Received: from mail.kernel.org ([198.145.29.99]:36470 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728992AbgDGKZq (ORCPT ); Tue, 7 Apr 2020 06:25: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 141882074F; Tue, 7 Apr 2020 10:25:43 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1586255144; bh=4pHLwaftfoue1jLFWgtZnNla0KEbD+Y0nes/UYDUXW8=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=aYGCrxbE5OpP98O/TTLqNYmOrYxoKIYwe4+06AzTrldUK43E1reE7jfYsYHDCFlxE 4uUyxLheqI0duWFMn5FJMZGqBPcpIZj0x3Gw+UDvOl6gqYLJqrRIMaltxKNnGe6WLS 9bEL2TXDLU8xmlD79PwhBm4KYPPIQveVBDiBy1Ic= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Hans de Goede , Sebastian Reichel Subject: [PATCH 5.5 30/46] power: supply: axp288_charger: Add special handling for HP Pavilion x2 10 Date: Tue, 7 Apr 2020 12:22:01 +0200 Message-Id: <20200407101502.698383372@linuxfoundation.org> X-Mailer: git-send-email 2.26.0 In-Reply-To: <20200407101459.502593074@linuxfoundation.org> References: <20200407101459.502593074@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: Hans de Goede commit 9c80662a74cd2a5d1113f5c69d027face963a556 upstream. Some HP Pavilion x2 10 models use an AXP288 for charging and fuel-gauge. We use a native power_supply / PMIC driver in this case, because on most models with an AXP288 the ACPI AC / Battery code is either completely missing or relies on custom / proprietary ACPI OpRegions which Linux does not implement. The native drivers mostly work fine, but there are 2 problems: 1. These model uses a Type-C connector for charging which the AXP288 does not support. As long as a Type-A charger (which uses the USB data pins for charger type detection) is used everything is fine. But if a Type-C charger is used (such as the charger shipped with the device) then the charger is not recognized. So we end up slowly discharging the device even though a charger is connected, because we are limiting the current from the charger to 500mA. To make things worse this happens with the device's official charger. Looking at the ACPI tables HP has "solved" the problem of the AXP288 not being able to recognize Type-C chargers by simply always programming the input-current-limit at 3000mA and relying on a Vhold setting of 4.7V (normally 4.4V) to limit the current intake if the charger cannot handle this. 2. If no charger is connected when the machine boots then it boots with the vbus-path disabled. On other devices this is done when a 5V boost converter is active to avoid the PMIC trying to charge from the 5V boost output. This is done when an OTG host cable is inserted and the ID pin on the micro-B receptacle is pulled low, the ID pin has an ACPI event handler associated with it which re-enables the vbus-path when the ID pin is pulled high when the OTG cable is removed. The Type-C connector has no ID pin, there is no ID pin handler and there appears to be no 5V boost converter, so we end up not charging because the vbus-path is disabled, until we unplug the charger which automatically clears the vbus-path disable bit and then on the second plug-in of the adapter we start charging. The HP Pavilion x2 10 models with an AXP288 do have mostly working ACPI AC / Battery code which does not rely on custom / proprietary ACPI OpRegions. So one possible solution would be to blacklist the AXP288 native power_supply drivers and add the HP Pavilion x2 10 with AXP288 DMI ids to the list of devices which should use the ACPI AC / Battery code even though they have an AXP288 PMIC. This would require changes to 4 files: drivers/acpi/ac.c, drivers/power/supply/axp288_charger.c, drivers/acpi/battery.c and drivers/power/supply/axp288_fuel_gauge.c. Beside needing adding the same DMI matches to 4 different files, this approach also triggers problem 2. from above, but then when suspended, during suspend the machine will not wakeup because the vbus path is disabled by the AML code when not charging, so the Vbus low-to-high IRQ is not triggered, the CPU never wakes up and the device does not charge even though the user likely things it is charging, esp. since the charge status LED is directly coupled to an adapter being plugged in and does not reflect actual charging. This could be worked by enabling vbus-path explicitly from say the axp288_charger driver's suspend handler. So neither situation is ideal, in both cased we need to explicitly enable the vbus-path to work around different variants of problem 2 above, this requires a quirk in the axp288_charger code. If we go the route of using the ACPI AC / Battery drivers then we need modifications to 3 other drivers; and we need to partially disable the axp288_charger code, while at the same time keeping it around to enable vbus-path on suspend. OTOH we can copy the hardcoding of 3A input-current-limit (we never touch Vhold, so that would stay at 4.7V) to the axp288_charger code, which needs changes regardless, then we concentrate all special handling of this interesting device model in the axp288_charger code. That is what this commit does. Cc: stable@vger.kernel.org BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1791098 Signed-off-by: Hans de Goede Signed-off-by: Sebastian Reichel Signed-off-by: Greg Kroah-Hartman --- drivers/power/supply/axp288_charger.c | 57 +++++++++++++++++++++++++++++++++- 1 file changed, 56 insertions(+), 1 deletion(-) --- a/drivers/power/supply/axp288_charger.c +++ b/drivers/power/supply/axp288_charger.c @@ -21,6 +21,7 @@ #include #include #include +#include #define PS_STAT_VBUS_TRIGGER BIT(0) #define PS_STAT_BAT_CHRG_DIR BIT(2) @@ -545,6 +546,49 @@ out: return IRQ_HANDLED; } +/* + * The HP Pavilion x2 10 series comes in a number of variants: + * Bay Trail SoC + AXP288 PMIC, DMI_BOARD_NAME: "815D" + * Cherry Trail SoC + AXP288 PMIC, DMI_BOARD_NAME: "813E" + * Cherry Trail SoC + TI PMIC, DMI_BOARD_NAME: "827C" or "82F4" + * + * The variants with the AXP288 PMIC are all kinds of special: + * + * 1. All variants use a Type-C connector which the AXP288 does not support, so + * when using a Type-C charger it is not recognized. Unlike most AXP288 devices, + * this model actually has mostly working ACPI AC / Battery code, the ACPI code + * "solves" this by simply setting the input_current_limit to 3A. + * There are still some issues with the ACPI code, so we use this native driver, + * and to solve the charging not working (500mA is not enough) issue we hardcode + * the 3A input_current_limit like the ACPI code does. + * + * 2. If no charger is connected the machine boots with the vbus-path disabled. + * Normally this is done when a 5V boost converter is active to avoid the PMIC + * trying to charge from the 5V boost converter's output. This is done when + * an OTG host cable is inserted and the ID pin on the micro-B receptacle is + * pulled low and the ID pin has an ACPI event handler associated with it + * which re-enables the vbus-path when the ID pin is pulled high when the + * OTG host cable is removed. The Type-C connector has no ID pin, there is + * no ID pin handler and there appears to be no 5V boost converter, so we + * end up not charging because the vbus-path is disabled, until we unplug + * the charger which automatically clears the vbus-path disable bit and then + * on the second plug-in of the adapter we start charging. To solve the not + * charging on first charger plugin we unconditionally enable the vbus-path at + * probe on this model, which is safe since there is no 5V boost converter. + */ +static const struct dmi_system_id axp288_hp_x2_dmi_ids[] = { + { + /* + * Bay Trail model has "Hewlett-Packard" as sys_vendor, Cherry + * Trail model has "HP", so we only match on product_name. + */ + .matches = { + DMI_MATCH(DMI_PRODUCT_NAME, "HP Pavilion x2 Detachable"), + }, + }, + {} /* Terminating entry */ +}; + static void axp288_charger_extcon_evt_worker(struct work_struct *work) { struct axp288_chrg_info *info = @@ -568,7 +612,11 @@ static void axp288_charger_extcon_evt_wo } /* Determine cable/charger type */ - if (extcon_get_state(edev, EXTCON_CHG_USB_SDP) > 0) { + if (dmi_check_system(axp288_hp_x2_dmi_ids)) { + /* See comment above axp288_hp_x2_dmi_ids declaration */ + dev_dbg(&info->pdev->dev, "HP X2 with Type-C, setting inlmt to 3A\n"); + current_limit = 3000000; + } else if (extcon_get_state(edev, EXTCON_CHG_USB_SDP) > 0) { dev_dbg(&info->pdev->dev, "USB SDP charger is connected\n"); current_limit = 500000; } else if (extcon_get_state(edev, EXTCON_CHG_USB_CDP) > 0) { @@ -685,6 +733,13 @@ static int charger_init_hw_regs(struct a return ret; } + if (dmi_check_system(axp288_hp_x2_dmi_ids)) { + /* See comment above axp288_hp_x2_dmi_ids declaration */ + ret = axp288_charger_vbus_path_select(info, true); + if (ret < 0) + return ret; + } + /* Read current charge voltage and current limit */ ret = regmap_read(info->regmap, AXP20X_CHRG_CTRL1, &val); if (ret < 0) { From patchwork Tue Apr 7 10:22:02 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "gregkh@linuxfoundation.org" X-Patchwork-Id: 228169 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=-6.9 required=3.0 tests=DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI, SIGNED_OFF_BY, 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 746C0C2BB55 for ; Tue, 7 Apr 2020 10:25:50 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 41F5720771 for ; Tue, 7 Apr 2020 10:25:50 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1586255150; bh=VG7Z96ZUZlKYwd0TaRLpdkJIVqF3gxuR9xzR4g0qwd4=; h=From:To:Cc:Subject:Date:In-Reply-To:References:List-ID:From; b=pldDg82XAsTr7fGFOLZd42I6JZ3ARUD4BR8CTIhOfwmS0HtgJBYCe2oGXMJGQCjf9 YF/snyn7x4h4NeZd95QITwhXxtfbwaFp32iqlCggQl3HtD9JL20I8ng2GsKNwtrJu9 zwg/vwumnPEyXxIhqCUMkj+6UIcG178Ufz8tnMXk= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728316AbgDGKZt (ORCPT ); Tue, 7 Apr 2020 06:25:49 -0400 Received: from mail.kernel.org ([198.145.29.99]:36512 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729024AbgDGKZs (ORCPT ); Tue, 7 Apr 2020 06:25:48 -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 864DE20771; Tue, 7 Apr 2020 10:25:46 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1586255147; bh=VG7Z96ZUZlKYwd0TaRLpdkJIVqF3gxuR9xzR4g0qwd4=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=JgXXRIe7uuEM/GzJfBD7z4R+VHLrAuBHb5Sp1jIzkj099DwljzKOMG0+abS1UvOE5 c6owCi8hlJ/vvOARmS2OciQgCGhmn5gakOjY2R+pv1aV2CYtee6BMTfx7A+U4wm9xJ XJ6S+ng4gdIyi3YLqfSeNMdeR0HzoPe7CEtGiQdM= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Andreas Gruenbacher , Barry Marson , Mike Snitzer Subject: [PATCH 5.5 31/46] Revert "dm: always call blk_queue_split() in dm_process_bio()" Date: Tue, 7 Apr 2020 12:22:02 +0200 Message-Id: <20200407101502.812102667@linuxfoundation.org> X-Mailer: git-send-email 2.26.0 In-Reply-To: <20200407101459.502593074@linuxfoundation.org> References: <20200407101459.502593074@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: Mike Snitzer commit 120c9257f5f19e5d1e87efcbb5531b7cd81b7d74 upstream. This reverts commit effd58c95f277744f75d6e08819ac859dbcbd351. blk_queue_split() is causing excessive IO splitting -- because blk_max_size_offset() depends on 'chunk_sectors' limit being set and if it isn't (as is the case for DM targets!) it falls back to splitting on a 'max_sectors' boundary regardless of offset. "Fix" this by reverting back to _not_ using blk_queue_split() in dm_process_bio() for normal IO (reads and writes). Long-term fix is still TBD but it should focus on training blk_max_size_offset() to call into a DM provided hook (to call DM's max_io_len()). Test results from simple misaligned IO test on 4-way dm-striped device with chunksize of 128K and stripesize of 512K: xfs_io -d -c 'pread -b 2m 224s 4072s' /dev/mapper/stripe_dev before this revert: 253,0 21 1 0.000000000 2206 Q R 224 + 4072 [xfs_io] 253,0 21 2 0.000008267 2206 X R 224 / 480 [xfs_io] 253,0 21 3 0.000010530 2206 X R 224 / 256 [xfs_io] 253,0 21 4 0.000027022 2206 X R 480 / 736 [xfs_io] 253,0 21 5 0.000028751 2206 X R 480 / 512 [xfs_io] 253,0 21 6 0.000033323 2206 X R 736 / 992 [xfs_io] 253,0 21 7 0.000035130 2206 X R 736 / 768 [xfs_io] 253,0 21 8 0.000039146 2206 X R 992 / 1248 [xfs_io] 253,0 21 9 0.000040734 2206 X R 992 / 1024 [xfs_io] 253,0 21 10 0.000044694 2206 X R 1248 / 1504 [xfs_io] 253,0 21 11 0.000046422 2206 X R 1248 / 1280 [xfs_io] 253,0 21 12 0.000050376 2206 X R 1504 / 1760 [xfs_io] 253,0 21 13 0.000051974 2206 X R 1504 / 1536 [xfs_io] 253,0 21 14 0.000055881 2206 X R 1760 / 2016 [xfs_io] 253,0 21 15 0.000057462 2206 X R 1760 / 1792 [xfs_io] 253,0 21 16 0.000060999 2206 X R 2016 / 2272 [xfs_io] 253,0 21 17 0.000062489 2206 X R 2016 / 2048 [xfs_io] 253,0 21 18 0.000066133 2206 X R 2272 / 2528 [xfs_io] 253,0 21 19 0.000067507 2206 X R 2272 / 2304 [xfs_io] 253,0 21 20 0.000071136 2206 X R 2528 / 2784 [xfs_io] 253,0 21 21 0.000072764 2206 X R 2528 / 2560 [xfs_io] 253,0 21 22 0.000076185 2206 X R 2784 / 3040 [xfs_io] 253,0 21 23 0.000077486 2206 X R 2784 / 2816 [xfs_io] 253,0 21 24 0.000080885 2206 X R 3040 / 3296 [xfs_io] 253,0 21 25 0.000082316 2206 X R 3040 / 3072 [xfs_io] 253,0 21 26 0.000085788 2206 X R 3296 / 3552 [xfs_io] 253,0 21 27 0.000087096 2206 X R 3296 / 3328 [xfs_io] 253,0 21 28 0.000093469 2206 X R 3552 / 3808 [xfs_io] 253,0 21 29 0.000095186 2206 X R 3552 / 3584 [xfs_io] 253,0 21 30 0.000099228 2206 X R 3808 / 4064 [xfs_io] 253,0 21 31 0.000101062 2206 X R 3808 / 3840 [xfs_io] 253,0 21 32 0.000104956 2206 X R 4064 / 4096 [xfs_io] 253,0 21 33 0.001138823 0 C R 4096 + 200 [0] after this revert: 253,0 18 1 0.000000000 4430 Q R 224 + 3896 [xfs_io] 253,0 18 2 0.000018359 4430 X R 224 / 256 [xfs_io] 253,0 18 3 0.000028898 4430 X R 256 / 512 [xfs_io] 253,0 18 4 0.000033535 4430 X R 512 / 768 [xfs_io] 253,0 18 5 0.000065684 4430 X R 768 / 1024 [xfs_io] 253,0 18 6 0.000091695 4430 X R 1024 / 1280 [xfs_io] 253,0 18 7 0.000098494 4430 X R 1280 / 1536 [xfs_io] 253,0 18 8 0.000114069 4430 X R 1536 / 1792 [xfs_io] 253,0 18 9 0.000129483 4430 X R 1792 / 2048 [xfs_io] 253,0 18 10 0.000136759 4430 X R 2048 / 2304 [xfs_io] 253,0 18 11 0.000152412 4430 X R 2304 / 2560 [xfs_io] 253,0 18 12 0.000160758 4430 X R 2560 / 2816 [xfs_io] 253,0 18 13 0.000183385 4430 X R 2816 / 3072 [xfs_io] 253,0 18 14 0.000190797 4430 X R 3072 / 3328 [xfs_io] 253,0 18 15 0.000197667 4430 X R 3328 / 3584 [xfs_io] 253,0 18 16 0.000218751 4430 X R 3584 / 3840 [xfs_io] 253,0 18 17 0.000226005 4430 X R 3840 / 4096 [xfs_io] 253,0 18 18 0.000250404 4430 Q R 4120 + 176 [xfs_io] 253,0 18 19 0.000847708 0 C R 4096 + 24 [0] 253,0 18 20 0.000855783 0 C R 4120 + 176 [0] Fixes: effd58c95f27774 ("dm: always call blk_queue_split() in dm_process_bio()") Cc: stable@vger.kernel.org Reported-by: Andreas Gruenbacher Tested-by: Barry Marson Signed-off-by: Mike Snitzer Signed-off-by: Greg Kroah-Hartman --- drivers/md/dm.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) --- a/drivers/md/dm.c +++ b/drivers/md/dm.c @@ -1739,8 +1739,9 @@ static blk_qc_t dm_process_bio(struct ma * won't be imposed. */ if (current->bio_list) { - blk_queue_split(md->queue, &bio); - if (!is_abnormal_io(bio)) + if (is_abnormal_io(bio)) + blk_queue_split(md->queue, &bio); + else dm_queue_split(md, ti, &bio); } From patchwork Tue Apr 7 10:22:04 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "gregkh@linuxfoundation.org" X-Patchwork-Id: 228154 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=-6.9 required=3.0 tests=DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI, SIGNED_OFF_BY, SPF_HELO_NONE, SPF_PASS, URIBL_BLOCKED, 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 2A69CC2BB55 for ; Tue, 7 Apr 2020 10:28:09 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id ED54B20644 for ; Tue, 7 Apr 2020 10:28:08 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1586255289; bh=KN/RtJgBrXn5vFfRyb79eWSReJRlqg0mW2vgwy54kG8=; h=From:To:Cc:Subject:Date:In-Reply-To:References:List-ID:From; b=zzmkK7pVOb7y3ZJR+RE0W+I2leqwEj4NcB+IFmAzxPzumsGuXtAlGS4ySsOd24/Jg ZVaPPLFYdEsYxxcjmL5XiHc6SKG2Uuwag23wlbHsbCKkwcL+IGZMc8KUxt1tuo6FQZ p7NNVJsmpDnDbDkdFEVxwhlrjksXy0r/14C7p7hM= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729047AbgDGKZw (ORCPT ); Tue, 7 Apr 2020 06:25:52 -0400 Received: from mail.kernel.org ([198.145.29.99]:36620 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729045AbgDGKZw (ORCPT ); Tue, 7 Apr 2020 06:25:52 -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 7101A20771; Tue, 7 Apr 2020 10:25:51 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1586255151; bh=KN/RtJgBrXn5vFfRyb79eWSReJRlqg0mW2vgwy54kG8=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=e3KvttlmP7fkaGFNrwPwacwI2ckQcbb0Il7awKLoJGDCmqEfaJjmbAEzS4FYn3nOB TXZh/iMWDiHJB5e4qBJ+maALQTc3NHOR764n+Ao2uGY7msLr0GBITabWnyVO6A2oll /wiobBnZHrR0d6S47jm5OU6Sa9g0aGTkIYgkWd0A= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Bibby Hsieh , CK Hu , Matthias Brugger Subject: [PATCH 5.5 33/46] soc: mediatek: knows_txdone needs to be set in Mediatek CMDQ helper Date: Tue, 7 Apr 2020 12:22:04 +0200 Message-Id: <20200407101503.033372873@linuxfoundation.org> X-Mailer: git-send-email 2.26.0 In-Reply-To: <20200407101459.502593074@linuxfoundation.org> References: <20200407101459.502593074@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: Bibby Hsieh commit ce35e21d82bcac8b3fd5128888f9e233f8444293 upstream. Mediatek CMDQ driver have a mechanism to do TXDONE_BY_ACK, so we should set knows_txdone. Fixes:576f1b4bc802 ("soc: mediatek: Add Mediatek CMDQ helper") Cc: stable@vger.kernel.org # v5.0+ Signed-off-by: Bibby Hsieh Reviewed-by: CK Hu Signed-off-by: Matthias Brugger Signed-off-by: Greg Kroah-Hartman --- drivers/soc/mediatek/mtk-cmdq-helper.c | 1 + 1 file changed, 1 insertion(+) --- a/drivers/soc/mediatek/mtk-cmdq-helper.c +++ b/drivers/soc/mediatek/mtk-cmdq-helper.c @@ -38,6 +38,7 @@ struct cmdq_client *cmdq_mbox_create(str client->pkt_cnt = 0; client->client.dev = dev; client->client.tx_block = false; + client->client.knows_txdone = true; client->chan = mbox_request_channel(&client->client, index); if (IS_ERR(client->chan)) { From patchwork Tue Apr 7 10:22:06 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "gregkh@linuxfoundation.org" X-Patchwork-Id: 228155 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=-6.9 required=3.0 tests=DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI, SIGNED_OFF_BY, SPF_HELO_NONE, SPF_PASS, URIBL_BLOCKED, 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 3B012C2BB1D for ; Tue, 7 Apr 2020 10:28:06 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 0579C2074B for ; Tue, 7 Apr 2020 10:28:06 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1586255286; bh=5/sL9mCXly5jrq1A3Z9N4VVG6JUPKXdB9TUdv7LPc+4=; h=From:To:Cc:Subject:Date:In-Reply-To:References:List-ID:From; b=sSYYJLqpFz1e/uAClvY1JtGMYZTvBtS99RwKwfp5B5EGTT2gkuGwP54686AT1FsGH 2jLoFJ83Ge3goJKkH13cbhj/QbRy9M7s+29RuD35UaDSDxfckqPQwfCwLHlA0MJ5ev 0CrZc6lrXDQWxL1lAujq6nEg78ueJScaIpSAPW14= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729052AbgDGKZ6 (ORCPT ); Tue, 7 Apr 2020 06:25:58 -0400 Received: from mail.kernel.org ([198.145.29.99]:36724 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729060AbgDGKZ5 (ORCPT ); Tue, 7 Apr 2020 06:25:57 -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 589492074F; Tue, 7 Apr 2020 10:25:56 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1586255156; bh=5/sL9mCXly5jrq1A3Z9N4VVG6JUPKXdB9TUdv7LPc+4=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=EIdUbJiJPT78BdFcL1S7HXCMq2aHT6E6mRM/jQNup6YOQTW0lBF0+eFq/oqyB2rxf XMBQvH+gfRMj0WExnIWSnuQcI0Kg46FBOYRo85OWSKRRKR5v8A5cOCircp9Bpy/kJi O/MnT+5Gf5Eh0xJ535n1TWlbrzskg6WomhjpsWvo= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Mordechay Goodstein , Luca Coelho Subject: [PATCH 5.5 35/46] iwlwifi: consider HE capability when setting LDPC Date: Tue, 7 Apr 2020 12:22:06 +0200 Message-Id: <20200407101503.219777386@linuxfoundation.org> X-Mailer: git-send-email 2.26.0 In-Reply-To: <20200407101459.502593074@linuxfoundation.org> References: <20200407101459.502593074@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: Mordechay Goodstein commit cb377dfda1755b3bc01436755d866c8e5336a762 upstream. The AP may set the LDPC capability only in HE (IEEE80211_HE_PHY_CAP1), but we were checking it only in the HT capabilities. If we don't use this capability when required, the DSP gets the wrong configuration in HE and doesn't work properly. Signed-off-by: Mordechay Goodstein Fixes: befebbb30af0 ("iwlwifi: rs: consider LDPC capability in case of HE") Signed-off-by: Luca Coelho Link: https://lore.kernel.org/r/iwlwifi.20200306151128.492d167c1a25.I1ad1353dbbf6c99ae57814be750f41a1c9f7f4ac@changeid Signed-off-by: Greg Kroah-Hartman --- drivers/net/wireless/intel/iwlwifi/mvm/rs-fw.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) --- a/drivers/net/wireless/intel/iwlwifi/mvm/rs-fw.c +++ b/drivers/net/wireless/intel/iwlwifi/mvm/rs-fw.c @@ -147,7 +147,11 @@ static u16 rs_fw_get_config_flags(struct (vht_ena && (vht_cap->cap & IEEE80211_VHT_CAP_RXLDPC)))) flags |= IWL_TLC_MNG_CFG_FLAGS_LDPC_MSK; - /* consider our LDPC support in case of HE */ + /* consider LDPC support in case of HE */ + if (he_cap->has_he && (he_cap->he_cap_elem.phy_cap_info[1] & + IEEE80211_HE_PHY_CAP1_LDPC_CODING_IN_PAYLOAD)) + flags |= IWL_TLC_MNG_CFG_FLAGS_LDPC_MSK; + if (sband->iftype_data && sband->iftype_data->he_cap.has_he && !(sband->iftype_data->he_cap.he_cap_elem.phy_cap_info[1] & IEEE80211_HE_PHY_CAP1_LDPC_CODING_IN_PAYLOAD)) From patchwork Tue Apr 7 10:22:09 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "gregkh@linuxfoundation.org" X-Patchwork-Id: 228150 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=-6.9 required=3.0 tests=DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI, SIGNED_OFF_BY, SPF_HELO_NONE, SPF_PASS, URIBL_BLOCKED, 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 C342EC2BB54 for ; Tue, 7 Apr 2020 10:28:35 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 97FE020771 for ; Tue, 7 Apr 2020 10:28:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1586255315; bh=o5+VVv/NdrgfdXFjKKdDinBsvD48G4NvcvDVyOKNL5A=; h=From:To:Cc:Subject:Date:In-Reply-To:References:List-ID:From; b=S5lUmCvQ/sPU9HIjyDn7wAww4nN9Kd+x0kvu9nfIH/K1JLeCczIcdkEdoCyFnhyDx tbdkJfXVYIvMj/ETM3f+U9ZOQ20le88vLY/hvc3lU/QLPTZV+M4bUAaOShJf6UEVnS /zIjEajLlOv5cJEogjQn/6EUWfxfS+8bmBO4WGZs= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728212AbgDGK2a (ORCPT ); Tue, 7 Apr 2020 06:28:30 -0400 Received: from mail.kernel.org ([198.145.29.99]:35882 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728919AbgDGKZU (ORCPT ); Tue, 7 Apr 2020 06:25:20 -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 733F82074F; Tue, 7 Apr 2020 10:25:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1586255119; bh=o5+VVv/NdrgfdXFjKKdDinBsvD48G4NvcvDVyOKNL5A=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=XzMI/GELhSra/yZ7N9G2I3Mh0DC8bBKtu4oTvQ1RDjs5+XtnRMfd71rEkQzKVvJyU uWmSJVbs26AgPYW84ZGgMKhIEQeH2Rf01bcN/mdtwEtLvECd2j2RbL15I8/zqRNnXx vzGXpxqUoWVSufYvg75GgVLaHq7UxIxBuvT65910= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, David Howells Subject: [PATCH 5.5 38/46] rxrpc: Fix sendmsg(MSG_WAITALL) handling Date: Tue, 7 Apr 2020 12:22:09 +0200 Message-Id: <20200407101503.512089696@linuxfoundation.org> X-Mailer: git-send-email 2.26.0 In-Reply-To: <20200407101459.502593074@linuxfoundation.org> References: <20200407101459.502593074@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: David Howells commit 498b577660f08cef5d9e78e0ed6dcd4c0939e98c upstream. Fix the handling of sendmsg() with MSG_WAITALL for userspace to round the timeout for when a signal occurs up to at least two jiffies as a 1 jiffy timeout may end up being effectively 0 if jiffies wraps at the wrong time. Fixes: bc5e3a546d55 ("rxrpc: Use MSG_WAITALL to tell sendmsg() to temporarily ignore signals") Signed-off-by: David Howells Signed-off-by: Greg Kroah-Hartman --- net/rxrpc/sendmsg.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) --- a/net/rxrpc/sendmsg.c +++ b/net/rxrpc/sendmsg.c @@ -58,8 +58,8 @@ static int rxrpc_wait_for_tx_window_wait rtt = READ_ONCE(call->peer->rtt); rtt2 = nsecs_to_jiffies64(rtt) * 2; - if (rtt2 < 1) - rtt2 = 1; + if (rtt2 < 2) + rtt2 = 2; timeout = rtt2; tx_start = READ_ONCE(call->tx_hard_ack); From patchwork Tue Apr 7 10:22:11 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "gregkh@linuxfoundation.org" X-Patchwork-Id: 228171 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=-6.9 required=3.0 tests=DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI, SIGNED_OFF_BY, SPF_HELO_NONE, SPF_PASS, URIBL_BLOCKED, 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 68794C2BB55 for ; Tue, 7 Apr 2020 10:25:31 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 317C720644 for ; Tue, 7 Apr 2020 10:25:31 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1586255131; bh=ojqA7GJty1sXsLltzpUdgQpF8D6qRE1HTnadQNXvzSo=; h=From:To:Cc:Subject:Date:In-Reply-To:References:List-ID:From; b=CdjghSOF+dvrdi8jdYWRiozgQX2pF4iOlQP0ZxQxdc5xc5nlmDYPLBNkEyZFnraj1 otBp0WCfzCKOjilD+VbYVRuThZlH0lI+3QlKPx3UdR+kg7yZh1uxgA1DpTGU1gIrfr jQCQxH5uQsjmxQA3BUUXuWO6tpvS1GNVIcuaVop0= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728927AbgDGKZ0 (ORCPT ); Tue, 7 Apr 2020 06:25:26 -0400 Received: from mail.kernel.org ([198.145.29.99]:35978 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728942AbgDGKZZ (ORCPT ); Tue, 7 Apr 2020 06:25:25 -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 5CE5A2074F; Tue, 7 Apr 2020 10:25:24 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1586255124; bh=ojqA7GJty1sXsLltzpUdgQpF8D6qRE1HTnadQNXvzSo=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=fldE7JfG2QJil7Qyh3Ih7CAdaiL0M/TMOJMifiQvPGOUmuqot9aqG/tnyI9fZ/my3 00Bwqoe3qvBbd5Sjx9Kf7wbj/8NHZrK1k0H2nCnkQsTwjTKZ2pmWlMMJXqatx2IHzP N0ZJYNJOSqihfZneSFEE4smi/IOTFqedPGZIO8Xg= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Jiri Pirko , "David S. Miller" Subject: [PATCH 5.5 40/46] sched: act: count in the size of action flags bitfield Date: Tue, 7 Apr 2020 12:22:11 +0200 Message-Id: <20200407101503.698766874@linuxfoundation.org> X-Mailer: git-send-email 2.26.0 In-Reply-To: <20200407101459.502593074@linuxfoundation.org> References: <20200407101459.502593074@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: Jiri Pirko commit 1521a67e6016664941f0917d50cb20053a8826a2 upstream. The put of the flags was added by the commit referenced in fixes tag, however the size of the message was not extended accordingly. Fix this by adding size of the flags bitfield to the message size. Fixes: e38226786022 ("net: sched: update action implementations to support flags") Signed-off-by: Jiri Pirko Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman --- net/sched/act_api.c | 1 + 1 file changed, 1 insertion(+) --- a/net/sched/act_api.c +++ b/net/sched/act_api.c @@ -186,6 +186,7 @@ static size_t tcf_action_shared_attrs_si + nla_total_size(IFNAMSIZ) /* TCA_ACT_KIND */ + cookie_len /* TCA_ACT_COOKIE */ + nla_total_size(0) /* TCA_ACT_STATS nested */ + + nla_total_size(sizeof(struct nla_bitfield32)) /* TCA_ACT_FLAGS */ /* TCA_STATS_BASIC */ + nla_total_size_64bit(sizeof(struct gnet_stats_basic)) /* TCA_STATS_PKT64 */ From patchwork Tue Apr 7 10:22:13 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "gregkh@linuxfoundation.org" X-Patchwork-Id: 228151 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=-6.9 required=3.0 tests=DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI, SIGNED_OFF_BY, SPF_HELO_NONE, SPF_PASS, URIBL_BLOCKED, 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 A3555C2BB85 for ; Tue, 7 Apr 2020 10:28:24 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 7AD9D2078A for ; Tue, 7 Apr 2020 10:28:24 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1586255304; bh=o3tP7Cu4+TLVKKugQELhD56pEd5zccyb22KcNkQy/QE=; h=From:To:Cc:Subject:Date:In-Reply-To:References:List-ID:From; b=2U7qQ1maRfHRRwVp0hokbq1IBcEZ0O8UWGf3bG7/jbTYB6FhRGyqbnXi+GIWvzgn1 47z/TAJcWHKRR5EwugHhuP6RLXk2va01vqHdwSuuXyFznnqKWdXXw8/0CInobhMtYS cgIo/zqvUWNSIEZ09b7qrJTMchJ+hrISeKLYC0jM= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728959AbgDGKZb (ORCPT ); Tue, 7 Apr 2020 06:25:31 -0400 Received: from mail.kernel.org ([198.145.29.99]:36110 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728382AbgDGKZa (ORCPT ); Tue, 7 Apr 2020 06:25: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 44F972078C; Tue, 7 Apr 2020 10:25:29 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1586255129; bh=o3tP7Cu4+TLVKKugQELhD56pEd5zccyb22KcNkQy/QE=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=PBdLnQOo043FAP32tqqVHXOlFhD6fBS4DqcUcdvO6GHgQz4qyt8p+HBZ2jQaixMY7 WkHvRDAZKrr1y+Zs99t2rc8IO3Q3QznBmS9YpM3jgyvzRga/1HFdV30MIIeiD3B7Hw /iS0w6VxSIiyr/T4i2OUJU8uY2BIM0Hj29sxHjo0= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Martin Volf , Mika Westerberg , Guenter Roeck , Wolfram Sang Subject: [PATCH 5.5 42/46] i2c: i801: Do not add ICH_RES_IO_SMI for the iTCO_wdt device Date: Tue, 7 Apr 2020 12:22:13 +0200 Message-Id: <20200407101503.858623897@linuxfoundation.org> X-Mailer: git-send-email 2.26.0 In-Reply-To: <20200407101459.502593074@linuxfoundation.org> References: <20200407101459.502593074@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: Mika Westerberg commit 04bbb97d1b732b2d197f103c5818f5c214a4cf81 upstream. Martin noticed that nct6775 driver does not load properly on his system in v5.4+ kernels. The issue was bisected to commit b84398d6d7f9 ("i2c: i801: Use iTCO version 6 in Cannon Lake PCH and beyond") but it is likely not the culprit because the faulty code has been in the driver already since commit 9424693035a5 ("i2c: i801: Create iTCO device on newer Intel PCHs"). So more likely some commit that added PCI IDs of recent chipsets made the driver to create the iTCO_wdt device on Martins system. The issue was debugged to be PCI configuration access to the PMC device that is not present. This returns all 1's when read and this caused the iTCO_wdt driver to accidentally request resourses used by nct6775. It turns out that the SMI resource is only required for some ancient systems, not the ones supported by this driver. For this reason do not populate the SMI resource at all and drop all the related code. The driver now always populates the main I/O resource and only in case of SPT (Intel Sunrisepoint) compatible devices it adds another resource for the NO_REBOOT bit. These two resources are of different types so platform_get_resource() used by the iTCO_wdt driver continues to find the both resources at index 0. Link: https://lore.kernel.org/linux-hwmon/CAM1AHpQ4196tyD=HhBu-2donSsuogabkfP03v1YF26Q7_BgvgA@mail.gmail.com/ Fixes: 9424693035a5 ("i2c: i801: Create iTCO device on newer Intel PCHs") [wsa: complete fix needs all of http://patchwork.ozlabs.org/project/linux-i2c/list/?series=160959&state=*] Reported-by: Martin Volf Signed-off-by: Mika Westerberg Reviewed-by: Guenter Roeck Signed-off-by: Wolfram Sang Signed-off-by: Greg Kroah-Hartman --- drivers/i2c/busses/i2c-i801.c | 45 +++++++++++------------------------------- 1 file changed, 12 insertions(+), 33 deletions(-) --- a/drivers/i2c/busses/i2c-i801.c +++ b/drivers/i2c/busses/i2c-i801.c @@ -131,11 +131,6 @@ #define TCOBASE 0x050 #define TCOCTL 0x054 -#define ACPIBASE 0x040 -#define ACPIBASE_SMI_OFF 0x030 -#define ACPICTRL 0x044 -#define ACPICTRL_EN 0x080 - #define SBREG_BAR 0x10 #define SBREG_SMBCTRL 0xc6000c #define SBREG_SMBCTRL_DNV 0xcf000c @@ -1550,7 +1545,7 @@ i801_add_tco_spt(struct i801_priv *priv, pci_bus_write_config_byte(pci_dev->bus, devfn, 0xe1, hidden); spin_unlock(&p2sb_spinlock); - res = &tco_res[ICH_RES_MEM_OFF]; + res = &tco_res[1]; if (pci_dev->device == PCI_DEVICE_ID_INTEL_DNV_SMBUS) res->start = (resource_size_t)base64_addr + SBREG_SMBCTRL_DNV; else @@ -1560,7 +1555,7 @@ i801_add_tco_spt(struct i801_priv *priv, res->flags = IORESOURCE_MEM; return platform_device_register_resndata(&pci_dev->dev, "iTCO_wdt", -1, - tco_res, 3, &spt_tco_platform_data, + tco_res, 2, &spt_tco_platform_data, sizeof(spt_tco_platform_data)); } @@ -1573,17 +1568,16 @@ static struct platform_device * i801_add_tco_cnl(struct i801_priv *priv, struct pci_dev *pci_dev, struct resource *tco_res) { - return platform_device_register_resndata(&pci_dev->dev, "iTCO_wdt", -1, - tco_res, 2, &cnl_tco_platform_data, - sizeof(cnl_tco_platform_data)); + return platform_device_register_resndata(&pci_dev->dev, + "iTCO_wdt", -1, tco_res, 1, &cnl_tco_platform_data, + sizeof(cnl_tco_platform_data)); } static void i801_add_tco(struct i801_priv *priv) { - u32 base_addr, tco_base, tco_ctl, ctrl_val; struct pci_dev *pci_dev = priv->pci_dev; - struct resource tco_res[3], *res; - unsigned int devfn; + struct resource tco_res[2], *res; + u32 tco_base, tco_ctl; /* If we have ACPI based watchdog use that instead */ if (acpi_has_watchdog()) @@ -1598,30 +1592,15 @@ static void i801_add_tco(struct i801_pri return; memset(tco_res, 0, sizeof(tco_res)); - - res = &tco_res[ICH_RES_IO_TCO]; - res->start = tco_base & ~1; - res->end = res->start + 32 - 1; - res->flags = IORESOURCE_IO; - /* - * Power Management registers. + * Always populate the main iTCO IO resource here. The second entry + * for NO_REBOOT MMIO is filled by the SPT specific function. */ - devfn = PCI_DEVFN(PCI_SLOT(pci_dev->devfn), 2); - pci_bus_read_config_dword(pci_dev->bus, devfn, ACPIBASE, &base_addr); - - res = &tco_res[ICH_RES_IO_SMI]; - res->start = (base_addr & ~1) + ACPIBASE_SMI_OFF; - res->end = res->start + 3; + res = &tco_res[0]; + res->start = tco_base & ~1; + res->end = res->start + 32 - 1; res->flags = IORESOURCE_IO; - /* - * Enable the ACPI I/O space. - */ - pci_bus_read_config_dword(pci_dev->bus, devfn, ACPICTRL, &ctrl_val); - ctrl_val |= ACPICTRL_EN; - pci_bus_write_config_dword(pci_dev->bus, devfn, ACPICTRL, ctrl_val); - if (priv->features & FEATURE_TCO_CNL) priv->tco_pdev = i801_add_tco_cnl(priv, pci_dev, tco_res); else From patchwork Tue Apr 7 10:22:15 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "gregkh@linuxfoundation.org" X-Patchwork-Id: 228152 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=-6.9 required=3.0 tests=DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI, SIGNED_OFF_BY, SPF_HELO_NONE, SPF_PASS, URIBL_BLOCKED, 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 73569C2BB1D for ; Tue, 7 Apr 2020 10:28:20 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 4AC082074F for ; Tue, 7 Apr 2020 10:28:20 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1586255300; bh=lRTeDg7OxkFH1iwMVZD3ptCWJybciKMTM81I9AHTji4=; h=From:To:Cc:Subject:Date:In-Reply-To:References:List-ID:From; b=poy206XkE0QdVydEWx3V9awvkwEyfKq7C21wHAYbW9LoPQWHWQEDLMITdFaMJ9qPn tJFvim32tPQTUtfQDl1mA0Q6gt0u5xeWMU5b4nIJ4yLufT61uU09JXcmXRE86ElQF8 UWtUo2260tgZkiObHGnX9BgMQmrDFEnWPAZfQgaA= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728979AbgDGKZf (ORCPT ); Tue, 7 Apr 2020 06:25:35 -0400 Received: from mail.kernel.org ([198.145.29.99]:36250 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728974AbgDGKZf (ORCPT ); Tue, 7 Apr 2020 06:25:35 -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 2BB6920644; Tue, 7 Apr 2020 10:25:34 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1586255134; bh=lRTeDg7OxkFH1iwMVZD3ptCWJybciKMTM81I9AHTji4=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=tDeAmzVhJNHaqI2Vkp+V9eM4ZP70NRC0CnzAnCaKf9ojmJrKgcV2hxdpiYd8Yj59J rmPwYc7R710rp3mevyTnM/JWGHs7P7+Yzz1L9pDS+K1/lRrByTM1Y22DI8QdCrgWg1 FqzMkiI5kp7v5xOSA+Mmuy38BQmQe4sfhqhQyGuY= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Amritha Nambiar , Alexander Duyck , Sridhar Samudrala , "David S. Miller" Subject: [PATCH 5.5 44/46] net: Fix Tx hash bound checking Date: Tue, 7 Apr 2020 12:22:15 +0200 Message-Id: <20200407101504.044548547@linuxfoundation.org> X-Mailer: git-send-email 2.26.0 In-Reply-To: <20200407101459.502593074@linuxfoundation.org> References: <20200407101459.502593074@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: Amritha Nambiar commit 6e11d1578fba8d09d03a286740ffcf336d53928c upstream. Fixes the lower and upper bounds when there are multiple TCs and traffic is on the the same TC on the same device. The lower bound is represented by 'qoffset' and the upper limit for hash value is 'qcount + qoffset'. This gives a clean Rx to Tx queue mapping when there are multiple TCs, as the queue indices for upper TCs will be offset by 'qoffset'. v2: Fixed commit description based on comments. Fixes: 1b837d489e06 ("net: Revoke export for __skb_tx_hash, update it to just be static skb_tx_hash") Fixes: eadec877ce9c ("net: Add support for subordinate traffic classes to netdev_pick_tx") Signed-off-by: Amritha Nambiar Reviewed-by: Alexander Duyck Reviewed-by: Sridhar Samudrala Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman --- net/core/dev.c | 2 ++ 1 file changed, 2 insertions(+) --- a/net/core/dev.c +++ b/net/core/dev.c @@ -3026,6 +3026,8 @@ static u16 skb_tx_hash(const struct net_ if (skb_rx_queue_recorded(skb)) { hash = skb_get_rx_queue(skb); + if (hash >= qoffset) + hash -= qoffset; while (unlikely(hash >= qcount)) hash -= qcount; return hash + qoffset; From patchwork Tue Apr 7 10:22:16 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "gregkh@linuxfoundation.org" X-Patchwork-Id: 228170 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=-6.9 required=3.0 tests=DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI, SIGNED_OFF_BY, SPF_HELO_NONE, SPF_PASS, URIBL_BLOCKED, 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 53CF4C2BB55 for ; Tue, 7 Apr 2020 10:25:42 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 1EC162074F for ; Tue, 7 Apr 2020 10:25:42 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1586255142; bh=Wh7+AJAc0sRg46fVl7Ybp0b9uAqplY9N7kq8TJFnsXM=; h=From:To:Cc:Subject:Date:In-Reply-To:References:List-ID:From; b=VD2KHRHpiyYkPvhDXQ17WPJjopqqyEWMDYjWS+R7Ka2ZhmJ1cCmVEsEg3zyLDTBvx EMdEAgb0umoonWBwjFDljJ0H/KQW0KTnmAkfUfnhUmz1ScPpRWgkc5lX794EPgOcJt tG24xiCZbTSXMqHkXNv+nmP2gTvoLB7pFZvp8Ug8= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728994AbgDGKZi (ORCPT ); Tue, 7 Apr 2020 06:25:38 -0400 Received: from mail.kernel.org ([198.145.29.99]:36296 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728992AbgDGKZi (ORCPT ); Tue, 7 Apr 2020 06:25:38 -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 AB5AA20644; Tue, 7 Apr 2020 10:25:36 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1586255137; bh=Wh7+AJAc0sRg46fVl7Ybp0b9uAqplY9N7kq8TJFnsXM=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=aacAbNXJDMifQ1yWwkgoyZ4fjcyzvXsNOhJzm93TDz0gRxTvvyuJ+XTlFS5XqyMAH 53qdDrLQ87POrgl1JmtjYIELAp7nkzV+pYyLvcbRrmZvnPZ9eHnwRCD1LZ0bfbjHEm iBIJ6xCbxN/PFaRvQbZeUpHlHNZPA/mz+u1VQUfA= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Ursula Braun , Karsten Graul , "David S. Miller" Subject: [PATCH 5.5 45/46] net/smc: fix cleanup for linkgroup setup failures Date: Tue, 7 Apr 2020 12:22:16 +0200 Message-Id: <20200407101504.120133480@linuxfoundation.org> X-Mailer: git-send-email 2.26.0 In-Reply-To: <20200407101459.502593074@linuxfoundation.org> References: <20200407101459.502593074@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: Ursula Braun commit 51e3dfa8906ace90c809235b3d3afebc166b6433 upstream. If an SMC connection to a certain peer is setup the first time, a new linkgroup is created. In case of setup failures, such a linkgroup is unusable and should disappear. As a first step the linkgroup is removed from the linkgroup list in smc_lgr_forget(). There are 2 problems: smc_listen_decline() might be called before linkgroup creation resulting in a crash due to calling smc_lgr_forget() with parameter NULL. If a setup failure occurs after linkgroup creation, the connection is never unregistered from the linkgroup, preventing linkgroup freeing. This patch introduces an enhanced smc_lgr_cleanup_early() function which * contains a linkgroup check for early smc_listen_decline() invocations * invokes smc_conn_free() to guarantee unregistering of the connection. * schedules fast linkgroup removal of the unusable linkgroup And the unused function smcd_conn_free() is removed from smc_core.h. Fixes: 3b2dec2603d5b ("net/smc: restructure client and server code in af_smc") Fixes: 2a0674fffb6bc ("net/smc: improve abnormal termination of link groups") Signed-off-by: Ursula Braun Signed-off-by: Karsten Graul Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman --- net/smc/af_smc.c | 25 +++++++++++++++---------- net/smc/smc_core.c | 12 ++++++++++++ net/smc/smc_core.h | 2 +- 3 files changed, 28 insertions(+), 11 deletions(-) --- a/net/smc/af_smc.c +++ b/net/smc/af_smc.c @@ -512,15 +512,18 @@ static int smc_connect_decline_fallback( static int smc_connect_abort(struct smc_sock *smc, int reason_code, int local_contact) { + bool is_smcd = smc->conn.lgr->is_smcd; + if (local_contact == SMC_FIRST_CONTACT) - smc_lgr_forget(smc->conn.lgr); - if (smc->conn.lgr->is_smcd) + smc_lgr_cleanup_early(&smc->conn); + else + smc_conn_free(&smc->conn); + if (is_smcd) /* there is only one lgr role for SMC-D; use server lock */ mutex_unlock(&smc_server_lgr_pending); else mutex_unlock(&smc_client_lgr_pending); - smc_conn_free(&smc->conn); smc->connect_nonblock = 0; return reason_code; } @@ -1091,7 +1094,6 @@ static void smc_listen_out_err(struct sm if (newsmcsk->sk_state == SMC_INIT) sock_put(&new_smc->sk); /* passive closing */ newsmcsk->sk_state = SMC_CLOSED; - smc_conn_free(&new_smc->conn); smc_listen_out(new_smc); } @@ -1102,12 +1104,13 @@ static void smc_listen_decline(struct sm { /* RDMA setup failed, switch back to TCP */ if (local_contact == SMC_FIRST_CONTACT) - smc_lgr_forget(new_smc->conn.lgr); + smc_lgr_cleanup_early(&new_smc->conn); + else + smc_conn_free(&new_smc->conn); if (reason_code < 0) { /* error, no fallback possible */ smc_listen_out_err(new_smc); return; } - smc_conn_free(&new_smc->conn); smc_switch_to_fallback(new_smc); new_smc->fallback_rsn = reason_code; if (reason_code && reason_code != SMC_CLC_DECL_PEERDECL) { @@ -1170,16 +1173,18 @@ static int smc_listen_ism_init(struct sm new_smc->conn.lgr->vlan_id, new_smc->conn.lgr->smcd)) { if (ini->cln_first_contact == SMC_FIRST_CONTACT) - smc_lgr_forget(new_smc->conn.lgr); - smc_conn_free(&new_smc->conn); + smc_lgr_cleanup_early(&new_smc->conn); + else + smc_conn_free(&new_smc->conn); return SMC_CLC_DECL_SMCDNOTALK; } /* Create send and receive buffers */ if (smc_buf_create(new_smc, true)) { if (ini->cln_first_contact == SMC_FIRST_CONTACT) - smc_lgr_forget(new_smc->conn.lgr); - smc_conn_free(&new_smc->conn); + smc_lgr_cleanup_early(&new_smc->conn); + else + smc_conn_free(&new_smc->conn); return SMC_CLC_DECL_MEM; } --- a/net/smc/smc_core.c +++ b/net/smc/smc_core.c @@ -162,6 +162,18 @@ static void smc_lgr_unregister_conn(stru conn->lgr = NULL; } +void smc_lgr_cleanup_early(struct smc_connection *conn) +{ + struct smc_link_group *lgr = conn->lgr; + + if (!lgr) + return; + + smc_conn_free(conn); + smc_lgr_forget(lgr); + smc_lgr_schedule_free_work_fast(lgr); +} + /* Send delete link, either as client to request the initiation * of the DELETE LINK sequence from server; or as server to * initiate the delete processing. See smc_llc_rx_delete_link(). --- a/net/smc/smc_core.h +++ b/net/smc/smc_core.h @@ -296,6 +296,7 @@ struct smc_clc_msg_accept_confirm; struct smc_clc_msg_local; void smc_lgr_forget(struct smc_link_group *lgr); +void smc_lgr_cleanup_early(struct smc_connection *conn); void smc_lgr_terminate(struct smc_link_group *lgr, bool soft); void smc_port_terminate(struct smc_ib_device *smcibdev, u8 ibport); void smc_smcd_terminate(struct smcd_dev *dev, u64 peer_gid, @@ -316,7 +317,6 @@ int smc_vlan_by_tcpsk(struct socket *clc void smc_conn_free(struct smc_connection *conn); int smc_conn_create(struct smc_sock *smc, struct smc_init_info *ini); -void smcd_conn_free(struct smc_connection *conn); void smc_lgr_schedule_free_work_fast(struct smc_link_group *lgr); int smc_core_init(void); void smc_core_exit(void);