From patchwork Wed Dec 23 21:23:19 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Antoine Tenart X-Patchwork-Id: 352236 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=-14.0 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, INCLUDES_PATCH, MAILING_LIST_MULTI, SPF_HELO_NONE, SPF_PASS, 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 BDD9DC433E0 for ; Wed, 23 Dec 2020 21:24:07 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 907AE22273 for ; Wed, 23 Dec 2020 21:24:07 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729054AbgLWVYG (ORCPT ); Wed, 23 Dec 2020 16:24:06 -0500 Received: from mail.kernel.org ([198.145.29.99]:50936 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727147AbgLWVYG (ORCPT ); Wed, 23 Dec 2020 16:24:06 -0500 Received: by mail.kernel.org (Postfix) with ESMTPSA id 8BB5B22273; Wed, 23 Dec 2020 21:23:25 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1608758606; bh=Byb4fjHHlydql2g8PI51aKxdzGmYBaZL8YcYQ25sw7U=; h=From:To:Cc:Subject:Date:From; b=K7z1359uO7p0AStNOI1MRhtU/Hj2e7xMxUvnkFjyf/RFUUkDq09C+Dizt5skFTDPM 8J5Qwk4Jkes4ceA9Wbu5bj1xntU75SRMq+Uc49aOpYZZebQ+yyIGwIYNXrynJMcX/v wbYato8F4SwTmGd0OZ/mDehzpf+aFmNwPt/K/802OgZidOvPHHJH0kUeeT50GJ3tSp labSaOOMe2lH2rkcHLBNm9H//+TF5pGwzB2eMGyY/wXzPPnt5NNJP9JKT7ih+EBywh L/5+7vXAb2BmxR7nztRHoH9MLCZuezhjMZFm47Y4Q6RSEHPl8SeHEEpbrTOfDLJwOx LvonziJ9DXU1w== From: Antoine Tenart To: davem@davemloft.net, kuba@kernel.org, alexander.duyck@gmail.com Cc: Antoine Tenart , netdev@vger.kernel.org, pabeni@redhat.com Subject: [PATCH net v3 0/4] net-sysfs: fix race conditions in the xps code Date: Wed, 23 Dec 2020 22:23:19 +0100 Message-Id: <20201223212323.3603139-1-atenart@kernel.org> X-Mailer: git-send-email 2.29.2 MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org Hello all, This series fixes race conditions in the xps code, where out of bound accesses can occur when dev->num_tc is updated, triggering oops. The root cause is linked to locking issues. An explanation is given in each of the commit logs. We had a discussion on the v1 of this series about using the xps_map mutex instead of the rtnl lock. While that seemed a better compromise, v2 showed the added complexity wasn't best for fixes. So we decided to go back to v1 and use the rtnl lock. Because of this, the only differences between v1 and v3 are improvements in the commit messages. Thanks! Antoine Antoine Tenart (4): net-sysfs: take the rtnl lock when storing xps_cpus net-sysfs: take the rtnl lock when accessing xps_cpus_map and num_tc net-sysfs: take the rtnl lock when storing xps_rxqs net-sysfs: take the rtnl lock when accessing xps_rxqs_map and num_tc net/core/net-sysfs.c | 65 ++++++++++++++++++++++++++++++++++++-------- 1 file changed, 53 insertions(+), 12 deletions(-)