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 10223C2BD09 for ; Sun, 7 Jul 2024 03:07:48 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 002306B007B; Sat, 6 Jul 2024 23:07:48 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id EF5476B0082; Sat, 6 Jul 2024 23:07:47 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id DBB3F6B0083; Sat, 6 Jul 2024 23:07:47 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id BD7746B007B for ; Sat, 6 Jul 2024 23:07:47 -0400 (EDT) Received: from smtpin21.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 16A1CC0B27 for ; Sun, 7 Jul 2024 03:07:47 +0000 (UTC) X-FDA: 82311471774.21.40082F4 Received: from szxga02-in.huawei.com (szxga02-in.huawei.com [45.249.212.188]) by imf10.hostedemail.com (Postfix) with ESMTP id B0ED6C0014 for ; Sun, 7 Jul 2024 03:07:43 +0000 (UTC) Authentication-Results: imf10.hostedemail.com; dkim=none; spf=pass (imf10.hostedemail.com: domain of wangkefeng.wang@huawei.com designates 45.249.212.188 as permitted sender) smtp.mailfrom=wangkefeng.wang@huawei.com; dmarc=pass (policy=quarantine) header.from=huawei.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1720321650; 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; bh=oM4G4k8u4DKJ6d+domE80ErdNOHe98qzZnnQU8t/l8w=; b=oB8Peg3UaJGqxPKPRBtXv2ePUhU2paZyUjAzK7hNiu+06Sfsgy/XfS6bcJXAOf+hp17QMI JZBeiK6SOrYwjtHDqzGX8EEpzOqMg3nVQnEUlJnmAoQza7cP07dz99g8+ATLd7APF0cMo+ YBgrT/6g8UaUFKt+AlYm3lLtk+dvo0w= ARC-Authentication-Results: i=1; imf10.hostedemail.com; dkim=none; spf=pass (imf10.hostedemail.com: domain of wangkefeng.wang@huawei.com designates 45.249.212.188 as permitted sender) smtp.mailfrom=wangkefeng.wang@huawei.com; dmarc=pass (policy=quarantine) header.from=huawei.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1720321650; a=rsa-sha256; cv=none; b=XIMFcUMhzI3TtWXOVo2gufw7OBXMmULeyNM8vTjYW197ysPYG3uW/rBmkLxH0yjqcF04WT Li+Dgqjx0RRp8Qsxz+wsZL8aODSDva3reiN6XgXtrqX7CaxiR+PX6taLYfSf81PCxF5xNu mIBttaQfanmCkpww0SYlKNwtY5rmwD0= Received: from mail.maildlp.com (unknown [172.19.163.48]) by szxga02-in.huawei.com (SkyGuard) with ESMTP id 4WGsZw4KYvzdgJ7; Sun, 7 Jul 2024 11:06:00 +0800 (CST) Received: from dggpemf100008.china.huawei.com (unknown [7.185.36.138]) by mail.maildlp.com (Postfix) with ESMTPS id 78D3418007C; Sun, 7 Jul 2024 11:07:39 +0800 (CST) Received: from [10.174.177.243] (10.174.177.243) by dggpemf100008.china.huawei.com (7.185.36.138) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.11; Sun, 7 Jul 2024 11:07:38 +0800 Message-ID: <55610a6f-dd13-4636-b13c-2d9269782687@huawei.com> Date: Sun, 7 Jul 2024 11:07:38 +0800 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH hotfix] mm: fix crashes from deferred split racing folio migration Content-Language: en-US To: Andrew Morton , Hugh Dickins CC: Baolin Wang , Nhat Pham , Yang Shi , Zi Yan , Barry Song , David Hildenbrand , Matthew Wilcox , , 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> <20240706191122.134c5ae35e86c68d52bf11a9@linux-foundation.org> From: Kefeng Wang In-Reply-To: <20240706191122.134c5ae35e86c68d52bf11a9@linux-foundation.org> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.174.177.243] X-ClientProxiedBy: dggems706-chm.china.huawei.com (10.3.19.183) To dggpemf100008.china.huawei.com (7.185.36.138) X-Rspamd-Server: rspam11 X-Rspamd-Queue-Id: B0ED6C0014 X-Stat-Signature: jtxmtm9kegey5bu9zrb9cz5ntjfp4c3o X-Rspam-User: X-HE-Tag: 1720321663-726957 X-HE-Meta: U2FsdGVkX1/bJNW+E2iIp3cIZiJS2yDqaADfvTqlOXGwAxWDQq3sEsGyUgleOp+w3ye3/ypSH1HpckuCRLObI63N96Xz9F4SKwVnlAt0APFz6m0pUs05/s1y0BGlVaYOvqTcgSxf4Ux6BNdRAV9zDARqoS1FN4/iDESYpLgpNuGOri2FiVD8/xvvOMR7ISP93v2TrQYpse1FaeukmkxTNiy3GhsT1yXqMSgYvGJVVnn/7EkmCSObmhW3yb5zm4tG7k7NdZTe+FhZsNYTeST4YZ8LvoWdZ5Ct78qpMSa++6jJ0TylzMEj/gofS/wSMzPVnJMfpi2Rso4g8As6r6RqWo+3/OKTMUJufdP6yNnr/JrwPX0jWHDjcR+uTIucLYB4ARzGfcICetsb7l29Vuw9KGwPMvYKkjzDCydH62RZyABuZEVFI5W4wVn5254HtLUnHCTqjgMO0bynrGONwCEBcC8ziWKh2tpJ/eyb6WAZxf3TtvJEB03nQg7G+94rAjOcCturUvt7BzvcyudniNZRCUXG352n/E14B4l9GNtc1RWTqmf5lnkNMc8e70ztPuAk+qZ2eajcSLoG69B0y6/7sNTlH4les9cWqUwXuPV6ZfQ6RLCbv5UmP9llvLD3YoROhELbMOEUd37v1RPeEoriEFTMnqQkvLmIUOGV85VS7U8GVJGl0wnzUSOn7/4q2IrxetcUQCqVaVajgZisQttgQplrNMGTfJtMrK6aHV0oo9ukwdCAAYNSomZw7Wk+C5RG0InEzc3cl+KofOytZ/1FDk8bSBHkxSzbPNyOCNE6PCeVRLEHq9giEFQjwFZtBhBi+1hpFxOSAyW7KL8weC+mtvPzSHk2ZgQy3pVhfr/qZXjxz89EPiPDQ9UY9phHa1TLB6mHZM8rdEYjWVrTsPwrEJZ7eM1QfquZlLu8oiCubIvZHiRfln7IuG2o6QmGj6Iel9FNzzm+5HBZFDeRTAi iDZ7VdzA X/2rxIrQOhUFt4kLmCWnc7AqiKLo7oPZ/vtLH/Rl8zPQ8G/4ijoaCMxApZwOuviuET4rVRt/Ii7icv25cW6ZDQdVxeqP06dIyrxXoECSV/E2Thg7YTQajJvcJokBfaF0qeVdAMKWE2YpFKvmwCy3pxc1535llvMV+4q6wqfBjbEsHB8RIiVLymILeF5t2aK1TvR/f 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 2024/7/7 10:11, Andrew Morton wrote: > 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. Maybe some helper to check whether or not we should unqueue the defferred_list, but it out of scope in this patch, and maybe not worth it >> >> 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. OK, let's keep it simple, thank your for pushing it out. > > 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.