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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 5E47AC61DA3 for ; Tue, 21 Feb 2023 18:18:12 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id D3D6E6B0073; Tue, 21 Feb 2023 13:18:11 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id CED1F6B0074; Tue, 21 Feb 2023 13:18:11 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id BB5586B0078; Tue, 21 Feb 2023 13:18:11 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id A9C826B0073 for ; Tue, 21 Feb 2023 13:18:11 -0500 (EST) Received: from smtpin21.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 76BE340749 for ; Tue, 21 Feb 2023 18:18:11 +0000 (UTC) X-FDA: 80492108382.21.C56634B Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf06.hostedemail.com (Postfix) with ESMTP id 88D3618000F for ; Tue, 21 Feb 2023 18:18:09 +0000 (UTC) Authentication-Results: imf06.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b="aTHEWPY/"; spf=none (imf06.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1677003489; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=tTqyemmz1pSv74LR4HajXP0tRM9VnFXvQ4hZwbauJIY=; b=T4/ViqdeBs7OqfZB3N+p96LXDxWjoVbjwwmB8kCzFqbVyN4gFcJoxy5szwY3YTlpUpvfaQ 3rtQwwHJ3L09/K3rwfTJO7Pk06aAoXdQdLjxW4XvAjD2nm/MyX9RomOVOS/0Ebq3UrlOlR OJjdyhLTmW7zQVTrkqVWH3LoOK0JbFw= ARC-Authentication-Results: i=1; imf06.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b="aTHEWPY/"; spf=none (imf06.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1677003489; a=rsa-sha256; cv=none; b=wtKyfVc8LKwoLYG1U6f6Ou2aJpYLQFPgW3sbZSsB/BA81Q+Fyv7ZwgowuAthrHB/9+QdWX MzpGifV0bFoEBGQUqpEV8YPCZtRZur4mhssQy3lUUOvzRXnbIZrscdFGxWIIejmYu5murn w43BukH/FuYXL7CRUwTsfCaryWEEYDU= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=tTqyemmz1pSv74LR4HajXP0tRM9VnFXvQ4hZwbauJIY=; b=aTHEWPY/BN+r5noMxZCmo9iSA1 Z9IeoyW/C1dX8qm5tPsU2u5j+AQ/AEhI+yMzMaNWzFE1cwZXzPuTpDM2a3cpTh+rJ9tg53kLukUWa 1Raq91MM6pgzQ18B3/7w2dnnQ/4vw7VRe3x3ALCx09tzgnM7YKGmSNjPqvYGrmmRZDG+B2EfthaKX fNj/RnFy+ub0fsZpl6t42kQ5htBwnbD8RQiyCn5tLpfTkOa9cTy6ZTVDCx8QIeUx/6Xdl6chkrflk F0Ixpvhu+kwgmwoFV6hu+MTaFi1VQjGIUecpBZdG5kpmzPyzvWpcSpPfnK9smVbeMgkCEVcxswtPw zEfhVeDw==; Received: from willy by casper.infradead.org with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1pUXDH-00CoXT-Io; Tue, 21 Feb 2023 18:18:04 +0000 Date: Tue, 21 Feb 2023 18:18:03 +0000 From: Matthew Wilcox To: Roman Gushchin Cc: Shakeel Butt , Yue Zhao , linux-mm@kvack.org, akpm@linux-foundation.org, hannes@cmpxchg.org, mhocko@kernel.org, muchun.song@linux.dev, cgroups@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] mm: change memcg->oom_group access with atomic operations Message-ID: References: <20230220230624.lkobqeagycx7bi7p@google.com> <6563189C-7765-4FFA-A8F2-A5CC4860A1EF@linux.dev> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: 88D3618000F X-Rspam-User: X-Stat-Signature: a6yw89yq9u61zdo6ur1et88k488xwixc X-HE-Tag: 1677003489-567775 X-HE-Meta: U2FsdGVkX18LPkPFZATwN680vIL9kqA5rhnJVZTjDKvlPyr4NjY9oGVF+ZGJ5981ZzQb4bvGgpuLft8SaTdR/NfUt93p96EVAAjF6eA6PGC3BdVGuoh38Nre6gg0s0nHoZsQKhYPxuTtDIYvEOSGrzceZWRovaPWgfSkhvo9P4I+f031aGO74cn6qeVvD1uwpZZwzNjz4cuBjBtuG1lhfzn3G9wVhVQ6UVYkHvdD1toVhPgsCQ8yjTBPXPySaSf0BBevxFBNYVv9Mvtvc5HxOl0+w5CdZGB7KpIH4on8lRbiOLJryu+0vvfQa4h3coI1mHd58aZoWBT9g71uwyvp0w4Hpya6+HWMIRLldsOFOxDOUjnS3ZrUs/207vieJJ8O+Og0dTcczYjvY7YdW507mI/FtInWKCTAy/yQYzzzD337kKmbDZYvO7BIXztFb+sDO+vYOK2+GB+RFK5xO0ZPVf6ujJ1RfrRRwtlB9wjsSIeSbFXwNUxnxYLKjQlKhPBEik1rCDofyPgX0XS7EIPOzhCsMdW9Zkh7ayog1ILTiLY2EM4nm0QE5l8DfXy5XnmBugeaZfMSuDowe8dJk2tU+kUPZ8Iqq9Ybwerkwp7sPHkSRxXgogVYWgo7ukSjMg+yCO5u49A02BbWkXPQKq07Fd+IDP/14h6P2rEPtecJL9QbeoIuE4bJOKdR7CvpxQpAJox7jh1tGXU0FHbDSr+O5/XLPb/o91sqRXGa1Qu9gQez96YFqowQO18cNQjqUdjTt8diVHCU1RrNr5D8oIFeKFEO0X4UvtzXJZQ8HNK5+xQQgXTrkUfHg0WI8tEsbdIz79EyrAbtU66Sh1+POI24qcdU86IlXYS0JIbf3+fLdoeoueDsuDIPgEpB9txow1VoCE3i8Lu++FcjwIt/DngImULKia7pE5WwmU1H3YuSevQQpCVxZxESrBNUAhoOrxyeHeKEBkxT2eHW/626evF CAfnnjiB NPhqpHI0LrkWlqz097KaouoYaW669962VG2RtLDaVtCRYvtKvsyIqsMa+Wk5Qmu34wP8BudPkI1hHtr8V3lfQY+nSCtg0sy2xn/uZ+7EdVvtvF4jliTUqiwoVJHuPPlTapOeQ2niK2GzSwGei7sks2H2JvwJ4uXG+YHqoRQsoKjt/ytw/RnMMyEMA9DW/hNqQu8FLHKUITRPWPSA= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Tue, Feb 21, 2023 at 09:47:05AM -0800, Roman Gushchin wrote: > > Wouldn't a compiler be within its rights to implement a one byte store as: > > > > load-word > > modify-byte-in-word > > store-word > > > > and if this is a lockless store to a word which has an adjacent byte also > > being modified by another CPU, one of those CPUs can lose its store? > > And WRITE_ONCE would prevent the compiler from implementing the store > > in that way. > > Even then it's not an issue in this case, as we end up with either 0 or 1, > I don't see how we can screw things up here. Thread 1: load word containing oom_group and oom_lock Thread 2: store to oom_lock Thread 1: store word containing oom_group and oom_lock Thread 2's store has been lost.