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 0701CD13592 for ; Mon, 28 Oct 2024 02:03:04 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 887046B0099; Sun, 27 Oct 2024 22:03:03 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 836BA6B009B; Sun, 27 Oct 2024 22:03:03 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6D7E36B009C; Sun, 27 Oct 2024 22:03:03 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 4FAFE6B0099 for ; Sun, 27 Oct 2024 22:03:03 -0400 (EDT) Received: from smtpin01.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id C831C1A1CDA for ; Mon, 28 Oct 2024 02:02:22 +0000 (UTC) X-FDA: 82721361870.01.B130807 Received: from out30-101.freemail.mail.aliyun.com (out30-101.freemail.mail.aliyun.com [115.124.30.101]) by imf22.hostedemail.com (Postfix) with ESMTP id 054F0C0008 for ; Mon, 28 Oct 2024 02:02:30 +0000 (UTC) Authentication-Results: imf22.hostedemail.com; dkim=pass header.d=linux.alibaba.com header.s=default header.b=sifwnlyv; spf=pass (imf22.hostedemail.com: domain of jefflexu@linux.alibaba.com designates 115.124.30.101 as permitted sender) smtp.mailfrom=jefflexu@linux.alibaba.com; dmarc=pass (policy=none) header.from=linux.alibaba.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1730080927; 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=ZQhBE1x/c/IpY8NyI+VMhcf5t90yL12OZvVcd60U6Vw=; b=DibScG0Bh6dV2lumDdjsNvqSrn6WdXjktsFT6nKQjmJKUVB/ZmrUt4UrUXv1We08KSXskP +H2GzYibJ+RkZQWePmeFMZLRtsQZoXW76rTKnJKICZs+/fOu/ilrwW2PJKq00APZkdVRVz Qhtc0JV5DYwqIaOqbtRavjoRBuKRXBI= ARC-Authentication-Results: i=1; imf22.hostedemail.com; dkim=pass header.d=linux.alibaba.com header.s=default header.b=sifwnlyv; spf=pass (imf22.hostedemail.com: domain of jefflexu@linux.alibaba.com designates 115.124.30.101 as permitted sender) smtp.mailfrom=jefflexu@linux.alibaba.com; dmarc=pass (policy=none) header.from=linux.alibaba.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1730080927; a=rsa-sha256; cv=none; b=EApOTwTItHm7uGBAUaDELAQyYqhGI0HhXw4YbeDPDOuGIW5nKyYMwAz6/2YX6n1KDlZpCP cFlBzOilR3J4m01SWxZYWJOdfpXQIVOCNoV0T7cgAhYWWYNkrrSlhNYYQ9fzXC2RNgAucv g7yWdcYuWord7Q9++3Wd8NeNJEyPDSc= DKIM-Signature:v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.alibaba.com; s=default; t=1730080976; h=Message-ID:Date:MIME-Version:Subject:To:From:Content-Type; bh=ZQhBE1x/c/IpY8NyI+VMhcf5t90yL12OZvVcd60U6Vw=; b=sifwnlyvrTb0U0Ocy+Ghy6UNoDkH1TXbiTYK1rSYl19iO/gD42oeUONim993raAKuyYGDkgdwLkKpvIgOo/yJgUffE2xYX1GEwre4fY+xSMFvIHWtO7cJ3TqUsHLOe4JNQDVTzK4rmQKVZjy3kcDKeNLz1MNtlPq81L1yH2ezzk= Received: from 30.221.148.132(mailfrom:jefflexu@linux.alibaba.com fp:SMTPD_---0WHywiIb_1730080973 cluster:ay36) by smtp.aliyun-inc.com; Mon, 28 Oct 2024 10:02:54 +0800 Message-ID: Date: Mon, 28 Oct 2024 10:02:52 +0800 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 2/2] fuse: remove tmp folio for writebacks and internal rb tree To: Joanne Koong , Miklos Szeredi Cc: 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 References: <20241014182228.1941246-1-joannelkoong@gmail.com> <3e4ff496-f2ed-42ef-9f1a-405f32aa1c8c@linux.alibaba.com> Content-Language: en-US From: Jingbo Xu In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Rspam-User: X-Stat-Signature: 56nchjzzioriuxqjgbft3x3gkjb6ptes X-Rspamd-Queue-Id: 054F0C0008 X-Rspamd-Server: rspam11 X-HE-Tag: 1730080950-26662 X-HE-Meta: U2FsdGVkX18YJ2H8eBevAIFP8LPEJzQ6T/z4B7x/1QZfBNhaDMDnKGWx8V5Qcgrb+LcfvpxErERbT84Iu7OGQDFTJtpXXFLH22VkSX1TRZGBF6I3yBRIQp7x9b6C8t0eKwnRlk6RdvEv/f5liRc0W4Gkoy3ug6oItp4fYUhk8Q2KKpcvR2XTRrPx2zP6FRAMoO7M2QVUStGudXy2KGdO/hgQYduZ+of9m371ljHJUDAIZhVYHn/7QV1xFns6mfrQJnICNJr5qASDOYB//GEStkzax+mzfph/GAeMJHBSTqkBU3cQtL6s5EEss6SNl02yWG9i+xHQhgrbF6KR/mW/v0i/JBjC8k8JBtIucxjMN9f87ZrK+EQ22gAbAFEthz0cfx5C4sYVqcTLBU8o4la6Kvm0RzO+MpnwCyHS4IAcoFoKGLbc+z5XNkJaIyndoYXFrCfsCIeuFUPg4wcW/1xFa2PSpuIrE85YEyqjOEMyK2lIL+CiDEZpBePUFJs1vtX9SgXcvjmuAZk5qxUtUXTMG1cXTHKs9nVgur8S59Ln2Rpb0mb1Drl/55fsGP6BKp9d0XBFuZhp5YsaI4NRAr9SrAOMM8Zr0L6VyVPyEA5LuRGI3eIFGvmYK97HBvuNyTR/C8OgH8iBTbVZzuhB6rsgCarvd5mVhNlXykQzRTv+onxVNyTMaMQmH6kr4b8xEkq31uRamGBqkDDxgER1X2hybdFNID5mpCbhSwHwt6xJ17ri4E9wnfps3lPCiqMBqssXsPnqTk3RHqXq5Z/W3BcEDHcqPmrSugUvV/zYpoWmLmBpYQNt1fxuL/Apb8P6mlw9e+Xwt1SHKSC+h96LJRsMzWHVXLUoIGB5A+tdcX/7inJafN3BwRfv4M4PrTHsPPcRRNPZmBq2SYJtuPG/qo6Z59HDQcfFFxjhImdVqrogs4smxP+HP2oc9aKWEV6LUQBemBDb0GAaZ8H5QzplYP6 h5f/T63v 8DJ6AKhUSkA2NEHQB4yddtJP9Vhf5ii5uDka9YVjPHJsKH1j8Eb76sebXG+IW5DLLB4c5hoxTf2dRaF3Qzf2HflBA0M7HHGxk5drnFUNYl740U+Rm8JHR/uM7Lb4QwjsfHGv10RjgDH/R9GlCdt41M96d3PfonQ5esVZ3Nkcsa2diFthSi9BRMiYfYDQcuzR3HISoLX8VdEyvLipcrTNBKgZ93hNKkZqYB9fsVMjFxwozDX0o3400As+4O/hERZ4+gP+h5g/KtDWvOuTAj13I0M8uAK4RcC5jzkOBTSt0mZ5YDZw= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, 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 10/26/24 2:19 AM, Joanne Koong wrote: > On Fri, Oct 25, 2024 at 11:02 AM Miklos Szeredi wrote: >> >> 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 >> > > Thanks for the trace. If i'm understanding it correctly, this only > blocks temporarily until the writeback wb_workfn is rescheduled? > >> 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 > > in the case of a malicious fuse server, it could block sync(2) forever > so I think this means we have to skip the wait for fuse folios > altogether. Right. In summary we need to skip waiting on the completion for the writeback in case of a malicious fuse server could block sync(2) forever, and meanwhile the change won't break the backward compatibility as the current fuse implementation also doesn't wait for the data actually being written back and persistent on the backstore in sync(2). -- Thanks, Jingbo