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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id D84F7C61DA3 for ; Tue, 21 Feb 2023 08:26:13 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233362AbjBUI0M (ORCPT ); Tue, 21 Feb 2023 03:26:12 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:41956 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231755AbjBUI0K (ORCPT ); Tue, 21 Feb 2023 03:26:10 -0500 Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.220.28]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id CDE8322DCB; Tue, 21 Feb 2023 00:26:07 -0800 (PST) Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by smtp-out1.suse.de (Postfix) with ESMTPS id 64C7D34636; Tue, 21 Feb 2023 08:26:06 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1676967966; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=64nOhdqsrfC+GQvY/2yDtSkhDgrub/IRKe6PuUtaoTA=; b=gL/+k88YS+b45aJgVurrBUpl0g1ZFiyovTv6aHjfZ9jSBCOegm2/HVLZmSevsnN8c27HXc qiKMeeqh92MmoN1xTCabTZIByhEkYtbvvgvTGShcDF2NbBr69DSWBVaLW+5RnkbEYyf7y/ zzDrC4knnc0O1PBH8hBci/5ov6RFTh0= Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by imap2.suse-dmz.suse.de (Postfix) with ESMTPS id 4802213223; Tue, 21 Feb 2023 08:26:06 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id DqbQDh6A9GNCCAAAMHmgww (envelope-from ); Tue, 21 Feb 2023 08:26:06 +0000 Date: Tue, 21 Feb 2023 09:26:05 +0100 From: Michal Hocko To: Shakeel Butt Cc: Roman Gushchin , Yue Zhao , linux-mm@kvack.org, akpm@linux-foundation.org, hannes@cmpxchg.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: <20230220151638.1371-1-findns94@gmail.com> <20230220230624.lkobqeagycx7bi7p@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20230220230624.lkobqeagycx7bi7p@google.com> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon 20-02-23 23:06:24, Shakeel Butt wrote: > On Mon, Feb 20, 2023 at 01:09:44PM -0800, Roman Gushchin wrote: > > On Mon, Feb 20, 2023 at 11:16:38PM +0800, Yue Zhao wrote: > > > The knob for cgroup v2 memory controller: memory.oom.group > > > will be read and written simultaneously by user space > > > programs, thus we'd better change memcg->oom_group access > > > with atomic operations to avoid concurrency problems. > > > > > > Signed-off-by: Yue Zhao > > > > Hi Yue! > > > > I'm curious, have any seen any real issues which your patch is solving? > > Can you, please, provide a bit more details. > > > > IMHO such details are not needed. oom_group is being accessed > concurrently and one of them can be a write access. At least > READ_ONCE/WRITE_ONCE is needed here. Most probably syzbot didn't > catch this race because it does not know about the memory.oom.group > interface. I do agree with Roman here. It is _always_ good to mention whether this is a tool/review or actual bug triggered fix. Also {READ,WRITE}_ONCE doesn't guarantee atomicity so it would be good to rephrase the changelog. Something like: The knob for cgroup v2 memory controller: memory.oom.group is not protected by any locking so it can be modified while it is used. This is not an actual problem because races are unlikely (the knob is usually configured long before any workloads hits actual memcg oom) but it is better to use READ_ONCE/WRITE_ONCE to prevent compiler from doing anything funky. This patch is not fixing any actual user visible bug but it is in line of a standard practice. -- Michal Hocko SUSE Labs