Received: by 2002:a05:6a10:206:0:0:0:0 with SMTP id 6csp2674828pxj; Mon, 31 May 2021 08:00:45 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwnTB6lnEJ7hy3lY/SkNrWccKJdGt7OOvjxIf12VDLjgxUNxpyloE2wI3KovbUAmyOZViM/ X-Received: by 2002:a05:6e02:1546:: with SMTP id j6mr18313101ilu.125.1622473245157; Mon, 31 May 2021 08:00:45 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1622473245; cv=none; d=google.com; s=arc-20160816; b=tk5teO+fEM0D8GzkxLE107pqufQIpts4ATKt2JzIdh3Ogx1QV8un/lpKzp1aXxrFAe poXJ9+qePZ/ugCpuEEbKnHPzCnk2wLqaVdcso/WKf4igHxe1iNstFL62SlSowiBtzzdA a6BvZJVhqXd9zVoGRU3a2u/Yp4DUk+vvrxfenlqjQll7wraoczu5rN+yujEpv9GvZSC9 enTDIMZ5ssYHX1cB1J3Fj+76hBqq6INJJ42SorUCnYERuOQmqQ7hUgK/3t2sJPJH+D0v VhRZw62qUXDqkULk6uEEk/MzcC2YFX7QDQlLB2anheZTMdk4Co1jGmDqxfY/7rtUJtUr /IBQ== 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=L4d4xTZYfPyFYEx0PwUEhaor8uZJChLH4aZENAVZVyo=; b=lzxeCJQa3qAFHAQ1q6Y6I6JuDEfmpsKvIohpDdlxnzIJSXyQUKIjBOX7iFP7cQThQD L/9n5lXkmwgldftCwa05dadkWuOJAjAr5P70EGbruxvtgsQ0f1654LkAU5E6V159x0+X SSW7FT0gql82DvEiyQgSPl0WR3rOaV6rw6rRCL6E4c9gNdjtSvTewsu+f39nSwagA/Ts JqsFnOX3QqnTy3b1tvvtYUmrBegl2uIXc2pnWMXafVkiOBKjd00GSQ2vL/YlF9QKKQz1 0TGxFk9/B+jI18k4SFr9Ag7u6NoM0fhHo8jN8m7lKarvG1FgaU66f8Q4mL3GZficBrUx +RHg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=k8MX6Nuh; 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 i14si13925020ilu.19.2021.05.31.08.00.31; Mon, 31 May 2021 08:00:45 -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=k8MX6Nuh; 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 S232163AbhEaPBH (ORCPT + 99 others); Mon, 31 May 2021 11:01:07 -0400 Received: from mail.kernel.org ([198.145.29.99]:39886 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232956AbhEaOG3 (ORCPT ); Mon, 31 May 2021 10:06:29 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id E874A61968; Mon, 31 May 2021 13:38:53 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1622468334; bh=Pk+wRoH3aM90NjcEyh2oeAkB7xg2RvR9VU9bhfGX9BE=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=k8MX6NuhNbnUWKFQ1HPQg7etYXILfo11dN38ZOm2bAixfXtpR0KlfMraHbX0yAjT+ Ce06tBW/gyE1Uwt30EMYQ1iZFfasE+JCHv/cFe5ccLyPbl8Sox79XCxs02/po8ke69 voQvXKfiHTA1b5jIrVKSK8AA2MtGgFRt7ehDpy80= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Tao Liu , Ilya Maximets , "David S. Miller" , Sasha Levin Subject: [PATCH 5.10 205/252] openvswitch: meter: fix race when getting now_ms. Date: Mon, 31 May 2021 15:14:30 +0200 Message-Id: <20210531130704.982387840@linuxfoundation.org> X-Mailer: git-send-email 2.31.1 In-Reply-To: <20210531130657.971257589@linuxfoundation.org> References: <20210531130657.971257589@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: Tao Liu [ Upstream commit e4df1b0c24350a0f00229ff895a91f1072bd850d ] We have observed meters working unexpected if traffic is 3+Gbit/s with multiple connections. now_ms is not pretected by meter->lock, we may get a negative long_delta_ms when another cpu updated meter->used, then: delta_ms = (u32)long_delta_ms; which will be a large value. band->bucket += delta_ms * band->rate; then we get a wrong band->bucket. OpenVswitch userspace datapath has fixed the same issue[1] some time ago, and we port the implementation to kernel datapath. [1] https://patchwork.ozlabs.org/project/openvswitch/patch/20191025114436.9746-1-i.maximets@ovn.org/ Fixes: 96fbc13d7e77 ("openvswitch: Add meter infrastructure") Signed-off-by: Tao Liu Suggested-by: Ilya Maximets Reviewed-by: Ilya Maximets Signed-off-by: David S. Miller Signed-off-by: Sasha Levin --- net/openvswitch/meter.c | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/net/openvswitch/meter.c b/net/openvswitch/meter.c index 8fbefd52af7f..e594b4d6b58a 100644 --- a/net/openvswitch/meter.c +++ b/net/openvswitch/meter.c @@ -611,6 +611,14 @@ bool ovs_meter_execute(struct datapath *dp, struct sk_buff *skb, spin_lock(&meter->lock); long_delta_ms = (now_ms - meter->used); /* ms */ + if (long_delta_ms < 0) { + /* This condition means that we have several threads fighting + * for a meter lock, and the one who received the packets a + * bit later wins. Assuming that all racing threads received + * packets at the same time to avoid overflow. + */ + long_delta_ms = 0; + } /* Make sure delta_ms will not be too large, so that bucket will not * wrap around below. -- 2.30.2