Received: by 10.223.176.5 with SMTP id f5csp1138368wra; Fri, 2 Feb 2018 11:53:04 -0800 (PST) X-Google-Smtp-Source: AH8x226sEimguPCp/3Hzy6fKcF/rkfPt7HiOwB4VEi5LY4dX+t8+05P9XkMyKdn20gVwbvualAWg X-Received: by 10.99.102.193 with SMTP id a184mr3512901pgc.141.1517601184486; Fri, 02 Feb 2018 11:53:04 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1517601184; cv=none; d=google.com; s=arc-20160816; b=QDv2RH6WsqfOVLzwuUfXD8Ag4pc0MUaHMG/VwWa+V+1BpU9Gb5GwjUHpOwOfz9fgbX 30Dy9J/v75JT4e28Ndi/wxWOYhSootzLeRTIuh/FSKUaBdUtoV627BJg0xOi2XjttUnG P2Cz9Pznrw22OH5k1xjr649ZR+HOnz8ToydWLnjPJv6UZTLcck9qslFzE3R1+C236A7V T6Hry5EdnoS1KY0wnMhuOLcTv0zTD50hggmMlh1CTV5rNb7Va/gvPLU0d/ygArrbWW4W P1rDk18jdMONUsbDP9lKqxxFhn/joqLBrpVtOyhT/sS2LOEfbXoOpkQwYAyXpB6mgKgE xKSw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:user-agent:references :in-reply-to:message-id:date:subject:cc:to:from :arc-authentication-results; bh=Ou7ftDabgV/Zh+gSfIWqYFk7ozQ5de00s0vDmMm3bvA=; b=pCEToMpKNM9bno/L9feQDElymho8WsuEZuyW54WS/5YL/6sB6HkroQQ4ITrZFKjqYY DJsnfrG/zAAhxvLhnEvBpkzv7IxxbctkP0n7BKFEj+gOGURtMDjKwVqXFg4wZk4rYlT0 69eZ120NrkmdzIaAiWSPekbc0SMEXiT6T2VLZCVcmNCC3I2K5FSkN4xggIcMdwwEfW5E FiX81sloITNXjf+UU9NqeP38PQhz/Ucrn2K3HtXlzYAwtcy+apqbUcszwad5zq/jzGZU cBnkZaX0FLAvEMHBd3IGFhcZybXPO+K8Qx3gKEUCxX0imYgq7kFXFYErinGNJfcrIzHw GM2w== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id s185si28278pgc.308.2018.02.02.11.52.49; Fri, 02 Feb 2018 11:53:04 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754614AbeBBSYD (ORCPT + 99 others); Fri, 2 Feb 2018 13:24:03 -0500 Received: from mail.linuxfoundation.org ([140.211.169.12]:35404 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752638AbeBBRCW (ORCPT ); Fri, 2 Feb 2018 12:02:22 -0500 Received: from localhost (LFbn-1-12258-90.w90-92.abo.wanadoo.fr [90.92.71.90]) by mail.linuxfoundation.org (Postfix) with ESMTPSA id 44269E5E; Fri, 2 Feb 2018 17:02:21 +0000 (UTC) From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, zhangliping , Pravin B Shelar , "David S. Miller" , Sasha Levin Subject: [PATCH 4.4 33/67] openvswitch: fix the incorrect flow action alloc size Date: Fri, 2 Feb 2018 17:58:02 +0100 Message-Id: <20180202140819.318783523@linuxfoundation.org> X-Mailer: git-send-email 2.16.1 In-Reply-To: <20180202140815.091718203@linuxfoundation.org> References: <20180202140815.091718203@linuxfoundation.org> User-Agent: quilt/0.65 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 4.4-stable review patch. If anyone has any objections, please let me know. ------------------ From: zhangliping [ Upstream commit 67c8d22a73128ff910e2287567132530abcf5b71 ] If we want to add a datapath flow, which has more than 500 vxlan outputs' action, we will get the following error reports: openvswitch: netlink: Flow action size 32832 bytes exceeds max openvswitch: netlink: Flow action size 32832 bytes exceeds max openvswitch: netlink: Actions may not be safe on all matching packets ... ... It seems that we can simply enlarge the MAX_ACTIONS_BUFSIZE to fix it, but this is not the root cause. For example, for a vxlan output action, we need about 60 bytes for the nlattr, but after it is converted to the flow action, it only occupies 24 bytes. This means that we can still support more than 1000 vxlan output actions for a single datapath flow under the the current 32k max limitation. So even if the nla_len(attr) is larger than MAX_ACTIONS_BUFSIZE, we shouldn't report EINVAL and keep it move on, as the judgement can be done by the reserve_sfa_size. Signed-off-by: zhangliping Acked-by: Pravin B Shelar Signed-off-by: David S. Miller Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman --- net/openvswitch/flow_netlink.c | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) --- a/net/openvswitch/flow_netlink.c +++ b/net/openvswitch/flow_netlink.c @@ -1672,14 +1672,11 @@ int ovs_nla_put_mask(const struct sw_flo #define MAX_ACTIONS_BUFSIZE (32 * 1024) -static struct sw_flow_actions *nla_alloc_flow_actions(int size, bool log) +static struct sw_flow_actions *nla_alloc_flow_actions(int size) { struct sw_flow_actions *sfa; - if (size > MAX_ACTIONS_BUFSIZE) { - OVS_NLERR(log, "Flow action size %u bytes exceeds max", size); - return ERR_PTR(-EINVAL); - } + WARN_ON_ONCE(size > MAX_ACTIONS_BUFSIZE); sfa = kmalloc(sizeof(*sfa) + size, GFP_KERNEL); if (!sfa) @@ -1752,12 +1749,15 @@ static struct nlattr *reserve_sfa_size(s new_acts_size = ksize(*sfa) * 2; if (new_acts_size > MAX_ACTIONS_BUFSIZE) { - if ((MAX_ACTIONS_BUFSIZE - next_offset) < req_size) + if ((MAX_ACTIONS_BUFSIZE - next_offset) < req_size) { + OVS_NLERR(log, "Flow action size exceeds max %u", + MAX_ACTIONS_BUFSIZE); return ERR_PTR(-EMSGSIZE); + } new_acts_size = MAX_ACTIONS_BUFSIZE; } - acts = nla_alloc_flow_actions(new_acts_size, log); + acts = nla_alloc_flow_actions(new_acts_size); if (IS_ERR(acts)) return (void *)acts; @@ -2369,7 +2369,7 @@ int ovs_nla_copy_actions(struct net *net { int err; - *sfa = nla_alloc_flow_actions(nla_len(attr), log); + *sfa = nla_alloc_flow_actions(min(nla_len(attr), MAX_ACTIONS_BUFSIZE)); if (IS_ERR(*sfa)) return PTR_ERR(*sfa);