From patchwork Thu Apr 30 19:38:45 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Ido Schimmel X-Patchwork-Id: 1280866 X-Patchwork-Delegate: davem@davemloft.net Return-Path: X-Original-To: patchwork-incoming-netdev@ozlabs.org Delivered-To: patchwork-incoming-netdev@ozlabs.org Authentication-Results: ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=vger.kernel.org (client-ip=23.128.96.18; helo=vger.kernel.org; envelope-from=netdev-owner@vger.kernel.org; receiver=) Authentication-Results: ozlabs.org; dmarc=none (p=none dis=none) header.from=idosch.org Authentication-Results: ozlabs.org; dkim=pass (2048-bit key; unprotected) header.d=messagingengine.com header.i=@messagingengine.com header.a=rsa-sha256 header.s=fm2 header.b=v99v1/6s; dkim-atps=neutral Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by ozlabs.org (Postfix) with ESMTP id 49Cm0n3S73z9sRf for ; Fri, 1 May 2020 05:39:21 +1000 (AEST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726814AbgD3TjU (ORCPT ); Thu, 30 Apr 2020 15:39:20 -0400 Received: from out3-smtp.messagingengine.com ([66.111.4.27]:34873 "EHLO out3-smtp.messagingengine.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726318AbgD3TjU (ORCPT ); Thu, 30 Apr 2020 15:39:20 -0400 Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 0E4A25C00A6; Thu, 30 Apr 2020 15:39:19 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Thu, 30 Apr 2020 15:39:19 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:date:from :message-id:mime-version:subject:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=8Ws9ps3lVg7IhWMNT naQ/4aJYXRu9Os3jYNOpTZ6jvA=; b=v99v1/6soCGfESBw9ZMkohNduywqGF+F6 ckTokBbPqazQ/k3wQjp2vnp1jEZr4m91K3UfXV3S4rR/u+fJNDTiW1iq4KxBvv3X bKKZhrZfLxnNq+Sj0S++HH6YrUgfE3l/Zbb8hAPFoIm04R6hNykmMnOp7WNGzlU5 XXbaW5QCYH0NGuFrBtj6PKS9Pm5gG9czOlgYZ/NTgLEqG7wdtr6ziupTb+VdbDzM whemRMhBXLdPmItICFUesqxIldjOhxLzqmbn/aUO2nWBIZChJd1icoVH8hUKe1ME HqKevSt3LbWSYLjyHm0twnECLH1y3irIBA3tu0L+zSBoK3O5LOpoQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrieehgddufeekucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefhvffufffkofgggfestdekredtre dttdenucfhrhhomhepkfguohcuufgthhhimhhmvghluceoihguohhstghhsehiughoshgt hhdrohhrgheqnecuggftrfgrthhtvghrnhepteevgefhvefggfffkeeuffeuvdfhueehhe etffeikeegheevfedvgeelvdffudfhnecukfhppeejledrudektddrheegrdduudeinecu vehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepihguohhstg hhsehiughoshgthhdrohhrgh X-ME-Proxy: Received: from splinter.mtl.com (bzq-79-180-54-116.red.bezeqint.net [79.180.54.116]) by mail.messagingengine.com (Postfix) with ESMTPA id E299F3065F40; Thu, 30 Apr 2020 15:39:16 -0400 (EDT) From: Ido Schimmel To: netdev@vger.kernel.org, bridge@lists.linux-foundation.org Cc: davem@davemloft.net, kuba@kernel.org, nikolay@cumulusnetworks.com, roopa@cumulusnetworks.com, s.priebe@profihost.ag, mlxsw@mellanox.com, Ido Schimmel Subject: [PATCH net] net: bridge: vlan: Add a schedule point during VLAN processing Date: Thu, 30 Apr 2020 22:38:45 +0300 Message-Id: <20200430193845.4087868-1-idosch@idosch.org> X-Mailer: git-send-email 2.24.1 MIME-Version: 1.0 Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org From: Ido Schimmel User space can request to delete a range of VLANs from a bridge slave in one netlink request. For each deleted VLAN the FDB needs to be traversed in order to flush all the affected entries. If a large range of VLANs is deleted and the number of FDB entries is large or the FDB lock is contented, it is possible for the kernel to loop through the deleted VLANs for a long time. In case preemption is disabled, this can result in a soft lockup. Fix this by adding a schedule point after each VLAN is deleted to yield the CPU, if needed. This is safe because the VLANs are traversed in process context. Fixes: bdced7ef7838 ("bridge: support for multiple vlans and vlan ranges in setlink and dellink requests") Signed-off-by: Ido Schimmel Reported-by: Stefan Priebe - Profihost AG Tested-by: Stefan Priebe - Profihost AG Acked-by: Nikolay Aleksandrov --- net/bridge/br_netlink.c | 1 + 1 file changed, 1 insertion(+) diff --git a/net/bridge/br_netlink.c b/net/bridge/br_netlink.c index 43dab4066f91..a0f5dbee8f9c 100644 --- a/net/bridge/br_netlink.c +++ b/net/bridge/br_netlink.c @@ -612,6 +612,7 @@ int br_process_vlan_info(struct net_bridge *br, v - 1, rtm_cmd); v_change_start = 0; } + cond_resched(); } /* v_change_start is set only if the last/whole range changed */ if (v_change_start)