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 B85F9C4167D for ; Mon, 28 Feb 2022 10:51:28 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 516718D000B; Mon, 28 Feb 2022 05:51:28 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 4C62C8D0001; Mon, 28 Feb 2022 05:51:28 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3B4B68D000B; Mon, 28 Feb 2022 05:51:28 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0159.hostedemail.com [216.40.44.159]) by kanga.kvack.org (Postfix) with ESMTP id 2F0548D0001 for ; Mon, 28 Feb 2022 05:51:28 -0500 (EST) Received: from smtpin19.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id DE80E9C16F for ; Mon, 28 Feb 2022 10:51:27 +0000 (UTC) X-FDA: 79191872214.19.673B274 Received: from mail-yw1-f180.google.com (mail-yw1-f180.google.com [209.85.128.180]) by imf20.hostedemail.com (Postfix) with ESMTP id 52B5B1C000E for ; Mon, 28 Feb 2022 10:51:27 +0000 (UTC) Received: by mail-yw1-f180.google.com with SMTP id 00721157ae682-2d07ae0b1bfso102900977b3.6 for ; Mon, 28 Feb 2022 02:51:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=kYkiTGE+IL621wQjI8CgMwBjCYo+uE8eI9lxYVOTdh4=; b=RgzHqIp1vA8is+C2ytkSxIxm4DQxeOY/hmAu6Qz3W1Q93ZAHaBl9TSm9MdRE48hQHp EcIAdPLfPu6/h7lXHaroH40GzxJBOSc0ioDrKP4QB8iOQlbT4slFg2FSDyrWxg4UgjE3 bOM9MSgnY3oaG+1e30qKUFXA4jeONfittua8vGZfygqJ/HPOqUbs7Q8OJ7QitjMJxPhS ZrsJDGMk23U2ili69HorKtfW6zbNnbsOYRaRVp6Tt345WWGtGJjQo0l4LAGmA0PKIsgt FUfFiZ4o46XXMd2vFJsoOHHII2yv9PvbSmtMIqAd8a/+ZEnDLxV+vb07oex9eUIV/9lw GgOQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=kYkiTGE+IL621wQjI8CgMwBjCYo+uE8eI9lxYVOTdh4=; b=AZylVo5oD3QZ4ISCiMYAGDQ227XpAYh8Fwoj0YvTCItyoXbf8inyjynT/50GDt92Ta M9TI192ubFp/JZOC20hguCensbNl906kz0Eqibie1omplxB7X5OjNS286NKxjBPOj4nA G2rqD7ZsEmT2BUZZc8HMEb7sL+yODBNABQB4vS8CqrqVPI1h4cNAaBEN+wNZgtfuMwB/ GboDyIye0wBgf/uw1FLdH97Uc2gIoJlcnNmZtID9kbZweo76DX1jPwweRbG033KcqqGM +XLtgrBa11uqWswj3ZKidR8W9ZoZ25/fl8opsHGxiSRUnUXwPehuilv0S+0Ewp07OHW5 jcng== X-Gm-Message-State: AOAM533BBi1hej7Kv96y5TTNSPIaH5MhQk5dq5e7Wf4ULyc7IND33GCk nOUzLNOFRj7ymVaHEDD1+0ccIzAPhniiU1qQIP/tOw== X-Google-Smtp-Source: ABdhPJxNJhPVWSLXvI3iBbzOTe+qklatZ5k5QaYFXfBVeasYi8gKHeTY8TCV153zvQlSda9HbUSe36S5qOS966ph55M= X-Received: by 2002:a81:1a49:0:b0:2d7:fc73:dab2 with SMTP id a70-20020a811a49000000b002d7fc73dab2mr19291710ywa.316.1646045486359; Mon, 28 Feb 2022 02:51:26 -0800 (PST) MIME-Version: 1.0 References: <20220225180318.20594-3-vbabka@suse.cz> In-Reply-To: From: Marco Elver Date: Mon, 28 Feb 2022 11:50:49 +0100 Message-ID: Subject: Re: [PATCH] lib/stackdepot: Use page allocator if both slab and memblock is unavailable To: Hyeonggon Yoo <42.hyeyoo@gmail.com> Cc: Vlastimil Babka , David Rientjes , Christoph Lameter , Joonsoo Kim , Pekka Enberg , Roman Gushchin , Andrew Morton , linux-mm@kvack.org, patches@lists.linux.dev, linux-kernel@vger.kernel.org, Oliver Glitta , Faiyaz Mohammed , Dmitry Vyukov , Eric Dumazet , Jarkko Sakkinen , Johannes Berg , Yury Norov , Arnd Bergmann , James Bottomley , Matteo Croce , Andrey Konovalov , Imran Khan , Zqiang Content-Type: text/plain; charset="UTF-8" X-Rspam-User: X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: 52B5B1C000E X-Stat-Signature: q1hzde3ngdgn7ib5yjik4una176ud9n3 Authentication-Results: imf20.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=RgzHqIp1; spf=pass (imf20.hostedemail.com: domain of elver@google.com designates 209.85.128.180 as permitted sender) smtp.mailfrom=elver@google.com; dmarc=pass (policy=reject) header.from=google.com X-HE-Tag: 1646045487-898783 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: On Mon, 28 Feb 2022 at 11:05, Hyeonggon Yoo <42.hyeyoo@gmail.com> wrote: [...] > > This is odd - who is calling stack_depot_init() while neither slab nor > > memblock are available? > > It's not merged yet - but Oliver's patch (2/5) in his series [1] does: > If user is debugging cache, it calls stack_depot_init() when creating > cache. > > > @@ -4221,6 +4220,9 @@ static int kmem_cache_open(struct kmem_cache *s, slab_flags_t flags) > > s->remote_node_defrag_ratio = 1000; > > #endif > > > > + if (s->flags & SLAB_STORE_USER && IS_ENABLED(CONFIG_STACKDEPOT)) > > + stack_depot_init(); > > + > > Oliver's patch series enables stack depot when arch supports stacktrace, > to store slab objects' stack traces. (as slub debugging feature.) > > Because slub debugging is turned on by default, the commit 2dba5eb1c73b > ("lib/stackdepot: allow optional init and stack_table allocation by > kvmalloc()") made stack_depot_init() can be called later. > > With Oliver's patch applied, stack_depot_init() can be called in > contexts below: > > 1) only memblock available (for kasan) > 2) only buddy available, vmalloc/memblock unavailable (for boot caches) > 3) buddy/slab available, vmalloc/memblock unavailable (vmap_area cache) > 4) buddy/slab/vmalloc available, memblock unavailable (other caches) > > SLUB supports enabling debugging for specific cache by passing > slub_debug boot parameter. As slab caches can be created in > various context, stack_depot_init() should consider all contexts above. > > Writing this, I realized my patch does not handle case 3).. I'll send v3. > > [1] https://lore.kernel.org/linux-mm/YhoakP7Kih%2FYUgiN@ip-172-31-19-208.ap-northeast-1.compute.internal/T/#t > [2] https://git.kernel.org/pub/scm/linux/kernel/git/vbabka/linux.git/log/?h=slub-stackdepot-v1 > > > Do you have a stacktrace? > > Yeah, here: > > You can reproduce this on vbabka's slab-stackdepot-v1 branch [2] with > slub_debug=U, and CONFIG_STACKDEPOT_ALWAYS_INIT=n > [...] > [ 0.000000] Call trace: > [ 0.000000] __memset+0x16c/0x188 > [ 0.000000] stack_depot_init+0xc8/0x100 > [ 0.000000] __kmem_cache_create+0x454/0x570 > [ 0.000000] create_boot_cache+0xa0/0xe0 I think even before this point you have all the information required to determine if stackdepot will be required. It's available after setup_slub_debug(). So why can't you just call stack_depot_init() somewhere else and avoid all this complexity? > [ 0.000000] kmem_cache_init+0xf8/0x204 > [ 0.000000] start_kernel+0x3ec/0x668 > [ 0.000000] __primary_switched+0xc0/0xc8 > [ 0.000000] Code: 91010108 54ffff4a 8b040108 cb050042 (d50b7428) > [ 0.000000] ---[ end trace 0000000000000000 ]--- > [ 0.000000] Kernel panic - not syncing: Attempted to kill the idle task! > [ 0.000000] ---[ end Kernel panic - not syncing: Attempted to kill the idle task! ]---