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 6A3BBD1AD39 for ; Wed, 16 Oct 2024 09:51:55 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id D081B6B007B; Wed, 16 Oct 2024 05:51:54 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id CB80F6B0082; Wed, 16 Oct 2024 05:51:54 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id BA6C86B0083; Wed, 16 Oct 2024 05:51:54 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id A274A6B007B for ; Wed, 16 Oct 2024 05:51:54 -0400 (EDT) Received: from smtpin27.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 658D5A1B7A for ; Wed, 16 Oct 2024 09:51:36 +0000 (UTC) X-FDA: 82678998612.27.8715403 Received: from mail-wr1-f42.google.com (mail-wr1-f42.google.com [209.85.221.42]) by imf04.hostedemail.com (Postfix) with ESMTP id 1A2FE4000D for ; Wed, 16 Oct 2024 09:51:40 +0000 (UTC) Authentication-Results: imf04.hostedemail.com; dkim=pass header.d=szeredi.hu header.s=google header.b=BgfqtptZ; spf=pass (imf04.hostedemail.com: domain of miklos@szeredi.hu designates 209.85.221.42 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=1729072265; 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=jTE7u8o5tI0FIkTxmDK+qnKrh3RskOoSkXunWZSYvDA=; b=3s44QW/8xPiPAb9rFeyZMxThiG+ZolYVVvCP+mMqbnC0qGy3SRV2R9BUeVFcaviBkyQfoE er8YxyCOcB36R9vrsIooI0th7jn9d/3WvrK846J47sUwrzHdshnqnKmv0oO6xaeu0Gv5j+ GUn48cpSC9uzf83JRS/5To6Q0ZXNgyk= ARC-Authentication-Results: i=1; imf04.hostedemail.com; dkim=pass header.d=szeredi.hu header.s=google header.b=BgfqtptZ; spf=pass (imf04.hostedemail.com: domain of miklos@szeredi.hu designates 209.85.221.42 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=1729072265; a=rsa-sha256; cv=none; b=02jBi2xsYxQ0VBBPAz7mrusnkrdKjpYFdjfGT8FzhJKwLqFK0ijdSBxafaEZ1KY5nVKDh9 gWXpChjwd43mE/OPmCFgyLewrkJJBGI3xDIss0ho+z4RuasLY+3ye7q48Vy9Pw0aa4dc/0 uj4f20GyUF/IGmyqNoLwK3uUBUVFMGs= Received: by mail-wr1-f42.google.com with SMTP id ffacd0b85a97d-37d4ac91d97so5438871f8f.2 for ; Wed, 16 Oct 2024 02:51:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=szeredi.hu; s=google; t=1729072310; x=1729677110; 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=jTE7u8o5tI0FIkTxmDK+qnKrh3RskOoSkXunWZSYvDA=; b=BgfqtptZKdI0yCiBrm8IGWw2Fqml7iieSbe+PwUXGpBX9Wn1xk9K/983C8nFY9DFuC BcYA1GR2AavLXaglzh8Hk9LKSryBcW1Jj3yONF9TVnPdFppuGyRpdpAkY/LLGjmK5ZeK fdpDWZ5HU/dDf3GTYrXSXrJF6iH/y/ctzM/Y0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1729072310; x=1729677110; 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=jTE7u8o5tI0FIkTxmDK+qnKrh3RskOoSkXunWZSYvDA=; b=J/XbY2BNr+k7Q8E0sOYFzGpdvB0fNH2Z0HQm7Qt2sjT/Se1OXhmBhO9JnaV6BvhnFC GPYtCSq4L2/sqtDtYQXq/yfwtWux13DUJvFPhDhOwX4AKTWxGKuhgxSvJLLLhBTtNUs+ q++qd1T9o8N10NQHD6AShffFzz96snrE9R8z6A2k5U/Eu8uuQwBRNTV54NUfZgJtf+hK yU9jlp8bYDyve4uLOQDLdA7H/IVpQ94RdfNqHBWSLuqwi8+vUXfjlt57yd7dNfylneUE FkuMM+eztN0sccYCQvHPqSmu1KMEW3OoXOA35Z88gRPkH2n+jELbayUHaFxowQaIx4/h gAsw== X-Forwarded-Encrypted: i=1; AJvYcCW+SgjrWACZyxPCRd9VJbYziDnOX0F0gzageWQN+GZachh2tMa9A+aKDJAnyZ8ZJdTh0HQwbwQy+g==@kvack.org X-Gm-Message-State: AOJu0YxZk8ZmmmGb97y4uUAqakcMxNP2puKTS1UNJNFb8LA84fHMX0Dz v+9Oe8Y5tHLuAfPRTUpJOPCYLhSmoH/qAtt55qY//YwUwn7px2cuSQCS6OS8Knh4blGmjpE/DuI gB9KWvhTKb7xOeRFi2eq3gyLYE/TU1+nS59aJTw== X-Google-Smtp-Source: AGHT+IHJimRU7kA9YKF3JTgoDD4uf700fxLLUhA7uSlebDcZu8rjEvIaflwjR+RPRB/FnozQr6QSjw50ZEua6MqYHRA= X-Received: by 2002:a05:6000:e4b:b0:37c:c832:cf95 with SMTP id ffacd0b85a97d-37d601db8b9mr13236270f8f.50.1729072310441; Wed, 16 Oct 2024 02:51:50 -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: Wed, 16 Oct 2024 11:51:39 +0200 Message-ID: Subject: Re: [PATCH v2 2/2] fuse: remove tmp folio for writebacks and internal rb tree To: Shakeel Butt 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 Content-Type: text/plain; charset="UTF-8" X-Rspam-User: X-Stat-Signature: g7jb6horzpp9xe4f4ro461ioagee9f9g X-Rspamd-Queue-Id: 1A2FE4000D X-Rspamd-Server: rspam11 X-HE-Tag: 1729072300-350604 X-HE-Meta: U2FsdGVkX1+6xw4ibBrOyvWv/VIhvMMXx1YKIpCdZD6jtfJleMGxn45jXioFAJwu0SyceTwQFaByhfBn/E06PSHXs/rjYi0Qigr/PUVJ3NVnwf9kR1eLkkj8apq9kzgmeRF7h1OGxNLGsiAmttpq6O2EEGyv7H8cMMBn9lDIRgB4C1vMDxaC2Wi1gLby5ZY8JXlT3JU8TSZ+fDWZTB2qYdhxIv8AlKgcZKLOM1bpMPVNkiEoQaqX25h1WE4vNhv7HI05H0NicjulNQWimvIuKnFxkzigz/jiM+zC1N4zBu2k7NjLlDAjRgqzrzwbsFIspz+V/nEh+CevrG8wLgMSk3gxFbMz+/vlpy9u+vNcj/C6D68KG0ApGNMczp9C2skHpYTvHWBU5ni+fmYiKhimFYL71Z14SYzMgP3KZVXv3tp+r21bBUJagwj54pthQIFB80SF74BFkP+G83iNLPhHaK5Gqk/G3hF830ke6vQClMr6OuRXWw0HHa4Mto4BMzxuujlxaTsfXGw4sLJwj48UzkSgzzxKN5si9c1tDrDNzIiOLo4JGqgKnZkYynOWBt7N/4rRVcRRWEgNYao/iwxBreO4ctiuaMcB5c9MnRw02DWyVyiqiqNY/fEtY5j8nN6jBGngEIKRJcg9JWsAqE+rHxnIZgS9o9CNMEnLEfvUcH81EpW/S78txZ+ySVmnaAq3yuQma6vu/KPzlmMsqhVT1vcEPYcK78Ty7WlbrsLR8xWB53M06E10oG5kGoFTPB4gCPpxgwQZJEVySBu5EZrMyopH+IYzB4S0WWs9KWzNPqH3G3PSJhY+ry2MgZWzhSkTXhaPQ1f4uBYZ192GjFWqHpSrO1v6dFcrOAyygFPPTjRyWXiJdeMycv0ErjS1HUclOnRMMURStCd2Es8wkC6z+3EyOECNRVEHcu40rriECFKyM6DLuF0QR8QAMo1Z4PgGc0UoT491qi/fSYIA9a/ cpdYvLen lv+EyvP/m3MUSEzOP9hFwIUvoLWa8J48/QZ3+GGSLKevumGBH0nZe6T15SclRVdd5orMj1cPMGSSen/QjmIqR2SS3f7IFzYbglVcV7mWEmDRmVu3TX2MXyDACvzG38pRsUIsdwbM6UrhvQ3fI6oqT0wfMOJ1ZxyIQzXX1FJS4px0IncZqabx8u3VKDiMSeeUFPZiO X-Bogosity: Ham, tests=bogofilter, spamicity=0.069015, 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 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. Thanks, Miklos