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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 2C9A3C433EF for ; Sat, 23 Apr 2022 15:57:46 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236235AbiDWQAl (ORCPT ); Sat, 23 Apr 2022 12:00:41 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:38822 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236196AbiDWQAM (ORCPT ); Sat, 23 Apr 2022 12:00:12 -0400 Received: from mail-qt1-f182.google.com (mail-qt1-f182.google.com [209.85.160.182]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 40704260F; Sat, 23 Apr 2022 08:57:13 -0700 (PDT) Received: by mail-qt1-f182.google.com with SMTP id f22so7573996qtp.13; Sat, 23 Apr 2022 08:57:13 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=feBO+KbcIht+BPtu2AkAQpokc7FT3Bt17XhQc38rY6I=; b=Joa6bmM+0gvNBp9oBUlhTxR8ZPxs/9eAbHbOEsWovmEaQHfNDnOVwPcKDPfCcCuxdy 76oFJIQ+bW95H9niQwNAoIIFCCWUNb3bCeTjXcgAPog8cBZ6EdlpLNlklbX8Fgm/BqTQ gU9Uauzrf3O3q+ns4PTxeQRLidvplH0lf6jjny8dUmVCsePCpcl3pBUd87HtLnzLMmgd cCwZIoE2+X1k23EeBJe8QLxH4w1vZatcyGArDZp94Zj7NaZXzBcrj9fbU8WJrOu2odLC Ko82xmphao59BHrycD4/45q+/4A4/eNnzOGP5ONwlSguoFvLOEl0x3Cx7OYNcdj0LHzP zt5A== X-Gm-Message-State: AOAM532JEMmGhtk67ka1LX3072PcPr07zvR6wN7lwnsBfsuQQACmdWm3 RnTHmHyERML1KqKEc14saVk= X-Google-Smtp-Source: ABdhPJxIXud5TfSFIhMm/UhJy9PJtx0SRoz2tqQh0wV2kl2SWYF7ZeJPEXsR6zpNHVRdizGPzQIUjw== X-Received: by 2002:ac8:5956:0:b0:2f2:521:7195 with SMTP id 22-20020ac85956000000b002f205217195mr6834676qtz.409.1650729432349; Sat, 23 Apr 2022 08:57:12 -0700 (PDT) Received: from localhost (fwdproxy-ash-014.fbsv.net. [2a03:2880:20ff:e::face:b00c]) by smtp.gmail.com with ESMTPSA id i68-20020a375447000000b006809e0adfffsm2529753qkb.25.2022.04.23.08.57.12 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 23 Apr 2022 08:57:12 -0700 (PDT) From: David Vernet To: akpm@linux-foundation.org Cc: tj@kernel.org, roman.gushchin@linux.dev, 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, void@manifault.com Subject: [PATCH v2 4/5] cgroup: Removing racy check in test_memcg_sock() Date: Sat, 23 Apr 2022 08:56:21 -0700 Message-Id: <20220423155619.3669555-5-void@manifault.com> X-Mailer: git-send-email 2.30.2 In-Reply-To: <20220423155619.3669555-1-void@manifault.com> References: <20220423155619.3669555-1-void@manifault.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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. Instead, this patch just removes that assertion altogether, and instead relies on the values_close() check that follows to validate the expected accounting. Signed-off-by: David Vernet Acked-by: Roman Gushchin --- tools/testing/selftests/cgroup/test_memcontrol.c | 3 --- 1 file changed, 3 deletions(-) diff --git a/tools/testing/selftests/cgroup/test_memcontrol.c b/tools/testing/selftests/cgroup/test_memcontrol.c index e899b3f28c22..38d2054eefe6 100644 --- a/tools/testing/selftests/cgroup/test_memcontrol.c +++ b/tools/testing/selftests/cgroup/test_memcontrol.c @@ -993,9 +993,6 @@ static int tcp_client(const char *cgroup, unsigned short port) if (current < 0 || sock < 0) goto close_sk; - if (current < sock) - goto close_sk; - if (values_close(current, sock, 10)) { ret = KSFT_PASS; break; -- 2.30.2 From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Vernet Subject: [PATCH v2 4/5] cgroup: Removing racy check in test_memcg_sock() Date: Sat, 23 Apr 2022 08:56:21 -0700 Message-ID: <20220423155619.3669555-5-void@manifault.com> References: <20220423155619.3669555-1-void@manifault.com> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20220423155619.3669555-1-void-gq6j2QGBifHby3iVrkZq2A@public.gmane.org> List-ID: Content-Type: text/plain; charset="us-ascii" To: akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org Cc: tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org, roman.gushchin-fxUVXftIFDnyG1zEObXtfA@public.gmane.org, linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-mm-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org, cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, hannes-druUgvl0LCNAfugRpC6u6w@public.gmane.org, mhocko-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org, shakeelb-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org, kernel-team-b10kYP2dOMg@public.gmane.org, void-gq6j2QGBifHby3iVrkZq2A@public.gmane.org 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. Instead, this patch just removes that assertion altogether, and instead relies on the values_close() check that follows to validate the expected accounting. Signed-off-by: David Vernet Acked-by: Roman Gushchin --- tools/testing/selftests/cgroup/test_memcontrol.c | 3 --- 1 file changed, 3 deletions(-) diff --git a/tools/testing/selftests/cgroup/test_memcontrol.c b/tools/testing/selftests/cgroup/test_memcontrol.c index e899b3f28c22..38d2054eefe6 100644 --- a/tools/testing/selftests/cgroup/test_memcontrol.c +++ b/tools/testing/selftests/cgroup/test_memcontrol.c @@ -993,9 +993,6 @@ static int tcp_client(const char *cgroup, unsigned short port) if (current < 0 || sock < 0) goto close_sk; - if (current < sock) - goto close_sk; - if (values_close(current, sock, 10)) { ret = KSFT_PASS; break; -- 2.30.2