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 56723C433F5 for ; Sat, 23 Apr 2022 11:50:35 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id B29D46B0073; Sat, 23 Apr 2022 07:50:34 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id AD9FF6B0074; Sat, 23 Apr 2022 07:50:34 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 9A2E96B0075; Sat, 23 Apr 2022 07:50:34 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (relay.a.hostedemail.com [64.99.140.24]) by kanga.kvack.org (Postfix) with ESMTP id 8B8176B0073 for ; Sat, 23 Apr 2022 07:50:34 -0400 (EDT) Received: from smtpin27.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 67BDD26128 for ; Sat, 23 Apr 2022 11:50:34 +0000 (UTC) X-FDA: 79387976388.27.D4BB6F8 Received: from mail-qk1-f178.google.com (mail-qk1-f178.google.com [209.85.222.178]) by imf30.hostedemail.com (Postfix) with ESMTP id D9DE480031 for ; Sat, 23 Apr 2022 11:50:29 +0000 (UTC) Received: by mail-qk1-f178.google.com with SMTP id a186so7594180qkc.10 for ; Sat, 23 Apr 2022 04:50:33 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=PveZFFy5DjWV6FRcjoJAL/47PpCBgs3g9S6snQO0X6I=; b=WhQ6qtoh6A8ODlmE2tcwIA/qdfMUaSrQFSiOs48AGv90oMI8bA6yC/C2NlI0ngLrRT V38/vCqgnoYYQ2/t0L5uSAnXsVzsqNHvVWo9MqSHSXKn1w/YR4g07eX4pZSeAUIFHuU1 kMU8Z1j24U4AL3iPiIOZizuA9QW6HrunupvLl963zdeLp+jJvTlU9WHp6AdTP4lCjSZu nN6jgUMhV3wTGeEgVbXVdEzqh0gBW2j1kvStwhKT9JKu//UvvevZmT3mRKVkT/JBcXCw QuUI6wCMNqvjaFO8YqS4kAZUe5ySssFiScS//G2/D5hJnN6LAL5AV4Qb0roxBvfxjVHE iypA== X-Gm-Message-State: AOAM533SSMLQsTvLCLytVKL+4W6/wRK5WSzPq/CtCrG/TdODoUdAu5n3 wxbm2QQigY0U/2j25p7SIiI= X-Google-Smtp-Source: ABdhPJzSNZPXMfHsH4gNHFIZZSEdZMchVyCNRJ7PtwHf6oYnAETrt3eM7zPN/0PyMTHGeSzavJ1UjA== X-Received: by 2002:a05:620a:2405:b0:69f:2238:989d with SMTP id d5-20020a05620a240500b0069f2238989dmr3391511qkn.318.1650714633308; Sat, 23 Apr 2022 04:50:33 -0700 (PDT) Received: from dev0025.ash9.facebook.com (fwdproxy-ash-020.fbsv.net. [2a03:2880:20ff:14::face:b00c]) by smtp.gmail.com with ESMTPSA id c13-20020a37e10d000000b0069c268c37f1sm2197836qkm.23.2022.04.23.04.50.32 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 23 Apr 2022 04:50:33 -0700 (PDT) Date: Sat, 23 Apr 2022 04:50:30 -0700 From: David Vernet To: Roman Gushchin Cc: akpm@linux-foundation.org, tj@kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, cgroups@vger.kernel.org, hannes@cmpxchg.org, mhocko@kernel.org, shakeelb@google.com, kernel-team@fb.com Subject: Re: [PATCH 4/5] cgroup: Removing racy check in test_memcg_sock() Message-ID: <20220423115030.ee2gxwkwjzetzoby@dev0025.ash9.facebook.com> References: <20220422155728.3055914-1-void@manifault.com> <20220422155728.3055914-5-void@manifault.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20211029 X-Rspamd-Queue-Id: D9DE480031 X-Stat-Signature: jmjxu3usjdfq7qrbohcb566m6c6e1ije Authentication-Results: imf30.hostedemail.com; dkim=none; dmarc=none; spf=pass (imf30.hostedemail.com: domain of dcvernet@gmail.com designates 209.85.222.178 as permitted sender) smtp.mailfrom=dcvernet@gmail.com X-Rspam-User: X-Rspamd-Server: rspam08 X-HE-Tag: 1650714629-901999 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 Fri, Apr 22, 2022 at 04:50:12PM -0700, Roman Gushchin wrote: > On Fri, Apr 22, 2022 at 08:57:28AM -0700, David Vernet wrote: > > test_memcg_sock() in the cgroup memcg tests, verifies expected memory > > accounting for sockets. The test forks a process which functions as a TCP > > server, and sends large buffers back and forth between itself (as the TCP > > client) and the forked TCP server. While doing so, it verifies that > > memory.current and memory.stat.sock look correct. > > > > There is currently a check in tcp_client() which asserts memory.current >= > > memory.stat.sock. This check is racy, as between memory.current and > > memory.stat.sock being queried, a packet could come in which causes > > mem_cgroup_charge_skmem() to be invoked. This could cause memory.stat.sock > > to exceed memory.current. Reversing the order of querying doesn't address > > the problem either, as memory may be reclaimed between the two calls. > > But just curious, does it fix the flakiness (assuming there is no memory > pressure)? Yes, it does fix the flakiness. I saw it fail once or twice in my runs, but to your point that was only in the presence of memory pressure, which could make many of the tests in the file fail. Let me know if you'd prefer to put the check back in, and instead reverse the order of querying memory.current and memory.stat.sock. > > > Instead, this patch just removes that assertion altogether, and instead > > relies on the values_close() check that follows to validate the expected > > accounting. > > Acked-by: Roman Gushchin > Thanks!