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 C4071C3600C for ; Thu, 3 Apr 2025 03:32:08 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id EE91D280003; Wed, 2 Apr 2025 23:32:06 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id E97C3280001; Wed, 2 Apr 2025 23:32:06 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D5FEE280003; Wed, 2 Apr 2025 23:32:06 -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 B9B8D280001 for ; Wed, 2 Apr 2025 23:32:06 -0400 (EDT) Received: from smtpin10.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id BA66C1410D1 for ; Thu, 3 Apr 2025 03:32:07 +0000 (UTC) X-FDA: 83291309094.10.2F238C6 Received: from out30-132.freemail.mail.aliyun.com (out30-132.freemail.mail.aliyun.com [115.124.30.132]) by imf26.hostedemail.com (Postfix) with ESMTP id B94F3140005 for ; Thu, 3 Apr 2025 03:32:04 +0000 (UTC) Authentication-Results: imf26.hostedemail.com; dkim=pass header.d=linux.alibaba.com header.s=default header.b=l6FVctyG; spf=pass (imf26.hostedemail.com: domain of jefflexu@linux.alibaba.com designates 115.124.30.132 as permitted sender) smtp.mailfrom=jefflexu@linux.alibaba.com; dmarc=pass (policy=none) header.from=linux.alibaba.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1743651126; 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=4HRLqzOVDnJA3M8Jj1I2PRudQxaI3/HlAG7E5faBSZE=; b=ESeiMgzlkx76znqbGaPrc1Mt097SAqxpdoLbCfVc0yqNdavw9NCa2kdq9+gLp7llIjMldx OSvY4j7vWQ62WsctKfZ1myShhnYj/b+4T0ndJiJ0yipVKqgjdvAHY2mFyMbJeSRsilHGhL JEv2Ouw21BRZPLoAnXoiZ2uATJ4OhcU= ARC-Authentication-Results: i=1; imf26.hostedemail.com; dkim=pass header.d=linux.alibaba.com header.s=default header.b=l6FVctyG; spf=pass (imf26.hostedemail.com: domain of jefflexu@linux.alibaba.com designates 115.124.30.132 as permitted sender) smtp.mailfrom=jefflexu@linux.alibaba.com; dmarc=pass (policy=none) header.from=linux.alibaba.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1743651126; a=rsa-sha256; cv=none; b=DBId5cIEP+ntVAYLMswEO+SafcukDAilkpkzoYMgj+M2XZp1pYCT4cCt0JlC+EDqBviymR Aw4FdNdZSAaxcUoxJrI6pqlb5Pt6NvQb80mgK+KQ+3lofpl5uQTsM/I4RM21jY365TN49E aAFPsW1Y8how+LT4c65vVKHJbZBDV/M= DKIM-Signature:v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.alibaba.com; s=default; t=1743651121; h=Message-ID:Date:MIME-Version:From:Subject:To:Content-Type; bh=4HRLqzOVDnJA3M8Jj1I2PRudQxaI3/HlAG7E5faBSZE=; b=l6FVctyGv5GWk5yW50YnpOnia0ngHkFWJHcyh5Q0wSYG2MXrH0X3oFLLpYPw4By90JV1WRkj/Z5xpffnoBFfNVNZAA/nNp8tWSsDOHZEgKanVFTDBYlpuo3eGaW79UP/Z1PrpRHLDcgO0Fh6qcGZP1GFEiQNQFZO/nFYv2wfWf4= Received: from 30.221.145.143(mailfrom:jefflexu@linux.alibaba.com fp:SMTPD_---0WUYlogQ_1743651120 cluster:ay36) by smtp.aliyun-inc.com; Thu, 03 Apr 2025 11:32:01 +0800 Message-ID: <1036199a-3145-464b-8bbb-13726be86f46@linux.alibaba.com> Date: Thu, 3 Apr 2025 11:31:59 +0800 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird From: Jingbo Xu Subject: Re: [PATCH v6 4/5] mm/migrate: skip migrating folios under writeback with AS_WRITEBACK_INDETERMINATE mappings To: Joanne Koong , David Hildenbrand Cc: miklos@szeredi.hu, linux-fsdevel@vger.kernel.org, shakeel.butt@linux.dev, josef@toxicpanda.com, bernd.schubert@fastmail.fm, linux-mm@kvack.org, kernel-team@meta.com, Matthew Wilcox , Zi Yan , Oscar Salvador , Michal Hocko References: <20241122232359.429647-1-joannelkoong@gmail.com> <20241122232359.429647-5-joannelkoong@gmail.com> Content-Language: en-US In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: B94F3140005 X-Stat-Signature: ayjh6kw9buugcmbf5aw6aeguu8g94mfd X-Rspam-User: X-Rspamd-Server: rspam12 X-HE-Tag: 1743651124-738927 X-HE-Meta: U2FsdGVkX18R7tq52AgyI35KWG+S+HMk/57usZXyE0v1yTjS5B9wKURaJ4RPMC7UpFLE+crhobux4Hn+IrnDeEXRjS7sH78UXuE2CuoM5InaCQjlh67Flcdx6/U1dwmKxA/xFBxLKnFHPkJt6jjrV1HWCzlWmp7wBYMmqNSixzsXsQhmB93JD39IoKahj/KZxrX1aHBq+km80eqhLfXHtxVXHzbUEcBYQYmoqiHljoKPEyo4nx+aUd2zlNMrflV8No54+ZCVVUDLA/Xrxm42z2/krctsrwPT6LQkT1D5g4rhghDz1EwnE8MC6pN2SqRydTLLI1C2K9unrsWioptxR3Q7jYgoSFpl7QJl02t5toiK8ducnvsqNAkq1QN1kXB2BtEt5eFiN4TFa1iwepKGEprHRWCrBuRl+nyCw/Ryn6FNMuZXVbNQK85xOFWNPE3JHTYZeKO8sfyA8czxiNjhons9RbHrpgrl3N8fNV3sBhgk6kpvnCfFE+uTQ4FiFoROmo79Bde6F6HoZzF9lC+RlblVgFyCBtoErTiDB7cbc9ZDQ8JsJ2lXdBJ+VHniVrX6lOwYOFTJz1PGqYK4c0/7tRNoA2ZJnqcFTObx82Ho3PhiuDjuFIR2FM4WU2LTY6I9dL/7JjBueE6xx/QcpylUCfmNDATzq6FsxQNJD1d1oAFHh9ZPN+Alw2X7MyZc1Ch9Pfg/1nbWCGRAjTO/hMfFesptp8jsrs7dv8n3DbYrPBZUpjzf9Rrti9KQKNWJtF4YKhgIYQePF9Kc2NfBwcwjaV8z9UNK22+I8vztnPzaBT8owiCvWWd9tBdmAFIytEBEAyv3vG9uvEnuKsdmw2j7Xpju+B4dDmx1pfBCHJgMad9gqs1d99Q0cGsCWq8NWwo2XLIX/1xux6rO2Z3eoKqpLVdz3AShT1zDISBsnyBUTAuBDPzUFbIo+HeAzpjfqXqYcSXClSi2cFdvSQEtjLa w+IAUJIN CTHzCrdgOdt5WmLmv9Zu7X31Fa/sFWScwEBOI++GRdfzwBX2EY9bJaaECVacOqBd8ayNUurHjS0ajNxdMZCgdoF22nX/135m23E/tZrFj75Ns9628aS4eDaOnHNKG4Qkqjt2HG94BeayjPiTTwWVKzR0O+xpi3LY03BVHnVhSDZhVZnE+7I431bMVudF5FgbpQl3eg2u4XB1VQ1TGOvTL26VZVL0v9eIWiDVPKqqm5XzZXd7SbPoayBwzNQr1+NhY9Lfov+Cjbtx2bm2rxsg4ze01FFeoN85Nty4ZCVOVBRs1EntH0iCYoE60fxzYGNR04xjENQubIlQ3i8ndKCl0izrGFbbApRG4QKOs3xTSJSeAV2XDVihnqJybOA== 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 4/3/25 5:34 AM, Joanne Koong wrote: > On Thu, Dec 19, 2024 at 5:05 AM David Hildenbrand wrote: >> >> On 23.11.24 00:23, Joanne Koong wrote: >>> For migrations called in MIGRATE_SYNC mode, skip migrating the folio if >>> it is under writeback and has the AS_WRITEBACK_INDETERMINATE flag set on its >>> mapping. If the AS_WRITEBACK_INDETERMINATE flag is set on the mapping, the >>> writeback may take an indeterminate amount of time to complete, and >>> waits may get stuck. >>> >>> Signed-off-by: Joanne Koong >>> Reviewed-by: Shakeel Butt >>> --- >>> mm/migrate.c | 5 ++++- >>> 1 file changed, 4 insertions(+), 1 deletion(-) >>> >>> diff --git a/mm/migrate.c b/mm/migrate.c >>> index df91248755e4..fe73284e5246 100644 >>> --- a/mm/migrate.c >>> +++ b/mm/migrate.c >>> @@ -1260,7 +1260,10 @@ static int migrate_folio_unmap(new_folio_t get_new_folio, >>> */ >>> switch (mode) { >>> case MIGRATE_SYNC: >>> - break; >>> + if (!src->mapping || >>> + !mapping_writeback_indeterminate(src->mapping)) >>> + break; >>> + fallthrough; >>> default: >>> rc = -EBUSY; >>> goto out; >> >> Ehm, doesn't this mean that any fuse user can essentially completely >> block CMA allocations, memory compaction, memory hotunplug, memory >> poisoning... ?! >> >> That sounds very bad. > > I took a closer look at the migration code and the FUSE code. In the > migration code in migrate_folio_unmap(), I see that any MIGATE_SYNC > mode folio lock holds will block migration until that folio is > unlocked. This is the snippet in migrate_folio_unmap() I'm looking at: > > if (!folio_trylock(src)) { > if (mode == MIGRATE_ASYNC) > goto out; > > if (current->flags & PF_MEMALLOC) > goto out; > > if (mode == MIGRATE_SYNC_LIGHT && !folio_test_uptodate(src)) > goto out; > > folio_lock(src); > } > > If this is all that is needed for a malicious FUSE server to block > migration, then it makes no difference if AS_WRITEBACK_INDETERMINATE > mappings are skipped in migration. A malicious server has easier and > more powerful ways of blocking migration in FUSE than trying to do it > through writeback. For a malicious fuse server, we in fact wouldn't > even get far enough to hit writeback - a write triggers > aops->write_begin() and a malicious server would deliberately hang > forever while the folio is locked in write_begin(). Indeed it seems possible. A malicious FUSE server may already be capable of blocking the synchronous migration in this way. > > I looked into whether we could eradicate all the places in FUSE where > we may hold the folio lock for an indeterminate amount of time, > because if that is possible, then we should not add this writeback way > for a malicious fuse server to affect migration. But I don't think we > can, for example taking one case, the folio lock needs to be held as > we read in the folio from the server when servicing page faults, else > the page cache would contain stale data if there was a concurrent > write that happened just before, which would lead to data corruption > in the filesystem. Imo, we need a more encompassing solution for all > these cases if we're serious about preventing FUSE from blocking > migration, which probably looks like a globally enforced default > timeout of some sort or an mm solution for mitigating the blast radius > of how much memory can be blocked from migration, but that is outside > the scope of this patchset and is its own standalone topic. > > I don't see how this patch has any additional negative impact on > memory migration for the case of malicious servers that the server > can't already (and more easily) do. In fact, this patchset if anything > helps memory given that malicious servers now can't also trigger page > allocations for temp pages that would never get freed. > If that's true, maybe we could drop this patch out of this patchset? So that both before and after this patchset, synchronous migration could be blocked by a malicious FUSE server, while the usability of continuous memory (CMA) won't be affected. -- Thanks, Jingbo