From patchwork Mon Mar 29 07:58:33 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "gregkh@linuxfoundation.org" X-Patchwork-Id: 411567 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=-19.0 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_CR_TRAILER, INCLUDES_PATCH, MAILING_LIST_MULTI, SPF_HELO_NONE, SPF_PASS, 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 BB571C433E5 for ; Mon, 29 Mar 2021 08:11:03 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 7A6B36196E for ; Mon, 29 Mar 2021 08:11:03 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232580AbhC2IKi (ORCPT ); Mon, 29 Mar 2021 04:10:38 -0400 Received: from mail.kernel.org ([198.145.29.99]:53328 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231639AbhC2IJd (ORCPT ); Mon, 29 Mar 2021 04:09:33 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id CF4DF6193A; Mon, 29 Mar 2021 08:09:31 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1617005372; bh=1mfDhbWVnnT10YC8N6PuVaoUUT+l8cKZeqfFqV8mvPM=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=ZOC/QGJtbsBhkhX4cjFukYBIH4NnCoXHbSkViSCd4ILbeGDWhW2WQywgySkGMjgDF qUGQoSbZWMw+JKlmq49su4Ma30egEE4i9HlROtLGznOuj1laWkvAOig6jsI5KF+nIX 2jLgCGVqd4MlzC3cug34K7N7aw9XpqIWji8Uhpq8= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Mark Tomlinson , Pablo Neira Ayuso , Sasha Levin Subject: [PATCH 4.19 57/72] netfilter: x_tables: Use correct memory barriers. Date: Mon, 29 Mar 2021 09:58:33 +0200 Message-Id: <20210329075612.161842075@linuxfoundation.org> X-Mailer: git-send-email 2.31.1 In-Reply-To: <20210329075610.300795746@linuxfoundation.org> References: <20210329075610.300795746@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org From: Mark Tomlinson [ Upstream commit 175e476b8cdf2a4de7432583b49c871345e4f8a1 ] When a new table value was assigned, it was followed by a write memory barrier. This ensured that all writes before this point would complete before any writes after this point. However, to determine whether the rules are unused, the sequence counter is read. To ensure that all writes have been done before these reads, a full memory barrier is needed, not just a write memory barrier. The same argument applies when incrementing the counter, before the rules are read. Changing to using smp_mb() instead of smp_wmb() fixes the kernel panic reported in cc00bcaa5899 (which is still present), while still maintaining the same speed of replacing tables. The smb_mb() barriers potentially slow the packet path, however testing has shown no measurable change in performance on a 4-core MIPS64 platform. Fixes: 7f5c6d4f665b ("netfilter: get rid of atomic ops in fast path") Signed-off-by: Mark Tomlinson Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin --- include/linux/netfilter/x_tables.h | 2 +- net/netfilter/x_tables.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/include/linux/netfilter/x_tables.h b/include/linux/netfilter/x_tables.h index 9077b3ebea08..0ade4d1e4dd9 100644 --- a/include/linux/netfilter/x_tables.h +++ b/include/linux/netfilter/x_tables.h @@ -377,7 +377,7 @@ static inline unsigned int xt_write_recseq_begin(void) * since addend is most likely 1 */ __this_cpu_add(xt_recseq.sequence, addend); - smp_wmb(); + smp_mb(); return addend; } diff --git a/net/netfilter/x_tables.c b/net/netfilter/x_tables.c index 8b83806f4f8c..c9fe35118b33 100644 --- a/net/netfilter/x_tables.c +++ b/net/netfilter/x_tables.c @@ -1394,7 +1394,7 @@ xt_replace_table(struct xt_table *table, table->private = newinfo; /* make sure all cpus see new ->private value */ - smp_wmb(); + smp_mb(); /* * Even though table entries have now been swapped, other CPU's