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 C3F9DC3DA7D for ; Tue, 3 Jan 2023 14:37:01 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 4BFD68E0002; Tue, 3 Jan 2023 09:37:01 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 448308E0001; Tue, 3 Jan 2023 09:37:01 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2C1738E0002; Tue, 3 Jan 2023 09:37:01 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 1A1438E0001 for ; Tue, 3 Jan 2023 09:37:01 -0500 (EST) Received: from smtpin29.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id BA293AAC35 for ; Tue, 3 Jan 2023 14:37:00 +0000 (UTC) X-FDA: 80313739800.29.C2ED096 Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.220.28]) by imf21.hostedemail.com (Postfix) with ESMTP id C9D571C000D for ; Tue, 3 Jan 2023 14:36:58 +0000 (UTC) Authentication-Results: imf21.hostedemail.com; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=24UqXN8r; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=rOXhukER; spf=pass (imf21.hostedemail.com: domain of vbabka@suse.cz designates 195.135.220.28 as permitted sender) smtp.mailfrom=vbabka@suse.cz; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1672756619; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=bxhFS7I2ISoqjLRhc7J0LagWlzINz+tb8rFIcAjGTX0=; b=b7QHJhVbY7Ud+hYVmfVzpwTD5XJkPe8crVYK8E6Ut2hZkaKKYLJbBMgoOBdMP6EmHbJzR1 Rs7/Y02ouZXOmBtWvawGN9psr+YVI5/VSBOUXbIa75w1KpF/+LliJyt6Xa3xz05lzWRPmx eJoDyjoPwIZUoV+K8lFjRc06yudNyao= ARC-Authentication-Results: i=1; imf21.hostedemail.com; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=24UqXN8r; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=rOXhukER; spf=pass (imf21.hostedemail.com: domain of vbabka@suse.cz designates 195.135.220.28 as permitted sender) smtp.mailfrom=vbabka@suse.cz; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1672756619; a=rsa-sha256; cv=none; b=jGo5lVkpjfWNJGyfK16hOXuPmC7yi4N/MlvQPApmlV/YIg+Xf1rDH9/hnUEWfiWk/xAnkM vifzyje5/BqVDE68hdhRZ3emXobamkIqLsLzQbN1b/vmKi5zullt82d7gZb+MoksipskLz TO48Rh+i6lQSpUFsVbeU+adV7G6xQD8= Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by smtp-out1.suse.de (Postfix) with ESMTPS id 22B653EE9E; Tue, 3 Jan 2023 14:36:57 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa; t=1672756617; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=bxhFS7I2ISoqjLRhc7J0LagWlzINz+tb8rFIcAjGTX0=; b=24UqXN8rZGqaZh//q7UjI5E04o6yRatG16Cr7x7D0/TjxBvFMwnYnTDMhrImH02s2AyeFc KtV4/FZq1WUw4w4Yq7RJ9tmPlBbviakfBkdv+xuBhZ1DwI7kyQuNOWwe+h5EH4qElIKrU1 tR4g8tVUJDWD/eVkZ3eFYNVFS9dAHdE= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_ed25519; t=1672756617; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=bxhFS7I2ISoqjLRhc7J0LagWlzINz+tb8rFIcAjGTX0=; b=rOXhukERf7zQ/Sho+7sdLPsIsufjxM1JR5DVj/6pO0bbb1E5O0Gce4I4PHjuFGy3pV/r2U 1Fzos6SCJ8LRqLDg== Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by imap2.suse-dmz.suse.de (Postfix) with ESMTPS id E12271392B; Tue, 3 Jan 2023 14:36:56 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id WYEBNog9tGMtTQAAMHmgww (envelope-from ); Tue, 03 Jan 2023 14:36:56 +0000 Message-ID: <8097505c-66a6-f60d-d8aa-2c36062813ff@suse.cz> Date: Tue, 3 Jan 2023 15:36:56 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.6.1 Subject: Re: [linus:master] [mm, slub] 0af8489b02: kernel_BUG_at_include/linux/mm.h To: Oliver Sang Cc: Hyeonggon Yoo <42.hyeyoo@gmail.com>, oe-lkp@lists.linux.dev, lkp@intel.com, Mike Rapoport , Christoph Lameter , linux-kernel@vger.kernel.org, linux-mm@kvack.org, Matthew Wilcox References: <202212312021.bc1efe86-oliver.sang@intel.com> <41276905-b8a5-76ae-8a17-a8ec6558e988@suse.cz> Content-Language: en-US From: Vlastimil Babka In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: C9D571C000D X-Stat-Signature: gr5fzptdxz1s7emj1na11j7bbc1z3rst X-Rspam-User: X-HE-Tag: 1672756618-422345 X-HE-Meta: U2FsdGVkX188mULi74rM/4DMptDgEfNRyXG3A/oxvCBAjJI8uRY/AWsZjih4K5egD6dC7eprw4/4p3cubJqR60jrxp2KqkU9ukhg4roQ9xPvXWgMM9NJmZpDoblpbOUuhOuuGwbo3fM5Vi0UzHYjo/3bKQmtm7FgZrUzfSG7rGaNLlad5glJyyiBB1/4XDoyFbPl4AYWfInHVeWUdfbAhLQITWv3JV12YJ1oXxFcEtEDrdakl133RavDZoBk4fZ8vcpfuTyLZPc6SXjeMyIG3Szd5Bm1BnbuSt333oNrWpckw1hTwUIpqzxutnUjTIV1QXTANZKtpCd4WyeOtqp+KQQY6HorAQlO6jxIZs3yl+QdvjsNSv15QIfB7ZaZ+IwP6Uh3Ydwd78ZdGdCTuaSjdqRIl+3RPHPGcXDwnM5g4n4DCkzzQNpbykXJ63jUFYENcO3/yso+2uv/iLTy5tQkZKYvRkKIotQzMZQFEBmCpexrCB8emYt8M4YN9yGl4vRTbedWvspPwVk5bwHCXZyt/5vxdW9eiILtJr49elHnbMBH7WQXggNV81MwqCen+/JXR/+CUpP/k6uYEfYMrT9gMxHE5hcR0i+k0I+Z1sezjb2B4AJiREls9bRomZ5hJWjHZL7mejYxhvT/aF2Ui7EqkNLNz2O24910aGnhsQnzdKK36IDydpFm0h2nw4xzHGZC+MTIKidhkkQLDXK61Syxo66KproncOMKU85EWsN44cc1BbZlWQ7LL36SHTWXDa7Qe+mUXMKHxBQ0vEMMr7Et6K5+2WAu4oQ5+n8OXSCdVX3H0SXjqdL6U2MLZeY4+h+gJ96YHe6soLlo5/HmnWIWohVrofsEffLbhHDoA/w3OZMWKYniK1p89b9Gkozw5Ul5BNhguSvgJXpgdUiKnGunnd7PuVQLJXG+kZqdSrEkm/SL39tD6Gj3Rcc7jLD2oMmi+NgojGr1W0IaCW8NJmn S1HJ0YDh u5wluDfR0bfee1NCBPchwMFSjWG1EmzaWTjKLaLakkhT+SUWOPR95dt5+Rg== 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 1/3/23 14:46, Oliver Sang wrote: > hi, > >> >> Yet the page owner info tells us, 0x2daee was most recently used as order-1, >> and now it seems to be (based on the raw struct page dump) sitting on a pcplist. >> >> So the events leading up to this could be something like: >> >> - 0x2daee is order-1 slab folio of the inode cache, sitting on the partial list >> - despite being on partial list, it's freed ??? >> - somebody else allocates order-2 page 0x2daec and uses it for whatever, >> then frees it >> - 0x2daec is reallocated as order-1 slab from names_cache, then freed >> - we try to allocate from the slab page 0x2daee and trip on the PageTail >> >> Except, the freeing of order-2 page would have reset the PageTail and >> compound_head in 0x2daec, so this is even more complicated or involves some >> extra race? > > FYI, we ran tests more up to 500 times, then saw different issues but rate is > actually low > > 56d5a2b9ba85a390 0af8489b0216fa1dd83e264bef8 > ---------------- --------------------------- > fail:runs %reproduction fail:runs > | | | > :500 12% 61:500 dmesg.invalid_opcode:#[##] > :500 3% 14:500 dmesg.kernel_BUG_at_include/linux/mm.h > :500 3% 17:500 dmesg.kernel_BUG_at_include/linux/page-flags.h > :500 5% 26:500 dmesg.kernel_BUG_at_lib/list_debug.c > :500 0% 2:500 dmesg.kernel_BUG_at_mm/page_alloc.c > :500 0% 2:500 dmesg.kernel_BUG_at_mm/usercopy.c Hm even if rate is low, the different kinds of reports could be useful to see, if all of that is caused by the commit. >> >> In any case, this is something a debug_pagealloc kernel could have a chance >> of catching earlier. Would it be possible to enable CONFIG_DEBUG_PAGEALLOC >> and DEBUG_PAGEALLOC_ENABLE_DEFAULT additionally to the rest of the >> configuration, and repeat the test? > > ok, we are starting to test by these 2 additional configs now. Great, thanks!