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 A4A23CE8E94 for ; Thu, 24 Oct 2024 16:55:10 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 38F006B00A2; Thu, 24 Oct 2024 12:55:10 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 318366B00A3; Thu, 24 Oct 2024 12:55:10 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1B9366B00A9; Thu, 24 Oct 2024 12:55:10 -0400 (EDT) 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 ED4F06B00A2 for ; Thu, 24 Oct 2024 12:55:09 -0400 (EDT) Received: from smtpin05.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 384251A1061 for ; Thu, 24 Oct 2024 16:54:36 +0000 (UTC) X-FDA: 82709095518.05.45C3EC6 Received: from mail-oo1-f52.google.com (mail-oo1-f52.google.com [209.85.161.52]) by imf15.hostedemail.com (Postfix) with ESMTP id EF1C6A002E for ; Thu, 24 Oct 2024 16:54:48 +0000 (UTC) Authentication-Results: imf15.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=cvg4QP1c; spf=pass (imf15.hostedemail.com: domain of joannelkoong@gmail.com designates 209.85.161.52 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=1729788830; 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=nsxehwx5rj/3butAtwSut3oTBv9CrenVnd4AZCxzHE8=; b=S3UiTABqlrfgvKgPUP4XHCmJpQ+LjqFTgUCvFi1rsWdbDLyCzY9+HU38/0lDVTmJ0r+ksq dQ897MeWnVAuIW4k7VNmXZ3y4i/y68w1ETc41pj4HPrtGN0MSN8AnpAkPWbwXjPCrc5KxM vrtbcPJetdrWDlE0FxGfOt4ZIx4Gj3k= ARC-Authentication-Results: i=1; imf15.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=cvg4QP1c; spf=pass (imf15.hostedemail.com: domain of joannelkoong@gmail.com designates 209.85.161.52 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=1729788830; a=rsa-sha256; cv=none; b=UxjE/wBg6jcKaLwTrU4rETUg3PHsm1zpzKIVxDk6MQrSorx4RjgySgDCpzslEvZp8z3and lEW2xffFHJQfbsH+m9vw5HV2tm8qQYgUzEfxd9nBQcZVQPgz4pua69mvMD6n7s7oXwNEvM rTScEzJuVtIOrSow8JItT300SqALtVE= Received: by mail-oo1-f52.google.com with SMTP id 006d021491bc7-5ebab72da05so539749eaf.0 for ; Thu, 24 Oct 2024 09:55:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1729788907; x=1730393707; 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=nsxehwx5rj/3butAtwSut3oTBv9CrenVnd4AZCxzHE8=; b=cvg4QP1cKpcUdP+m5RfiX/rrgt4w3SVPN9LbyR3yn7Xp5cyJB2JxpkDLG516H+Y9Y8 2pzbJdaaucGVKvPOtEWW7tHJTvev8w9SP1uoqpbyxhaK+SJAl5GqIkqQazrqzwD98T0J CjzNtHCSLqktRwoH9vyvaUEWvUH4JoHDpsU7ZKfwymRjwisTBG34eP6nd1IhAzQ7y/G5 1saNQF3mXN3gm8ju4Ut5n+x147iNMeJDBvxRsecnmojhYLV4/9Y/+mJjWmFFliLbgRaT g+lJCZHKEVMVoHiuoKXC10qHoLa9OgbNhofgYBiiZ7Cdi2UTdQTVnasrqkrhp1sLXqq2 zoyg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1729788907; x=1730393707; 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=nsxehwx5rj/3butAtwSut3oTBv9CrenVnd4AZCxzHE8=; b=VF23KfRKXFDZLMp625T21rxFtiIrHlkSrXvUX34M8FYkzEEFu+fvyJdmyFO+LuFJNb aKBtMK5tfo+e1nvBPPDTvqJaDvRPUgM5SC9z2KWWhP1gRspHbnRZ0caAA3J1tnSo5GNY zNxN2nRtwfnwhSvSc5JEIbHQdrBQ6a1oeOmbd3AZcMvisMQ1+cjBHE1iAlL5dxBZgMtX I0dAaVf368qJ+Mucr3IQDDOiIHSg+3bMfLbCZtMN3YVMj1tD0IQAtg26kEaFidb1eNOX 25rL9MxzTXVy68Z4VnK9l61j+hTlTxZKVqi/2L0i0Co8TkqD0/MSTfZiTmOkE/WBsBhM it3A== X-Forwarded-Encrypted: i=1; AJvYcCUdiFaaYO5mpM26nmj8eaY9/RD6kTvq7t1q8Uem6fNrfpAtupkTopiviqzcVAOW4JdrBv5X/ckv4Q==@kvack.org X-Gm-Message-State: AOJu0YwvPQzQG+idDeRZapfvblJfz5jmXVqqbX9K9+9cyxUkUkvYL/xY QHVAkkeX3evCPPQgdCXn7B2gaH0F3IEbciIq6Fh4RIg3w3igz9yb1FPuST+ir8AVpzPY3OdO88c y9vnAKT59/Y8EJjrFEW1DSa2/+nU= X-Google-Smtp-Source: AGHT+IHmvls8WbFBJsOeRRviOjJpnHymZ95JCWz5Av1XvK2GK/Y28lqgr259UNOkqA2HjjcxAmhvSTSHqywQ1MgxXo4= X-Received: by 2002:a05:6358:7188:b0:1c3:727:844d with SMTP id e5c5f4694b2df-1c3e4d171b9mr189199755d.4.1729788906681; Thu, 24 Oct 2024 09:55:06 -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, 24 Oct 2024 09:54:55 -0700 Message-ID: Subject: Re: [PATCH v2 2/2] fuse: remove tmp folio for writebacks and internal rb tree To: Miklos Szeredi Cc: Shakeel Butt , linux-fsdevel@vger.kernel.org, josef@toxicpanda.com, bernd.schubert@fastmail.fm, jefflexu@linux.alibaba.com, hannes@cmpxchg.org, linux-mm@kvack.org, kernel-team@meta.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: rspam03 X-Rspam-User: X-Rspamd-Queue-Id: EF1C6A002E X-Stat-Signature: oew4h4cnnd71ofz3qgfdh1xaaohhkin7 X-HE-Tag: 1729788888-916351 X-HE-Meta: U2FsdGVkX188YFd+cDurkgDjoRb62ke4kS0M8FhTpaIG5gI1SJfmU0HMaP8/CVIm3lyPz0AG9U8+1QyFlALfQq4RgVV1FdrBtN8PcVNP8KlNN/wl+nh2Rq05rhS4qfDZJEXln0TAchPr/u6K7G43Sh+kDYmTtgAFpJQfXZnorrXLmf8N47WMOahzqijEXmN7ddoyq/gyCzH1biX5gtDgWxrIXbmR9y0Y71HWtm3mSKd4QVxkpKup68gIpCosnNVDeukg00qahxeHz411J2dle8vGsB8fHAISh1nobmHv7fRd1fgnX7aupaIB2E4SYBMS2mrXsKmIhEau1HjoRAUh1UVvGYhZaXblAZu1AiYZtvJzPM7gRpouAr073wID839IkwNYjoIU61W6jsYvGMKK8cXSKdgTaK6FczQRtLYk9RjC2a3XNIUIJEV1xxEsB/HT1XKBY04sIEoZC6tGHSiC8r7c5B26yLsUVT/XgDwLE/aVRijgTE7tP6jNJkzgVBG/1oB1t9nqaPBSlVp2MvPIY+0j8nvTlihHZBNU5oYGRrrIlbhktalZjNdbiphIp1b7nNDppqM6zfwy9joUWADl//8ZUY/PR7C30HL29LgCAf4ZHtXbot1sorMX/ineBhEfbp+cTx9f/BV1PpVOREtdiyWKlasEScsiCLZ7TW7qWb5pb8s62hCXwAi/3p3PW2ssupuPNF3PpSMrXpOqKuElkf99ut2SAdO/wgRfYkezdVcV9BhXHw++LbeF7W4IWDcGY805W1C+QVYP68qGWjpc3YCss3loh/OxdplvflH5EgArDMrQzV7yw4eMs7U+GZ/kk01c4UEupXbnXevN8ds/XqHmm/a3EllSyN2FVzmyhQdBStLZiBuUVn1N+NYKwvUgUP66qH4+jQbRix/U9behDSqm4e2nouuDk9vvm/2d64nrhUfmEblzpVRLeZ5HNW4VXeLvw36pBksKzBwNOSG gdq7Pa5p JRxp+VFoQXP+4IJp+ApLtuwCCSMF8sa41GV/OFISJYHY3MXzDRgA5ZDCKRgSfsFM0L0q5jseiKjKTkBJw/V5BEZXSUPWbf2VQD1OUpqq9mMuFQLQhT6ytT+RpwOzxLMNIb3ayVH/8k+PljTmSDHob0t7dj98clJsTGQgim7VgDc0dhBE1Mn8kBchMgFp7ulHzhRjBVpGKm5eICQJ8aqYX54158gjRkiIC6qkxOX88dC27gI5vqOwMsJzLyd425lrivaHq6GmBer3d6/1854LewAADnYaZ+nBruS5tUc2FXlvn5EdXMGJAF6wlEHdGzlkTgoZDhdoAgAmxQXBiaJpltH4jlPzf3f08pU8Pe2jChs2cDYPkAWk0Ue+J7sqVHNRaVV+pJb6h/8d3CRPDqfPSfECw+F0d28ZkiTsfhAGWGMXCqbtTDGSdqiduFpxlmAN7Nl8162DxoR1zOdNb5bqOQoO4jQcyjVl780KH X-Bogosity: Ham, tests=bogofilter, spamicity=0.000147, 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, Oct 21, 2024 at 2:05=E2=80=AFPM Joanne Koong wrote: > > On Mon, Oct 21, 2024 at 3:15=E2=80=AFAM Miklos Szeredi wrote: > > > > On Fri, 18 Oct 2024 at 07:31, Shakeel Butt wro= te: > > > > > I feel like this is too much restrictive and I am still not sure why > > > blocking on fuse folios served by non-privileges fuse server is worse > > > than blocking on folios served from the network. > > > > Might be. But historically fuse had this behavior and I'd be very > > reluctant to change that unconditionally. > > > > With a systemwide maximal timeout for fuse requests it might make > > sense to allow sync(2), etc. to wait for fuse writeback. > > > > Without a timeout allowing fuse servers to block sync(2) indefinitely > > seems rather risky. > > Could we skip waiting on writeback in sync(2) if it's a fuse folio? > That seems in line with the sync(2) documentation Jingbo referenced > earlier where it states "The writing, although scheduled, is not > necessarily complete upon return from sync()." > https://pubs.opengroup.org/onlinepubs/9699919799/functions/sync.html > So I think the answer to this is "no" for Linux. What the Linux man page for sync(2) says: "According to the standard specification (e.g., POSIX.1-2001), sync() schedules the writes, but may return before the actual writing is done. However Linux waits for I/O completions, and thus sync() or syncfs() provide the same guarantees as fsync() called on every file in the system or filesystem respectively." [1] Regardless of the compaction / page migration issue then, this blocking sync(2) is a dealbreaker. I see two workarounds around this: 1) Optimistically skip the tmp page but add a timeout where if the server doesn't reply to the writeback in X seconds, then allocate the tmp folio and clear writeback immediately on the original folio). This would address any page migration deadlocks as well. And probably we don't need the reclaim patch either then, since that could also be handled by the timeout. This would make 99% of writebacks fast but in the case of a malicious fuse server, could make sync() and page migration wait an extra X seconds. 2) Only skip the tmp folio for privileged fuse servers (we'd still need to address the page migration path) Would love to hear thoughts on this. Should we go ahead with option 1? [1] https://man7.org/linux/man-pages/man2/sync.2.html > > Thanks, > Joanne > > > > Thanks, > > Miklos