From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pl1-f180.google.com (mail-pl1-f180.google.com [209.85.214.180]) (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 43E273A4F4B for ; Mon, 20 Jul 2026 19:58:46 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.180 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784577527; cv=none; b=PFCljZrCOkCmH+DaVjt8R3K4fSFY3NuxrIQO36DgPwJ9GrjGqmMHnLsQ9Zwu1gFud6zd++PJfa70zzlP52nvIqV5XXUX2X0ImiNNAf29qlji73q0uxDTl1x1nsbFXa6zktYfwWxHkveq9dBv8wLfER/GDxjItTR+qbMwUnlrnSo= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784577527; c=relaxed/simple; bh=3vaHX55eRnwF9/hLAZDG/1AlGi77ds9PDEh9RAs84vA=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=BrD+6NLv9gBHVhXeXJKe4JOBNCi06p5zRz+2AuYl6CBSINmrmYZ599z+K2RTI3hM8bpsbjUSl5GuWbCoz4alZp+exfT82cV3dGe06vbzH1XvXjtf1+gAppfiT8EqdRKYyBbpLLef4vPcJCA31L2LGN3eV8pTybddZUfcPqCN90E= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=osandov.com; spf=none smtp.mailfrom=osandov.com; dkim=pass (2048-bit key) header.d=osandov-com.20251104.gappssmtp.com header.i=@osandov-com.20251104.gappssmtp.com header.b=BM4cTztP; arc=none smtp.client-ip=209.85.214.180 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=osandov.com Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.mailfrom=osandov.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=osandov-com.20251104.gappssmtp.com header.i=@osandov-com.20251104.gappssmtp.com header.b="BM4cTztP" Received: by mail-pl1-f180.google.com with SMTP id d9443c01a7336-2cc7a269ca1so23833945ad.3 for ; Mon, 20 Jul 2026 12:58:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=osandov-com.20251104.gappssmtp.com; s=20251104; t=1784577525; x=1785182325; darn=vger.kernel.org; h=in-reply-to:content-disposition:content-type:mime-version :references:message-id:subject:cc:to:from:date:from:to:cc:subject :date:message-id:reply-to:content-type; bh=HcwVCKMCsgSSFOSFUSeqAhsycxUaPnb4s9hCiCZnUoQ=; b=BM4cTztPMJJD0uY+NMQ9ELzMqGkiCh6qicngOVR2KhUSfYH9FRqes86stK9v7OHDT3 hoX3DjJaqdsToWyh4UUzsCDzwDUH162xijujAr4RtTimNrjHXAHs8WZ47Yehx0JdWsoH ihg9aM0DSZJktXNmeoYevgDWzBssSbnuKLRHh2sHX0cwldP+dP2dizMWVkj5xGrZcb6g acvIiyAZst4J17qM9pcp+C70AjjOXq4FF6siqTeP3XFLlUhT2VglOMAuvvlxti9yVmCL Z5vfiuE+zgq8a+0jwef7L3rZvk9xxWG37SVLxSfiJfDbBhI+tC7FBtqX2aFhGChsREWB X+bg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1784577525; x=1785182325; h=in-reply-to:content-disposition:content-type:mime-version :references:message-id:subject:cc:to:from:date:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=HcwVCKMCsgSSFOSFUSeqAhsycxUaPnb4s9hCiCZnUoQ=; b=mjZebQ/VWxs5zs9H+MS6FFi/ZIwnSkvVajcXZJn/hucn0vnyOiePWd/zvTi41CwDzC ChvRwWTztAzPeJ5vmM1bLObW9zsY0ESzDlB/PM0a5o5p4uFkBrrHW8JX/B0FIpyB8Xm9 XJeMBdyGhl9aCs0FNp2i+FtCmxgYrqcHJPsUrBOl/6CexH//03wlZrUXW3iT9jxCeemr vJaP/DbqlNYhvP5lsTv1QrFYMEgqnfsn1lNqPVBCZegeoekRs3suAf5jJwqbpdZEo6LN LUN3dcVPCugh81EDTy808bKoizW0wXK5EAm+s+7XoPJUkthAiESBEo5GL6uGC1xSHEvN niQQ== X-Forwarded-Encrypted: i=1; AHgh+RpnnNH25sowRY5YFhWZJYIGf+s3Bjjh+SPvTXQ4FLrdrFaFa+NJG/41k8ZkyoKfoSyFeOtRGRDpXZnYHqw=@vger.kernel.org X-Gm-Message-State: AOJu0Yy++lKmp5vQfUqWrnNaok7bmFsFCaM+wCNgI0vrsqJPGwy/FQho o4ACtMY0ha07fZokSfKZx4JhXEgu7sVrJcTBHokUANirK8aQuQ3UdD7YuHjI/QfX0QA= X-Gm-Gg: AR+sD10ISC8jLgOVcn6o9Mm51SWjoV6dO15IMbWfvsyxxZ6orzthe/jrkpMx4q9TriV xgClKQiVVDm8O3Q3JXKd3LZT3Nwr2M2sAUeEe53ZpokXLYznSKPLKixcoGXeh0G+0Gj9jzH8/HA bPFhHxEV+rVuu6qS2GLcYOeV0umRRBudJ8RZmHhUv65I9WLtI2yg5/RSmFCmlcz1AVQB1rHO6rA d+45r9Och9FYHWJUXHrM9TKB7i9U5HnOrEd9yTcJwS3QEop0ppzjvUzVXs5+yJ45RXSW+PNDdKD VEOQhFzm3ZcB1jGdwQxQXxZnH/WOVwOhIm64q1VT0oexfmCrKL9yJm5vM0ckZ2ukwxvFMEYIZeq 6pibwzkPqAQVfSVVT8e1fWT+BeyLQAuXaKLoq+VTEn0aJTc7NppnriO4WpMt+TowaXl8Ia8hsWW jQf2YTIBQe0nJw+ZoY X-Received: by 2002:a17:903:1905:b0:2c4:397:dd7a with SMTP id d9443c01a7336-2cf80472f4amr2950035ad.4.1784577525668; Mon, 20 Jul 2026 12:58:45 -0700 (PDT) Received: from telecaster ([2620:10d:c090:500::5ee8]) by smtp.gmail.com with ESMTPSA id 5a478bee46e88-3142a1e348bsm41134232eec.25.2026.07.20.12.58.43 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 20 Jul 2026 12:58:44 -0700 (PDT) Date: Mon, 20 Jul 2026 12:58:42 -0700 From: Omar Sandoval To: "Vlastimil Babka (SUSE)" Cc: Harry Yoo , Suren Baghdasaryan , Roman Gushchin , Ye Liu , Hao Li , Shakeel Butt , Alexander Potapenko , Marco Elver , Andrew Morton , Christoph Lameter , David Rientjes , linux-mm@kvack.org, linux-kernel@vger.kernel.org, cgroups@vger.kernel.org, Stephen Brennan , SeongJae Park Subject: Re: [PATCH RFC 05/12] mm/slab: abstract slabobj_ext.objcg access Message-ID: References: <20260715-b4-objext_split-v1-0-9a49c4ccf4c3@kernel.org> <20260715-b4-objext_split-v1-5-9a49c4ccf4c3@kernel.org> <976e4d7b-24d6-4047-a405-e86c2feb45d3@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <976e4d7b-24d6-4047-a405-e86c2feb45d3@kernel.org> On Fri, Jul 17, 2026 at 12:00:29PM +0200, Vlastimil Babka (SUSE) wrote: > On 7/15/26 12:10, Vlastimil Babka (SUSE) wrote: > > In preparation for changes to the structure, abstract access to the > > objcg field with a slab_obj_ext_objcgp() function. > > Rename the field to _objcg to make an unexpected direct access a compile > > error. > > > > No functional change intended. > > > > Signed-off-by: Vlastimil Babka (SUSE) > > Hm sashiko finds [1] that this is breaks tools/mm/show_page_info.py > > But I think it was already buggy. get_memcg_info() is supposed to return > memcg info for a page but in case of MEMCG_DATA_OBJEXTS there's no such info > for the whole page, there is only for individual slab objects and it doesn't > know which object so it effectively gets the first one. I think it should > just stop handling MEMCG_DATA_OBJEXTS, but that's a fix that should be sent > unrelated to this series. > > There's also tools/cgroup/memcg_slabinfo.py and that I think has been > already broken with memalloc profiling as it assuems slab.memcg_data is > still a raw struct obj_cgroup * and not struct slabobj_ext. > > I think it will be easier to fix it at once to handle the layout after this > series than trying to fix it first to handle the pre-series layout and then > update it with every relevant change. > > [1] > https://sashiko.dev/#/patchset/20260715-b4-objext_split-v1-0-9a49c4ccf4c3@kernel.org?part=5 FWIW, if these scripts were in the drgn repo with test cases, these breakages would be caught by our CI and someone (usually me) would fix them up promptly :)