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 82DF9C3DA4A for ; Thu, 8 Aug 2024 15:54:16 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 12C016B00D6; Thu, 8 Aug 2024 11:54:16 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 0B4736B00E0; Thu, 8 Aug 2024 11:54:16 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id EBF316B00E6; Thu, 8 Aug 2024 11:54:15 -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 CA3716B00D6 for ; Thu, 8 Aug 2024 11:54:15 -0400 (EDT) Received: from smtpin04.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 91FF71A15AD for ; Thu, 8 Aug 2024 15:54:15 +0000 (UTC) X-FDA: 82429524870.04.63526FA Received: from mail-lj1-f175.google.com (mail-lj1-f175.google.com [209.85.208.175]) by imf03.hostedemail.com (Postfix) with ESMTP id 4D11220017 for ; Thu, 8 Aug 2024 15:54:13 +0000 (UTC) Authentication-Results: imf03.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=google header.b=HW9kDAso; spf=pass (imf03.hostedemail.com: domain of torvalds@linuxfoundation.org designates 209.85.208.175 as permitted sender) smtp.mailfrom=torvalds@linuxfoundation.org; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1723132388; 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=EX5+8aeSzFSKcA+0lbl8uR/ffra+3uio0EheWhiGtJ4=; b=sc1+tIjoACYJIlIIVGn/eWE7y8XOPPf8XX6FEwPV9HH7fpdrjLPAcUNYaii8f2ahc7+I1X 1g4upHqlfRLP0b1deAk7t5xThuq5OlZ0SgRj9PAofe+TACN567DVpss5159ADNxTUClMP0 Khc2gKvu9+Ean3lZMwP4qxWTpZadKO8= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1723132388; a=rsa-sha256; cv=none; b=1q1Lz0GodpqNKJ85p1bA2Jrhs8xkVmWspQq92mI3/haHop+t/Iae6mTpr9AbYHzCvinkJ6 d/AqV6Laog85/BPxhBxmXFlxv5YMRU2+ySxhamFZf1XEhqb80IjTd6IZZA+i+tJMH5tjk0 soHK3oIPcGiubr/Impckxt9T7tJ2eaA= ARC-Authentication-Results: i=1; imf03.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=google header.b=HW9kDAso; spf=pass (imf03.hostedemail.com: domain of torvalds@linuxfoundation.org designates 209.85.208.175 as permitted sender) smtp.mailfrom=torvalds@linuxfoundation.org; dmarc=none Received: by mail-lj1-f175.google.com with SMTP id 38308e7fff4ca-2f15790b472so13468871fa.0 for ; Thu, 08 Aug 2024 08:54:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; t=1723132451; x=1723737251; darn=kvack.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=EX5+8aeSzFSKcA+0lbl8uR/ffra+3uio0EheWhiGtJ4=; b=HW9kDAsologQNPmTUhPn5Rca4zzOuNy3qDK84yizkm/Zvc/atYoUTrUc7dYcrYw5og xOf8r280clOCvOmIkLBHXd0GdK6wU+aLNcuMefxoOKRttA5wpskYj2r9DMysbH1YTEir 8nA527tD+K1kTwKNQIXVkL7FoFSi8CbqE5XZ8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1723132451; x=1723737251; 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=EX5+8aeSzFSKcA+0lbl8uR/ffra+3uio0EheWhiGtJ4=; b=FpoZklOS0ozJJFkfPrDfmWmQ4sPpsVFbJ7oPTuYJG7JbdNxRJQSwdzStWYVjX27tnr 12va6AsaQ1h96nXk3nD2KDTCULhl/T9K6wEXlpEcgEtuLREYcrygaf6SQfpWWGKNLFEu dNflMIjmhMz3H+RFRVD+Lzt8LjY1D0SAEo1R2+9OdMGL9Avm6jdOfWbup2eAjILcWyWy cvALj/F84D8YIsDgWI0R/VT95k7Wj5qbpCNQvWrrFcIIYm1/d7flvPqAP45n0duRlN56 SOu69mgvk+k6QBNxOxIznq7yo+vEowGR7C63ukWynKSXYk07+NIyhWCQiM3aiAX1zqIP /pfQ== X-Forwarded-Encrypted: i=1; AJvYcCXQ25QVuMLTP1mByiuN5S+ySaF4YANKo7UPYH5TwnyE4oBAknqkTyogustgGEslIrY7MagwnPCCKvRpqHk0+7mM/Zc= X-Gm-Message-State: AOJu0YxLDPtrAbooYqVltF66NBYTPj92Im7xM0IpgV3mVF4M+lmF9X0J jQ4U+SjYqp7Qlpwo0Bf2sJUpo0nqXna8XZt48Z+Q0jbEarrPyDWBK/M8gQcqBXBXo9rvPXxXTPA 4e6ETDw== X-Google-Smtp-Source: AGHT+IEEW9HVnMKeiP3TO4PzUISiTxoylpBnGYNh2fLvc41SadAB2sVCIoi4lhSQIMFAoW7/9MXwxA== X-Received: by 2002:a05:6512:238a:b0:52e:f9f1:c13a with SMTP id 2adb3069b0e04-530e5815a47mr1749063e87.12.1723132450929; Thu, 08 Aug 2024 08:54:10 -0700 (PDT) Received: from mail-ej1-f47.google.com (mail-ej1-f47.google.com. [209.85.218.47]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-a7dc9d89aacsm745465666b.159.2024.08.08.08.54.10 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 08 Aug 2024 08:54:10 -0700 (PDT) Received: by mail-ej1-f47.google.com with SMTP id a640c23a62f3a-a77ec5d3b0dso133361166b.0 for ; Thu, 08 Aug 2024 08:54:10 -0700 (PDT) X-Forwarded-Encrypted: i=1; AJvYcCU6Yuqaugvfj46qPykTDJ2ZY7Qza32wWLRpBvHz1pU/9e+tzg7whILN92d479yN1zfwENuZ0MEW9gcWgZBx11gM8ZU= X-Received: by 2002:a17:907:f716:b0:a77:cbe5:413f with SMTP id a640c23a62f3a-a8090c2228bmr161289566b.4.1723132449801; Thu, 08 Aug 2024 08:54:09 -0700 (PDT) MIME-Version: 1.0 References: <20240731095022.970699670@linuxfoundation.org> <718b8afe-222f-4b3a-96d3-93af0e4ceff1@roeck-us.net> <53b2e1f2-4291-48e5-a668-7cf57d900ecd@suse.cz> <87le194kuq.ffs@tglx> <90e02d99-37a2-437e-ad42-44b80c4e94f6@suse.cz> <87frrh44mf.ffs@tglx> <76c643ee-17d6-463b-8ee1-4e30b0133671@roeck-us.net> <87plqjz6aa.ffs@tglx> In-Reply-To: <87plqjz6aa.ffs@tglx> From: Linus Torvalds Date: Thu, 8 Aug 2024 08:53:52 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH 6.10 000/809] 6.10.3-rc3 review To: Thomas Gleixner Cc: Guenter Roeck , Vlastimil Babka , linux-kernel@vger.kernel.org, Linux-MM , Helge Deller , linux-parisc@vger.kernel.org Content-Type: text/plain; charset="UTF-8" X-Stat-Signature: t3co7b7tu7k988dc5fjjficain5ggr7p X-Rspamd-Queue-Id: 4D11220017 X-Rspam-User: X-Rspamd-Server: rspam08 X-HE-Tag: 1723132453-694217 X-HE-Meta: U2FsdGVkX18r5mShmP/q/Hxg97vuD+YTnnI4GnWOrdP+PAZ+0tU7KkAE5dlGMkqMliegSTGu/H3Qy4Uj9w4ux16d/JQYSwU0zSD2yTLjfa2s8YLCNKFPOpNev/siQZmbmhPN7ctHhPMXpqJFYk9y7p/hSxICt9l6ZDtVGQxzOOWK75uVWifILKGix212aGIeRH+Y/3cLwQSBWxe/QhmfHj3bBgy2aPQy+QfEZj4PgELXBNPCT4Pi6NVHVnrRNYvXgHgxbkBBCmQGxTA0dSMet6LUzcPj+6PLQOwaTuj6pkrmRttV7z+rMJSzUsRTrNjtM23IJZOpO540ipaJHV5E5zrcC1UCo8IsvMD6Veg4h4VP3FiHseGfYRmS2RC8aD8sa99BsoGzVby04tLXj1c+8S4fZg/rX5i+eDCCo4BK+Y6qbcnqVpIX9MW+nAGaUURM/YJAYvIxyEv8DROb0LjlGzNyo+hkByOt+6MnjXz8VQfCOa9XsM/fY+9kboblLtcBZeK+vxlL4W6wUpDNcC5I8AbrS701OuxOBpA/oVYgcfJ90V6QGWSJpd8qXFdSZB0Q//T0Jv8tDKbL2FCevL3Hf2zlD6ke9xjYWzjcGOjw7hTJxrfZ/Z1KHwuOnugTBIaEPV8Vx0GSGG/7tHElZPz1NTmdjeW9gggS9oubnaN6MptP6P2m8q6uSX2h2kCwW4seV2XBn8f936E0CMo81VZmx8ZzpgQFmqwAzYmG2Sgdt/edKqkB3KY3th8+4MJm7s4BH9Yfwl7SgKMc0WVwXyxum0/Axjye+poI0X0KQv3ClRxOUMimAYop9bGvV836bez+jy9NWLKtWUGVXQbMejQU2r80Tjr/MTiIxN62/qfMFLbVbb7MjwQeTJw1mhTKs0FvBgGT5DeQJm7occDEm6gbQfsYkdbIUCFXCHcJyZqQJj8ELj1l3IqZif/USJGb0aUoZMYpWhBQ3gao8amwtb1 2xQqUOpN 5Pn3zwDW1LYOAld74GHtu2exPyToc1U0cuDHxuKjk1izkJelaKMjtOoUQJSsmO7SE0mpZxrRJXyoI4TagTZJH/vFnJmb76Hr/BrNywF8lzlwxAUed0WZOM7KemOSo9CPGJ6ZH3ffad/ltBeK/irVr1rOpbUt1+8cEMTXFK+P0lZ2Z8KcbRfxyGpm0kGPiKB8kapBkvURZ8aoTSuCJPKvDmdBLM7Th6e30ifROhSCq8ffvMubPxyuHiD7LIB08ZuCb8w08JQLvCDir5YiIxGLEKrYWz7mOt/24Keg6SnB7fyJr/G+ixKZ0A2F/aY3HnOYPpclmofRRbmKVG1UJY7qEjkoQLK4o+2wgBqFw+ZQW5dGFiYDcKy+CiLW5P2XQKWQ4ppz0Ypw27nXF3EB5kyythw02TbRGJfDw6TiCTpWaspptcK3vqIzkHzhkBcN07xNegNbvm6qIBpAWVetuPvtJndTygco13SaCOBEqcZyNZUxtzcQptS7MLTd0W+S8swHIR2KNw8LqZY7zzik= 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, 8 Aug 2024 at 02:57, Thomas Gleixner wrote: > > Careful vs. the pr_once(). It's not necessarily the first allocation > which trips up. I removed slab_err() in that condition and just printed > the data: > > [ 0.000000] Order: 1 Size: 384 Nobj: 21 Maxobj: 16 21 Inuse: 14 > [ 0.000000] Order: 0 Size: 168 Nobj: 24 Maxobj: 16 24 Inuse: 1 > [ 0.000000] Order: 1 Size: 320 Nobj: 25 Maxobj: 16 25 Inuse: 18 > [ 0.000000] Order: 1 Size: 320 Nobj: 25 Maxobj: 16 25 Inuse: 19 > [ 0.000000] Order: 1 Size: 320 Nobj: 25 Maxobj: 16 25 Inuse: 20 > [ 0.000000] Order: 0 Size: 160 Nobj: 25 Maxobj: 16 25 Inuse: 5 > [ 0.000000] Order: 2 Size: 672 Nobj: 24 Maxobj: 16 24 Inuse: 1 > [ 0.000000] Order: 3 Size: 1536 Nobj: 21 Maxobj: 16 21 Inuse: 1 > [ 0.000000] Order: 3 Size: 1536 Nobj: 21 Maxobj: 16 21 Inuse: 2 > [ 0.000000] Order: 3 Size: 1536 Nobj: 21 Maxobj: 16 21 Inuse: 10 > > The maxobj column shows the failed result and the result from the second > invocation inside of the printk(). Hmm. There's a few patterns there: - the incorrect Maxobj is always 16, with wildly different sizes. - the correct value is always in that 21-25 range and neither of these are particularly common cases for slab objects (well, at least on x86-64). I actually went into the gcc sources to look at the libgcc routines for the hppa $$divU routine, but apart from checking for trivial powers-of-two and for divisions with small divisor values (<=17), all it is ends up being a series of "ds" (divide step) and "addc" instructions. I don't see how that could possibly mess up. It does end up with the final addc in the delay slot of the return, but that's normal parisc behavior (and here by "normal" I mean "it's a really messed up instruction set that did everything wrong, including branch delay slots") I do note that the $$divU function (which is what this all should use) oddly doesn't show up as defined in 'nm' for me when I look at Guenter's vmlinux file. So there's some odd linker thing going on, and it *only* affects the $$div* functions. Thomas' System.map shows some of the same effects, ie it shows $$divoI (signed integer divide with overflow checking), but doesn't show $$divU that is right after it. The reason I was looking was exactly because this should be using $$divU, and clearly code alignment is implicated somehow, but the exact alignment of $$divU wasn't obvious. But it looks like "$$divU" should be somewhere between $$divoI and $$divl_2, and in Guenter's bad case that's 0000000041218c70 T $$divoI 00000000412190d0 T $$divI_2 so *maybe* $$divU is around a page boundary? 0000000041218xxx turning into 0000000041219000? Some ITLB fill issue together with that delayed branch and a qemu bug? Linus