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 A70B4E77184 for ; Thu, 19 Dec 2024 17:44:56 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 383056B007B; Thu, 19 Dec 2024 12:44:56 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 332F46B0082; Thu, 19 Dec 2024 12:44:56 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1FAAF6B0083; Thu, 19 Dec 2024 12:44:56 -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 005486B007B for ; Thu, 19 Dec 2024 12:44:55 -0500 (EST) Received: from smtpin20.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id B1A91160142 for ; Thu, 19 Dec 2024 17:44:55 +0000 (UTC) X-FDA: 82912431798.20.E59646A Received: from mail-qt1-f170.google.com (mail-qt1-f170.google.com [209.85.160.170]) by imf21.hostedemail.com (Postfix) with ESMTP id 48BDA1C0010 for ; Thu, 19 Dec 2024 17:43:50 +0000 (UTC) Authentication-Results: imf21.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=Ig+XvyU2; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf21.hostedemail.com: domain of joannelkoong@gmail.com designates 209.85.160.170 as permitted sender) smtp.mailfrom=joannelkoong@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1734630262; a=rsa-sha256; cv=none; b=VxqxpoFA2jjf3UBDab1e1LH6iTJlPNvX0n+QUiaIGsa0y2xAJlpnPJ6LYVq1xHhO6vYg7N tbSzwfK3YK4NnS716Wr8nWn+oCUghl7zpZUTKq681u0Qma4aAvx3qXp0gPblqimt16KUKK T1d5ia6FCYy+nuUOX9JQGYnYOJ1BUFc= ARC-Authentication-Results: i=1; imf21.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=Ig+XvyU2; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf21.hostedemail.com: domain of joannelkoong@gmail.com designates 209.85.160.170 as permitted sender) smtp.mailfrom=joannelkoong@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1734630262; 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=jOWnHsk58LEisFTupGhSlXEEpiCe7RKkGgtg+2S7HhQ=; b=TrQQ04YViEjU5nG21qrVp7N1FatwgtB2/1BaVCU9w2yxjUX1vUFbfn/2QvQZSaWhpBIjMm Mm1edXZDKu1RrtahxexKRPc6C+hx0Rlu7thSGojHZdd+gk8fDXTmcKkTYZSaSEmXjEmUPk EzgM3Iz5yUSOCaVo531b+wp2Ut3qNv8= Received: by mail-qt1-f170.google.com with SMTP id d75a77b69052e-46792996074so8896011cf.0 for ; Thu, 19 Dec 2024 09:44:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1734630293; x=1735235093; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=jOWnHsk58LEisFTupGhSlXEEpiCe7RKkGgtg+2S7HhQ=; b=Ig+XvyU2uGSLmfhmn953GyzSkZIehT1WCcgE9KUjRh3d06CCo8rRLjMteDoQcywarC pc798BGHtJUo45klWaDvzVNKSHOuLRCcN2Rhph9OJxaDv5j8IlInTeakBvWSxpK/e9oI i1b/BST8HPgYHtabw4difz8lvmENT9RfR4OcZGhdwr7upwzTAyOzSTM1LpOcuROstS1o +SobYEk/VZqKSnro5cYPxs2AJ5MbO1e4WGsvRSFr2jMJ8DdXrQKX6eIDwp67jiS9KGcu 8PB4NojgRonRnaaXEX2hB2CpTY8oaVmZA2N+2+y6EiZwKdAKtFnldXaGrTSaHntx+mEr JENA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1734630293; x=1735235093; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=jOWnHsk58LEisFTupGhSlXEEpiCe7RKkGgtg+2S7HhQ=; b=OWvtTueq22hLcx0dVeBDXooN9oAl3ZKP5dqnD1svTGAVO6YCMCsDVvibJbI6h66rvu ztfR/Og9HOZyZAF8hGrFdbNLagFwpprVGqxu3qQZHCKX8DgFVNrbb6VmgYatT+usntzz KfNu2f9uxELi+AXGYjF9FVb6d9Ua3B9ZQm8+TjT7u5Ob/4Ws1IWSKTHKOCXjHVZegB5p pe1NyoLbFYNnzLqMteCZ+r/s2KsO6dBgBBY80hn4rPwSCJeOj/Y+kvCrZrWYZBFjVfAb c54NB7Qu45H7GKfh991WdcH2YegKF/+AlHTIoASGUnJNIAwR2V3eIFvBjDE7RKPGF1Gc wN0g== X-Forwarded-Encrypted: i=1; AJvYcCUPtQHO++3SDw2A8ql30x/OlI1cUGhoqyUghjeHreC/7H9VdH2aK6ygd9xrwe8Vc1GVwJcwaZ3+Fw==@kvack.org X-Gm-Message-State: AOJu0YxIKLCti0N70tSImOmKAKTr4kLuzq8EXJfWKGfHzgHge8qN/viC Yc+WX37KmtOZzrdYByrNLDDkCg39sTGwUnzBMTxrhqXifgR1VgOYKntul2m80DBgzwH69REA3yi 6ITwoU7bNiocO+HzltIgvrTDHaNQ= X-Gm-Gg: ASbGncsPpZuE8DKx0/0ovtkUmAZwsd7z5k7Q+qJqqdbgvAYBGejef2CskTOYJzFDsz+ l9L4MdqeHFGZKuT1IYMQxSz603w2r//dBKxnVOl0= X-Google-Smtp-Source: AGHT+IFfm1c5TKG3NbPLfRn7IXWp7kmYfdPLU69mqMPaE4XrXA6Bdido8NZHSAjhLpcJfKHLr+M3idkr0ijn7Nrh61I= X-Received: by 2002:a05:622a:13d4:b0:466:948e:bef6 with SMTP id d75a77b69052e-46908e6f405mr130775701cf.43.1734630292992; Thu, 19 Dec 2024 09:44:52 -0800 (PST) MIME-Version: 1.0 References: <43e13556-18a4-4250-b4fe-7ab736ceba7d@redhat.com> <968d3543-d8ac-4b5a-af8e-e6921311d5cf@redhat.com> <7b6b8143-d7a4-439f-ae35-a91055f9d62a@redhat.com> <2e13a67a-0bad-4795-9ac8-ee800b704cb6@fastmail.fm> In-Reply-To: From: Joanne Koong Date: Thu, 19 Dec 2024 09:44:42 -0800 Message-ID: Subject: Re: [PATCH v6 4/5] mm/migrate: skip migrating folios under writeback with AS_WRITEBACK_INDETERMINATE mappings To: Shakeel Butt Cc: Bernd Schubert , David Hildenbrand , Zi Yan , miklos@szeredi.hu, linux-fsdevel@vger.kernel.org, jefflexu@linux.alibaba.com, josef@toxicpanda.com, linux-mm@kvack.org, kernel-team@meta.com, Matthew Wilcox , Oscar Salvador , Michal Hocko Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 48BDA1C0010 X-Stat-Signature: kw4tzr1swacogk7ccruz96qirynfgs1r X-Rspam-User: X-HE-Tag: 1734630230-174977 X-HE-Meta: U2FsdGVkX19u6aBUt2tXXMYdMTrQd9dCFxOJJv1J+Y8PJn9WTTMAbdteNAaWZNUla4U5tVwv61LGbkAX5MNz33CuOsxZFzfqqx5uhm9i5QN2sEKR95dNIPJt/ImtW8mPHFbcAIp+t6p/t8dH0CTW/Bxtj0nrSipkqLRcQoSyIR4FF1JHiCFGO7/mBWLDPUj8ZwESJhuSH643Ag55RusG36nKB5frhxWIyKm/2jca8xnxlg0gSvabFhrPbTwIXWi2c9o42xkTUXNIh5ka4SMWMWzNrkSWwNLenBXQOtly3TsgkW/6sGF4fWcNHcuqOyvbzEkUBNkxMiZV3sV5lGVk+pCqvf+U5Er6gOJznuZQzrRV5jK9GffkcWd6E/nXzwk4+b01hIWO+TZsiO6xbKI9/BYAAqShyRrceWnPh5yMebsC7G/fsJN5lu7iYL688kqIE/V2YvQP/1cLYHD1Yzu0v4StkMtIqA8bswVe86tjzTHGMX6FjP4slR8FVFYbkZIh5XGYjogRG2IM+/EFuT64F6n8556uj8Q7TI5TaklE2Y2sp+njjqfUyplmfJZnLQMdhoN8sb4aSihxKfoPbGmcLkAHNQKOtGZ777j4DYp+N2btsmonYl2zaQG+fnU9iPhgbXbcLvPID1MDSizvUOyazVMyRdVqmtjLyB/LA+qyVcZp7vkMaPFsmlPrPfNl5pA9fDYElGKEMhoQ+IRvUEudy/SxqPv8tOz/2RHj1f/2tyIhD3kUoqwvFVVXv4lNkLsSLT6W7hFKPEqgoFJqPUwqhLHkgC56HyP4YvDURldvkRokPhgKhYSTTmg8mS4843TdZ7ANjKorrQTXWKgpiZxPVLvbqSq21uV2Svmg0EqUtBgTYpFA/C+sikUNGzaTENJ0prnJ/BO6Kl3b6+owDIBPr8bt+6/n090ksSy23A5OAkesh38t9Kq2F+yVoWfsGw2zQ+ZOVCwoqcG4DTiR16H YdECE7t9 /zqT/4ku4Bogrvu0eJOzeKHjQfebE+gCC6n/om51K2LpSv6mLA7yEyot7ZpQCXcAAFMKB9pxiJaBpXuuZ4U+XeEDLkkBN+TQT0KnXJv7JpFs9j7pc23lg2aF3cIzglOvmqDoDxBVKcc9FZuW5j2j23ygE2eaj8ROCd/JDm3ck9J4nQeI6B1YT4f7UB98k8aprwFRCGqzSm1cUrj9Gqd52O5sdOFEpRNpBDLVcji7HfRTzPqZyDnDNhpQMxMLtqTUe20dgGxeCdHF9quZSbE08jY//koX69dDFZK9RVXMutmuX0WZ+M/1JiWEi4Y0Tkv+Hl3JfmM+4HyaFpZLSzW46algqnl18Xtr+dwrO7ltF4bCwH9pMCM1GbMLagv30ZNdtKPgQFGD6B1fukYAig9aKDssuyQISDJooKP1q X-Bogosity: Ham, tests=bogofilter, spamicity=0.419965, 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 Thu, Dec 19, 2024 at 9:37=E2=80=AFAM Shakeel Butt wrote: > > On Thu, Dec 19, 2024 at 06:30:34PM +0100, Bernd Schubert wrote: > > > > > > On 12/19/24 18:26, David Hildenbrand wrote: > > > On 19.12.24 18:14, Shakeel Butt wrote: > > >> On Thu, Dec 19, 2024 at 05:41:36PM +0100, David Hildenbrand wrote: > > >>> On 19.12.24 17:40, Shakeel Butt wrote: > > >>>> On Thu, Dec 19, 2024 at 05:29:08PM +0100, David Hildenbrand wrote: > > >>>> [...] > > >>>>>> > > >>>>>> If you check the code just above this patch, this > > >>>>>> mapping_writeback_indeterminate() check only happen for pages un= der > > >>>>>> writeback which is a temp state. Anyways, fuse folios should not= be > > >>>>>> unmovable for their lifetime but only while under writeback whic= h is > > >>>>>> same for all fs. > > >>>>> > > >>>>> But there, writeback is expected to be a temporary thing, not > > >>>>> possibly: > > >>>>> "AS_WRITEBACK_INDETERMINATE", that is a BIG difference. > > >>>>> > > >>>>> I'll have to NACK anything that violates ZONE_MOVABLE / ALLOC_CMA > > >>>>> guarantees, and unfortunately, it sounds like this is the case > > >>>>> here, unless > > >>>>> I am missing something important. > > >>>>> > > >>>> > > >>>> It might just be the name "AS_WRITEBACK_INDETERMINATE" is causing > > >>>> the confusion. The writeback state is not indefinite. A proper fus= e fs, > > >>>> like anyother fs, should handle writeback pages appropriately. The= se > > >>>> additional checks and skips are for (I think) untrusted fuse serve= rs. > > >>> > > >>> Can unprivileged user space provoke this case? > > >> > > >> Let's ask Joanne and other fuse folks about the above question. > > >> > > >> Let's say unprivileged user space can start a untrusted fuse server, > > >> mount fuse, allocate and dirty a lot of fuse folios (within its dirt= y > > >> and memcg limits) and trigger the writeback. To cause pain (through > > >> fragmentation), it is not clearing the writeback state. Is this the > > >> scenario you are envisioning? > > > > > > Yes, for example causing harm on a shared host (containers, ...). > > > > > > If it cannot happen, we should make it very clear in documentation an= d > > > patch descriptions that it can only cause harm with privileged user > > > space, and that this harm can make things like CMA allocations, memor= y > > > onplug, ... fail, which is rather bad and against concepts like > > > ZONE_MOVABLE/MIGRATE_CMA. > > > > > > Although I wonder what would happen if the privileged user space daem= on > > > crashes (e.g., OOM killer?) and simply no longer replies to any mess= ages. > > > > > > > The request is canceled then - that should clear the page/folio state > > > > > > I start to wonder if we should introduce really short fuse request > > timeouts and just repeat requests when things have cleared up. At least > > for write-back requests (in the sense that fuse-over-network might > > be slow or interrupted for some time). > > > > > > Thanks Bernd for the response. Can you tell a bit more about the request > timeouts? Basically does it impact/clear the page/folio state as well? Request timeouts can be set by admins system-wide to protect against malicious/buggy fuse servers that do not reply to requests by a certain amount of time. If the request times out, then the whole connection will be aborted, and pages/folios will be cleaned up accordingly. The corresponding patchset is here [1]. This helps mitigate the possibility of unprivileged buggy servers tieing up writeback state by not replying. Thanks, Joanne [1] https://lore.kernel.org/linux-fsdevel/20241218222630.99920-1-joannelkoo= ng@gmail.com/T/#t