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 C9D87D2A53B for ; Wed, 16 Oct 2024 17:52:56 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 4A6B46B007B; Wed, 16 Oct 2024 13:52:56 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 4564C6B0082; Wed, 16 Oct 2024 13:52:56 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 345396B0083; Wed, 16 Oct 2024 13:52:56 -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 162656B007B for ; Wed, 16 Oct 2024 13:52:56 -0400 (EDT) Received: from smtpin12.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 3DAEE1C1595 for ; Wed, 16 Oct 2024 17:52:44 +0000 (UTC) X-FDA: 82680210858.12.62CFDF2 Received: from out-170.mta0.migadu.com (out-170.mta0.migadu.com [91.218.175.170]) by imf27.hostedemail.com (Postfix) with ESMTP id D8D0F4000E for ; Wed, 16 Oct 2024 17:52:44 +0000 (UTC) Authentication-Results: imf27.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=f6PtUGAN; spf=pass (imf27.hostedemail.com: domain of shakeel.butt@linux.dev designates 91.218.175.170 as permitted sender) smtp.mailfrom=shakeel.butt@linux.dev; dmarc=pass (policy=none) header.from=linux.dev ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1729101029; 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=3qEmnxdf1qUSBhAKRuNMDcudJRPSZUM0/YNJNSgZwkA=; b=PsKg13pGwBjL4XNpuSJJ4UZzUToDfsu+7duErGt7YCYR8MD124k2ZDYTQp6ZC6DcSyZV6Y Or8i4MbeENsU9X5hVJwNYvRguiY0Y58akHJDohgVo8OtOd/aZuOT4CLqyPVlf0TlVL3a6B MkHxaPoIGjSKiNRiHneHI5X65az+fxs= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1729101029; a=rsa-sha256; cv=none; b=jW4RgOTcDmsFwM9A+LsgMF+JGC/+Cv77AHxzbjoZ1NSVuZ4V6GWGo/m2rXk+pdv3iobUvR /PU24FCREqmBUzVt1iqAOGwU945QOEKckBj27XogcZM3w5gmZuPX+4jFbaOY2aex4v44hu i8C3fTK1VbstyFOX+RIiGxb41eadA4k= ARC-Authentication-Results: i=1; imf27.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=f6PtUGAN; spf=pass (imf27.hostedemail.com: domain of shakeel.butt@linux.dev designates 91.218.175.170 as permitted sender) smtp.mailfrom=shakeel.butt@linux.dev; dmarc=pass (policy=none) header.from=linux.dev Date: Wed, 16 Oct 2024 10:52:45 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1729101171; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=3qEmnxdf1qUSBhAKRuNMDcudJRPSZUM0/YNJNSgZwkA=; b=f6PtUGANHdBtvg9CorG1ogGqmbREt38kyTWoRcYA314OI7znbKpjCVYcxOVQwbwF34mKLY Q09BG7zL8Esx/OgRd+QV/+IZbHQAN4FeXlYAyq2j/dqh2WGEqWrRRQRYGX2QWslsc3h/rq jzqWlvolFZStoo6FqIZZk5b9eUseM4M= X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Shakeel Butt To: Miklos Szeredi Cc: Joanne Koong , 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 Subject: Re: [PATCH v2 2/2] fuse: remove tmp folio for writebacks and internal rb tree Message-ID: References: <20241014182228.1941246-1-joannelkoong@gmail.com> <20241014182228.1941246-3-joannelkoong@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Migadu-Flow: FLOW_OUT X-Rspam-User: X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: D8D0F4000E X-Stat-Signature: itsiinj13aji78h7e4ud9zj6z3qfnbt8 X-HE-Tag: 1729101164-641971 X-HE-Meta: U2FsdGVkX19equCaqJrPEouWDSbXeIvLAcEG+/AWi0A+guC2vu9K0q0P6x7zacDCK1F6ocAzxPmRaS6CBCIxF0Xbsbkbb1oxijbr5+iKFBrbfo6wv7N3VwfQQpAyf4RMCibMX/VukctCmN/s1UnAtVdN7x1kGBeZFG2SWYeRqW61ryAVivU5aVxghDZ6+mQ8LRAND0pHjiHD2Ht5QjD36+umwpwMlSCyOLBMjvf8vh6g6gEidd4tpNU8LZ/zrJxDtXX2D7PWnqj4HYabvl1Xw//oVXieiUnd1mICOhZMiC1F+vtalPPGSrGY2qnhhseHxZdddw9wU1YEQdc7NtZZAgDIuofvHVhBt87ojIGQ29Z6amIgUkbyinZHf7hHbViPyAM3cZsJ0Y0pydjUsMOevReON6Ol+xRK8PV0nyCJayEW0zYmL73OcdaEHJiu3C7dlJWW4HTqxC4AwYyrwBpGrbF4wv7lbNpQRLct/1mx3Cjb/Jc9PqypU//rjMKwBRuH0nqip9tC/jpTvlFFKyVQ4gHL5lbClC3wf8pTVgTmMi4ymnt0aI1SzwU7ObyDDX94kjovk6JuYZCj0rQfHfmEerol/hJvjh1LB8WwiehT0X94C3J6t5UtMrO8MnTGWHwclLJ8t9Y/zu0dhHOUhJsoDHjE9KAhF6EwXLPdK7U3xFGDAPl+7nHV1F0TJZUVtAaFzoCWJOwRNLXOZE8LUlXPelE/uiHyF2Q9Ko7o2EnpQL7lDRb7Qftu82EkleJs3vS+aKnZ34Fu6+/UkNFPGfdwXK7dNRQXtG4CurtV5dpc4USvoPpLcMhWDeeSi5e3V2zHXmg7/pcdKePX3sS+HTe69RWpE/fFJPNO/jD+EdMJGpIE1ZFnLnPELgVL5EOGPuLR1zn1S8Q6QzHfb+9oEYxRARpQKUw2pYNuGZJ53i8IVvOJ5RkOwpk35EpfyYEyz9T6mY5ke1qdOYLmsI9wezU yHBGsw1S Ey+RZX29mmK98JFHz8nZMbPgbBvMtzqHWqEW7QV0RtR4Hsis6O7OD4U10ntXRvW1sPDgw+QZh/8fXQbIf/11ji+0QvmCxNVDIOsBzAIG7ifqcVQSK14qTSsE+HFV5RN/LodHiR3KADs/TngJ1lzlt0CZ7fA== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000002, 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 Wed, Oct 16, 2024 at 11:51:39AM GMT, Miklos Szeredi wrote: > On Tue, 15 Oct 2024 at 21:17, Shakeel Butt wrote: > > > So, any operation that the fuse server can do which can cause wait on > > writeback on the folios backed by the fuse is problematic. We know about > > one scenario i.e. memory allocation causing reclaim which may do the > > wait on unrelated folios which may be backed by the fuse server. > > > > Now there are ways fuse server can shoot itself on the foot. Like sync() > > syscall or accessing the folios backed by itself. The quesion is should > > we really need to protect fuse from such cases? > > That's not the issue with sync(2). The issue is that a fuse server > can deny service to an unrelated and possibly higher privilege task by > blocking writeback. We really don't want that to happen. If I understand you correctly, you are saying fuse server doing wrong things like accessing the files it is serving is not something we need to care about. More specifically all the operations which directly manipulates the folios it is serving (like migration) should be ignored. Is this correct?