From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pg1-f170.google.com (mail-pg1-f170.google.com [209.85.215.170]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id A2C06305E32 for ; Wed, 8 Jul 2026 00:33:54 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.215.170 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783470842; cv=none; b=O+648Xg53RY43ruRobl+MS7q5OCKxJzvS3KdujuJTHJOWz2phtgEsQb30qN23GTeuw9i2xuF/Aitd2pnV4xeSYfNlsUMsAmygPl19O5u7nqRk3jGullGhmebPpc/PpGcJVbCLDPSjFW8QGmZmt8Jug9Hn3vp6yuFYmjsE7Pd7Yc= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783470842; c=relaxed/simple; bh=O8dlhXGaKZVLXNWM+o64TPqGISoXyx4XSm5T4i4QYg0=; h=Message-ID:Subject:From:To:Cc:Date:In-Reply-To:References: Content-Type:MIME-Version; b=Jv1xB2HofVtRdzPoj9dIntOoSBdw05BU595MXyOy2Yr8ovhdzK7iRr6HUQkn6z0e3aC6LILjG45dYaZ76zrRD5haWIrDrSi7sLXpsb6Gf9oQeWbxYHoYIYtojh/gdZ42RlmdjMLxYWMiRT77Pxh6oC8KRatMKKknarrlrTZkr3M= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=Ktbeh1//; arc=none smtp.client-ip=209.85.215.170 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="Ktbeh1//" Received: by mail-pg1-f170.google.com with SMTP id 41be03b00d2f7-c9e2489e117so29821a12.0 for ; Tue, 07 Jul 2026 17:33:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1783470831; x=1784075631; darn=vger.kernel.org; h=mime-version:user-agent:content-transfer-encoding:references :in-reply-to:date:cc:to:from:subject:message-id:from:to:cc:subject :date:message-id:reply-to; bh=6PPCHw1C4s9wB8+ak3IGBUi1NrCIfjVxm5EQeAbcpyE=; b=Ktbeh1//7+N3DxvK+f6VKqWUItIjmxmhQgtPWIH9NHPeU5iLF9YQzAr94iegew2tVn QJRB23/JdrTOZ8tOp2X/2NfVQ2S2fjkob1wnCTJuDDaUJWkzME+XeZDsa3to7zTCSsAL qKWhEsACssY+HTq66AIFmIW1uHUba0BwiYKuJplIPXgzg3fwkxNsxvln9JsauINjMrH4 GV6fZ2TlwqE4txmntQqtHmJ2avFR94vnzqfk3enrufZW2gTrCV3t/Ep3l5JmjB81iunJ FfqwXOFW15TCBHngaCYxg0ZFoNxebp78lWH181oWdWM16pUkWyy4TvvwHQzu4RcCakMn qw4Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1783470831; x=1784075631; h=mime-version:user-agent:content-transfer-encoding:references :in-reply-to:date:cc:to:from:subject:message-id:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=6PPCHw1C4s9wB8+ak3IGBUi1NrCIfjVxm5EQeAbcpyE=; b=WErLKCaU8wi+YkcgzXoNSGjSvm68NjQ4Znn1zXbXtYexqQM/zX+TJhi4hZhYU6zrBk ZVNdsZFYFNyEYBhTraDdfz4Wc8DfMNdjYA0k6eSfjxl9T3ycrGHdCwFu/nGqv+dl4wk+ 9yESYLZpEOpmRmdf5h+TkiY9umJ7Xp3SnQmdF6bFL/hLPoqVKZn3FsdLCIApdVDVd0ce h3k6fEDJslsXsf3Fe352wQubXh9jhLl0pBxUWwbJqYyQRih277oLIMQ9uzZFmdc/Af3R oDFEli9xS1Eg67AbNDPyvPN8fkSt8S2m+U+0hDWNF4o8P6X0nl6CBfBZpOx2TMRmBhTJ H7xg== X-Forwarded-Encrypted: i=1; AHgh+RqIpdzxroWM0hmHk1Mycrt/qqJU9aBUxU5rzlhLBR5zAEWMrTM5A/9VLYYNerZpD55A5tmZXmGMsKbXKIY=@vger.kernel.org X-Gm-Message-State: AOJu0YyK2kRLiH3hCN3fc+717sOozuX01teUmGj5kmBeZpSFZksiqIVi okd3+1hEVxSm0pEb1cQhEGKHOb21ser2JpMFETJpgur0PKNTmASGJAsd X-Gm-Gg: AfdE7ckM9BTyTTeSP+Wd7CAiAG6G5ia7bkgMD4S3kdtgud9yV/DthPdxtDgCWCJjbYK DSKR/yUU6HS3w9QqIvlKN9P2mM0k8tXbPYBCDlwEoqvCAe/Jq/j5DMMbR1Zl+6VPp5PszdI7onJ MZqRzsXK9iMkfITKK3aoBptyoCvWC8AR5gZ5cfELg5yn7oAogNkQcE6u/i1YMs+X8RdQGFu4y6a u2nWovqoPDeDNMtzWXwy8Gk5vMmdan7k94bHbGI3sicdXNrMRTfS+00c5uvG4Zd7S10xDtInJPW 8fSeyNkF5S19VUBlFy5u3AtKODb5G/EG/epn+Knr85NwR2OwdlP+ASkg+7tqWJuE8BOrrIy1cAm cWlWyQ1Y3UvDuLUBr1h3tjNurp0lXXwe7ZD1e2GAF7ZrfTdX9CqIV+3um11358zpCJE/gm1/Rhb x6bTqE5LI0/L1b9cmv8wIODkiHxSpqOwG4gBj81Q0hO0YRZdASbm89cv3ZFOO9C1kTcK9pEFJFh X5omihA X-Received: by 2002:a05:6a21:7706:b0:3b3:1c7b:ff7 with SMTP id adf61e73a8af0-3c08ef16b7emr8743089637.46.1783470830910; Tue, 07 Jul 2026 17:33:50 -0700 (PDT) Received: from ?IPv6:2a03:83e0:115c:1:f2fe:14ed:44aa:14cf? ([2620:10d:c090:500::2:84e7]) by smtp.gmail.com with ESMTPSA id a92af1059eb24-13b659c865asm13266118c88.11.2026.07.07.17.33.49 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 07 Jul 2026 17:33:50 -0700 (PDT) Message-ID: <030dc01fa51430f4ac27d3f4eb4a6147322cb51d.camel@gmail.com> Subject: Re: [PATCH 0/3] selftests/bpf: compare BPF and memory.stat memcg stat readers From: Eduard Zingerman To: Shakeel Butt Cc: Ziyang Men , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , Kumar Kartikeya Dwivedi , bpf@vger.kernel.org, Martin KaFai Lau , Song Liu , Yonghong Song , Jiri Olsa , Emil Tsalapatis , Shuah Khan , Roman Gushchin , kernel-team@meta.com, linux-mm@kvack.org, cgroups@vger.kernel.org, linux-kselftest@vger.kernel.org, linux-kernel@vger.kernel.org Date: Tue, 07 Jul 2026 17:33:48 -0700 In-Reply-To: References: <20260704045617.487664-1-ziyang.meme@gmail.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.60.1 (3.60.1-1.fc44) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 On Tue, 2026-07-07 at 17:31 -0700, Shakeel Butt wrote: > On Tue, Jul 07, 2026 at 04:50:11PM -0700, Eduard Zingerman wrote: > > On Tue, 2026-07-07 at 16:27 -0700, Ziyang Men wrote: > > > But the patch also carries functional value: alongside that compariso= n, it > > > checks the correctness of the stats the kfuncs return. > > >=20 > > > Let me first answer the main question -- what these tests add over wh= at we > > > already have -- and then lay out a plan. > > >=20 > > > First, the static test (memcg_stat_reader) vs the existing cgroup_ite= r_memcg. > > >=20 > > > The existing test calls the kfuncs, but for each value it only checks= whether it > > > is greater than zero. For example, in prog_tests/cgroup_iter_memcg.c: > > >=20 > > > memset(map, 1, len); /* dirty some anon */ > > > if (!ASSERT_OK(read_stats(link), "read stats")) > > > goto cleanup; > > > ASSERT_GT(memcg_query->nr_anon_mapped, 0, "final anon mapped val= "); > > >=20 > > > It never checks the value is actually correct -- i.e. compares it aga= inst the > > > value in cgroupfs -- only that it is non-zero. > > >=20 > > > Besides, it also walks a single cgroup: > > >=20 > > > .cgroup.order =3D BPF_CGROUP_ITER_SELF_ONLY, > > >=20 > > > and reads only five fields. > >=20 > > Arguably one of the the cgroup_iter_memcg.c tests can be extended to > > allocate some mem and check if the value is reflected in the stats. > > But there is a line between MM tests and BPF tests. > > All BPF kfuncs except iterator logic itself are thin wrappers on > > top of the existing MM functionality. Hence, I don't think that > > BPF selftests are a place to stress-test these things. >=20 > That is actually a good discussion point. Where does such kind of tests (= i.e. > testing that bpf based memcg stats read functionality is equivalent to > traditional memcg stats reading). As more subsystems are exposed to bpf, = similar > questions would arise more often. >=20 > In this particular case, IIUC you want only tests for bpf related code (w= rappers > & iterator) to be present in bpf selftests, right? Yes, I think this makes most sense. > Personally I don't have strong opinion where this test should live. > Functionality wise as it is testing rstat infra, I think cgroup selftests= might > be better home for this.