Received: by 2002:a05:6a10:206:0:0:0:0 with SMTP id 6csp2710675pxj; Mon, 31 May 2021 08:49:41 -0700 (PDT) X-Google-Smtp-Source: ABdhPJySPkL8p7ZeslPI4lc+ErKSqw8LaBFsClrkaFIvGSaTAyk10srXZvNpVDWrX8FpsiGkMvSe X-Received: by 2002:a05:6402:34c8:: with SMTP id w8mr26306850edc.243.1622476181499; Mon, 31 May 2021 08:49:41 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1622476181; cv=none; d=google.com; s=arc-20160816; b=Vr20JhdpHSnkTH5ZpTYm3cVUEjiIqBZdv3Ay9gQ+laFVUYjbzQYyKkfJiJGO2ameQQ 72P82MmDFOXW12wDqfgzKFZNw5ji2CRFuAFyjw95llvoDoO+pz4NKSc4X07kz59NFWdg iD/c2iepKMfqa9fcS3ICqQR2gyVyHRWPJEadPJkioyQXwu+H6gnxCGFFP0A9CkiAA7JL bHdrcPFKj8fQejRdj/RAjMjFtSWv8mywtIXkSJ1WNRKAaJTh0aQIem2pvopD1baKgcWk hTkp+FmnetylAalFaoYnTxsD+7oJ5uJ0KdfQw+SZ/tfDBV1F8jMRal5erdNBX6PSK7B8 O2bQ== 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=nv44mQoAXB1cQfue/ViEVWnRirTjmJrIH3atOXDmqqQ=; b=E8qUyKpoTl6G8ooPfH7z+AhynY+UretjNAS2Tep4J0DyVmyOQ09xV1er4r7FFi/uBm RJrHXcTSZU09Z23oWLmsA97bKERV74QJS5jsMUsd4JWTvlMeBnLHASMa+JE/7aJ8ji7J Wcz4qL9qB4KLFxgVY9YnhidPh5itVZibxxxCAEls4pmlzGPXifjJDmIIVbH3Ml8yvCP1 +i6Mk8bBVDs+gQNf4E8FB2s9+k8NUVVAE7/05IBzzAq5LeNFJsQ+yGCYo9DL+dlB3/BY MBzCTfA7VQqFuwcxP+741Ioth7xYIX4+dWDzQMG91oJ4Xf3h5IvEWrgJo7QbB6NAkUtn +vvQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=p7Jwrz9o; 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 au2si13693232ejc.88.2021.05.31.08.49.18; Mon, 31 May 2021 08:49:41 -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=p7Jwrz9o; 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 S231947AbhEaPrf (ORCPT + 99 others); Mon, 31 May 2021 11:47:35 -0400 Received: from mail.kernel.org ([198.145.29.99]:55734 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231859AbhEaO1E (ORCPT ); Mon, 31 May 2021 10:27:04 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id E46CA613AF; Mon, 31 May 2021 13:47:05 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1622468826; bh=G84Ilfjf86aJZc/ARrBpFe4Wleqp3UBU2qrlegj8OwU=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=p7Jwrz9oY411JI7Asn1yJGsv3+xSnIy5f1PcU0igpHO+PKY6MOSrOWYyPoLLlObBM kCrijo0m4wiBFkBBtdpvRE3yRuJGAR7hxhQCFFDFj+nDnq7wCPL+KtXYlvxzChxweC jR+gF+LlEgOy+bDVZlLE0xq0oFGoLcEJ7vC735d4= 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.4 143/177] openvswitch: meter: fix race when getting now_ms. Date: Mon, 31 May 2021 15:15:00 +0200 Message-Id: <20210531130652.877940509@linuxfoundation.org> X-Mailer: git-send-email 2.31.1 In-Reply-To: <20210531130647.887605866@linuxfoundation.org> References: <20210531130647.887605866@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 541eea74ef7a..c37e09223cbb 100644 --- a/net/openvswitch/meter.c +++ b/net/openvswitch/meter.c @@ -460,6 +460,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