Received: by 2002:a25:8b91:0:0:0:0:0 with SMTP id j17csp2795515ybl; Sun, 26 Jan 2020 10:57:54 -0800 (PST) X-Google-Smtp-Source: APXvYqylPUVVtW7+Z0ahk3ji3MH+PNSl53vsRq2LFu5h2YsCfy6si+DbclpuqfnZMejr4EFquVj0 X-Received: by 2002:aca:7244:: with SMTP id p65mr5218119oic.50.1580065074060; Sun, 26 Jan 2020 10:57:54 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1580065074; cv=none; d=google.com; s=arc-20160816; b=cM1eVBymsPdd//3HbinKOFe3fr5/AM2U5MABZI1GlE2xvDUrVz+qE9VdbzGmHTdp8h fnkA1aZbYenmlGAy9MqleB/I6AC5dG4agaxBlooL4R6cz8rnIxrww/pRsZvPQ25ZP2bF 8EceFUVx8Wb20lQSfetW3I/3Yv3Ri0TjuUCT2c8eM2RFxIXnPzlNbxA7cAtUPNi7kBn7 qAIuALqWIg8xQb5r1hgRbyPt3mA+tA7GMOTOadZKLwY8TnJz8vR9LRfiOt5AFFaf5S0N 7wYszhj5B81tV7CHjDNE37r7bLODGHSzPYS3fc6MfR6btOKTlY2zCRenkmcavI/YxUnb ftig== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=JTaJncikpGRQdGkyWQve1nNTmy33iSWZeJTc9cftw9s=; b=CBwQ9BXskcl5UXDqYK1ajEENGqbdyf6uR/0/x6mqz0eaQvEpVcT5pxxUG1oDuCMgN4 EtCLOP1aHJIpJVF10IVtS22HHTqAQwYdzIFlUyMd8cDzzIQKX7JZuiRLJpwmFiw0Ftss /4EVaLB2ETY0KyhccLz034E4R9MABPVASpG61wxhZ7VEOJ3SEyy2HxfrLkMu/sMV9cdk wnQggJYaKjyqROhLHRu8rzF/W5gxXTVdsTq4nR1sQx7ZO4DLomdge95FTa/Z36ofqguE Hoa5gQFKjD0ZKUOk8fh2HvgDhIZ0d0bTmyx4x55SZfP20mjPFblTlfFLedOsAkSixcgA 9ZPQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id z1si6070575otq.21.2020.01.26.10.57.30; Sun, 26 Jan 2020 10:57:54 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728668AbgAZS3b (ORCPT + 99 others); Sun, 26 Jan 2020 13:29:31 -0500 Received: from jabberwock.ucw.cz ([46.255.230.98]:49498 "EHLO jabberwock.ucw.cz" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726657AbgAZS3b (ORCPT ); Sun, 26 Jan 2020 13:29:31 -0500 Received: by jabberwock.ucw.cz (Postfix, from userid 1017) id 309901C013C; Sun, 26 Jan 2020 19:29:29 +0100 (CET) Date: Sun, 26 Jan 2020 19:29:18 +0100 From: Pavel Machek To: Greg Kroah-Hartman Cc: linux-kernel@vger.kernel.org, stable@vger.kernel.org, Eric Dumazet , Willem de Bruijn , "David S. Miller" , Sasha Levin Subject: Re: [PATCH 4.19 625/639] packet: fix data-race in fanout_flow_is_huge() Message-ID: <20200126182917.GA26911@amd> References: <20200124093047.008739095@linuxfoundation.org> <20200124093207.912523612@linuxfoundation.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="17pEHd4RhPHOinZp" Content-Disposition: inline In-Reply-To: <20200124093207.912523612@linuxfoundation.org> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --17pEHd4RhPHOinZp Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi! > From: Eric Dumazet >=20 > [ Upstream commit b756ad928d98e5ef0b74af7546a6a31a8dadde00 ] >=20 > KCSAN reported the following data-race [1] >=20 > Adding a couple of READ_ONCE()/WRITE_ONCE() should silence it. >=20 > Since the report hinted about multiple cpus using the history > concurrently, I added a test avoiding writing on it if the > victim slot already contains the desired value. > static bool fanout_flow_is_huge(struct packet_sock *po, struct sk_buff *= skb) > { > - u32 rxhash; > + u32 *history =3D po->rollover->history; > + u32 victim, rxhash; > int i, count =3D 0; > =20 > rxhash =3D skb_get_hash(skb); > for (i =3D 0; i < ROLLOVER_HLEN; i++) > - if (po->rollover->history[i] =3D=3D rxhash) > + if (READ_ONCE(history[i]) =3D=3D rxhash) > count++; > =20 > - po->rollover->history[prandom_u32() % ROLLOVER_HLEN] =3D rxhash; > + victim =3D prandom_u32() % ROLLOVER_HLEN; > + > + /* Avoid dirtying the cache line if possible */ > + if (READ_ONCE(history[victim]) !=3D rxhash) > + WRITE_ONCE(history[victim], rxhash); > + Replacing simple asignment with if() is ... not nice and with all the "volatile" magic in _ONCE macros may not be win for everyone. [Actually, I don't think this is win here. This is not exactly hot path, is it? Is it likely that array aready contains required value?] If this is going to get more common, should we get WRITE_ONCE_NONDIRTY() macro hiding the uglyness? Best regards, Pavel --=20 (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blo= g.html --17pEHd4RhPHOinZp Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAl4t2n0ACgkQMOfwapXb+vKWZACfXGUxeWdbOxPidKjzXNS5xqcf llUAmwZqpQqfdyEY953YC5qnZziTVQa/ =ckpY -----END PGP SIGNATURE----- --17pEHd4RhPHOinZp--