Received: by 2002:a05:6a10:9848:0:0:0:0 with SMTP id x8csp3417082pxf; Mon, 29 Mar 2021 01:25:34 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxV6L/YLr827M6Ywym4zHNLiqy8xuR4+0wu9TxjdHap9x5zErBCym7qOTXievz27Uq5p7v3 X-Received: by 2002:a17:906:2c44:: with SMTP id f4mr26290957ejh.508.1617006334724; Mon, 29 Mar 2021 01:25:34 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1617006334; cv=none; d=google.com; s=arc-20160816; b=eNFoHPpJpIOQleZYmJ6Aa+o0lZhCYomgU9r0OkB4UeO7FwjKVErDhYf9hMOZKYHYax WX1t9AtDSgaQ+x1C2A999pRDYGn+E2UmfaiCuch2ciYrgXvq9ty3UdP9lk9It4UjJ+XW CiyD0WsA9dvQJNe67rHwWs6PN0CB6FsTARHtaHvoiWpchPiKoCLA2+MCRk4dLmVCydQp I9zA3Us0529gI8OI/HNwxUOa0eoz7owRPwn8QTNIRtZeuofJA+UkLqnt9ZqKWz6J0jOF NRzAW/AhsV+lfI5JcM2znxvrZnJMY1nAQxGTte5YXGoJ/8DzTCeqfCkIcJ61DixPf5Xf DNUg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:message-id:date:subject:cc:to :from:dkim-signature; bh=d05dNTFe5dXcNKzj9JEWPucI5vG8FtT/yAGb2BCRNJw=; b=x78sVXqfmmmOlhlHKwCCBMtySVgfDfqKgHBH4hHuqlRN9K+wrmGhMUho8syNn1YTpp 5lyQov5Xtd8nD8In9ukTFFUSAkMRPD+0I6jeSM+/qHN9VRbq+1yHx5TTKmnOTcyPe89B 94EO6lJPU7CdhDUU66FbtK3jW1QlYjj5brAm5SCLX9UO0RQTsazr6ewHSX+vs/tvJLtp IRsOdgpbK+wK+YRKUkY60bYHtKouWnQO4bnvVme0rylYZ+qqvwjBSEOOe6vPp1n6/95Y S82d9DNvH8NqBgOpO3kUSzo3SFkwqKkSiYqVWqFU36VJHopyEuGZyeW8Me+zY4brprjl aPIg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=0AxwziBZ; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id f11si12622292ejw.277.2021.03.29.01.25.12; Mon, 29 Mar 2021 01:25:34 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=0AxwziBZ; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232402AbhC2IYW (ORCPT + 99 others); Mon, 29 Mar 2021 04:24:22 -0400 Received: from mail.kernel.org ([198.145.29.99]:57848 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233046AbhC2IPt (ORCPT ); Mon, 29 Mar 2021 04:15:49 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id D59546196D; Mon, 29 Mar 2021 08:15:26 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1617005727; bh=43SFuyqFDg25OjiCtBvWthzGUpSNIkUtCbK5kUNqPKU=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=0AxwziBZNUNTd8RDABUV3XIGFKno5el/5F+HRbPrcpROmKC/kaI8Gc8s4u0V6Dkis i6PF7BuRNOGhY741AhJ5xXN8JSNdr1FZ5fLKBMkiP9pqhIwMPA7Vgw8v0VO5o1zYMz FHLcNKgXqVhNjOozYMv3muDFEKnGiJUIoHGZRTsk= 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 5.4 095/111] netfilter: x_tables: Use correct memory barriers. Date: Mon, 29 Mar 2021 09:58:43 +0200 Message-Id: <20210329075618.372991371@linuxfoundation.org> X-Mailer: git-send-email 2.31.1 In-Reply-To: <20210329075615.186199980@linuxfoundation.org> References: <20210329075615.186199980@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@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 1b261c51b3a3..04e7f5630509 100644 --- a/include/linux/netfilter/x_tables.h +++ b/include/linux/netfilter/x_tables.h @@ -376,7 +376,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 ef6d51a3798b..5c35d64d1f34 100644 --- a/net/netfilter/x_tables.c +++ b/net/netfilter/x_tables.c @@ -1389,7 +1389,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 -- 2.30.1