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 5D4DFC3064D for ; Tue, 2 Jul 2024 15:16:35 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id D6CEC6B0099; Tue, 2 Jul 2024 11:16:34 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id D1CFD6B009A; Tue, 2 Jul 2024 11:16:34 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C15D46B009B; Tue, 2 Jul 2024 11:16:34 -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 A2D806B0099 for ; Tue, 2 Jul 2024 11:16:34 -0400 (EDT) Received: from smtpin26.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 1DBB2160303 for ; Tue, 2 Jul 2024 15:16:34 +0000 (UTC) X-FDA: 82295164308.26.54074F3 Received: from mail-yw1-f175.google.com (mail-yw1-f175.google.com [209.85.128.175]) by imf25.hostedemail.com (Postfix) with ESMTP id 315AFA002C for ; Tue, 2 Jul 2024 15:16:30 +0000 (UTC) Authentication-Results: imf25.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=S+bGJEEB; spf=pass (imf25.hostedemail.com: domain of surenb@google.com designates 209.85.128.175 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=1719933360; 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=sa19PPKQit/6l2WVAcrh2RkbPmxofPvqwrxfkehB9rs=; b=mJ5TZI5N31/7hIZdM37FDB2KMUDASMF1iab4x8wyoOhdm7DvzZr99MA3pMjpEg/adfGPg/ HcQrakhCN0bh/3LKlvXSApa3hiUxnBgKTcmjVehdKPk+b32bNxjmp5c6o7Rs6E1Ctpn2yb vjyyR3swAebMx/ht17irqLfVo4FaJ1s= ARC-Authentication-Results: i=1; imf25.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=S+bGJEEB; spf=pass (imf25.hostedemail.com: domain of surenb@google.com designates 209.85.128.175 as permitted sender) smtp.mailfrom=surenb@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1719933360; a=rsa-sha256; cv=none; b=7iZgLI2G5T9/hDopHQUNa/HqUVlu/L9RZKIibJjE5iK3BWfxesvz2+oHp3qYfZnF4Pgt6X zXculdeEpzz+xVJBtZDAXYH1FiLYSrxOilUNa0tPMnuvhO6LXhVelPkhPUqsCn20Rsez9j yn9mITx1JoddTTsMC+KZtEbN0WTnvSc= Received: by mail-yw1-f175.google.com with SMTP id 00721157ae682-64a6bf15db9so37336057b3.0 for ; Tue, 02 Jul 2024 08:16:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1719933390; x=1720538190; 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=sa19PPKQit/6l2WVAcrh2RkbPmxofPvqwrxfkehB9rs=; b=S+bGJEEBn87uleG4FS/mnpbhWS/RmRIgOyAFVlBnUCDR/A8wZMJdLjpSCepid6OoNy xpPaoV5Om4H8+gwOGDtrZFHRgb2VcwIGQ1gAGcO2TJJvj9h3+nIAcZKqHVueeNeZaCbF QuuBm3CGO5qlJmJdgkF/qbuqoqn0PKcRjrlCNLVhBB8/WjvJcFnDXuiQfaES2rO7JjHE UxO1A1Da/3hplHdNcu2k/DysJk4BKRJpEDlEGJE55lmlidbiCtZLE6QGeA+5fM3/wSQN GWN+lygK8EHtB4hI0SHVpp/HNT2dD4EulCbx+4jxpH3xWzZ2+zw2GQ8U1eithWFBPY9w bSvA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1719933390; x=1720538190; 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=sa19PPKQit/6l2WVAcrh2RkbPmxofPvqwrxfkehB9rs=; b=lcYzqKvQde9Pe6sZMCvv/AmFQrSM6ha3TTbXS9+ynzpFrxELix3Wgk6Nk23tzouIFs VE3GjP3aPxOhsY8pgzVwgbz/aIePsWbYEF3SOEoOIVbcvholBtTamcdb3BbRYwNCM6OA SfCNKOog6HiGQpYZlFZMRDxHbeipMOZOwDAv7ZYK47naj/b+q25+lFUs5uzbCxKqT+KK dnb1mgYBd9/Vr7lCtWpOypm0kTSEVENTytryPwM67veajefsHb1/R6HV076zcTuLMi+U T+prquVQyWBE15H1qBhftkGQhZSBlwV4oM1co9/OK328mT0IfbyzJJ+PkvYP735bQHUS t41A== X-Forwarded-Encrypted: i=1; AJvYcCWIsKJ88nxNAnqxc0zxl/qmZk8NPhUxQ3soxaVgcLLh6sof+z9UATPYbvnwkS60vkcBb+sYXLMS1+BPa2GqiMygJcg= X-Gm-Message-State: AOJu0YwWKCcB0sEHP/dNcPniEDfmjgx7OcnyjyH9oWW63YfEvJSWLp7Q nqq73IfwZf5OUqVjkOWAVISGwcrCy2AB+NKIJM0V9sCoE9nelBhS5IDbeHWPtJ4Ynri93EV6Equ AUO6voFZg3hWBA74La10WYm0sP+FWsKjP7jEF X-Google-Smtp-Source: AGHT+IFx6DSHJnJhc4x7w1fofiZ/DpQdbBv1kkUvEbzs7Z3G4JNMTfpmq8uXFoB3KhpwOcT4URKG2MSZNmrwdubCYIE= X-Received: by 2002:a0d:e682:0:b0:64a:49a4:3e9 with SMTP id 00721157ae682-64c71aeb4e8mr69774637b3.19.1719933389857; Tue, 02 Jul 2024 08:16:29 -0700 (PDT) MIME-Version: 1.0 References: <20240614225951.3845577-1-surenb@google.com> <18a30d5c-abf3-4ceb-a7fd-2edfd8bee2a8@suse.cz> In-Reply-To: From: Suren Baghdasaryan Date: Tue, 2 Jul 2024 15:16:18 +0000 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-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: 315AFA002C X-Stat-Signature: bgdcnkf1o9fadpbfk3etj37mix6g4q4o X-Rspam-User: X-HE-Tag: 1719933390-302294 X-HE-Meta: U2FsdGVkX18sWNyQccv7SD5jnZtKNegX1nDlBhH27N+Fzf0VM6aJKupzXxNImcNUiOXDd0n2tP1ejAfjlKNVqV7yx62s6YgZGJ5pf6FT+noCqRkHpZ4SEkM880VLNWDikZ69tHpY01r1yyTeHn7xi+SIHZEvPntai+WeIoqJTrBMwUMh59a14I/8LTQMBjjE3OVW2BLgl9w8UZGBOtAEAlcnnsCXWZgEI54frsGL3cqdIR/s1R2dj6p9h03MQHvuEYOmAsZVUS97Jbbw1dxIk1EmzM1/zIwJqfXomWb4jnvqFarJYPvce0trpzryEB+PqKUBhStaaVsttgHvPOwsNzVDBaCszQTc+Y4zPHohb4mHLt3gXgAFIUCpSO4hQFIpK9Wmry1xBeLW/1TP6v0PIaREBVBzRgFFJaq3YwcSqgdKwCh72sjttfcXXkHtxOGharbdPk5xt6FLD5ywEK7469cSAha67+RSEM6HJt0zHUSzx03S5QMbvCPCIuPK7IAu6UNQZQbWFHLY7a2/xiRCcvXB4InzbWGWbMBnoiR34aS2we/QySYjclJcbkHWlypdnNpafxCPnPWKx3YXZXHn56jHx8WLybnFR2KkaKAR/NDD0LPahjM0CruuODmTQtBRI7OR+zxuf6TySRhwwFX/9JGFtDoTIZ9qm3+uFNbbFWVXW1jVav7kDM1Kmt5SPLxTIWEC634sl4msFT4OYWuGRp51N7Sbp1G/+Dnyv6rLDPylL5RJOI3wGFII8g2hFMZMA0uyfW/5vIG6nTxM0/kII2EeBr2uElt8iTEKyDeZjdYLrL7wGA/LLhCGv9QnzNRmITushdFzXTWudNic5Vlk4pXWrzSEc+n4KviSGlfnaeTjyaQBZCAWbwQndOz9A+aurNtRlYbrzwf07N1XXFHTDdPanMSEGht0rV7SrEDhpY2Q9x5aFj+2ECebWRO6XCHsfuc2xo9vSJtp6YK+4MH S3HgVZGu IidKHG6Mzk5qLWTXVtmzLBBJNH+x8eIIEqIuqRUeYm0rvD2jW+00GydMjPR/6hu+5dVcf1jKVOQzcc8r5vKMFFhsdUgnLq/XD+6xJbuauPWzkLnlaLreNe596qrVB9oPv/xa6MSV6Xhlnpd6XbU0Qzhpx2wTdg5pVv0VRqfFCNI77P2f5m8fTgPhqus3zKGJfAUzmcrttOeVpGxED5hXhV+qqdoqoH/V/uASnXiigvNqYUR2ZL09uvHvt2COjzHFTEynYtj75Vvi5VV4ONbsbL57mKiSRUaRXIJr1OYIiVqU0zSUaIBv/xvhokWlPnEG5DoaG 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 Tue, Jul 2, 2024 at 9:31=E2=80=AFAM Vlastimil Babka wro= te: > > On 6/30/24 9:20 PM, Suren Baghdasaryan wrote: > > On Mon, Jun 17, 2024 at 3:04=E2=80=AFAM Vlastimil Babka wrote: > >> > >> 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 en= abled > >> > this object is not needed. This also generates a warning when compil= ing > >> > with CONFIG_MEM_ALLOC_PROFILING=3Dn. Move the code under this config= uration > >> > 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 a= llocation 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. > > The fix is now in mm-hotfixes-stable but we can cleanup for the future as= a > non-hotfix. Yes, it's on my TODO list now. Thanks! >