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 A7462C433F5 for ; Tue, 5 Apr 2022 02:01:28 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 36C616B0073; Mon, 4 Apr 2022 22:01:18 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 31BAB6B0074; Mon, 4 Apr 2022 22:01:18 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 16F176B0075; Mon, 4 Apr 2022 22:01:18 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (relay.a.hostedemail.com [64.99.140.24]) by kanga.kvack.org (Postfix) with ESMTP id 021926B0073 for ; Mon, 4 Apr 2022 22:01:17 -0400 (EDT) Received: from smtpin10.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id BEE89238DF for ; Tue, 5 Apr 2022 02:01:07 +0000 (UTC) X-FDA: 79321172574.10.1939F56 Received: from mail-pf1-f177.google.com (mail-pf1-f177.google.com [209.85.210.177]) by imf28.hostedemail.com (Postfix) with ESMTP id 4E445C000A for ; Tue, 5 Apr 2022 02:01:07 +0000 (UTC) Received: by mail-pf1-f177.google.com with SMTP id x31so10699749pfh.9 for ; Mon, 04 Apr 2022 19:01:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=XCPmRc0IVgYgnGswAlG4yXz+KuFMoJ3P6+aO8i17Nyw=; b=JegdvKFJkQly7ZyOveDWGt3k2Kyk57pEOEbrjKjqlmrb8+N+YI46tYuhBKqNuRYMro 9/zY4m8gN/H7O3MEMJvKvagY3bW6+TAP61AK+EbqU+iunqW56CxOIdlXHYEePfaLXvHo fAmn8QSljckU4vKvpTPybkSn8jmlyKRYfzgTo3NOlY86VWS27hx7ohejcDgv28D1xnVr QJS6lZE4K8+HG3gDQYEGqHFnqwP1EDMJkpvm9ZHYEDMeeJbT45cpU72jDzpeqMHW8PzC 9KoInl5KIBPSzgpVM0H3ep5cUrlvGTHSxLDMjqzVi/UH4VxEDup/tGbViIWle/Lr4I0L t3xQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=XCPmRc0IVgYgnGswAlG4yXz+KuFMoJ3P6+aO8i17Nyw=; b=ZOV+QY+k3Zq6O20g61u+unogsAg1HmxTfpfGpup+BThRw6A+xG03GI9YL8ZDQdDZAl nNHtW91wA1JeTB0YThhWIMmYOu1O2QQOkqmy/5YCYpzKu24TE/bBb5K3zhYqip909hgJ cVmtHMSQnyCJkRza82NGp+9eBVm9mmhmba8pRFYm9bb/zJJpuSy71kQHesW3ygi2e5AM RArSAwijQO7LEzVepqaQnAVthe5pUcz2qL/M4s52YYLRmEdGNEdATWDYPKBbFatp2/jU DE6+mQY5QjnfjJZe2L7AuLugrlM2+udB6pK+LPV8idkvv7J0wMoFuhao7e4MC+V6AysS 7BzQ== X-Gm-Message-State: AOAM533OGHqEbxttPexLC8RJNj9n9uroQKivDwI1HuByVla/hTq3Zanv 0/Zn9nEEwZyQSP3z0waqPFs= X-Google-Smtp-Source: ABdhPJx8ODqukr4ThTQP2Zolc7rN01PScQwudBUJ4+CZTh017i28ntS57/D4l+okojym+X/7MmPsCg== X-Received: by 2002:a63:b24b:0:b0:398:9894:b8be with SMTP id t11-20020a63b24b000000b003989894b8bemr947415pgo.108.1649124066161; Mon, 04 Apr 2022 19:01:06 -0700 (PDT) Received: from hyeyoo ([114.29.24.243]) by smtp.gmail.com with ESMTPSA id q27-20020aa7961b000000b004fdf7a4d49esm6458763pfg.170.2022.04.04.19.01.01 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 04 Apr 2022 19:01:05 -0700 (PDT) Date: Tue, 5 Apr 2022 11:00:58 +0900 From: Hyeonggon Yoo <42.hyeyoo@gmail.com> To: Marco Elver Cc: Vlastimil Babka , kernel test robot , Oliver Glitta , lkp@lists.01.org, lkp@intel.com, LKML , Imran Khan , Andrey Konovalov , Zhen Lei , Zqiang , linux-mm@kvack.org Subject: Re: [mm/slub] 555b8c8cb3: WARNING:at_lib/stackdepot.c:#stack_depot_fetch Message-ID: References: <20220323090520.GG16885@xsang-OptiPlex-9020> <20220324095218.GA2108184@odroid> <8368021e-86c3-a93f-b29d-efed02135c41@suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: 4E445C000A X-Rspam-User: Authentication-Results: imf28.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=JegdvKFJ; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf28.hostedemail.com: domain of 42.hyeyoo@gmail.com designates 209.85.210.177 as permitted sender) smtp.mailfrom=42.hyeyoo@gmail.com X-Stat-Signature: r438817jdf49my143y59ef335jimqhz7 X-HE-Tag: 1649124067-304628 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, Apr 04, 2022 at 05:18:16PM +0200, Marco Elver wrote: > On Mon, 4 Apr 2022 at 16:20, Vlastimil Babka wrote: > > > > On 4/4/22 10:10, Marco Elver wrote: > > > On Mon, Apr 04, 2022 at 12:05PM +0900, Hyeonggon Yoo wrote: > > > (Maybe CONFIG_KCSAN_STRICT=y is going to yield something? I still doubt > > > it thought, this bug is related to corrupted stackdepot handle > > > somewhere...) > > > > > >> I noticed that it is not reproduced when KASAN=y and KFENCE=n (reproduced 0 of 181). > > >> and it was reproduced 56 of 196 when KASAN=n and KFENCE=y > > >> > > >> maybe this issue is related to kfence? > > > > Hmm kfence seems to be a good lead. If I understand kfence_guarded_alloc() > > correctly, it tries to set up something that really looks like a normal slab > > page? Especially the part with comment /* Set required slab fields. */ > > But it doesn't seem to cover the debugging parts that SLUB sets up with > > alloc_debug_processing(). This includes alloc stack saving, thus, after > > commit 555b8c8cb3, a stackdepot handle setting. It probably normally doesn't > > matter as is_kfence_address() redirects processing of kfence-allocated > > objects so we don't hit any slub code that expects the debugging parts to be > > properly initialized. > > > > But here we are in mem_dump_obj() -> kmem_dump_obj() -> kmem_obj_info(). > > Because kmem_valid_obj() returned true, fooled by folio_test_slab() > > returning true because of the /* Set required slab fields. */ code. > > Yet the illusion is not perfect and we read garbage instead of a valid > > stackdepot handle. > > > > IMHO we should e.g. add the appropriate is_kfence_address() test into > > kmem_valid_obj(), to exclude kfence-allocated objects? Sounds much simpler > > than trying to extend the illusion further to make kmem_dump_obj() work? > > Instead kfence could add its own specific handler to mem_dump_obj() to print > > its debugging data? > > I think this explanation makes sense! Indeed, KFENCE already records > allocation stacks internally anyway, so it should be straightforward > to convince it to just print that. > Thank you both! Yeah the explanation makes sense... thats why KASAN/KCSAN couldn't yield anything -- it was not overwritten. I'm writing a fix and will test if the bug disappears. This may take few days. Thanks! Hyeonggon > Thanks, > -- Marco