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 D2E2AE77184 for ; Thu, 19 Dec 2024 17:37:31 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 4B41F6B007B; Thu, 19 Dec 2024 12:37:31 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 463C86B0082; Thu, 19 Dec 2024 12:37:31 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3530F6B0083; Thu, 19 Dec 2024 12:37:31 -0500 (EST) 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 1A71B6B007B for ; Thu, 19 Dec 2024 12:37:31 -0500 (EST) Received: from smtpin11.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id CBE85A013D for ; Thu, 19 Dec 2024 17:37:30 +0000 (UTC) X-FDA: 82912414830.11.BD7146F Received: from out-188.mta1.migadu.com (out-188.mta1.migadu.com [95.215.58.188]) by imf14.hostedemail.com (Postfix) with ESMTP id 0DDCE100011 for ; Thu, 19 Dec 2024 17:36:51 +0000 (UTC) Authentication-Results: imf14.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=fTRBcy9P; dmarc=pass (policy=none) header.from=linux.dev; spf=pass (imf14.hostedemail.com: domain of shakeel.butt@linux.dev designates 95.215.58.188 as permitted sender) smtp.mailfrom=shakeel.butt@linux.dev ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1734629833; a=rsa-sha256; cv=none; b=wIt9ishkuwOD5CF03D67azSdYsINeusAGyth1xH2LGe5+n0FVAFWG2xYPZprqOoG4EfrND gukinQuQOp6ywcfnKdXQkAt8BJa5qYP0U6744g+I/HNwyN4HjW3PCY62kCTmR71u+HoAQG rxyX60zXLRyXaUDtrrNg3sWnpqvZVfc= ARC-Authentication-Results: i=1; imf14.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=fTRBcy9P; dmarc=pass (policy=none) header.from=linux.dev; spf=pass (imf14.hostedemail.com: domain of shakeel.butt@linux.dev designates 95.215.58.188 as permitted sender) smtp.mailfrom=shakeel.butt@linux.dev ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1734629833; 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=Ez9lQ0zUpSZUQnMmCVi1G57IlRWrWw6LTcl8bwl1GfQ=; b=cyHJhiTmp+AyZ2DFHugx54rSGHphToNBzw14ahjf5fpHYGiznvGbSc3AmBCWEn9p2HHbEk pAyVV+VlcL1uNAwNIJFb/SxT8b6sw8xCx/pdzzA9y6/E8IC173/0fXsEE1TlgA4MI5emSh hnHtsbHNC5U/Y04YB1S4Rt5fApCDI7k= Date: Thu, 19 Dec 2024 09:37:20 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1734629846; h=from:from: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=Ez9lQ0zUpSZUQnMmCVi1G57IlRWrWw6LTcl8bwl1GfQ=; b=fTRBcy9PF31ktvOR3VGccK6aHxK2a4u5zfvB0ONMeTAqr2Agp0aq9UwpaEEeyMoIdaB0uC mIJd/EQvEKg4sSGzdJobv/zbD1R8zX6Jv9J4BWmXjgCArNgLwyo/wKOXEDnSRfOIwEN2mm 1f0p/Oa/Kzia+4887i0SYWEDzLvCNgI= X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Shakeel Butt To: Bernd Schubert Cc: David Hildenbrand , Zi Yan , Joanne Koong , 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 Subject: Re: [PATCH v6 4/5] mm/migrate: skip migrating folios under writeback with AS_WRITEBACK_INDETERMINATE mappings Message-ID: 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> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <2e13a67a-0bad-4795-9ac8-ee800b704cb6@fastmail.fm> X-Migadu-Flow: FLOW_OUT X-Rspam-User: X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: 0DDCE100011 X-Stat-Signature: bfyh1xwkb1qm7456yi7jk6c6eodmju9f X-HE-Tag: 1734629811-81533 X-HE-Meta: U2FsdGVkX19AhnXuYwRQCsPmLKLBNwdiLRYNpTgq+xyUwdn62ivJ1Q+ChNul2wTafgJpbIUH85gvLS5z0Si0L3rnDKImiJTFBQC0ds48vgvSu6O9EZ7kURdVMGhCxV+knUOAhqtRSExCymA9fD5XQVYSCmU/Cy9Di3NKyu4cFs9bSQFu9udLbd84F7t+zu+a2ACzRSU6mmzOZzK5zCt+gqmTu4QOM0fY6WxnoxejLI1YVzD0k6Mizol731f7+jeWRQSC+S4jUtCIAUlsptfrFvDihIbpJAsRz0cQX0wXPgDv9wAbd4ed1tSjt4Lawro1NeoCsOujTADoUjLxFjokj2MEZeXG2G+FJTQxR5riywnPoMz/7OT6o74ypCksaC+xECby1HxpvxAgd865Uj0QXFIpkIBdEL/XYL3qBCSAd79qxAgPLJDIV7SKOtcHYTZrtAUdhHn22kOan0Q16fWZW+hZcdyWpLt27UetxR8U2JvN8GKg6/8ZF/xfeLaiZBN8Htp+V1DC2S36LdC69cYSIs+NGQUc+6pE3FlbxldsQcJ4IuDiSZ6M4LlbIfbZ1eWlufcea7PwdwP6CrR/julbDo3dFMvNAufROX/QqsTBLJ9GjrChjuWHSfiT/2quY9PGvDg8BtUUqe2ofN6U+JPms/8bvobOq52eCXmERmMJnTOT9pJKy557eRDq1h2fM/G4wXjaksMrx0TbcAsoc4stRkNQcDE2zAlvJbPhooU83hD7aCzBRMHXfm+gzCgmDnSI4c77SxhgR+f8bM+Fzh2uoOitQM/F7G83fePgYaO0uIYy+YyIULoXioWtkKT9AumbOs2jFmHV6rTke8h5gElrp5QnIG5K94ZU4Var/BynfRMify62oEzUJHGfLiQzzegeSjuwVBrOQPb1Bfcxdf7+KGmS2T+wMtNW+y3N78We8ybNeYOayp0Lp48mFK9p7M3TRypx6tE9Fgn+8YTSJ4z bV4jvcY2 iWJ0k8OExzm7w4Fi6/OrYpZ/OalCeyimxSwOX9Ja+g9vIx26gqw8s1V3bpYZRvUawraB5NjpLPlSwkW+XLPr1VxCUoYHJZDfH+vymSsZm8dvzmOegFnWNPZ3xa0jmeNBTuJ2Ra/9yJSIYn0D2dPKtXId4SkFwyCrKBq8IX53KlXTrx5UjHoUDd5hbEaM+dXRTriZLhf19AEO0qGzAjhCZFkFMdDaEhwJMKg6d 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 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 under > >>>>>> writeback which is a temp state. Anyways, fuse folios should not be > >>>>>> unmovable for their lifetime but only while under writeback which 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 fuse fs, > >>>> like anyother fs, should handle writeback pages appropriately. These > >>>> additional checks and skips are for (I think) untrusted fuse servers. > >>> > >>> 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 dirty > >> 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 and > > patch descriptions that it can only cause harm with privileged user > > space, and that this harm can make things like CMA allocations, memory > > 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 daemon > > crashes  (e.g., OOM killer?) and simply no longer replies to any messages. > > > > 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?