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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 83DBBC433FE for ; Fri, 30 Sep 2022 16:10:20 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231986AbiI3QKS (ORCPT ); Fri, 30 Sep 2022 12:10:18 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:34368 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231970AbiI3QKL (ORCPT ); Fri, 30 Sep 2022 12:10:11 -0400 Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C1DBB7969B for ; Fri, 30 Sep 2022 09:10:01 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id BC9045C013C; Fri, 30 Sep 2022 12:10:00 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute2.internal (MEProxy); Fri, 30 Sep 2022 12:10:00 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tycho.pizza; h= cc:cc:content-type:date:date:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:sender:subject :subject:to:to; s=fm1; t=1664554200; x=1664640600; bh=F4O4h+VOdz H126wyw/ep2Ha1ckfcYasTdafRdCqfFzk=; b=0G0OhHqOzl9Y0IsrfLNCTyydHW ltUZMccBq7Vz1WhIK1eAj6XURlL/GqKrky+I0pibesDtrceic5i1zZGFZrLFTcin 6+8nK30JNw93myCmLTHALFLK1/znYIrP/3q8k7o5ThtQp9OGtTUfV2yx89vE3LAt 4oSYPoqHHOz+QuZHVFR92Seh3UcjgTYAXTiZgNVs/JbBd/HeCLEDNGzo1EnTZlQj d+pQOfUhpeXjZ+u3Pr5ZO3VRkrd70NvCi/ojTJGhFrRtLTfzTFkg1B66GWd2pXF0 qUr+WNUSlQ6E+HKe2wYUm7RfbKvBu+xA2T+gJy/Vl5NXfYZQy5EtaShwS60A== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:date:date:feedback-id :feedback-id:from:from:in-reply-to:in-reply-to:message-id :mime-version:references:reply-to:sender:subject:subject:to:to :x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm2; t=1664554200; x=1664640600; bh=F4O4h+VOdzH126wyw/ep2Ha1ckfc YasTdafRdCqfFzk=; b=ZxlcOhFYMcoLfSgxalfhEAvs4yPcEdLbJRMZRAXJ+bUQ 7lx7jnnZJMP877F1OGs1zgFm+KwUnGWXS10OKlBYhg0Ml3or+OA1UQmRzmj8C0S6 OtEPjTsq7ax5Ba+fBSPeeuhchZybtUdRMU+dmEV7CukDsxZNQwu0FhI6X9Y7f1nE YvYsINhp0L87W/fUZhiJw5t1wpfvXJTGbzuS4cgXgD0iwOgJ1x5W4jydpW4vep90 w4tOXJnB6Bg1AMjs8Cy76q7ae7B+SheNc+ZIRDGokamy3PiRzm1AchD4ejNBGvsZ OV8/w/M0fSNLfQVnDTXUJuS/Cf44297z0m+euoiyTg== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvfedrfeehvddgleejucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepfffhvfevuffkfhggtggujgesthdtredttddtvdenucfhrhhomhepvfihtghh ohcutehnuggvrhhsvghnuceothihtghhohesthihtghhohdrphhiiiiirgeqnecuggftrf grthhtvghrnhepueettdetgfejfeffheffffekjeeuveeifeduleegjedutdefffetkeel hfelleetnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomh epthihtghhohesthihtghhohdrphhiiiiirg X-ME-Proxy: Feedback-ID: i21f147d5:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Fri, 30 Sep 2022 12:09:59 -0400 (EDT) Date: Fri, 30 Sep 2022 10:09:56 -0600 From: Tycho Andersen To: Miklos Szeredi Cc: Eric Biederman , "Serge E. Hallyn" , linux-kernel@vger.kernel.org, fuse-devel@lists.sourceforge.net Subject: Re: [PATCH v2] fuse: In fuse_flush only wait if someone wants the return code Message-ID: References: <20220929163944.195913-1-tycho@tycho.pizza> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Sep 30, 2022 at 04:41:37PM +0200, Miklos Szeredi wrote: > On Fri, 30 Sept 2022 at 16:01, Tycho Andersen wrote: > > > > On Fri, Sep 30, 2022 at 03:35:16PM +0200, Miklos Szeredi wrote: > > > On Thu, 29 Sept 2022 at 18:40, Tycho Andersen wrote: > > > > > > > > If a fuse filesystem is mounted inside a container, there is a problem > > > > during pid namespace destruction. The scenario is: > > > > > > > > 1. task (a thread in the fuse server, with a fuse file open) starts > > > > exiting, does exit_signals(), goes into fuse_flush() -> wait > > > > > > Can't the same happen through > > > > > > fuse_flush -> fuse_sync_writes -> fuse_set_nowrite -> wait > > > > > > ? > > > > Looks like yes, though I haven't seen this in the wild, I guess > > because there aren't multiple writers most of the time the user code > > that causes this. > > > > I'm not exactly sure how to fix this. Reading through 3be5a52b30aa > > ("fuse: support writable mmap"), we don't want to allow multiple > > writes since that may do allocations, which could cause deadlocks. But > > in this case we have no reliable way to wait (besides a busy loop, I > > suppose). > > > > Maybe just a check for PF_EXITING and a pr_warn() with "echo 1 > > > /sys/fs/fuse/connections/$N/abort" or something? > > AFAICS it should be perfectly normal (and trivial to trigger) for an > exiting process to have its dirty pages flushed through fuse_flush(). Agreed. > We could do that asynchronously as well, generally there are no > promises about dirty pages being synced as part of the process exiting > . But ordering between dirty page flushing and sending the FUSE_FLUSH > request should be kept. Which needs more complexity, unfortunately. How can we wait in fuse_set_nowrite()? Or are you suggesting we just do a fuse_flush_writepages() in the async part and hope for the best? Thanks, Tycho