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 E6F23C54E4A for ; Fri, 8 Mar 2024 18:18:26 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 24FE66B03E0; Fri, 8 Mar 2024 13:18:26 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 1FFFE6B03E1; Fri, 8 Mar 2024 13:18:26 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0C9776B03E2; Fri, 8 Mar 2024 13:18:26 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id EF16F6B03E0 for ; Fri, 8 Mar 2024 13:18:25 -0500 (EST) Received: from smtpin29.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id A7066411B6 for ; Fri, 8 Mar 2024 18:18:25 +0000 (UTC) X-FDA: 81874681770.29.1587FF6 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf04.hostedemail.com (Postfix) with ESMTP id D8C3640019 for ; Fri, 8 Mar 2024 18:18:23 +0000 (UTC) Authentication-Results: imf04.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=WuCI4pBa; dmarc=none; spf=none (imf04.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1709921904; 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=ETBOM89fDb9HSwSqHTI8gl9VA12m1/jKfDX6oYw0CZA=; b=zTi2v10Lsb1mpjSTZ5dllC+u9DgSqZxSvGKaPNhYbhET5/C8QXbPG+179bpI8juc/8nAaW xk7iG+tqGh3VgD1Ft1ov4OfQVRKx/wdqZc8AvzEvs5SHpzovbB+3gtow3AdhJvgcaWcBao qABXszsUyPUtBDciDVwZYUgEu5zf3vk= ARC-Authentication-Results: i=1; imf04.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=WuCI4pBa; dmarc=none; spf=none (imf04.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1709921904; a=rsa-sha256; cv=none; b=eFfrI6Tf4KqtozXJQw002hvqPLbluKjsTG5gzGT6I3QvPm3PMQLl66KpjQODjAJf4wEhnl bMkCjxTOk/rYUizTNFkoUiATgoKE2liy9i+ktQcGJNZYHTF5OchLkI0Uk/VkFthpiN2auZ 1dvtF9axjts1kDOhrC/uTuaa5XibwQY= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=ETBOM89fDb9HSwSqHTI8gl9VA12m1/jKfDX6oYw0CZA=; b=WuCI4pBaDjZUXosZgG6ufOO7lW EVmmzreA6kOEyy48qzZ7fXBmhp25WsuEpDqpsPcG1X1tKkMsqg3y55cf3YYtRSmmvzFRror/sATY1 INPi+bIk6N5hLnYHMvK63CFRfrnxfBVLFWGsxxOxmDmw4RaXC9Cc+HbtH7Voo5Km/QQxpp2Aslhab HRjYDQWzISCIAridjrJrFRodOBD0oQscqi9ThkF8JZWDdBpQKKa34LUQ+lhTrJvIoO/0qyuYc2b64 /z1yOFJ1sF2Bx/V1kln/JDVvmefC68oapCV8ekc2DFd+Q/mjhAaeZjC2Ll+ZQixIVk3vXaGrlrYbN 3mhIfmzg==; Received: from willy by casper.infradead.org with local (Exim 4.97.1 #2 (Red Hat Linux)) id 1rienR-0000000C34e-2qZm; Fri, 08 Mar 2024 18:18:17 +0000 Date: Fri, 8 Mar 2024 18:18:17 +0000 From: Matthew Wilcox To: Ryan Roberts Cc: David Hildenbrand , Zi Yan , Andrew Morton , linux-mm@kvack.org, Yang Shi , Huang Ying Subject: Re: [PATCH v3 10/18] mm: Allow non-hugetlb large folios to be batch processed Message-ID: References: <7415b36c-b5d3-4655-92e1-b303104bf4a9@arm.com> <644c2f60-dbb0-4fdb-8505-96f8101b2399@arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: D8C3640019 X-Rspam-User: X-Rspamd-Server: rspam05 X-Stat-Signature: 88xyda4c55976jsaru3cayyhaoxicoxk X-HE-Tag: 1709921903-708690 X-HE-Meta: U2FsdGVkX1/28SmVhKAR4qAAsBTKu2bgRe4qVH9fjLQHX24VzGn5YBbIltWvqxvU+Lgpl4kzJJ822GmyqZD0DLranUXglllZfQvI/KkGXuPR0rTTCWq3qqsI/BI3MkFZt0gahqYUngBL1o2EJJtdYEpevQWMpZ5i6COHJyQH0T+f+HSgmsnxnWma5Xzf92ZMI3OuQLkcLFMWfSbz5p1b01i3J5AYwxTx1LsEVNLeXm1OJxymLHMzSaUJSyhz543lFBr1mk7faqIasBoFOWN2SSsS36jg2Pmmj6dqgwwxc/qAzjdEtUgwoQsiL2bJ05MXIrX7Et5uQgSsbc+vCAQYYkVsTajCUXp3nw4vGyiMgCqBAUVnvBVE7ydpCR3NeglqQKQkAuQjALayau9Y1W3WIiLy+izIZl4TILR1PAMnpRjnwcerEad30sKWphRtOy/w2ci8N0CtnOM132SDJ53mfrSIKfkY1r52LVg9H3z2a438QN1LL9Gb0/x9200fJxoJd9V2S6jZICbIlxwHBXArNUC6YK9s/+ITTYTY1v/Vfjv6L5mwIhjrn4ykCTISQTK3tAk3uqhL/BcnTqT/WyxrMptHU1fRi2P3653pJ4t+D5L1Wk95Sr58DbZmvhTNDvpHYM5JT+FxvKnnhwzZJ3w4dSvNGL/R3lbNwxZsVmTGfUda9lj4siEGroZJZr3CpPOz/kDbV3Vsycv6Sd14usDfm2tVIODZXBoVY8siwPjuo3usy33KdANwqVtTGZeG3WXZKrcIz5zQIDfM8KvTounHUMVEVnXQYkrPZpkEWL6d4uPbWIof3P6qF+HqryKph4J72btZ9vXyFOc8+hw7ei9ZJw== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000006, 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 Fri, Mar 08, 2024 at 06:09:25PM +0000, Ryan Roberts wrote: > I think the world is trying to tell me "its Friday night. Stop". I can no longer > reproduce the non-NULL mapping oops that I was able to hit reliably this morning. HEISENBUG! > I do have this one though: > > [ 197.332914] Unable to handle kernel NULL pointer dereference at virtual > address 0000000000000000 > [ 197.340790] pc : deferred_split_scan+0x210/0x260 > [ 197.341154] lr : deferred_split_scan+0x70/0x260 > [ 197.347534] Call trace: > [ 197.347729] deferred_split_scan+0x210/0x260 > [ 197.348069] do_shrink_slab+0x184/0x750 > > > deferred_split_scan+0x210/0x260 is the code that I added back: > > if (!folio_try_get(folio)) { > /* We lost race with folio_put() */ > list_del_init(&folio->_deferred_list); <<<< HERE > ds_queue->split_queue_len--; > continue; > } > > We have the spinlock here so that really should not be happening. So does that > mean the list is being manipulated outside of the lock somewhere? Or maybe its > mapping (actually one of the deferred_list pointers being cleared by the buddy? > I dunno... give up. Will resume on Monday. Have a good weekend. This is actually congruent with a new theory I have which is that somewhere/somehow we're freeing the page without taking it off the deferred list. I don't see such a path, but if it does exist, we could absolutely corrupt the deferred_list in this way. Just working on a patch to make my detection patch reliable ... You have a good weekend too!