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 13A6BC5475B for ; Mon, 11 Mar 2024 12:26:33 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 737356B008C; Mon, 11 Mar 2024 08:26:33 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 6E6A96B0093; Mon, 11 Mar 2024 08:26:33 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5D5AC6B0095; Mon, 11 Mar 2024 08:26:33 -0400 (EDT) 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 519346B008C for ; Mon, 11 Mar 2024 08:26:33 -0400 (EDT) Received: from smtpin15.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id F326AA0944 for ; Mon, 11 Mar 2024 12:26:32 +0000 (UTC) X-FDA: 81884681424.15.DC76C41 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf10.hostedemail.com (Postfix) with ESMTP id DB66CC0016 for ; Mon, 11 Mar 2024 12:26:30 +0000 (UTC) Authentication-Results: imf10.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=TxOxjCDn; spf=none (imf10.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1710159991; 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=1cPb/XNSUsTtc5V6ZXLpOgUYJiLjKV6PzMvfFv7wFW8=; b=is/XPJPml0XrR5NAzzfXEgbYr0RQWayD9OzMYK14fzLrUVn17HV2P9SmzT2vTL2kqw47iU 2pm+6VEWsi0WJ2d9pQCKuftLEfgJZOVQC0uTC3jihjJFQBAOrUnWEfuahByt0RH1UJcNO2 bHko5QyClrRqVuFMpGUhC2FphO/8S8I= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1710159991; a=rsa-sha256; cv=none; b=6pbHTU7D89g4Cs6EJpB4TNDP/t0ItDFi7Hd9ryLZJCEyzBOxZ6JTQ7M/Guj9+dVpll9BY5 x4U6ZlWnw4pWHVemiEJrKeX+y12p+ODW2f0S6UHRT7+QDvJSgb+EEgaDzYmSaRW4nMNseX YKAUI1U/QxTSNX9AWb5cAKqCgO6Wlys= ARC-Authentication-Results: i=1; imf10.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=TxOxjCDn; spf=none (imf10.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org; dmarc=none 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=1cPb/XNSUsTtc5V6ZXLpOgUYJiLjKV6PzMvfFv7wFW8=; b=TxOxjCDnbFTyueAPSO5p6vLKbn +b6kGo4tZXq2i5+pU9/FItAjVibfA3R2itn9Z9k/ftc2boksckIIxb2LyNWpkBv3V+z0ZCWJXjcmO zkSHvQu/Yi2vK5agO9QzAWdLnruwDil1j3cQoeYBlq8kiyNTHVWLZSLIzJowpE6sF/3GkXbx4JvyX TKeHP5wEWjCO9nLDR5b4VhwDFMroI0OK0qLSIjaQFrHq8ezteQrmKFXb239PGVhNpatesP6KRIBjm N5bmvM6aLs4hZyRIW+3kVq4OzR+hyfSGpWSVMUY+KkJzJusggJ8RriqqhDFjHkVsgv/3soxKew8Km 2fNn85zQ==; Received: from willy by casper.infradead.org with local (Exim 4.97.1 #2 (Red Hat Linux)) id 1rjejZ-00000000c73-1fGo; Mon, 11 Mar 2024 12:26:25 +0000 Date: Mon, 11 Mar 2024 12:26:25 +0000 From: Matthew Wilcox To: Ryan Roberts Cc: Andrew Morton , linux-mm@kvack.org Subject: Re: [PATCH v3 10/18] mm: Allow non-hugetlb large folios to be batch processed Message-ID: References: <20240227174254.710559-11-willy@infradead.org> <367a14f7-340e-4b29-90ae-bc3fcefdd5f4@arm.com> <8cd67a3d-81a7-4127-9d17-a1d465c3f9e8@arm.com> <02e820c2-8a1d-42cc-954b-f9e041c4417a@arm.com> <9dfd3b3b-4733-4c7c-b09c-5e6388531e49@arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: DB66CC0016 X-Rspam-User: X-Stat-Signature: cdupcuee8q5wphxbwyqamg3j9bq8peqs X-Rspamd-Server: rspam03 X-HE-Tag: 1710159990-72320 X-HE-Meta: U2FsdGVkX1+LF82s/KIV7vIWD5gEbaJsrt9smqq2jNpLJ5eYU2EWJM4H190vFeu+soZYWusRryDLWgiFmI5+csWpuPZ3fU+xHcG1o5JQ+06TnYZ6JDeO78FlbiK3AJz3nAylIrmVD5ITf+Ghw89424lldprJdov3LA2EMiUrw5ZniCu0g18JOVf703HwqTOwZLBHiIY9F6ng7KdsI/4MHCADzeO2MwFmUng8DJ4SF0MfMQkrpnZZfQDkLpRWugM3rEdYoDZMDWmo3HJXjUNq3zs1hZ4K7HMrvbo9YeBoKqrE6HzXkBT6tLWBKA6K8vq+JyuOqoeKWwQeUre4gSuOZ6cb35G4vGZ0lDjhVqXTZA/G5pWo/fIhe6PIN1giwFTZ7enRpY7XvFYdjA5RziOEzASF5+p3zyRogAEwD3xTbNw35GjP2uLdkSAEKCWGyIYVtokZF5nbyLqikJ4cosncGbt2unDfHj5vYVzJmZropoeztII/Iki7fTGorfC2Z1xm6glc7pZtflGUE3JmIHxb39j71hhSz8eRtjCk99Tbnw17F0Ab3gBBo819GEOofQ7ggj6MwDEUib/cqfwhRXD1a/VvhGAxSmgvK9KobPXEFVTrFb0+ag6cK0QoPUx01XseBrcDn+N6+WT5iwwOB1ZMR4PgVjld1RZUHxlK8d2JpghLr6QVys5kL48rerCCTpIMlqcZ7LMJAhYH9w9zW0cEQXNMUkCVHNceiJQP9ELWuth3dcq70EdvNA1d/cZ0VclugQ+xmQoMYK4RHNB7q66qCYKM0dEWVkv1EGwZeGP/9eS6JnlieV3LHMwBbQa9v2r3TKLKNWQhir4NVGmb6d5T7Q== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000015, 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 Mon, Mar 11, 2024 at 09:01:16AM +0000, Ryan Roberts wrote: > [ 153.499149] Call trace: > [ 153.499470] uncharge_folio+0x1d0/0x2c8 > [ 153.500045] __mem_cgroup_uncharge_folios+0x5c/0xb0 > [ 153.500795] move_folios_to_lru+0x5bc/0x5e0 > [ 153.501275] shrink_lruvec+0x5f8/0xb30 > And that code is from your commit 29f3843026cf ("mm: free folios directly in move_folios_to_lru()") which is another patch in the same series. This suffers from the same problem; uncharge before removing folio from deferred list, so using wrong lock - there are 2 sites in this function that does this. Two sites, but basically the same thing; one is for "the batch is full" and the other is "we finished the list". diff --git a/mm/vmscan.c b/mm/vmscan.c index a0e53999a865..f60c5b3977dc 100644 --- a/mm/vmscan.c +++ b/mm/vmscan.c @@ -1842,6 +1842,9 @@ static unsigned int move_folios_to_lru(struct lruvec *lruvec, if (unlikely(folio_put_testzero(folio))) { __folio_clear_lru_flags(folio); + if (folio_test_large(folio) && + folio_test_large_rmappable(folio)) + folio_undo_large_rmappable(folio); if (folio_batch_add(&free_folios, folio) == 0) { spin_unlock_irq(&lruvec->lru_lock); mem_cgroup_uncharge_folios(&free_folios); > A quick grep over the entire series has a lot of hits for "uncharge". I > wonder if we need a full audit of that series for other places that > could potentially be doing the same thing? I think this assertion will catch all occurrences of the same thing, as long as people who are testing are testing in a memcg. My setup doesn't use a memcg, so I never saw any of this ;-( If you confirm this fixes it, I'll send two patches; a respin of the patch I sent on Sunday that calls undo_large_rmappable in this one extra place, and then a patch to add the assertions.