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 04EBDC02183 for ; Tue, 14 Jan 2025 08:39:04 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 8BF0E280005; Tue, 14 Jan 2025 03:39:03 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 86ED2280003; Tue, 14 Jan 2025 03:39:03 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 73644280005; Tue, 14 Jan 2025 03:39:03 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 53615280003 for ; Tue, 14 Jan 2025 03:39:03 -0500 (EST) Received: from smtpin01.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id CFB9A12079D for ; Tue, 14 Jan 2025 08:39:02 +0000 (UTC) X-FDA: 83005407324.01.1F73500 Received: from mail-qt1-f170.google.com (mail-qt1-f170.google.com [209.85.160.170]) by imf13.hostedemail.com (Postfix) with ESMTP id B1A0E20006 for ; Tue, 14 Jan 2025 08:39:00 +0000 (UTC) Authentication-Results: imf13.hostedemail.com; dkim=pass header.d=szeredi.hu header.s=google header.b=PnjbXC7e; dmarc=pass (policy=quarantine) header.from=szeredi.hu; spf=pass (imf13.hostedemail.com: domain of miklos@szeredi.hu designates 209.85.160.170 as permitted sender) smtp.mailfrom=miklos@szeredi.hu ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1736843941; a=rsa-sha256; cv=none; b=Thp8HoUV5usXL9pQd68rUSnSstRlURskZxoucbpA57XnwbodO7F0opdS5LmeI+CW8EpRfD 0ENR/XK/aBM2Oi7U/IctcIxeLiL3L61EYugBhKsrDcuqv1aIP3nL0qCdj9NtBqaoTqOzzg Gj+OkWfsLy7SbcVdBylzyXYpuShROTo= ARC-Authentication-Results: i=1; imf13.hostedemail.com; dkim=pass header.d=szeredi.hu header.s=google header.b=PnjbXC7e; dmarc=pass (policy=quarantine) header.from=szeredi.hu; spf=pass (imf13.hostedemail.com: domain of miklos@szeredi.hu designates 209.85.160.170 as permitted sender) smtp.mailfrom=miklos@szeredi.hu ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1736843941; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=/9gXrJEdxE9BES3C0tahnLqshk2xWlO7dk0aSnzTxp4=; b=m0RE4D3oZpyjJHuv2NpywOvqq7OCvfm+kus5YHG+i+YAmbBd9vqj4aGxnhhoCIKrx33QoQ muc/6ezZzlFBzeDW7ubDSSBQ2yQKhB11ItX0Q2ewrQE7GqirD1/UmaVkSf8wiqM8For+kr g5DTfL7mN/Bpo4PAaJ57ro+Trd/IVi0= Received: by mail-qt1-f170.google.com with SMTP id d75a77b69052e-46c8474d8f6so34076051cf.3 for ; Tue, 14 Jan 2025 00:39:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=szeredi.hu; s=google; t=1736843939; x=1737448739; darn=kvack.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=/9gXrJEdxE9BES3C0tahnLqshk2xWlO7dk0aSnzTxp4=; b=PnjbXC7e8cdmbAg9k7KaAJmuPXrF8DsMs9Bgyidm8+T2tfR7DgeLTRZmQkATtrhNM/ BpcttMNiAnlmN6ics4yvBqsjonsb8BQ9NjSPixsHos0AS85UlWCXstDYpvMy2IAaewjC yxhZopwwQVP6fh0eD5/jocm23VeoAPu4FTMAk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1736843939; x=1737448739; h=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=/9gXrJEdxE9BES3C0tahnLqshk2xWlO7dk0aSnzTxp4=; b=nlYC2NjQWOd2FjPpS5bIOICQgDag5aLCRIi9NZDEAaTFmUeAlfkgGcsJDy6y0cgjgG aaNYS6kvw95XUomEw3Alu7GldRBQjPAg/nr2iM6/HH9TEAJVAbmr+c/Yk7yOdvscJ9KZ t1m74vvBdQQ/KyGpJHdGaKFpAFnh/syhRf8TjAWa1WYrUnTgN+3WthAW8fdG8BvVJ9FA 4IQN7yHl6K1dx1GTc8G7H68JLWXlk0u32z8jsiZSD3gbUt7LlvPi1g2Pvczf1PfeEkNv jZ+HZdlQ+c4SVKIUN9lHPurs9jx+QE94lLmzMyVAHLhykkSkIe2aYqdIEQOpmnWxKs/f n4ew== X-Forwarded-Encrypted: i=1; AJvYcCXjiOZE2mKG9MsNNKNL6x+IYf0Z6QeGTJBHh7d7zdoc36tkNDmefa654x9tow+MSO7XTDi5w9cIkA==@kvack.org X-Gm-Message-State: AOJu0Yx/rg6riDK5aLSdiOZZgt/OMVCRU7WV51FuZopPKGD3xS1aBPsH zLalgFEn+WHegzH5tJLjX7sVAqlGBcXgCfgSEuOPDblrgeZQXcxdmVOyM0SjF0slNStiTS0N0Br RTXrROUReesRN+puILzR+v4A/rQmXiwZ+Zs57Lw== X-Gm-Gg: ASbGncv2zBPWwLs5MdSM6YedQdC0wnl4jAKMIsjnYt55LjAz33Ha1xm2+Bg2+46CAXx 1E0wXFsUC6ZTBp0xd2PIG+1QoZxGA9ILVH1lr X-Google-Smtp-Source: AGHT+IEJKDfnmsXjSbFk5D88FYMeWl9RkltEjwsUS/7pNDJcXGKcBjcxurJLDulzVtLc0VGVXfFFxYlJlx5xsv+P8Ng= X-Received: by 2002:a05:622a:180c:b0:467:4fc5:9d72 with SMTP id d75a77b69052e-46c710e4d0bmr411318271cf.36.1736843939597; Tue, 14 Jan 2025 00:38:59 -0800 (PST) MIME-Version: 1.0 References: <791d4056-cac1-4477-a8e3-3a2392ed34db@redhat.com> <1fdc9d50-584c-45f4-9acd-3041d0b4b804@redhat.com> <54ebdef4205781d3351e4a38e5551046482dbba0.camel@kernel.org> <2848b566-3cae-4e89-916c-241508054402@redhat.com> In-Reply-To: From: Miklos Szeredi Date: Tue, 14 Jan 2025 09:38:48 +0100 X-Gm-Features: AbW1kva92yO2fTIr2fmGoiS8vGjhFf6j-l_b4bVMDNUI_zrX-XtZj908q4CRcag Message-ID: Subject: Re: [PATCH v6 4/5] mm/migrate: skip migrating folios under writeback with AS_WRITEBACK_INDETERMINATE mappings To: Jeff Layton Cc: David Hildenbrand , Shakeel Butt , Joanne Koong , Bernd Schubert , Zi Yan , 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" X-Stat-Signature: di6wi7pusj3nxn61hrjfpgphn3n6k8kh X-Rspam-User: X-Rspamd-Queue-Id: B1A0E20006 X-Rspamd-Server: rspam08 X-HE-Tag: 1736843940-510797 X-HE-Meta: U2FsdGVkX1+XliPHLXYtsc3UkocFPXbIp1RClWcx2uJt8QXFXGGBZxO525hbgt6z/lAQ7wxC4HzizSIWGVDl9VxR/j3zoiXbHxhERMvoCxxP5fVO6F5V0zt0CItke6glyH4fmOz7eolIpU4D95A1PBMGCmhzqxcNiijXS7b61Q6tEJBC0lRoUInxY9HpbUj8K6KZl3PQKn1bA5yIXUg7M15n5oJ/3LsAxWXKKTo9LHBdgkv1BR9vncx878OlFShPlWp6urVfYGl0hIc3DsbRpwmOtGUvT9AtkZPXCfzoZQ5FW3oQQyYzakXLov5nVC7uboTyk3Y0k/Njhi+mxxlTLgLIOex0F5qZbjDWiUHwQDh+6PDbC1NMaSMzR1x2hQ0vt5tDpMtViOWaEIGL3hHUPxrbVVDpiP6jduQ/Dx6p4+vQVYJ1PblxDeH5etBWfGgOUHeZxA2MZH4gM/ZEJPBcBk4Q7ahOD4tdhDaTlSizLhZRJhNZVP0D2TRWFo3vTWnnH45DpvZveHrlVRDSBuG6tTrbDykHfXjYiZTcwGsEdD3RqGB+p2CvQfNbx4aT46TGCyz+FpfrApEQdsn7WQQ/bvjdLg250qAynj4mdIM+gfO7mxFIvNcr5FqbNuAApsUTLRT9FHh0dZTNDxM+zqVifUt/TGFtP/vrpvnoXrG7p6053qR3uR/xEYuYRKx88o+MMbqjG6+4XVbVpFTwsver+leogxFa6B6OtI41yNOiEy8kOPL0v1QN4QKet9z2FREM6GXU3i1u4C1NR29xc7fH4XDESXdSCZIGf+hmJMxPMX2EArWzTdLZvlql/Rwv/x6IOTsvppD1oS/wDF2hyRoTVioV4peZL68zSSaHNgnfq/aAG0YhgYBXvNO+kvMd4BBA5Wjb6u/jVMjMA9EIRtxKQBxDN2rLxMtldZ525zR0q3HjLhf77xwVkSsgPgqDkNVloihwqJBeNAh5X75kcUX Rh+1l+kr J0WadBXbRilNjroZNArbPFdcdasQc5/hk0uC+eZGyh5XksKawjhuXOgYJXO6AhAtQE/Y3GSCuhBbRgDVXZZcCF6W+HNwFP5Df0RzFvNHSi6ajEpSp3OAmYWRxUnV/dp0VU9qrnwKl7+sIglU4r/sf8A7COzkRG6wLlxR5y2sDppTsi6FIK24ndiezALT4GhQkVoC6eYhVVSbsYc0EXmv6XJTnZ63XHU0icbT6XeEqW/uSGvfjfSqVyfFp90g3Iz3LuXbEfkKJNUVntW0= X-Bogosity: Ham, tests=bogofilter, spamicity=0.080635, 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 Mon, 13 Jan 2025 at 22:44, Jeff Layton wrote: > What if we were to allow the kernel to kill off an unprivileged FUSE > server that was "misbehaving" [1], clean any dirty pagecache pages that > it has, and set writeback errors on the corresponding FUSE inodes [2]? > We'd still need a rather long timeout (on the order of at least a > minute or so, by default). How would this be different from Joanne's current request timeout patch? I think it makes sense, but it *has* to be opt in, for the same reason that NFS soft timeout is opt in, so it can't really solve the page migration issue generally. Also page reading has exactly the same issues, so fixing writeback is not enough. Maybe an explicit callback from the migration code to the filesystem would work. I.e. move the complexity of dealing with migration for problematic filesystems (netfs/fuse) to the filesystem itself. I'm not sure how this would actually look, as I'm unfamiliar with the details of page migration, but I guess it shouldn't be too difficult to implement for fuse at least. Thanks, Miklos > > Would that be enough to assuage concerns about unprivileged servers > pinning pages indefinitely? Buggy servers are still a problem, but > there's not much we can do about that. > > There are a lot of details we'd have to sort out, so I'm also > interested in whether anyone (Miklos? Bernd?) would find this basic > approach objectionable. > > [1]: for some definition of misbehavior. Probably a writeback > timeout of some sort but maybe there would be other criteria too. > > [2]: or maybe just make them eligible to be cleaned without talking to > the server, should the VM wish it. > -- > Jeff Layton