Received: by 2002:a05:6a10:206:0:0:0:0 with SMTP id 6csp2626579pxj; Mon, 31 May 2021 06:53:43 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwk4yFL04biPf6V2KCFbEzso2HNvzoEd0yjoYgCTquA1Y7eF7/OOtdtZvL/+x29vRE0faw1 X-Received: by 2002:a6b:e70e:: with SMTP id b14mr1426571ioh.65.1622469223718; Mon, 31 May 2021 06:53:43 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1622469223; cv=none; d=google.com; s=arc-20160816; b=KCyL76Qj2xHdIODG16Q/gkqsklis1rtp8iMPBiLIKEpzmMFoOzUtrY5wr89Sybdpab Q/LwhBuJd1eB+7qO2T99Tujm10+dhRrWWAZ5aBdmGBBTnc96U0YUmRGuLs4RAt00UkgJ WGd3Rbaj2ASnjjeXqF37be55p3zG8AkWYX38T8laREkmmWhopXXC3tG5nGN//tXc1TXs Lz5Pm0sero+BCrN/91AfGIFQpMFknhAoUHQX+wXn+Qw4mrexpCuFi3SC8TQlLFwpznY2 +9gNIBFDDZ/4RPXIe9Pc46m0py249ipm0Y/N933VqKsaChCEm58RG7muIcU0DNcD3/PE ON6g== 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=1rNm76owaumfcWmEU09UYYTKaZpzGJPr3UH5JhCuFJM=; b=B47ezH/zTdlNETIU8f6her3c6t2q6cuPUFqPkN9UI2U/iLExrzr0k18Dv155F2m9kB C5Tdg/slLZ7n6e4BU5gEd+fWkKFz5Y/y9U3TYDFcRWtWbmjO0JQkE7XyO8uqZWV5vRJ0 mmxHAH+0Lks+FKUZpgwDl07xHbLOuyklbxR7UNDIXiLN7R+tGpS8bymMO/DmIu167doi Hq+pvBkzq3GcDzLILP3h0f14l6NpYzhxgkZpO2fDCS7caqxv8OkrFK9mo4t3hJ2lxWg7 uuUHVQ/WKclq6kDbx8voGBXxCNHuSBMN48NNm8BGx9XXylQC7i94PhLH+j4VkS56fjcJ 2HJw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=oDUy0pmc; 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 h21si14018986jav.99.2021.05.31.06.53.29; Mon, 31 May 2021 06:53:43 -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=oDUy0pmc; 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 S232866AbhEaNx5 (ORCPT + 99 others); Mon, 31 May 2021 09:53:57 -0400 Received: from mail.kernel.org ([198.145.29.99]:39376 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232105AbhEaNfs (ORCPT ); Mon, 31 May 2021 09:35:48 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id 89D736144C; Mon, 31 May 2021 13:25:36 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1622467537; bh=VliTm5Omfb1FQ1MFvq7AlbAecyXYQOrR6hstGepmpu0=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=oDUy0pmcBnBRyfgHKXVEd0MQs4K9hsICPc7gNPbvW7I0U5reavRtlPgkM9KvP4m95 YEaDGf0rVsmpzhJ0oos/tNCEteLfHNonwV675OBlynidR4ms0hzVuGl0XAT7ufzWLG BnYaM4DSFQOjaXJUy/w3uqJUFZ7s5t7Ld+o+7nGU= 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 4.19 101/116] openvswitch: meter: fix race when getting now_ms. Date: Mon, 31 May 2021 15:14:37 +0200 Message-Id: <20210531130643.553968554@linuxfoundation.org> X-Mailer: git-send-email 2.31.1 In-Reply-To: <20210531130640.131924542@linuxfoundation.org> References: <20210531130640.131924542@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 5ea2471ffc03..9b0c54f0702c 100644 --- a/net/openvswitch/meter.c +++ b/net/openvswitch/meter.c @@ -464,6 +464,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