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 713B5D3C540 for ; Fri, 18 Oct 2024 01:30:44 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id D67116B0082; Thu, 17 Oct 2024 21:30:43 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id D174E6B0083; Thu, 17 Oct 2024 21:30:43 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id BDEFD6B0085; Thu, 17 Oct 2024 21:30:43 -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 9FA436B0082 for ; Thu, 17 Oct 2024 21:30:43 -0400 (EDT) Received: from smtpin29.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 2846FA047E for ; Fri, 18 Oct 2024 01:30:22 +0000 (UTC) X-FDA: 82684993440.29.F5EA5DB Received: from mail-qt1-f177.google.com (mail-qt1-f177.google.com [209.85.160.177]) by imf02.hostedemail.com (Postfix) with ESMTP id 7DD7C80021 for ; Fri, 18 Oct 2024 01:30:20 +0000 (UTC) Authentication-Results: imf02.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=gNKFOXhe; spf=pass (imf02.hostedemail.com: domain of joannelkoong@gmail.com designates 209.85.160.177 as permitted sender) smtp.mailfrom=joannelkoong@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1729214847; 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=sZVKNx7iYNwMmxwNVimUKiG1hoYsVLPRoG+wE2ltw4A=; b=fqm9nbtWlo8e3lnP2JBZO5B6OsAQi7ZxQlHOm6xQxEtxrGWWOqNTSVrYfp9tr37lIYXCZ+ 1ZNp0i98z14KfA8Qdf3L0IFEVVCI7+zzVtGKWQ8j6lYZ7/mlYn/N6Uow8cMONTBWhPucN4 e/MjwZcCL39wAgRFtCquJYBp7lulZSY= ARC-Authentication-Results: i=1; imf02.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=gNKFOXhe; spf=pass (imf02.hostedemail.com: domain of joannelkoong@gmail.com designates 209.85.160.177 as permitted sender) smtp.mailfrom=joannelkoong@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1729214847; a=rsa-sha256; cv=none; b=grZ3/onP0mVTMOMyxpys3AVrKOHGSzi2n9AepsYi3djgpYCaiMclhBYVvASXFJNWLmBTld iuDS71L+jPaPxDsRM0n/QsE6ZbZ3tTjlaYudX102m3aqyyRahBL4zG6M3aZCZ4kGRmcBwF jbD665FWSRwxFH1hAPytvLXyV+e1A7k= Received: by mail-qt1-f177.google.com with SMTP id d75a77b69052e-46089a6849bso9386861cf.3 for ; Thu, 17 Oct 2024 18:30:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1729215019; x=1729819819; 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=sZVKNx7iYNwMmxwNVimUKiG1hoYsVLPRoG+wE2ltw4A=; b=gNKFOXhejayi+8asPMBYllo+41IPtT0bpFVzIJiWQLEIHrfJMg3GCTc56ml0d/eghs tO5oc4vf3ook0efGcpYJ2tijRXboYo+ov4v2dgDdQ2oCrxgUcGYENfmccvUwnzXtfYNk 316lnnelBhdRBZU8PE1UN8+ZQvmP3Hz1oPfNCzjvFBH1TmS+gDogCP0appc3U5rFZUHm uZJxDTmvqx7VJF3WkvAhsUwGMet+U9gxSZIvfRaRPODI1dDsfs+KM5gRwliFh0/FoUcF WQEAcdgrbGsad6OgWTQp4PBMIJBnQWM0esbn1rwNrWtJexEsJYvBP/8sk0x8EJj2jrMH oCvQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1729215019; x=1729819819; 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=sZVKNx7iYNwMmxwNVimUKiG1hoYsVLPRoG+wE2ltw4A=; b=uW+l8SdEHERyGVPMfBqpzjCB4sB+X9gDlll2NceYWJF98DSa+Q/eRUjV98oegKRzqd Eh40oj9/QkbuGS9zuCtuSOy7vt+u0qfriz1d6lADuBGizlNnmNn17hbVCwDCNlBOT2CK JQIP4zDZetycIQvob72EiCGykWgVWiG9J6uz+6NJpKBm0iLnBz5gnPjrcslzEH+ZhVAi iITtLgwJyROo8hybo814cbq8hzgKwNzK5nnVItigYYWttBbvHPuq97Cw0GOmRTJhqQRK j4/FhTRyP+Gd72dLGidSW49GxeFaZ9V7h7ZlA8aWm9RkWXc8nraYSI4w6X4aZjIJrhcv MLxw== X-Forwarded-Encrypted: i=1; AJvYcCXVJWd6AnOQ3osqqmd8Aqys6+h43OXV/pn/ckLNSDZ4HjXdiSkYxqi0VmTdP2InpQKuHpEOkJqtEQ==@kvack.org X-Gm-Message-State: AOJu0YwrgvYnfsAgP2Q05RcYkppgqMXO7oinWgr9/CeYoMQ0ielrx1+l FnVesND3INne6uqXCAd/bpdHDYnSE6j8hZqrAxsVniw8IzIaRdx2kDyGr+LhjmGJJPoVQvFkhCe +UdcYcBvRjyYdJzHpqUkTuXPcp40= X-Google-Smtp-Source: AGHT+IE5fksQ1BrS7z7aksxC8DURy773ccdhGVAUL/r/qAEcI1JUs2Tovnh/yMNza0jhPUj84BirK1Rt1XM706Ijiy4= X-Received: by 2002:ac8:5952:0:b0:460:948c:d546 with SMTP id d75a77b69052e-460aee41a37mr8823421cf.50.1729215019226; Thu, 17 Oct 2024 18:30:19 -0700 (PDT) MIME-Version: 1.0 References: <20241014182228.1941246-1-joannelkoong@gmail.com> <20241014182228.1941246-3-joannelkoong@gmail.com> In-Reply-To: From: Joanne Koong Date: Thu, 17 Oct 2024 18:30:08 -0700 Message-ID: Subject: Re: [PATCH v2 2/2] fuse: remove tmp folio for writebacks and internal rb tree To: Miklos Szeredi Cc: linux-fsdevel@vger.kernel.org, josef@toxicpanda.com, bernd.schubert@fastmail.fm, jefflexu@linux.alibaba.com, hannes@cmpxchg.org, shakeel.butt@linux.dev, linux-mm@kvack.org, kernel-team@meta.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: 7DD7C80021 X-Stat-Signature: 36xjd79w9jr8tjgiyz8ddirkasf3fd5w X-Rspam-User: X-HE-Tag: 1729215020-339689 X-HE-Meta: U2FsdGVkX19nYodpF8p1I9i6lqiQnpk2CXBorEDuedO6UBN6yexOExO6+siQYrZvddf0U7n4uEWu0mz9FVVm4dxbs6WABSBjO4zjEdn6bBPnuj7DaHTTPGwuN4iF1gUsP/NmYBhpplKXk2sBCdqjT1NE7vK93AahOAVdUIXQ1v2Pnk8GkcjAe7a9hf02b1b0Zyb1u+z7pzrPWO+mAOOtMQZlBygKEOFRmMf2Yfb5sBSC7J3EFRKDW1l6bVFb24ZHctu29+ehIpjhmbubZ3kImHnPaPx2BWTvtc5PjfDo33rTM3ESPn7gE8MtgcHxMHzZy/bsaIz+SAppAqffmux90ni9YnxmXlClQkySTJw/XuYKDe+OxSQG8brSwoleXph/nJuF18VX013X4iXez9OodlVyDDznGOhAujWFPulNoNxS55iuMZz5+QwOrg8Tt+3PZMdC9SwbBZi4cQdwLgQjsCqlP1kMAiYiKKTOTSfA/Ymy9IRsR/HkHouxwsvupaqei3iaUaqMM9QH46DgSFxcSDqaE6pqLyW0JoCe75CJ1/fwbQTV/bU5bIe7Jwa7hW7fG2H6Vnq+TBxjAgmvv5FTfHQL+gLXaEg5mkOBgQxxFv7sb8XFez7gLmowZ0xarhxhpAeawlqkYiG3MTKVROIns4clPzE+kr3QLVK97RuD/h4tPxkrq7pRuYiTKiXgm+eYKDbJxu4zTW/GXt+QtSkM6s9//sgX5Op7BnVKbln2SwM/0RRHyoUi72evb5aZPrBe8mQjV19wPyZuRYOyftehPzaQQSDDqB4lNS52DKF2RGnQvfUKat7coH4Wb54EUydDq8l8kFhubFwdT4KMzcGm49c1JLLfV9VcptZgu0tOYqPSnPuqvh8T+FwCZtq0/79yrybFYVTn21yIiUoS+JW/bPDky+n4FmmJq6y3r9hp7brhZ8lZuCcdhY+1DFKzhTgSKAo7WsFsuRZnV86+bCj tUYaWyIX dylq6jmepm9M3CM3HZaIy8JcXQqx7yG2OXTebGyJsF5WnMOFFvYsvTlNRfIz7Dnzu46/Ir79/I5BHhVn9tTuhle7ZXuY0ATvUKVMV7ILET/Fiq5b7XPWvqwqcpDXvQweIkauthowHIa7pcdfbZYUF8HwAUmURQT5Mty/gMvw0uOmGmMgQnSor+LlQYzcdElVLihqn1WK90aZDK1YXevtNr58hNF4oehYqbU7EPXKKADhyT8EZ9lVAsm309Oc3JqR6uIpDoMSg0oLINNI3FTsVny5WljZ+1aQ78RBDcEt6TetWu8OUz+Wk0kjIXnjA5JHOIYM88gfuABMXGCT9aG+pDam6/w== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000151, 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 Tue, Oct 15, 2024 at 3:01=E2=80=AFAM Miklos Szeredi = wrote: > > On Mon, 14 Oct 2024 at 20:23, Joanne Koong wrote= : > > > This change sets AS_NO_WRITEBACK_RECLAIM on the inode mapping so that > > FUSE folios are not reclaimed and waited on while in writeback, and > > removes the temporary folio + extra copying and the internal rb tree. > > What about sync(2)? And page migration? > > Hopefully there are no other cases, but I think a careful review of > places where generic code waits for writeback is needed before we can > say for sure. The places where I see this potential deadlock still being possible are: * page migration when handling a page fault: In particular, this path: handle_mm_fault() -> __handle_mm_fault() -> handle_pte_fault() -> do_numa_page() -> migrate_misplaced_folio() -> migrate_pages() -> migrate_pages_sync() -> migrate_pages_batch() -> migrate_folio_unmap() -> folio_wait_writeback() * syscalls that trigger waits on writeback, which will lead to deadlock if a single-threaded fuse server calls this when servicing requests: - sync(), sync_file_range(), fsync(), fdatasync() - swapoff() - move_pages() I need to analyze the page fault path more to get a clearer picture of what is happening, but so far this looks like a valid case for a correctly written fuse server to run into. For the syscalls however, is it valid/safe in general (disregarding the writeback deadlock scenario for a minute) for fuse servers to be invoking these syscalls in their handlers anyways? The other places where I see a generic wait on writeback seem safe: * splice, page_cache_pipe_buf_try_steal() (fs/splice.c): We hit this in fuse when we try to move a page from the pipe buffer into the page cache (fuse_try_move_page()) for the SPLICE_F_MOVE case. This wait seems fine, since the folio that's being waited on is the folio in the pipe buffer which is not a fuse folio. * memory failure (mm/memory_failure.c): Soft offlining a page and handling page memory failure - these can be triggered asynchronously (memory_failure_work_func()), but this should be fine for the fuse use case since the server isn't blocked on servicing any writeback requests while memory failure handling is waiting on writeback * page truncation (mm/truncate.c): Same here. These cases seem fine since the server isn't blocked on servicing writeback requests while truncation waits on writeback Thanks, Joanne > > Thanks, > Miklos