From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.7 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id F3AB0FA3728 for ; Wed, 16 Oct 2019 15:35:35 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id D6CCE20854 for ; Wed, 16 Oct 2019 15:35:35 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2405084AbfJPPfe (ORCPT ); Wed, 16 Oct 2019 11:35:34 -0400 Received: from mx2a.mailbox.org ([80.241.60.219]:16483 "EHLO mx2a.mailbox.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2405055AbfJPPfe (ORCPT ); Wed, 16 Oct 2019 11:35:34 -0400 Received: from smtp1.mailbox.org (smtp1.mailbox.org [80.241.60.240]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) by mx2a.mailbox.org (Postfix) with ESMTPS id 1ED8AA1149; Wed, 16 Oct 2019 17:35:32 +0200 (CEST) X-Virus-Scanned: amavisd-new at heinlein-support.de Received: from smtp1.mailbox.org ([80.241.60.240]) by spamfilter01.heinlein-hosting.de (spamfilter01.heinlein-hosting.de [80.241.56.115]) (amavisd-new, port 10030) with ESMTP id 9R7HIXzq1RpU; Wed, 16 Oct 2019 17:35:28 +0200 (CEST) Date: Thu, 17 Oct 2019 02:35:20 +1100 From: Aleksa Sarai To: Tejun Heo Cc: Li Zefan , Johannes Weiner , cgroups@vger.kernel.org, linux-kernel@vger.kernel.org, stable@vger.kernel.org Subject: Re: [PATCH] cgroup: pids: use {READ,WRITE}_ONCE for pids->limit operations Message-ID: <20191016153520.zet5mn5xsygig4xc@yavin.dot.cyphar.com> References: <20191012010539.6131-1-cyphar@cyphar.com> <20191014154136.GF18794@devbig004.ftw2.facebook.com> <20191014155931.jl7idjebhqxb3ck3@yavin.dot.cyphar.com> <20191014163307.GG18794@devbig004.ftw2.facebook.com> <20191016083218.ttsaqnxpjh5i5bgv@yavin.dot.cyphar.com> <20191016142756.GN18794@devbig004.ftw2.facebook.com> <20191016152946.34j5x45ko5auhv3g@yavin.dot.cyphar.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="gae43k7kt3kmufic" Content-Disposition: inline In-Reply-To: <20191016152946.34j5x45ko5auhv3g@yavin.dot.cyphar.com> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --gae43k7kt3kmufic Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2019-10-17, Aleksa Sarai wrote: > On 2019-10-16, Tejun Heo wrote: > > Hello, Aleksa. > >=20 > > On Wed, Oct 16, 2019 at 07:32:19PM +1100, Aleksa Sarai wrote: > > > Maybe I'm misunderstanding Documentation/atomic_t.txt, but it looks to > > > me like it's explicitly saying that I shouldn't use atomic64_t if I'm > > > just using it for fetching and assignment. > >=20 > > Hah, where is it saying that? >=20 > Isn't that what this says: >=20 > > Therefore, if you find yourself only using the Non-RMW operations of > > atomic_t, you do not in fact need atomic_t at all and are doing it > > wrong. >=20 > Doesn't using just atomic64_read() and atomic64_set() fall under "only > using the non-RMW operations of atomic_t"? But yes, I agree that any > locking is overkill. >=20 > > > As for 64-bit on 32-bit machines -- that is a separate issue, but from > > > [1] it seems to me like there are more problems that *_ONCE() fixes t= han > > > just split reads and writes. > >=20 > > Your explanations are too wishy washy. If you wanna fix it, please do > > it correctly. R/W ONCE isn't the right solution here. >=20 > Sure, I will switch it to use atomic64_read() and atomic64_set() instead > if that's what you'd prefer. Though I will mention that on quite a few > architectures atomic64_read() is defined as: >=20 > #define atomic64_read(v) READ_ONCE((v)->counter) Though I guess that's because on those architectures it turns out that READ_ONCE is properly atomic? --=20 Aleksa Sarai Senior Software Engineer (Containers) SUSE Linux GmbH --gae43k7kt3kmufic Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEABYIAB0WIQSxZm6dtfE8gxLLfYqdlLljIbnQEgUCXac4XgAKCRCdlLljIbnQ EqfmAQCvvl9RoS0Za1ejIafzulKxMufJWahNQcrCVULRur+MvwEA+lhgaq8rJ/Qb 48BFtp02gSX3aYFTdGOSILPOV6Op+Ak= =c8Qz -----END PGP SIGNATURE----- --gae43k7kt3kmufic--