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 708B6C32793 for ; Wed, 18 Jan 2023 17:11:07 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 120AB6B0078; Wed, 18 Jan 2023 12:11:07 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 0A9F96B007B; Wed, 18 Jan 2023 12:11:07 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E3E2C6B007D; Wed, 18 Jan 2023 12:11:06 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 245996B0078 for ; Wed, 18 Jan 2023 12:11:06 -0500 (EST) Received: from smtpin05.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id E7E1E120574 for ; Wed, 18 Jan 2023 17:11:05 +0000 (UTC) X-FDA: 80368560090.05.BF40E5C Received: from mail-yb1-f175.google.com (mail-yb1-f175.google.com [209.85.219.175]) by imf17.hostedemail.com (Postfix) with ESMTP id D9FC840016 for ; Wed, 18 Jan 2023 17:11:03 +0000 (UTC) Authentication-Results: imf17.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=google header.b=bW+I6GT3; dmarc=none; spf=pass (imf17.hostedemail.com: domain of torvalds@linuxfoundation.org designates 209.85.219.175 as permitted sender) smtp.mailfrom=torvalds@linuxfoundation.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1674061864; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=fdqIaz/OuT3KiECAYbJfl+d3yacajyE8FY/hHAgDXU4=; b=o51wefLBlWIdV/WlpQZ3Ge8tuUyAI6CNVsMOrCiV1NyR5OcKlTZUDhe0yMRYosplEOrdKL dQbcxSZm3tKwVAM2b/d8il8NS/1hSRoNbYUTHq7uuI5ZsQxSMl1Kc+wa9klt3dAg9zkvAz aZM0ecZilcXrcFpEBizpe4f36ldiVI0= ARC-Authentication-Results: i=1; imf17.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=google header.b=bW+I6GT3; dmarc=none; spf=pass (imf17.hostedemail.com: domain of torvalds@linuxfoundation.org designates 209.85.219.175 as permitted sender) smtp.mailfrom=torvalds@linuxfoundation.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1674061864; a=rsa-sha256; cv=none; b=7aS3jfPexP2cKRfK21yY6cs/YJNS/kCGAp+6v8v2xRjMR46B23mlwgEgSeLVxFXXLP3JCr xKjs5YyPUEf1xUPwo5mVsMQjpf/VfbSWwBb4Wu61hPzOmW8TxnjZMiqD+hi8kfdehHeHQM 3ebgpAWtEfZceOgKcPGsQJWs7O/1y88= Received: by mail-yb1-f175.google.com with SMTP id 20so19841608ybl.0 for ; Wed, 18 Jan 2023 09:11:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=fdqIaz/OuT3KiECAYbJfl+d3yacajyE8FY/hHAgDXU4=; b=bW+I6GT3472rBqyqGwRHftx7r2GGIogKz2Y0oQTedgzUrfMCpXWKof68tlXZFbetUY 2WATXsTp3RN1pb5gw6psBaXonl0PhuZDMJziCI8xLhFsEUJHCwD7EFzPgWd1Kuk7vxkd FZsGsrkAAdXlgWHrdqvwR81hEpMUYuiE/bHLE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=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=fdqIaz/OuT3KiECAYbJfl+d3yacajyE8FY/hHAgDXU4=; b=pahYWoEMiLK+IzM1H1jK0rDurY5mG5EKKph68m9hOHV8IRJ6Ld6pCkwnn9Pa+6vLE5 8QOIz/2Jc6bK9o6iPaffAOCarfE8NJCBmpZwHLgAgOXu2HKK9kfaIyuFN3q0vmE55VC1 fjYUVYBuQF1ZqYts2RIJItkIOkPWCHWGgZx7ynkkuKAuiuPDsMcok38ftHTiQB2k8yXR K8q6v1RerEacHnTc5ifgaTaeu0yi+9z8ieCl0Ko71luWNVehvtTr1K4uIAEsVomssAu0 53beJNVjIRu/M5chMEhFzQ/79a99IUPn6rulc57LAIc+hqAH8ubSiaJPE7j7n/7b77XO d3jA== X-Gm-Message-State: AFqh2kpoNNbC83HGM3juI+2XsQNBlT6OgVn3pAsbNRHDNAf73kH3FT2J QPVoow8aAIXXrlbBu/gp++ajjbSZx17towFS X-Google-Smtp-Source: AMrXdXsLKpj19xb1Tr02OW/I6DU4e4HF+FBdRWMMpke94sEw3lSY2uwLn8abR4kpQiNBo/0gfnRZDw== X-Received: by 2002:a05:6902:514:b0:719:f3e1:1d43 with SMTP id x20-20020a056902051400b00719f3e11d43mr5923530ybs.44.1674061862591; Wed, 18 Jan 2023 09:11:02 -0800 (PST) Received: from mail-qv1-f51.google.com (mail-qv1-f51.google.com. [209.85.219.51]) by smtp.gmail.com with ESMTPSA id de9-20020a05620a370900b007057cc1e87bsm22180473qkb.136.2023.01.18.09.11.01 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 18 Jan 2023 09:11:01 -0800 (PST) Received: by mail-qv1-f51.google.com with SMTP id q10so24172506qvt.10 for ; Wed, 18 Jan 2023 09:11:01 -0800 (PST) X-Received: by 2002:a05:6214:5f82:b0:534:252f:b091 with SMTP id ls2-20020a0562145f8200b00534252fb091mr345510qvb.130.1674061861468; Wed, 18 Jan 2023 09:11:01 -0800 (PST) MIME-Version: 1.0 References: <202301170941.49728982-oliver.sang@intel.com> <2f483247-da76-9ec9-3e51-f690939f4585@suse.cz> In-Reply-To: From: Linus Torvalds Date: Wed, 18 Jan 2023 09:10:45 -0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [linus:master] [hugetlb] 7118fc2906: kernel_BUG_at_lib/list_debug.c To: Feng Tang Cc: Vlastimil Babka , "Sang, Oliver" , Mike Kravetz , "oe-lkp@lists.linux.dev" , lkp , "linux-kernel@vger.kernel.org" , Jann Horn , "Song, Youquan" , Andrea Arcangeli , Jan Kara , John Hubbard , "Kirill A . Shutemov" , Matthew Wilcox , Michal Hocko , Muchun Song , Andrew Morton , "linux-mm@kvack.org" , Hyeonggon Yoo <42.hyeyoo@gmail.com>, "Yin, Fengwei" , hongjiu.lu@intel.com Content-Type: text/plain; charset="UTF-8" X-Rspam-User: X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: D9FC840016 X-Stat-Signature: mfqy1zxeqstn65q1pgzeqzdikyeyba8m X-HE-Tag: 1674061863-303458 X-HE-Meta: U2FsdGVkX1+hwTyze0lN6+VowUvixgd0MpGu/eSaYaE0RgddRy38HS39DiuWkUQWF4PghUj7JBUKfrzoEExm31EKzM3mUZpWNeH0neuH9a0I0fvqkDF8PPL1AAyVNMcwnmSHPDe6NOMRkRJb/LrOM3u1izLnpuiNVrThE2A/heKnDLN86o1vQRBayVwYBC4k6ZV+FTtsGnmiEJx0lrGEcYit5MQVMFqu8UVWwreDTly36yqfnnpOpLvUcaFoX0renUcH9lhpyttKpE702lbo9f5pwP7U4T1dFRXoROCXxkK9olkt/ajzVPA6iDBCeX/nixeSIlwzqo5jRw/tdT1bRCdThbYCWLA4nfe+swJhOU/Dy84cqB0QUO5c+Fq3EQ8EezPcXkl6VVIJNVDGmaOby/SrahHfteUw4mCDRBqUBN/ZHINVJSLvzIE083G5esDBAoUfzKfpVCif2PcxuJIk09wEKQlMxugWAQT6xorSZJcNHbotgV0k0PTdcM6ug8GZ/JbdZ2a2yFOWWDJd4QStMa07uBnBn604B3SEEuJSFpeAHKExNN0eVQiTdFu1ugIwl1ef/BZwEYPOsoy5OVDKWZpMjRcNj+bbI5LKIxmjWGk0oVT5bjm88et5jtL9AlIeguzk3f+FjXmCnoq46DvkYfPhbsb6USUghWDiSEyuITydjdzdmS3yfmNuzMfND8IkNdkOPtUFpDQSln1tkPpJuVmIV0TfkTfMv3TG/AOK6L0AdCi1p6XNTySA4+6rqvGdowms0AdpRz5hVFnkR4FjiFGVzhZN3oLtjysKQC2C63RW+k5z6olvoSqrFnrXhjEYNvbXkkNBdMBzuuiIm/Zot93eD1GGeM0ig/u+l/N4yfea5N06jFBmKf4tJztJMMTYhdNlkzXvh+BKK1HA7BdM2N3MrLMxn7stUN9h01+gRpNKQ1Rgc26YbG1ItHc2e/YVBxR6WKW4RLqdc7Z3MD0 30QdNH6O VlqWVdw9NdI/vjpxNtQgUZNxFs58sJm5tRgMSYZ/EUGLxQq04NEgg9fWT948VabtlMtPzuVaXGRhxvsqNGsZfQwOtwOI5u2Wcp1dkzQsWZ9dfLIr5Mr8ilcM9tzvCJnNyYXlafgdwNeeAbnMMlJI+VvEXlrjQG7783irKGK+1/1Jit4sDH4LyEckzZDmLdYBRhyHx+cpvxLRJQwe+Js3uDbWgY8YvTFQp/nULrn7dwxmZABpJ71GjLXCr1ZgF4ZmqQWuwSWAMQJym8zAqBpPXK/G7U4cmRZllJLjpBtsxxfr/bS+7mK2aZMDs9x/kR9XE2+aS2IxifERRNUnYvvtXEGBDzjrvYVoiQZ+x1zpl10k+DiYSmU9vZB2UjV8gUDL9nJ1AL6MPEtugcRh+7st+3mhUrqEc61lqJ89pUADG9x1GIrdS7kBDxzy9OWK0kV8xIabu 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 Wed, Jan 18, 2023 at 5:33 AM Feng Tang wrote: > > > Finally, your objdump version also does some horrendous decoding, like > > > > c13b3e29: 8d b4 26 00 00 00 00 lea 0x0(%esi,%eiz,1),%esi > > I know little about these tools, and I tried objdump tool from > Cent OS 9 (objdump version 2.35.2) and Ubuntu 22.04 (objdump version > 2.38), they both dumped similar assembly. Please let me know if you > want us to try other version of objdump. It's fine - it just makes things even less legible than they already were. I personally very seldom try to look at objdump output - I tend to do things like make mm/page_alloc.s and look at the compiler-generated assembly instead. That ends up generally being a lot more legible for various reasons, not the least of which is the variable name commentary that the compiler also outputs. So objdump is kind of a last resort, and then you just have to deal with the fact that its output format is very nasty. > We modify the kconfig to disable GCOV and UBSAN, and the issue can't > be reproudced in 1000 runs. Ok, it does seem like this is a compiler bug, as per Vlastimil's decoding. And the reason it happens on 32-bit is probably that we just have much fewer registers available there, and the 64-bit GCOV counts then complicate things even more, and then some interaction between that and UBSAN just generates crazy code. And it probably has very little compiler test coverage in real life anyway. >From Vlastimil's decode, it does look like gcc has mixed up the "update GCOV counts" with actual real values for "nr_pages", and is using %eax for both things because of some register allocation mistake. So I think we can dismiss this one as a compiler bug. It might be good to see if it happens with a newer version of gcc too, and even perhaps post a gcc bugzilla entry, but since this probably isn't really a very interesting config for real life, I'm not sure how interested people are going to be. Linus