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 283E3D149D9 for ; Fri, 25 Oct 2024 18:02:28 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id B17596B0083; Fri, 25 Oct 2024 14:02:27 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id AC7246B0085; Fri, 25 Oct 2024 14:02:27 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 98DAE6B0088; Fri, 25 Oct 2024 14:02:27 -0400 (EDT) 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 79CC36B0083 for ; Fri, 25 Oct 2024 14:02:27 -0400 (EDT) Received: from smtpin22.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id B0B0680E8B for ; Fri, 25 Oct 2024 18:02:09 +0000 (UTC) X-FDA: 82712893746.22.F45F531 Received: from mail-qk1-f179.google.com (mail-qk1-f179.google.com [209.85.222.179]) by imf10.hostedemail.com (Postfix) with ESMTP id DB26FC000C for ; Fri, 25 Oct 2024 18:02:15 +0000 (UTC) Authentication-Results: imf10.hostedemail.com; dkim=pass header.d=szeredi.hu header.s=google header.b=pFYwkhpI; spf=pass (imf10.hostedemail.com: domain of miklos@szeredi.hu designates 209.85.222.179 as permitted sender) smtp.mailfrom=miklos@szeredi.hu; dmarc=pass (policy=quarantine) header.from=szeredi.hu ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1729879266; a=rsa-sha256; cv=none; b=tEByzdiChNFVAC/Sdldtye+eg3Mnt4GgaEbyqsiXEO/q695YlVQWGMEF7OCsvMWJR2i6Ss bqld5ZEBfCJI82FcuaPaybnZR57dF2ygq2n++Pb9QOPQgrf9ekxyVnWV4JDJxLcGfsExIH CZ0mnMcMfyI09Twos2CWLK3tGmiWApI= ARC-Authentication-Results: i=1; imf10.hostedemail.com; dkim=pass header.d=szeredi.hu header.s=google header.b=pFYwkhpI; spf=pass (imf10.hostedemail.com: domain of miklos@szeredi.hu designates 209.85.222.179 as permitted sender) smtp.mailfrom=miklos@szeredi.hu; dmarc=pass (policy=quarantine) header.from=szeredi.hu ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1729879266; 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=s7jI+cVj/0Vp7vLRDMNOKjs5v00Q6EAB/w2WS63LbRg=; b=yZqpv+c4KHiREL5BcwPphj4XWU4/+Xr6OyuyVLATwZ7f5/LSGUL3g0G3KnCXE/fgZR3dtC MFYWBcoKGlh9M94KTu2W1zCxH9S5W56YdIZNLTeSRBJhMsE1IRV2p28AvvVyHVrc+M0Q/J NS9YrYGN0NA+uv6LRL6g9of7cw3Z3zE= Received: by mail-qk1-f179.google.com with SMTP id af79cd13be357-7b152a923a3so159128685a.3 for ; Fri, 25 Oct 2024 11:02:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=szeredi.hu; s=google; t=1729879343; x=1730484143; 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=s7jI+cVj/0Vp7vLRDMNOKjs5v00Q6EAB/w2WS63LbRg=; b=pFYwkhpITwUuc+TXA7h49TZxyxlCsENTrUl5fb4R+D1Lu9xzuHP6rAeWrxwwTLzjjF E8ciEGfQnZcG/mlspuVJtrxzc+GC31trVdfT383us4O4OqMbYbq3rUq9baBU/9OQASvI qVMXQpZibr1L5CcvMeODlfewtP9i17VJcgUHM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1729879343; x=1730484143; 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=s7jI+cVj/0Vp7vLRDMNOKjs5v00Q6EAB/w2WS63LbRg=; b=v7gdv/Zqsrq7jsjRY6JUkyccpRbYp9rzKEdLrwCvuwHWEZgEl27EY9OseeqId24JZY OfxjSKkAEMTGFi6iCep4p4Gn0m27Dl0BG9dErie/iOMxaZxE9i+NxDOOkCc+Cpf980zx eEv3kvaE90U0BPxCIh7ADRooCFTAgm0PITPs0kzDouj/17Zf4WRnudAb92gMpW+THXaX BNFogcyPC8wlEp7C+qFRY5KGVFowsNmxHVvJTuv9W/H1lA0iRdD7Jso57nBpP3HYWlpP vTAxU0PIpC5csA1DNakr3/3QwULjcOv+3Ui0aAGIUB3T6fklL9GSQnO7eREWnIFfK5ZV Lk4w== X-Forwarded-Encrypted: i=1; AJvYcCXSo1XyFP1+f3qbOWgGuAE4dQFLHnJZjaPLfWiQFZMRgYYM0gGYNWTgH7XMEWQK+vQUyyeK+EheNg==@kvack.org X-Gm-Message-State: AOJu0Yy8kWHzwo0nl939kQ2M2Z+xtLbT+7wlYYa2IfERFBdhj2ywEO9E ecGXCdQVsEcJqsc5til2tzzK+u2lsJ1p9Q0pvWhHs7BYPdaeLVzscAMyjZjL7f9HqyOOqjIMhYN nzjP4fPh5hNYLUVGGNRBUeolgpJ0qgnvHHjpNOQ== X-Google-Smtp-Source: AGHT+IHLxwf8GyD7abelP0DnXH6pF3Z/rGm9BsLy31uke0VSLgq2REqYS/YuFkUrt4oxcyV39h6yJ/5eJVeAuDBxJDk= X-Received: by 2002:a05:622a:10e:b0:461:1c54:5bcd with SMTP id d75a77b69052e-4613c0046f6mr1602731cf.13.1729879343454; Fri, 25 Oct 2024 11:02:23 -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: Miklos Szeredi Date: Fri, 25 Oct 2024 20:02:12 +0200 Message-ID: Subject: Re: [PATCH v2 2/2] fuse: remove tmp folio for writebacks and internal rb tree To: Joanne Koong Cc: Jingbo Xu , 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" X-Stat-Signature: geedyo16z3owgmj86m6pk7d5knom9k3u X-Rspamd-Queue-Id: DB26FC000C X-Rspam-User: X-Rspamd-Server: rspam10 X-HE-Tag: 1729879335-441681 X-HE-Meta: U2FsdGVkX18XclHsvHcXTY8R4DEkG0dOqrInrIi1Drr5mWK4k5sk9zLBdyS1tg3673FQVVVQRqldwKxGuJHmHcsJROyu4xEFNAtamysAfQm8wItE+RmVOqvycM6Z+ZGmLtcy6lcwmIc7ioOZtd7DZj7eJ6S2psJp2ZkOnP8l4fLW/MpLqM1E4GNCxVlTiwuORjFKDtX51R8IsRYluBPocyo/SVsVCXaSI/GDITFQ0GGSiy9s9dB+D3xZHuPgbESghqn0GnnblgjHPcCDy4A7omg8ifNK75EWwzk/35VjsCJ5jUb7tLyZEW9wSfzk/Bjm9TFBUeqxKodQ2RBdtrnipnT38Z+ym2s+vOsK5cOLsflSENiaOHT1sHKsJ6aRw3PZpfgs3S08PCltHtR91WpSwznQMtWZWLy2KDTCScirOcOLMH7lo0CFWIzrQPcs0px7xTWIazaQPLegvVyOqtlVGTEQG7p57JFr4t0ZlLHFAaJeNOWtOmkiduJbhnXZqm6k+OCfMQaIDPLDxe+j1H3gp7ezpp4p4/yHsB3t0SjCuSZXiRlyYKYXyV1m1ll8b34FmXSHbuEqqcjA0ed5LQSdymdGtq8XNlTsrBpzAJ01uqviB8UWvo8S6sANVF+6XVO3vDhz9ZVzUcBbUz5IuZ2akTIO9kGwoXxpZwgJ+BCYI/IpPSh4OYufVe5pvkM7IVybOQBBCOW5uFJ4Cr1/VBxpsra98ERv2AJrNIC4gPCXK66lApOf2WcD5VVtEcSoneCTLM/e55wsATTD/8ye/bD53ScELDQWdB56EDxlSECioCVQ3m+iGGB0lLj5kQXgWoXUVTw7jXmBKBQ3k3C/efMp/3rJrEJMs6fJwBPWhlxsItq+UOS9WZdumUx7IJvsUPJ+wIZMzg80J0/bu1U9FfQUMqav90pxU0Il6bk3pIstKtUrwMyQSscEwyifj61MNdq0SEQrh/LuQSm2H2+pH5t QOz1AdNh BR6U9LIHJuBSKTFvufapxihdaIYo3/RUFcJqRMnemHDYq0cF8O+EYegsnpNn/vJjXH4vwmOBk0bF/RNGCRhUYho9qsJnzHGgqdtE+vE3zT9a9SJduXE2A7CRqwGJL79OIo4Kx+e9lJS0EDZknXHAL/MAQH7bRx2wCJQkUQQMKio1sNY83pfTFgRooUkAdgXZeHaHbIBe20/lNKqo/8iffDQh8IXY+mY0ooWdz X-Bogosity: Ham, tests=bogofilter, spamicity=0.006980, 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, 25 Oct 2024 at 19:36, Joanne Koong wrote: > 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 just tested this, and it turns out this doesn't quite work the way I'd expected. I can trigger sync(2) being blocked by a suspended fuse server: task:kworker/u16:3 state:D stack:0 pid:172 tgid:172 ppid:2 flags:0x00004000 Workqueue: writeback wb_workfn (flush-0:30) Call Trace: __schedule+0x40b/0xad0 schedule+0x36/0x120 inode_sleep_on_writeback+0x9d/0xb0 wb_writeback+0x104/0x3d0 wb_workfn+0x325/0x490 process_one_work+0x1d8/0x520 worker_thread+0x1af/0x390 kthread+0xcc/0x100 ret_from_fork+0x2d/0x50 ret_from_fork_asm+0x1a/0x30 task:dd state:S stack:0 pid:1364 tgid:1364 ppid:1336 flags:0x00000002 Call Trace: __schedule+0x40b/0xad0 schedule+0x36/0x120 request_wait_answer+0x16b/0x200 __fuse_simple_request+0xd6/0x290 fuse_flush_times+0x119/0x140 fuse_write_inode+0x6d/0xc0 __writeback_single_inode+0x36d/0x480 writeback_single_inode+0xa8/0x170 write_inode_now+0x75/0xa0 fuse_flush+0x85/0x1c0 filp_flush+0x2c/0x70 __x64_sys_close+0x2e/0x80 do_syscall_64+0x64/0x140 entry_SYSCALL_64_after_hwframe+0x76/0x7e task:sync state:D stack:0 pid:1365 tgid:1365 ppid:1336 flags:0x00004002 Call Trace: __schedule+0x40b/0xad0 schedule+0x36/0x120 wb_wait_for_completion+0x56/0x80 sync_inodes_sb+0xc5/0x450 iterate_supers+0x69/0xd0 ksys_sync+0x40/0xa0 __do_sys_sync+0xa/0x20 do_syscall_64+0x64/0x140 entry_SYSCALL_64_after_hwframe+0x76/0x7e Maybe I'm too paranoid about this, and in practice we can just let sync(2) block in any case. But I want to understand this better first. Thanks, Miklos