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 65D00C4345F for ; Thu, 25 Apr 2024 21:31:10 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id B73346B009B; Thu, 25 Apr 2024 17:31:09 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id B22C36B009D; Thu, 25 Apr 2024 17:31:09 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 9EA456B009E; Thu, 25 Apr 2024 17:31:09 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 82C0B6B009B for ; Thu, 25 Apr 2024 17:31:09 -0400 (EDT) Received: from smtpin12.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 32466121358 for ; Thu, 25 Apr 2024 21:31:09 +0000 (UTC) X-FDA: 82049349858.12.4687A23 Received: from mail-yb1-f176.google.com (mail-yb1-f176.google.com [209.85.219.176]) by imf01.hostedemail.com (Postfix) with ESMTP id 591A940004 for ; Thu, 25 Apr 2024 21:31:07 +0000 (UTC) Authentication-Results: imf01.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=z8+WOXoK; spf=pass (imf01.hostedemail.com: domain of surenb@google.com designates 209.85.219.176 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=1714080667; 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=BiewKxmK6Ch1JRpkm+LvVPlL0LObf9hp6GU9toLILKw=; b=QythFlDezjEbOAYEtROqAiqeTN9MDepq8pX4TeNAKRFDjfAi8QBa6AtJ+5huYf0/Z9o7BR PsQjdGsij+3+Tcm+TFE0BDlSInD5fqzTb5E/8L42hhdrgywNljmPiSNIYIh+gsHlkwSJ2i um/RD1bX8zM57h8NOjG4Lgqs2XGoJ6A= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1714080667; a=rsa-sha256; cv=none; b=L19VEC02OWmsb4az9Tnmcgxg3fRJKB1gjEJwyohOina+WRCjwSC4eQuvl9Nihw9Jvu8IWn VkhLtvX71+UraFMCNmoDykjn14/bk6H+ZVrjwPKqFldsaPSns4opHjBXLqU5c9wW781VoJ kuJ+CVI64/0WwhT4u4QxSu/ZOpo3Azc= ARC-Authentication-Results: i=1; imf01.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=z8+WOXoK; spf=pass (imf01.hostedemail.com: domain of surenb@google.com designates 209.85.219.176 as permitted sender) smtp.mailfrom=surenb@google.com; dmarc=pass (policy=reject) header.from=google.com Received: by mail-yb1-f176.google.com with SMTP id 3f1490d57ef6-de55708c616so1655059276.1 for ; Thu, 25 Apr 2024 14:31:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1714080666; x=1714685466; 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=BiewKxmK6Ch1JRpkm+LvVPlL0LObf9hp6GU9toLILKw=; b=z8+WOXoK1aveSQ6j3Kh8UGL+AJtDdRpLU3eDp4JAjzktoWOoILCTcopstq3ZVtghm4 OuPsvxukXE82Dnr7e/unP240F2tKOYc7eUGWkF0G2JgEdO3taFc9LkpPsixc/LCpCGet UBIzMTxfAMJnlGMbwvf7T39sGPU9uPYSNirobkNfNA3zppxEYphMkIIw7CQJNXSpnRh2 AMnEv4Ow0ZCo67uG+T6A5RzjyDM2WVZuR7Bd24zl7BQr6fq/5fuSyBmrSpZS7akuiN0i kMV+shBIybvYKKwQ4IE0bCiOkLkJgPemzhSHNUIgFtLixgiOYQCeBRKPl7jbmBUXn8zN N18A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1714080666; x=1714685466; 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=BiewKxmK6Ch1JRpkm+LvVPlL0LObf9hp6GU9toLILKw=; b=OB8Yh8pr/PlOajptZjo8vdAzhDMD91HjuDFfPBJVij7P4PVrtz6nONlag5V++YSeZU ogJXVdjrMmv3qirthH8liK+dCYOI62CvXZuPXV21v225p9njYc/XNkw/ISvNRAACrRcs mviqporPlXY2Bn2u7HgU0mXke4a1zbj3e29TfQ2xJ1/AG/W2iWr7wtiSVSkZGtSduJjy JH4/PqG3ICVMWKqHYIg155PSOWdecpm2hId69hTm7PeLPoa1lgopysJbQvHDYtZ9G7T/ 6/LI5NqhyaNaUR63AtobAlplBGvFC70bXg6GBYfpkBeZwxo6Guc+ins+LSNCc3opiZRG V13Q== X-Forwarded-Encrypted: i=1; AJvYcCXTGH9JUAEFvzTdElj9pyl+5LgotsQFhZqQoG1EOnBsxCQtgOZZ5HFhEH1oR6P8G1fjQXTJkt1LuQQb+NClxir0UZo= X-Gm-Message-State: AOJu0YzAXIYdeDEV90CXnuCJfnQpXlI/6+WHLupvjMBMheGxyOxV972h 8uMCh4FWujsp4chKsvNS2qTvnZpNnq2xHB7MhsYjCzE8rLhYbVmqoL2TCvGSaiiCLDijPYKYcqc lV7a5zWNB79fcRN7JWiuEoq4qpoeRB7BiAa/L X-Google-Smtp-Source: AGHT+IFZ1q3ipQeESd0wnp2IqOoKRLw1VF18WtCFxq+hKgD5VNAEI4uAesWuCPJa3UPiUmszv/cPtrW09cccyfGBTmw= X-Received: by 2002:a25:8748:0:b0:de5:5a38:8e96 with SMTP id e8-20020a258748000000b00de55a388e96mr968314ybn.18.1714080666108; Thu, 25 Apr 2024 14:31:06 -0700 (PDT) MIME-Version: 1.0 References: <20240425205516.work.220-kees@kernel.org> In-Reply-To: From: Suren Baghdasaryan Date: Thu, 25 Apr 2024 14:30:55 -0700 Message-ID: Subject: Re: [PATCH] mm/slub: Avoid recursive loop with kmemleak To: Kent Overstreet Cc: Kees Cook , Catalin Marinas , Andrew Morton , Christoph Lameter , Pekka Enberg , David Rientjes , Joonsoo Kim , Vlastimil Babka , Roman Gushchin , Hyeonggon Yoo <42.hyeyoo@gmail.com>, linux-mm@kvack.org, linux-kernel@vger.kernel.org, linux-hardening@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Stat-Signature: zg7hn5t14zx8gi4j1toaspmecyyaaaca X-Rspamd-Queue-Id: 591A940004 X-Rspamd-Server: rspam06 X-Rspam-User: X-HE-Tag: 1714080667-899544 X-HE-Meta: U2FsdGVkX1+Xkvs5Bi5DjGCIVeOUYsOKRLnwVO/KjowpSL5svrLc+XauLHY3qLbxrJ76mwaa7NDfWQG9x5ju2BiFzvDqSJMSFh525XzCDTGV1dzRwSkcOD5hQTXmIz2znUlpx8DNagX0PEJ2OAaJVJsHoExZikyfWVChPi7UGY0x9nNBRcgNH6y1pynNWZxNY8Ti9xkUEXnN8tURXkTZWxq6BGRhXALhjvyAX7qcyyL1/zN12yYEyBIDCJAqNNoq5B/s4+bvc7txuuhPS3O+l6L5118Oz8IM4hEBNp3RFfSPGOZEO05yflPs/4+P4VthJSvWQsqiyRdA6Un1jCjA6wY6LXtWBCgeNgmD43gXUFFypgiNjtJeJ2K7udmc4H+5f7cW4/4lvJIJhGfo95XeZam+xdCuN98x6/ElR7gtwDMlrU10FU2jRG3hChjEdNgXxtBIMxteXN5dPJbsuFpP1r1qtGmo3renTfk4vCbaZKg3cVNb7QgxXlrp1L3/QDUMkryjMzXg5ZXOyBzS8KedFcL5GGV95mGvD90P1ZJoOVkPk0vRwQFJWp6aTvvbIeHR8eVndNa1muCIdrCDVE9SNImaxgy3cav+8jleOyNpr0vPP9gSiVf5hxtqEIcYhgR1iDCtjOeZljcdZ41VlQsE5Ef9aRi+pe8OtPZCscmgVUCtscgN8K5/63XPiyQuTJiLiB1l9uPq+IdQaB7JffP8rEtVOhWMib8/+waDj7YHxH9Q0QdcYvxNnfT4MUjvZvjkGkh7RJ0+8fSlL6ZvKyDod2gRWIl63QW99Sk6ufubOuFGpO/0vee72BamSTlyqtT6m10KPOz4yU5tYzP0uJF4GAwZhZuKqkn8BcZPfIZSRA8z2WMaxfB+7FR0ZS9W3AFeOHscXenB7eyOtfnFViOyv6/uErAtQwD+GZgALzoZ3T0tj+fLb0xEcZ7FPfjLbh4zfp8DprSothV7P0heUnZ 43mTTlIX iBqO6LZDd7vc6YxDG9KAifbjqz+SiBKGXCY987O4vxLQJZucy1puyjAiKaUps/94rdFkB55kyj7EH2hOnoYsc27TsGBEtVkkSEZ93ZhtV9aUDaBfbg3TGZPJhKU+SeieY39jBGi9dTX7kbxDrn/eUqRuOHpdludLMmK50/U9Tv/aw3JBpY2w2eNryAu34CIIXDyD3Bmv8WqPxLyi6x82tnqxJlpHzp59TAXa+0b6AVSbBa74orqQDVwxyNKlMH8BDNVtuAcIdX1bw87gryRpbHqbBq5jAS8wGylWfwX3N5er07LYQyo5FjCnHcQbF5fd8KmZRUbABaQCRvdwE+rEzwYBIKJ0epIkPiia0hqER02nc/EoKUIQBjWuf+q7LOy4uqFR6xh9y2UHmOFm461Z2wC/03QUyQHW9vGsAD1MA6F5DOnRVx/k6+oLXehTTIAUVXABJBZ3yQTZf62xAWoxkcVQeV7PP5lDqHy2ZkCDRAWD826d8EtSsJ0uIWtQ6KNxZe9bIp9Fjder3O81yHuUplXxzJ/IGXhQIs+2R4Zjfk65SagCO2/NTwKcySzCvCy84gt60VFfg59CIXbEAIx+dL4tesXB/fwSt6Yt9hpvynW+KAAUlrH/uCix+JxzE9FizWQxlCa4w+0gUzuuPW1oxNJa0/0wtbmeF/AKuanPxNPxZc7wefXUedwqxaF1rwoWlU0eZRPjsIVLCwv/20PJ4QcmlJ+QZctcfdpI5rDah8TJsm1+SRMrK/h8SfgyH5+aGsbWG 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 Thu, Apr 25, 2024 at 2:09=E2=80=AFPM Kent Overstreet wrote: > > On Thu, Apr 25, 2024 at 01:55:23PM -0700, Kees Cook wrote: > > The system will immediate fill up stack and crash when both > > CONFIG_DEBUG_KMEMLEAK and CONFIG_MEM_ALLOC_PROFILING are enabled. > > Avoid allocation tagging of kmemleak caches, otherwise recursive > > allocation tracking occurs. > > > > Fixes: 279bb991b4d9 ("mm/slab: add allocation accounting into slab allo= cation and free paths") > > Signed-off-by: Kees Cook > > --- > > Cc: Suren Baghdasaryan > > Cc: Kent Overstreet > > Cc: Catalin Marinas > > Cc: Andrew Morton > > Cc: Christoph Lameter > > Cc: Pekka Enberg > > Cc: David Rientjes > > Cc: Joonsoo Kim > > Cc: Vlastimil Babka > > Cc: Roman Gushchin > > Cc: Hyeonggon Yoo <42.hyeyoo@gmail.com> > > Cc: linux-mm@kvack.org > > --- > > mm/kmemleak.c | 4 ++-- > > mm/slub.c | 2 +- > > 2 files changed, 3 insertions(+), 3 deletions(-) > > > > diff --git a/mm/kmemleak.c b/mm/kmemleak.c > > index c55c2cbb6837..fdcf01f62202 100644 > > --- a/mm/kmemleak.c > > +++ b/mm/kmemleak.c > > @@ -463,7 +463,7 @@ static struct kmemleak_object *mem_pool_alloc(gfp_t= gfp) > > > > /* try the slab allocator first */ > > if (object_cache) { > > - object =3D kmem_cache_alloc(object_cache, gfp_kmemleak_ma= sk(gfp)); > > + object =3D kmem_cache_alloc_noprof(object_cache, gfp_kmem= leak_mask(gfp)); > > What do these get accounted to, or does this now pop a warning with > CONFIG_MEM_ALLOC_PROFILING_DEBUG? Thanks for the fix, Kees! I'll look into this recursion more closely to see if there is a better way to break it. As a stopgap measure seems ok to me. I also think it's unlikely that one would use both tracking mechanisms on the same system. > > > if (object) > > return object; > > } > > @@ -947,7 +947,7 @@ static void add_scan_area(unsigned long ptr, size_t= size, gfp_t gfp) > > untagged_objp =3D (unsigned long)kasan_reset_tag((void *)object->= pointer); > > > > if (scan_area_cache) > > - area =3D kmem_cache_alloc(scan_area_cache, gfp_kmemleak_m= ask(gfp)); > > + area =3D kmem_cache_alloc_noprof(scan_area_cache, gfp_kme= mleak_mask(gfp)); > > > > raw_spin_lock_irqsave(&object->lock, flags); > > if (!area) { > > diff --git a/mm/slub.c b/mm/slub.c > > index a94a0507e19c..9ae032ed17ed 100644 > > --- a/mm/slub.c > > +++ b/mm/slub.c > > @@ -2016,7 +2016,7 @@ prepare_slab_obj_exts_hook(struct kmem_cache *s, = gfp_t flags, void *p) > > if (!p) > > return NULL; > > > > - if (s->flags & SLAB_NO_OBJ_EXT) > > + if (s->flags & (SLAB_NO_OBJ_EXT | SLAB_NOLEAKTRACE)) > > return NULL; > > > > if (flags & __GFP_NO_OBJ_EXT) > > -- > > 2.34.1 > >