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 28384C433FE for ; Sat, 12 Mar 2022 11:04:38 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id AB7FC8D0002; Sat, 12 Mar 2022 06:04:37 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id A49D48D0001; Sat, 12 Mar 2022 06:04:37 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 92E538D0002; Sat, 12 Mar 2022 06:04:37 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0040.hostedemail.com [216.40.44.40]) by kanga.kvack.org (Postfix) with ESMTP id 8422C8D0001 for ; Sat, 12 Mar 2022 06:04:37 -0500 (EST) Received: from smtpin26.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 4854EA011C for ; Sat, 12 Mar 2022 11:04:37 +0000 (UTC) X-FDA: 79235450994.26.E4106AA Received: from mail-pl1-f181.google.com (mail-pl1-f181.google.com [209.85.214.181]) by imf23.hostedemail.com (Postfix) with ESMTP id D63AC14001F for ; Sat, 12 Mar 2022 11:04:36 +0000 (UTC) Received: by mail-pl1-f181.google.com with SMTP id h5so8376857plf.7 for ; Sat, 12 Mar 2022 03:04:36 -0800 (PST) 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=xixA67+CyBszDmeLpcJ5bC/ErLQH8CHjHgxpS8GoaOg=; b=FaLddWrjzCNwNpV+4oG8wrN5zawUTnx/S2++0S0ZRKYRxMR78ty3GxOil0Zbmj8ikz k+chYyEryktbPiwQKEHbPn8RNkffjmIyd740/rFdMw5lTHeZX46BFlrOLiAAwpb9FXrH zS5kOtAffkm3QWBtFisz/Qarv/HbKrO0qthDc752+0XABN43fAazTM5BSuee8pMZkHr2 UDS6uRSdAVjtm/Vmw5Ka4G7RkAtPnpcVsEq43nPVKuvtrj99oO/c+XM0v93FYCWkmFVY saf7Ma6zqhQdpP9QMEcPe27O0mEzcmHwtt16uAGyEKCndgR3MG44bf06QArQpwW6w31M mlSw== 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=xixA67+CyBszDmeLpcJ5bC/ErLQH8CHjHgxpS8GoaOg=; b=byKobbwOfY2cjv1ZRYokl3kpI/ZTCz3uRKJOm7QhjM7UFhShxUR941PI96XWcDbe+2 zqj7zw8EPgNsH0PnODn1ndQW1Uz8b1R3qIR/GmEYDIXx6DrQfrNBik2XvLn+KsS46eTi cty6fk6n4Y+PefZtwgrUuI57YaSq5G31DPDAz2oO3mXBxiutlWVImc2u1u5A1FNduwc0 lsoGt93/k9xzWl4E4yZmwipu6rmWj7G6XP6Bk+rb8UKNh+zXcNpE4UpZV2zInTAqFhNh puolgbe6Sc8bbqBXW4iGXi+Y7vFOOuwwes0ZHM+wVKCGRO0UEazZPYGlS7pVcDW7sbHX apQA== X-Gm-Message-State: AOAM533qwA3td71ntbjH6D+1+Rxww4y3N41ZIOU+/PVPUf8gvbCpaZMf JmEWgnJOokICsfmhQex9BQA= X-Google-Smtp-Source: ABdhPJyAMdhmVdu1pjPZfi4n63j0CbVjP5SByz4pCfc/FT5kaIKcKjAvUJB0tmT20vcopupAUH9oHw== X-Received: by 2002:a17:902:b614:b0:151:f034:4058 with SMTP id b20-20020a170902b61400b00151f0344058mr15057749pls.84.1647083075766; Sat, 12 Mar 2022 03:04:35 -0800 (PST) Received: from ip-172-31-19-208.ap-northeast-1.compute.internal (ec2-18-181-137-102.ap-northeast-1.compute.amazonaws.com. [18.181.137.102]) by smtp.gmail.com with ESMTPSA id a20-20020a056a000c9400b004f7ab5a44ebsm1885214pfv.18.2022.03.12.03.04.33 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 12 Mar 2022 03:04:35 -0800 (PST) Date: Sat, 12 Mar 2022 11:04:30 +0000 From: Hyeonggon Yoo <42.hyeyoo@gmail.com> To: Vlastimil Babka Cc: kernel test robot , Oliver Glitta , lkp@lists.01.org, lkp@intel.com, LKML , linux-mm@kvack.org, Mike Rapoport Subject: Re: [mm/slub] ae107fa919: BUG:unable_to_handle_page_fault_for_address Message-ID: References: <20220311145427.GA1227220@odroid> <667d594b-bdad-4082-09d5-7b0587af2ae3@suse.cz> <20220311164600.GA1234616@odroid> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: D63AC14001F X-Rspam-User: Authentication-Results: imf23.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=FaLddWrj; spf=pass (imf23.hostedemail.com: domain of 42.hyeyoo@gmail.com designates 209.85.214.181 as permitted sender) smtp.mailfrom=42.hyeyoo@gmail.com; dmarc=pass (policy=none) header.from=gmail.com X-Stat-Signature: j6x16bdrurm6q6qk3b9erb1iinnb1f9u X-Rspamd-Server: rspam07 X-HE-Tag: 1647083076-208881 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 Sat, Mar 12, 2022 at 10:21:25AM +0100, Vlastimil Babka wrote: > On 3/12/22 02:10, Hyeonggon Yoo wrote: > > On Fri, Mar 11, 2022 at 04:46:00PM +0000, Hyeonggon Yoo wrote: > >> On Fri, Mar 11, 2022 at 04:36:47PM +0100, Vlastimil Babka wrote: > >>> On 3/11/22 15:54, Hyeonggon Yoo wrote: > >>>> On Wed, Mar 09, 2022 at 10:15:31AM +0800, kernel test robot wrote: > >>>>> > >>>>> > >>>>> Greeting, > >>>>> > >>>>> FYI, we noticed the following commit (built with gcc-9): > >>>>> > >>>>> commit: ae107fa91914f098cd54ab77e68f83dd6259e901 ("mm/slub: use stackdepot to save stack trace in objects") > >>>>> https://git.kernel.org/cgit/linux/kernel/git/vbabka/linux.git slub-stackdepot-v3r0 > >>>>> > >>>>> in testcase: boot > >>>>> > >>>>> on test machine: qemu-system-x86_64 -enable-kvm -cpu SandyBridge -smp 2 -m 16G > >>>>> > >>>>> caused below changes (please refer to attached dmesg/kmsg for entire log/backtrace): > >>>>> > >>>> > >>>> [+Cc Vlastimil and linux-mm] > >>> > >>> Thanks. > >>> lkp folks: it would be nice if I was CC'd automatically on this, it's a > >>> commit from my git tree and with by s-o-b :) > >>> > >>>> I _strongly_ suspect that this is because we don't initialize > >>>> stack_table[i] = NULL when we allocate it from memblock_alloc(). > >>> > >>> No, Mike (CC'd) suggested to drop the array init cycle, because > >>> memblock_alloc would zero the area anyway. > >> > >> Ah, you are right. My mistake. > >> > >>> There has to be a different > >>> reason. Wondering if dmesg contains the stack depot initialization message > >>> at all... > >> > >> I think I found the reason. > >> This is because of CONFIG_SLUB_DEBUG_ON. > >> It can enable debugging without passing boot parameter. > >> > >> if CONFIG_SLUB_DEBUG_ON=y && slub_debug is not passed, we do not call > >> stack_depot_want_early_init(), but the debugging flags are set. > >> > >> And we only call stack_depot_init() later in kmem_cache_create_usercopy(). > >> > >> so it crashed while creating boot cache. > > > > I tested this, and this was the reason. > > It crashed on CONFIG_SLUB_DEBUG_ON=y because stackdepot always assume > > that it was initialized in boot step, or failed > > (stack_depot_disable=true). > > > > But as it didn't even tried to initialize it, stack_table == NULL && > > stack_depot_disable == false. So accessing *(NULL + ) > > Thanks for finding the cause! > ;) > > Ideas? implementing something like kmem_cache_init_early() again? > > I think we could simply make CONFIG_SLUB_DEBUG_ON select/depend on > STACKDEPOT_ALWAYS_INIT? Oh, sounds better. If we make CONFIG_SLUB_DEBUG_ON select STACK_DEPOT_ALWAYS_INIT, that is simple solution. but stackdepot will be initialized on slub_debug=- too. But I think no one will set CONFIG_SLUB_DEBUG_ON=y if not debugging... I don't think making CONFIG_SLUB_DEBUG_ON depend on CONFIG_STACKDEPOT_ALWAYS_INIT is good solution. only KASAN selects it. -- Thank you, You are awesome! Hyeonggon :-)