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 2A743D149E8 for ; Fri, 25 Oct 2024 18:48:05 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id B38836B0089; Fri, 25 Oct 2024 14:48:04 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id AE8C86B008A; Fri, 25 Oct 2024 14:48:04 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 9D7856B0092; Fri, 25 Oct 2024 14:48:04 -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 7FBA26B0089 for ; Fri, 25 Oct 2024 14:48:04 -0400 (EDT) Received: from smtpin12.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id DD3A7C0F04 for ; Fri, 25 Oct 2024 18:47:42 +0000 (UTC) X-FDA: 82713008700.12.7C6B94D Received: from mail-qt1-f170.google.com (mail-qt1-f170.google.com [209.85.160.170]) by imf28.hostedemail.com (Postfix) with ESMTP id 46B5BC0023 for ; Fri, 25 Oct 2024 18:47:42 +0000 (UTC) Authentication-Results: imf28.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=Oq4A+82q; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf28.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=1729881968; a=rsa-sha256; cv=none; b=iOHUBFZvjEZZIyWpAXeHArRbJI2l5+FrPnInq0QMxpGpPsHlhXx0TgKc+h1cA7TjfCxbjl hq+qdUWrP992jUH+4PUrOAJ+VbsE2XTHtC7MTkJ5zRCuSehF0j6gZoFch8Xcthh+P4NpoP a5eK4tH2v5EX/sgWMaYNTHLV61Qkmag= ARC-Authentication-Results: i=1; imf28.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=Oq4A+82q; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf28.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=1729881968; 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=GaHQh/uxcueeKmc7Ia2usZ0ir1pT0Tu5YtRHZ1CT2Gg=; b=8f2nVfMyrvUQ5CvdAeYb1eW9ebDOZ8erg6YzkdBZmcRkqg85cPBx2tn6WPK83gB3q7b/3H J3Ajlp9fLo1q0AaugNVxMMSM1S7TUgf+NWtfAItRODgUKFKsaF+Pk0YhuR7cLYwz9w6xDr jUpb75oWz1uvLGZCUbB3M9JSRURkQY8= Received: by mail-qt1-f170.google.com with SMTP id d75a77b69052e-460c1ba306bso14058141cf.2 for ; Fri, 25 Oct 2024 11:48:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1729882081; x=1730486881; 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=GaHQh/uxcueeKmc7Ia2usZ0ir1pT0Tu5YtRHZ1CT2Gg=; b=Oq4A+82qKYjNMRb07DM/ndOiepmjp+rqydHnA1+OVNzWMtTVB5gvgN1vvMaxjP/t0T zNsmsyvIyzvbjT4icpuvvWS9eZJSOmAxXHKFDJCN1p8zgn0wAg1k87GrL2xtvBmUKTOY tuVVEJdr4MPIc6yDNtrxJbdKyx57CKQdg66+AL2jZWNt9ByFc32ieaNxZHoutINx4SP6 ibdEkRnyjRDp+fn8LTtZ1ViGCHq2VUwo2IWvFet8u4WW5FjZhIX/f6iGuqlS00Joortu rKIVOU9sTN877g+CW/P7Vwui3QGQuKZqVreIrNNivuXS4MvvwyRvtu3ylLAnWAL/Wiin DPhw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1729882081; x=1730486881; 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=GaHQh/uxcueeKmc7Ia2usZ0ir1pT0Tu5YtRHZ1CT2Gg=; b=SNTl0dnh0nTvAn8bf2brBfq7ts/uzOP3HwupUwlTNtPYG8+SfNfu2huLhqlAzQuYsL jgn1Ts18vIJSuM2xxU9p8PTQ3RR4Gv07EarLRTQDPW1MpwoPFK7pl1YGE6xJ9jcdBaGj sKRVG1ArOUlc/PhndvjL15rdBLVb5pusHm+qtZp6uttOzMZf54KP6ZA0FbcxX4AFEi+2 Frwu9rFT5oCMJ4iOvbus1xwYPJs1J2JamLZx9gLpMX/1AEFKyECP1cLvFJuQmmrlhEiN hd+pVoBwy00q9MrnEaWQm78jSX2TPBmIEFH90SkUmgdeUVAm3yUQmd4dXwK9uSgdNgGQ 9Shw== X-Forwarded-Encrypted: i=1; AJvYcCVgIbXn91lbKKG4d4OkP7XpifApoowq4RYpoKYR7ZEd/ABHPa4ByJtKq/XYqILQh96NKyHRpf0XVw==@kvack.org X-Gm-Message-State: AOJu0Yz0RoSsKiflScijCn3DI6YgygReMLHxipwcP2B6Ltc61IimAXAJ IUERe+elSm1vohyp9aPiGaUjwQq2YtpRFthl0Q3Iv6ttk35ltsc8MAaQQbascjQ7fOv5Nr8uXi9 lvSr76LnmmvDybdXFhsbbOmBYJA4= X-Google-Smtp-Source: AGHT+IFKzGMyWhJk3WQPpCMXPD5R1Ppb/OJq9Et0s6vPW3KvecDYCHRMmEMI7RTce8d+qOUyE//Giekmeh2v7CzMScc= X-Received: by 2002:ac8:5f14:0:b0:461:22f0:4f7d with SMTP id d75a77b69052e-4613c19dcddmr3037511cf.41.1729882081428; Fri, 25 Oct 2024 11:48:01 -0700 (PDT) MIME-Version: 1.0 References: <20241014182228.1941246-1-joannelkoong@gmail.com> <20241014182228.1941246-3-joannelkoong@gmail.com> <3e4ff496-f2ed-42ef-9f1a-405f32aa1c8c@linux.alibaba.com> In-Reply-To: From: Joanne Koong Date: Fri, 25 Oct 2024 11:47:50 -0700 Message-ID: Subject: Re: [PATCH v2 2/2] fuse: remove tmp folio for writebacks and internal rb tree To: Jingbo Xu Cc: Miklos Szeredi , Shakeel Butt , linux-fsdevel@vger.kernel.org, josef@toxicpanda.com, bernd.schubert@fastmail.fm, 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-Queue-Id: 46B5BC0023 X-Rspam-User: X-Rspamd-Server: rspam05 X-Stat-Signature: utsx6rcqhtuogmbjknp6xfdyaqwjhwpn X-HE-Tag: 1729882062-591029 X-HE-Meta: U2FsdGVkX1904f5OieH7UbFZMacOZEXzJsZsVbg1s0eMaqt7YUghIHVZJ0hBksAmAnqgQ4xXvyNPbVue6e0TUibnpRVKzfmzC2NDvEQCV3a2jOLI//rjLR+7TKjvCetz+ZT0Zlt0ShrFEfpiAa6pZ/O6hFRpyaEElhrNsWuWX+oYyqqtmHquTbRHBGdubjVKkuxFz62gBL7MnB+L8xsWpwmDTmDBYbJxw8KirqmxKf0hURT+Uz47h+8Cv+4afe8FQO+um7/oz3GYe2AXbyPvHAJmHB0tR98yZQcZO09swx4m1Iv1VjJIwWYkGt0dvQwckiimylzDnCpTnhnqyBYEQgGqidsEkDsCWc5crFWMbYBUZUfOThLRDVSHjyiQWMswsElHe0jxga4bS1VCmwo5GQoSgjghqXtN6rZU9vQku0txTLfgwObfNNlGaP/VXHanucGfY5AnNeQI+yt+uSBtFak1yXuA8dxWb4Tqh+OOIavtM7FdvqaKUU6Q5/A+TiYqg+0rO5ClBUaG2yHRBTVOu49/Pz9DDluHDOm8PErpFqlG+DAEKhGUVneBzR5XkTkay6iJH/dVqQGjORm5h7Mc5xsCTK8imQHCiL77tiup2G+bt0jHVOzfpzlAM9+BNcvPCc5VWJOX01rdglM313IoxHCBtFJuIB/l0wIZ3vzyy/Q1+vppQKrGp8sbT3zvK+o2i6Q/37Jq7aoPy5MTQatP/NRqPugbFO3OyCdTIx3f54R4/VhxOdrDzMrsc2zJLFVUUci60bghiHFVGj47Jdormwplgp6bUO5zlxImc9aGk/ilI8TVwwXjJWcKrTpVieV8MQCh2rM4LyXWP5XekXNgJtlzCkTwPudprEVzzqZrcS8XqmOErrG/pJd0CGWAFeLRAjWjcH2Rf+Yx2YALN+H4JzIbVlkEdAiMzcrubkDvJxyHxtGMpqr7xmYd8ey12X45OPBpjRUE4jmQlsFNIzR iwfLWUjH B12wmRK8zjSPehp/ImMN0Unp4k5S5TEoxtp7FgYFg5IXeaKjV9r1y12hfkX7UoQfmiBHFHVp0x908eI80Mrw40nTKfspVkoV2niE4ebTyARFDsL7Phoh7zwSy/CQMOoUkCDssGhCvomotVwhFthBit/acy7xv5ScMse77Wc6cyhgFvF5Nm1zZUyf3Y92r1G7KQDIifa98SVXsXkrjQLNuv14iuFvgkLM/rCg/ztR64hkd0I7SXj3WsnYiy9xqAa8Seju2gQlzqNc0NM6H6ANvVZiZdWS99/VvrS4rX02SCWDdW/kazTDJ6+cMhSz44W/RPnHHdjmvQJFOAP4rEq4JSG/xZ1+5Zlwm7GLFnmezBJ6ggdwCeak1WdphSY6apzO6jsiYI8WdCcT8mT53fV+pxOL2UNwbfZvJTZud/ABV7FcBj9OamwqZ08uJIZ3CcfglixCcnoHrMFx1wfs= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000148, 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 Fri, Oct 25, 2024 at 10:36=E2=80=AFAM Joanne Koong wrote: > > On Thu, Oct 24, 2024 at 6:38=E2=80=AFPM Jingbo Xu wrote: > > > > > > > > On 10/25/24 12:54 AM, Joanne Koong wrote: > > > 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 = wrote: > > >>> > > >>>> I feel like this is too much restrictive and I am still not sure w= hy > > >>>> blocking on fuse folios served by non-privileges fuse server is wo= rse > > >>>> 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) indefinite= ly > > >>> 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] > > > > Actually as for FUSE, IIUC the writeback is not guaranteed to be > > completed when sync(2) returns since the temp page mechanism. When > > sync(2) returns, PG_writeback is indeed cleared for all original pages > > (in the address_space), while the real writeback work (initiated from > > temp page) may be still in progress. > > > > That's a great point. It seems like we can just skip waiting on > writeback to finish for fuse folios in sync(2) altogether then. I'll > look into what's the best way to do this. I think the most straightforward way to do this for sync(2) is to add the mapping check inside sync_bdevs(). With something like: diff --git a/block/bdev.c b/block/bdev.c index 738e3c8457e7..bcb2b6d3db94 100644 --- a/block/bdev.c +++ b/block/bdev.c @@ -1247,7 +1247,7 @@ void sync_bdevs(bool wait) mutex_lock(&bdev->bd_disk->open_mutex); if (!atomic_read(&bdev->bd_openers)) { ; /* skip */ - } else if (wait) { + } else if (wait && !mapping_no_writeback_wait(inode->i_mapping)) { /* * We keep the error status of individual mapping s= o * that applications can catch the writeback error = using and changing AS_NO_WRITEBACK_RECLAIM to AS_NO_WRITEBACK_WAIT. Thanks, Joanne >