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 22FFBD0E6D5 for ; Mon, 21 Oct 2024 09:32:59 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 909626B0083; Mon, 21 Oct 2024 05:32:58 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 892416B0088; Mon, 21 Oct 2024 05:32:58 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 70BDF6B0089; Mon, 21 Oct 2024 05:32:58 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 4F5D46B0083 for ; Mon, 21 Oct 2024 05:32:58 -0400 (EDT) Received: from smtpin21.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 5ED4C1217B4 for ; Mon, 21 Oct 2024 09:32:44 +0000 (UTC) X-FDA: 82697094774.21.CBD3E33 Received: from mail-yb1-f176.google.com (mail-yb1-f176.google.com [209.85.219.176]) by imf07.hostedemail.com (Postfix) with ESMTP id CC9B34001A for ; Mon, 21 Oct 2024 09:32:34 +0000 (UTC) Authentication-Results: imf07.hostedemail.com; dkim=pass header.d=szeredi.hu header.s=google header.b=MQbFR4el; spf=pass (imf07.hostedemail.com: domain of miklos@szeredi.hu designates 209.85.219.176 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=1729502976; 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=wzQoWkoxZnBoGUKhVz/WGG4vDvYXQJw7pxUehUocXpQ=; b=uNUYhHw8EiDKjCevK1WNhRLCmM34BQrA9Je7chcC7GMZxHpLaTKcSku/qjBZt7a9VSzROu yGABrmkExusovySM9rjpGjyU45o29P6MQnECd8lnHDAPMu6qDhJL4+XJfI67Iv7UEjWvBJ J8I0NugYeV/dpSSpklepcswhF7hx3qg= ARC-Authentication-Results: i=1; imf07.hostedemail.com; dkim=pass header.d=szeredi.hu header.s=google header.b=MQbFR4el; spf=pass (imf07.hostedemail.com: domain of miklos@szeredi.hu designates 209.85.219.176 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=1729502976; a=rsa-sha256; cv=none; b=iwrkUCDAAEmq+asDqonNpE9bIhVqScZcnwmCKyH6nlQwWB7tVPkFCP4rw/cHaSS3MZvcgF QeClJE/yHxQRMRq4iasH9MVy02xfD9PRx4T042sZMsHvG4WHiTvXia4tqZESm/D1Aozaev D+tMPP0z94Di8oYjbNAi+ZbZMo9bAas= Received: by mail-yb1-f176.google.com with SMTP id 3f1490d57ef6-e297bd161e0so3677117276.1 for ; Mon, 21 Oct 2024 02:32:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=szeredi.hu; s=google; t=1729503174; x=1730107974; 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=wzQoWkoxZnBoGUKhVz/WGG4vDvYXQJw7pxUehUocXpQ=; b=MQbFR4elfv6b8eVjrFBRZ841VM3GF8O22auul7VtI6TBrygU26C2sjZIRuTU8WgAIu S+uxIn4NQ3eKY7JiMcQ5pqBFNV4a3ft2mr+68fyOAcoWAEfBToy/wYdZuETGJo+sBeXI GQNvO9ayi/5t3rKJ3ktiV2j4uZGuKMZ86ICPo= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1729503174; x=1730107974; 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=wzQoWkoxZnBoGUKhVz/WGG4vDvYXQJw7pxUehUocXpQ=; b=OUsuj8NMUFksFpFXl6goVe6tX03ipmdTdwJ8wN9YVTejlcMuwzXrebe+C07EzHxEoq 98dikv5E/Ge0YRIEpy7sEoDqOvhLXO2LCPBpk1R0wSqrEdUQsD9CzZMCsbeS5DSH3Rw4 4VKIekvU3ecGgYfsg77mbmZMTE6rKsUPKIBIaXI5k0RMulGLGqvJ9GTKFa6CjGv6T/Wb 2iQNiKBtFgdIJ0BAkAlEmqZfn442g9/dQ9MyBW0sXb5kYz+KLc+Qul7Ig6PWiZrQizuB TStTJiA6I4nmOYWh43Atms7vj9C06hWKDXdIxqI+gB88k33BEgLwFq7y9r17Tp7FnOb+ dlwQ== X-Forwarded-Encrypted: i=1; AJvYcCWZRrXsTU4rri9SJAyTeW4PJQB7OLvJHmweqndLbDGIsGK3p8mgajcMztcJyRUZMqLu7CjWUTagkg==@kvack.org X-Gm-Message-State: AOJu0YysAkd70UTV8YTwJKzevCdcZ5FQTuDvdmjktjWhMeivwk2Yv/6D rNTlCDxcqjHT804LtQW/SKaqU2au8E7jtusLTp7jtVPmNgP39lVar9Qvd8CMGc3bvA2QJX4gb+K 1dJTg1aOitk38k8dLOTiuogOtX9rnPU7XeJkiog== X-Google-Smtp-Source: AGHT+IF33aCb4BiI0InxUmsARrMvP0g3rwGjh9O0/sliUSZghwSdT6XQrnZ72Y/apOWBultHW7rn7j/QBsg5x8PofFc= X-Received: by 2002:a25:cec5:0:b0:e2b:d097:377c with SMTP id 3f1490d57ef6-e2bd0974fa2mr3644302276.10.1729503173952; Mon, 21 Oct 2024 02:32:53 -0700 (PDT) MIME-Version: 1.0 References: <20241014182228.1941246-1-joannelkoong@gmail.com> <20241014182228.1941246-3-joannelkoong@gmail.com> In-Reply-To: From: Miklos Szeredi Date: Mon, 21 Oct 2024 11:32:42 +0200 Message-ID: Subject: Re: [PATCH v2 2/2] fuse: remove tmp folio for writebacks and internal rb tree To: Joanne Koong 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" X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: CC9B34001A X-Stat-Signature: pfsesuxd9mtfw8mgqgggmbjimrs3t6o5 X-Rspam-User: X-HE-Tag: 1729503154-357717 X-HE-Meta: U2FsdGVkX18J9LJqk/SQPvx3nS2y/aeEPjbiganndmcwiPg5TA8keyXToqX68+iKRGhMZ9zUlUNKnUEOGp32qsYs8dVxdlscMCsm6s4r7+WsabB1Y2ne79i4gXmGKHM+NK+3J7I38CNe+Tviw2YyAvsWdqH1sEKc1lmpEEyBDXwaHuLqM6zU2w+/oU++1s/UZEUY8dZS8tPSSQI99ru5dwjrdhiSqWEvfoUOReqiZh0RLZRH9KKUTNDWY61iduU5YljtfMBzavMDs+yUn4pqETTsuGzRUWBZ8BXXd0zD6xC6vbv0ZWbsY0t2lTvX/2GMPOveY5nveclwVMD+rJ+Y19KNBjluSNs7JYo9M8x4A3ji7zXT1T0tgUMFCFRLF67ZU87A092UvA6OPHVBlL2JZ/81PmaqQlKhvonl6qKlgpwzbkV+bU/KHCZf7o2XWo3UXmjs3Mfhv+eeRD+WH0HdnbecKDvrqOl13vV3ISuNyIuSrOVDxb+9VFhuqT0LJQTcU8ETeqPUmVaNkwCYismw88SvcvHlTZJiVsoqVBzDIF94jsmFzcGn46lEbpfNjKUfiELdc/4LbIxC9PJHkhCk2R6Zksy7Zew7yA3ZlUxEZfmOXszUugH10/iQs632oRnvjAvneP5fxLSDWXMW2pz7/gbhTTosMY6199wES82j/oxpd2lvm83HpPB/G+oWJMhpzju0IliOX2W1EkdNw4Wps27AxjE+I27onWqXh/nO+iDE0nB4nRQqKhfNh/S2YnStTwnDXMjCHUl6PXJ4MA6PnHtzT+0iJs1tdcHXRhXHChHXRSyTqAc8KLhlqBJRMZZxqdhvMukCoW1QsGo0Z+ArGtfsy+qVamBq7BNJlIm2H4FQYS2DOpawc7vdZqyvpFDKYqxcEKyvemYVOORUM7vD7Mlv6W4eP6f66HETYaE54oPJiuw8YNFrRY1WcfJlykN5le1YGcv4ozwOBpb1vEg UJ5MVtVH BB6ekeq82nPLKVuGlSsa8qh6+5t80QoLMC+rcIypnno07GZsIPGb2HiINDybXlVM6VfzbF4tZQdY1n/zfXM4PLAGpMn8F7W1EplJddtowkRa23qQoo1/mmy5XwrNq2ofDFywHzS5yUPQ1Uj3mvTucu+1g3hfPmDksQ0I87UEJUQaeLbkfRND+zYfZrOi1fAO7Tvge++tzf9EfXG3QZMbdFqNl0zvNd3q+flvc X-Bogosity: Ham, tests=bogofilter, spamicity=0.001433, 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, 18 Oct 2024 at 03:30, Joanne Koong wrote: > 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. Yes. > 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? Generally no. Any kind of recursion in fuse is a landmine. E.g. CVE-2019-20794 was created to track an issue with a fuse server going unkillable on namespace shutdown. It didn't occur to the reporter that this is just a special case of a plain old recursive deadlock, because it happens to be triggered by kill. But recursion is clearly there: there's a file descriptor referring to the same fuse mount that is being served. When this fd is closed at process exit the recursion is triggered and the thing deadlocks. The fix: move the recursive part of the code to a different process. But people seem to believe that recursion is okay and the kernel should deal with that :-/ > 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 Right. Thanks, Miklos