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 CC9D0C27C4F for ; Sun, 30 Jun 2024 19:20:57 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 478366B007B; Sun, 30 Jun 2024 15:20:57 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 428706B0092; Sun, 30 Jun 2024 15:20:57 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 317146B0095; Sun, 30 Jun 2024 15:20:57 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 148976B007B for ; Sun, 30 Jun 2024 15:20:57 -0400 (EDT) Received: from smtpin27.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 77006A06E2 for ; Sun, 30 Jun 2024 19:20:56 +0000 (UTC) X-FDA: 82288522512.27.C2DFF3A Received: from mail-yw1-f182.google.com (mail-yw1-f182.google.com [209.85.128.182]) by imf28.hostedemail.com (Postfix) with ESMTP id B27ACC000D for ; Sun, 30 Jun 2024 19:20:54 +0000 (UTC) Authentication-Results: imf28.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=0rk7sn5f; spf=pass (imf28.hostedemail.com: domain of surenb@google.com designates 209.85.128.182 as permitted sender) smtp.mailfrom=surenb@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1719775234; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=C06Lxu2qWtoIPdhV6FpMtGF74vdhlrNGojrNRfofH9A=; b=aZfbUD2qnKcKz+EV4QS/c8ajOH2cf3B5cyPM3IkdiWkrPq4mkovQNtoQNbQA5Nfq3rwuuE vAUP4cqnoAPjNYgDuAlI3X9n9T7UFRxfOtl6Ha+b5SMy3hi6gQJH7hLCp/n2p1zeKA692y bnfOaw4jOe59LN3h9ZVSY7XCMVp+avU= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1719775234; a=rsa-sha256; cv=none; b=RbprYWLYYsw8bdziy4/aJGbDQVRPQUUdtEtYnmQy59zIgoqQ5jQXT+DxCzO0rJzo0gb6Vf /v3EIFWyrsLX36iZ5WoMczEgB4ugXiCpG5CEQRWsY/q9jsOKPC6ASSN4a7l1P09d/mwyDc OMOvDiCU2YuwkiDC5YAAnnxB2Xh5d54= ARC-Authentication-Results: i=1; imf28.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=0rk7sn5f; spf=pass (imf28.hostedemail.com: domain of surenb@google.com designates 209.85.128.182 as permitted sender) smtp.mailfrom=surenb@google.com; dmarc=pass (policy=reject) header.from=google.com Received: by mail-yw1-f182.google.com with SMTP id 00721157ae682-64361817e78so21644637b3.1 for ; Sun, 30 Jun 2024 12:20:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1719775254; x=1720380054; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=C06Lxu2qWtoIPdhV6FpMtGF74vdhlrNGojrNRfofH9A=; b=0rk7sn5fZkBA/LWFw1c1xl60Gh/rrl+da1mpIyJhxYtja+sKfy/Z9y3EfzrLM/PmWY WARr2qQ/f9aB1XAxZUfix4iYd63vKZ3PnYcA9uiMiX7Y8pI7WfPU5xy23J+aegssQ5IY NxnzI12wu3hx0ES87HsAivjY1CK7yX0x9D+F3oDrsUsgQWFtNMA3O6cDtDoe4PGZx+nD lbrKhnlUgm6FNJivq0w1bJq+7dDPA8tDAb3QX+RJvimPWl7cc5+VWHE+WUC1x3Ij3xx+ FLwP5Dz7TpTGirxl+uea35VMScz3iwFoTXVoskywtqYFtYiKbwRNGrYfemN5AHgRoBys pJwQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1719775254; x=1720380054; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=C06Lxu2qWtoIPdhV6FpMtGF74vdhlrNGojrNRfofH9A=; b=DB8bKRvD78byl0ZWh3kCu19GvVDWLyLvOL3HBDC6s1fQexiDe0SiBkmAi5Bamqv1kM bxlEPswcv1AqtX3oBWkxXVmuCHSx25INHZ8SBRSEkSai/niUUgzcUuag5crTf9LZQpGJ 6aWY9jWGO/5EPGGMp4PAsNcpF6b3PC1U27iSB7cE48Sv5ioPO1ojy9A8XGHWk3hFqY/+ T7lW8MYukUphQrB15aX7oLQlOxRKiqYBotk2ASkEBSSOO5Jv6bp3Yx3bDdTSMXVaFX7J ATitI2wiJqt2OTdfNnsruhLI6/72ZlNb6ZMBvdLomGN/t60wzJ/L6dOQVe2KJ26TLC5N oV7Q== X-Forwarded-Encrypted: i=1; AJvYcCUuBqIjyCc9LIJ0r552miUP0iOEr5hlaVV8HFZV26kSSwUDa3E8NWkTt9odHWQlMaxdD8+pQZRip07DLmhG693/Ll0= X-Gm-Message-State: AOJu0Yw1hRATAz3Da380vJ6PPwS+PesWd0I2QxpGwEeypewB3dZRsndk rCQPYS5u1xX0Ns3x/U/tNdWndGlIlE7FaVB/JjUcHRrz0aWibE75hhxQDqq09lB3kJH2tdvhWrD 9J+CV00I9d0kP18ltB8tmviewJEAQEviiOp3TnU2xWJfocvJd1FCb X-Google-Smtp-Source: AGHT+IGCOqYO5pqQ2PG6c8jd1PMpmtTfTOZf69o8IXJqeg8eV2Vim7tcDe/Fn0eirZ3xG+EnMPI+pXn4eXzAftJKWyQ= X-Received: by 2002:a81:60c2:0:b0:647:eaea:f4d9 with SMTP id 00721157ae682-64c73ae7b6dmr30365037b3.52.1719775253512; Sun, 30 Jun 2024 12:20:53 -0700 (PDT) MIME-Version: 1.0 References: <20240614225951.3845577-1-surenb@google.com> <18a30d5c-abf3-4ceb-a7fd-2edfd8bee2a8@suse.cz> In-Reply-To: <18a30d5c-abf3-4ceb-a7fd-2edfd8bee2a8@suse.cz> From: Suren Baghdasaryan Date: Sun, 30 Jun 2024 12:20:42 -0700 Message-ID: Subject: Re: [PATCH 1/1] mm/slab: fix 'variable obj_exts set but not used' warning To: Vlastimil Babka Cc: akpm@linux-foundation.org, kent.overstreet@linux.dev, pasha.tatashin@soleen.com, souravpanda@google.com, keescook@chromium.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, kernel test robot Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspam-User: X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: B27ACC000D X-Stat-Signature: nbhq67epmzknjn5yaj8131mj93qt1uri X-HE-Tag: 1719775254-329490 X-HE-Meta: U2FsdGVkX19LfgG98ovXwc+8uPEaA9t6N6DE0YmosOxWVTAOew1rxeSKXhVA4oOaZ5je29MiDQ+uLdjljNsarVG/K+l0Xja/ZhyIbgxNfzOS8hn0iJ3O+d5/6cLo5vaBYstOo4YozVA4mxX5OSPnHp6fr1KZLq4Zsn6Owjq2KLC5s5WZF2O7DAsMSvdrQQL9VNLwt/KUP1AhQl0Tds4zO0PHr8fp0Jiy//5gpSCygYps2jEcQvCPsLT97p0RO9TUiBoZX1wji++694/mWTjOvQyXvsLCfHtMx5EdrrSnaR8/99Q5qVDNgOM9nfwXrL8mGTl/VefpdN8ZKvvjzWGaf8T0jbvy1RDXKWvN4hZy1ccxLOE9HWphGkwXUyXWtXT+HhFEEoZ7M8l4qv7P8Pz50G12n2bN0FkvJTsaKpSj/5kLciDzkiddbZTPW+ppQg3FhH5dOYlmkZ409Jjgv3dYCVzOJ77jXyjLyRZk6TEB2k0ZEqvISMifGMBObNxR8Bx4X970nXt0FggW5HUKesvqrB3XqzzjXNBZhAR7pV0zz9QLlbUD+OrWGhe+FTKOpGlDgh4zr6E8x8jJMaH7Snk4CXxwLCtzv4tEw8o0txLZ3b0vuYY9nHlRUmVjBVPPr5Yat+/1mXl7bEq95EUvZYEE9dRrkT+C1VseofHOSJ7u9tIIdheqkJa0gtLBhPQZhLmd0ERDpfu1Lho5fvuSLJ0nb4lkLh42vwgSm1ymk/cRf+5bPGk42CqmohNqdL5LNYqvXO/P0a0eGP57hisdjfuMkyFiC3wHZATihJ8ghYGwlsHm6ydyuSDCQ8jkUooxHTJKDk3DJBFI+UZT71O9UglHpKsa/boUMw28qwLfIF4p25ouEtT+bMTrPEfneYJnhJPSIVREpuW8WJAlX697xiFu/Btng3ntwg49icyjlCsy6O0+D3FcVXhTDReGtiHbKSB2r3daJgKQ7D2HAgabwAf B+x7iKhl X8oZ6JlsGz0joac/7l9jyBoQO1EgJY2Q6DoCEYkTlPmbDscFqHS5kYK9rDlFulKNCRysVgdpOIg5geMN6VMkrYYC5fuHr7qejyhx0IxctkQTAlJYVW3WN6VbnnLwFtsvSbL5hX3U5KC8qtNcKsVBbxUN4JWjevcuGvqP7YdCEuWKNMRHja5fgruDnpl2gqwHXkjCuwEHLK4Rg0ENNDd9hXJC+KJIAtFQAHnBEi+TZTsZxwVaijN2gLAzObO7yId4oY1FA4kJu4u9fcb/j6UooF5Im0VlpSqovpRdKJFaJd/q3AeCcK+sl7Ktsea2KWrllHVt8 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: List-Subscribe: List-Unsubscribe: On Mon, Jun 17, 2024 at 3:04=E2=80=AFAM Vlastimil Babka wr= ote: > > On 6/15/24 12:59 AM, Suren Baghdasaryan wrote: > > slab_post_alloc_hook() uses prepare_slab_obj_exts_hook() to obtain > > slabobj_ext object. Currently the only user of slabobj_ext object in > > this path is memory allocation profiling, therefore when it's not enabl= ed > > this object is not needed. This also generates a warning when compiling > > with CONFIG_MEM_ALLOC_PROFILING=3Dn. Move the code under this configura= tion > > to fix the warning. If more slabobj_ext users appear in the future, the > > code will have to be changed back to call prepare_slab_obj_exts_hook(). > > > > Fixes: 4b8736964640 ("mm/slab: add allocation accounting into slab allo= cation and free paths") > > Reported-by: kernel test robot > > Closes: https://lore.kernel.org/oe-kbuild-all/202406150444.F6neSaiy-lkp= @intel.com/ > > Signed-off-by: Suren Baghdasaryan > > Acked-by: Vlastimil Babka > > But it seems to me we could remove the whole #ifdef if current->alloc_tag > (which doesn't exist with !MEM_ALLOC_PROFILING) had an access helper, or > there was a alloc_tag_add_current() variant? Hmm. I'll check if current->alloc_tag is the only reason for this ifdef. If so then you are correct and we can simplify this code. > > > --- > > mm/slub.c | 7 ++++--- > > 1 file changed, 4 insertions(+), 3 deletions(-) > > > > diff --git a/mm/slub.c b/mm/slub.c > > index 1373ac365a46..4927edec6a8c 100644 > > --- a/mm/slub.c > > +++ b/mm/slub.c > > @@ -3902,7 +3902,6 @@ bool slab_post_alloc_hook(struct kmem_cache *s, s= truct list_lru *lru, > > unsigned int orig_size) > > { > > unsigned int zero_size =3D s->object_size; > > - struct slabobj_ext *obj_exts; > > bool kasan_init =3D init; > > size_t i; > > gfp_t init_flags =3D flags & gfp_allowed_mask; > > @@ -3945,9 +3944,11 @@ bool slab_post_alloc_hook(struct kmem_cache *s, = struct list_lru *lru, > > kmemleak_alloc_recursive(p[i], s->object_size, 1, > > s->flags, init_flags); > > kmsan_slab_alloc(s, p[i], init_flags); > > +#ifdef CONFIG_MEM_ALLOC_PROFILING > > if (need_slab_obj_ext()) { > > + struct slabobj_ext *obj_exts; > > + > > obj_exts =3D prepare_slab_obj_exts_hook(s, flags,= p[i]); > > -#ifdef CONFIG_MEM_ALLOC_PROFILING > > /* > > * Currently obj_exts is used only for allocation= profiling. > > * If other users appear then mem_alloc_profiling= _enabled() > > @@ -3955,8 +3956,8 @@ bool slab_post_alloc_hook(struct kmem_cache *s, s= truct list_lru *lru, > > */ > > if (likely(obj_exts)) > > alloc_tag_add(&obj_exts->ref, current->al= loc_tag, s->size); > > -#endif > > } > > +#endif > > } > > > > return memcg_slab_post_alloc_hook(s, lru, flags, size, p); > > > > base-commit: c286c21ff94252f778515b21b6bebe749454a852 >