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 D69E5C2BD09 for ; Sun, 7 Jul 2024 02:11:28 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 1A5F46B0083; Sat, 6 Jul 2024 22:11:28 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 1565C6B0088; Sat, 6 Jul 2024 22:11:28 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 01D756B0089; Sat, 6 Jul 2024 22:11:27 -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 D90996B0083 for ; Sat, 6 Jul 2024 22:11:27 -0400 (EDT) Received: from smtpin04.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 700D8A0A7A for ; Sun, 7 Jul 2024 02:11:27 +0000 (UTC) X-FDA: 82311329814.04.328A3F8 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf28.hostedemail.com (Postfix) with ESMTP id 79B34C0006 for ; Sun, 7 Jul 2024 02:11:25 +0000 (UTC) Authentication-Results: imf28.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=korg header.b="V/QlLI9X"; spf=pass (imf28.hostedemail.com: domain of akpm@linux-foundation.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=akpm@linux-foundation.org; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1720318248; 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=zRKTBvYqqMCTu4elrGIWnBFCj2Log+ep5dh5iiwRPQk=; b=dvqFLW+oImozkyDKLcxfnLFfKZVDDbOCCzFWgJjpO8b/9pZi24LT6NwupHumkxEk8n1zPV rqg6SqC8RXFXcwaM1aPholuguYuTBjrRUJhol5iwl34ljCi4PJemQ2ocrNPp9XbNinzKzW TZrOJ4T25cK7mQ1cigR+UES1R6/Tn3Y= ARC-Authentication-Results: i=1; imf28.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=korg header.b="V/QlLI9X"; spf=pass (imf28.hostedemail.com: domain of akpm@linux-foundation.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=akpm@linux-foundation.org; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1720318248; a=rsa-sha256; cv=none; b=SQoPREwInt8PiSK39qfSRY2kRwIQ/Ob0m62NZlDbkF92t5pr3/K1o9OCBknTmQIlKzfeo3 OnTytdLkp56IuoA67XqyQxLdX6P9N3Usaj5UEHzrqCmEQ4FQR7OM8AD2GL1koCl1Yr2Ae5 lAg/LOUVf/LAZ72f2lIMHg+8dsl2OU4= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id 3711560B75; Sun, 7 Jul 2024 02:11:24 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 7DF5BC2BD10; Sun, 7 Jul 2024 02:11:23 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux-foundation.org; s=korg; t=1720318283; bh=uVV4zf6SMSVoLy2muGtpKIxe37Jvz/r6lR9ZxeJZR4M=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=V/QlLI9XKXAX7glP3L70L8cnhoJ2nzp0tiUjg8kVT2YEolYmWlSShNxo6cNB5ZJs/ 7eOL5upPHLcVJMjSSBFZ7Q44SNgz7U7Hynv3gAzDFl+iswwRpgogWhnTx0s0+8jlPp sv6uk+Mdf9CUnAFR0aidIuac1vRW44z/zzam2ysU= Date: Sat, 6 Jul 2024 19:11:22 -0700 From: Andrew Morton To: Hugh Dickins Cc: Kefeng Wang , Baolin Wang , Nhat Pham , Yang Shi , Zi Yan , Barry Song , David Hildenbrand , Matthew Wilcox , linux-kernel@vger.kernel.org, linux-mm@kvack.org Subject: Re: [PATCH hotfix] mm: fix crashes from deferred split racing folio migration Message-Id: <20240706191122.134c5ae35e86c68d52bf11a9@linux-foundation.org> In-Reply-To: <68feee73-050e-8e98-7a3a-abf78738d92c@google.com> References: <29c83d1a-11ca-b6c9-f92e-6ccb322af510@google.com> <20240703193536.78bce768a9330da3a361ca8a@linux-foundation.org> <825653a7-a4d4-89f2-278f-4b18f8f8da5d@google.com> <7b7f2eb7-953a-4aa0-acb0-1ab32c7cc1bf@huawei.com> <68feee73-050e-8e98-7a3a-abf78738d92c@google.com> X-Mailer: Sylpheed 3.8.0beta1 (GTK+ 2.24.33; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: 79B34C0006 X-Stat-Signature: ipjgmo83rtix75f9hg1zdfodihwybwmj X-Rspam-User: X-HE-Tag: 1720318285-719986 X-HE-Meta: U2FsdGVkX18nP+sACiXwnOj5XNZMOaJNWIKAG3v+LMDyvlMD8hFU9teRLKODf2oJLti/czxcArnppR9DzxIaBjQsKLAmdVdbuj20ApYMHFJiuOeyk08JRiX1iDg32SIgsaliay/QMQLRraSgNitDz0evXigDNCkuKSdwsm7qyHZpYOn2VS+QC8Dv7ifqTomNoIKNuhlyLs5rsbPAS2qMOZSoFQAUd02CaaroQSAgTL7F6EGLReUFvXlmolQrOoOoR6SeDSn+raKKyTo/Dv279VEnHyvwbDLE9GuASQgQA3fRR7VytXW0sq6hRIWAlm9j4kzq2b9I4YcRpKGA2259EupclOOejLaJLwqxlRQzlo3h93RHvVYNAB37n5WDF77Ye5BLU1NOSII1wEBHEU1HjGOeaCoHBSd8qvFfLnW87iI0WUmtpO2mL00CtnLTdX4TyKQHaDtUj05XdZU8VQFPCk8muwGU7FIqrGXlDegYn2qlCted3J3VYPWf6om32bu5a/OmX6RU3mbN1rAKyKg1MKP2hkGzre7atFvzsGA5/nG0XQ7pLcB27602BNxGbGQWv8sRcE03+QxUqPRX6wA7Hh+C1P/7SBr/ur//6A2XyxqQxa+DDahHZ01QN5MAfQW4vtkgZ/Rr4cRvfhjHbcHc0pfSZDodPA9uc2RDmV42vM32y2+RTg1FxFOwoahXDn05bVmKiGmSq8EOKTz/PTlaO+p9n2yezdTf3CWpgtPyK7bN9DmHQk01IDOoWUUq7/iaR9Rai5LZg8ihRS42aNH/FRkY9J8zFkhJpzT6GoHO/hk2KE2b/45mjvS/kFNbF+dvm7R7p088YJQcMwgrLU8liLLO/VjCOeivtPN57S2vs5X6eolHidxrziEGBk2yRdpnTkiAa4jTo4s1TTeo5cP4JInAA+9D+Lcy30jl+XbImBFYjy4y+SCQElHIrBwXE8STkzoGSwgMW+O5LukixiP RtD9FI3y rovZUz3hgtxTs9o6MJ1R7SdItQMSmVZJ+NAOtQw5CtzBD2yzl5253jjX7u6Dj/h98cuHZ3s4h7UhKvhs5k2Z2QtEtPTWQQmU12j+Y+EKLzu4DROr+GmmUhhlRvfvmRyBGFx4or27AgayyoGSgDfdeRDPdyE29ko6L4ZiQsSqwGffIxWlJc+8ohBnEmU9574+muWadkLfw3E8y6hiFhKq/haDAnVc06ihol9d2BR/9dZhntVcNALdeFXIE5w== 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 Sat, 6 Jul 2024 14:29:00 -0700 (PDT) Hugh Dickins wrote: > > What you show above is exactly what I had when I was originally testing > over the top of mm-everything (well, not quite exactly, I don't think I > bothered with the data_race()). But I grew to feel that probably everyone > else would be happier with less of those internals _deferred_list and > __folio_undo_large_rmappable() spread about. > > There are many ways to play it. I had also considered doing it Zi Yan's > way, freezing always in the !mapping case as well as in the mapping case: > what overhead it adds would probably get lost amidst all the other overhead > of page migration. It will not be surprising if changes come later requiring > us always to freeze in the anon !swapcache case too, it always seemed a bit > surprising not to need freezing there. But for now I decided it's best to > keep the freezing to the case where it's known to be needed (but without > getting into __s). > > Many ways to play it, and I've no objection if someone then changes it > around later; but we've no need to depart from what Andrew already has. > > Except, he did ask one of us to send along the -fix removing the unnecessary > checks before its second folio_undo_large_rmappable() once your refactor > patch goes in: here it is below. Grabbed, thanks. > [I guess this is the wrong place to say so, but folio_undo_large_rmappable() > is a dreadful name: it completely obscures what the function actually does, > and gives the false impression that the folio would be !large_rmappable > afterwards. I hope that one day the name gets changed to something like > folio_unqueue_deferred_split() or folio_cancel_deferred_split().] Naming is important, but so also is commentary. folio_undo_large_rmappable() lacks any. > [PATCH] mm: refactor folio_undo_large_rmappable() fix > > Now that folio_undo_large_rmappable() is an inline function checking > order and large_rmappable for itself (and __folio_undo_large_rmappable() > is now declared even when CONFIG_TRANASPARENT_HUGEPAGE is off) there is > no need for folio_migrate_mapping() to check large and large_rmappable > first (in the mapping case when it has had to freeze anyway). > > ... > > For folding in to mm-unstable's "mm: refactor folio_undo_large_rmappable()", > unless I'm too late and it's already mm-stable (no problem, just a cleanup). Missed the mm-stable mergification by >that much<. I'll queue it separately, thanks.