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 79047CCA47C for ; Tue, 12 Jul 2022 13:44:58 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233224AbiGLNoi (ORCPT ); Tue, 12 Jul 2022 09:44:38 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:32994 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233195AbiGLNoI (ORCPT ); Tue, 12 Jul 2022 09:44:08 -0400 Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 167311EEC9; Tue, 12 Jul 2022 06:43:57 -0700 (PDT) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id CBEEC5C00E9; Tue, 12 Jul 2022 09:43:53 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute5.internal (MEProxy); Tue, 12 Jul 2022 09:43:53 -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=fm2; t=1657633433; x=1657719833; bh=U63C9vKYqb yyQVXMseKFJL5UTTd7BOn74sOr5EP6CUM=; b=MbNJjCTtD2flfZ2hTQGRAS++5o zqXTGq+UznE4x4bwhzAXZjGutckkgY/Ocyyp12HgJvDlzFepqFGYZmF17v/jSOl3 3y6O8G434Indwh4khZQygy/2vkyJC07tnXSyd/Vx5krsh36o6cvkjEw5bsnkBSjQ +WwdrimTWSyVnlolxA8fK+LFP3TG2nJrFLuxZlTf5Ay1i9H9jvAnTsyslut8AEJf paKgHwkmqbT722AYzHjvJxOrb06siNqlGBSGtp2XH7q5ga3x7Ar4nqYMksQGs/+z utefzIMLPII2JDzvxZMRhyJjy2bRNcpCfdRDzshYGcUcJayFY0QlRHZEzR+w== 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= fm3; t=1657633433; x=1657719833; bh=U63C9vKYqbyyQVXMseKFJL5UTTd7 BOn74sOr5EP6CUM=; b=Fcd2Oxczk3F178MxWy3slksKMXCjtS3pStt7VwHyJlh9 oeOqT1jZd/vDQlkkKX3kAhe83Gg9aYxBjG/axX8utz7bV0TJSeEErpVHQUFi+yap XvvBkBDp68N4OL3TJzF3Gyw2gs2fp2o7SfjmPrSp6bUYnvcOuiZYDDqMzkSOOyfV YaEj6PzgQsNzziK8LroD4MwD8kyH578cBQt8EnaiL3iXu84fX+uh/LEnd3bYOsw/ WsN6sXdYKOjiAU4Jz25nXYuzyetSiWNofU0Qa5KNMOJZjCidMwwyMKu9CwyDAdBP daNvSTap4BiXnTwOixZpK66RbYhDlHuxmjJt/Nq54A== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvfedrudejhedgieelucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepfffhvfevuffkfhggtggujgesthdtredttddtvdenucfhrhhomhepvfihtghh ohcutehnuggvrhhsvghnuceothihtghhohesthihtghhohdrphhiiiiirgeqnecuggftrf grthhtvghrnhepueettdetgfejfeffheffffekjeeuveeifeduleegjedutdefffetkeel hfelleetnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomh epthihtghhohesthihtghhohdrphhiiiiirg X-ME-Proxy: Feedback-ID: i21f147d5:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 12 Jul 2022 09:43:52 -0400 (EDT) Date: Tue, 12 Jul 2022 07:43:51 -0600 From: Tycho Andersen To: "Eric W. Biederman" Cc: Miklos Szeredi , Christian Brauner , fuse-devel , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: strange interaction between fuse + pidns Message-ID: References: <877d4jbabb.fsf@email.froward.int.ebiederm.org> <87zghf6yhe.fsf@email.froward.int.ebiederm.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87zghf6yhe.fsf@email.froward.int.ebiederm.org> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Jul 11, 2022 at 06:06:21PM -0500, Eric W. Biederman wrote: > Tycho Andersen writes: > It is not different enough to change the semantics. What I am aiming > for is having a dedicated flag indicating a task will exit, that > fatal_signal_pending can check. And I intend to make that flag one way > so that once it is set it will never be cleared. Ok - how far out is that? I'd like to try to convince Miklos to land the fuse part of this fix now, but without the "look at shared signals too" patch, that fix is useless. I'm not married to my patch, but I would like to get this fixed somehow soon. > The other thing I have played with that might be relevant was removing > the explicit wait in zap_pid_ns_processes and simply not allowing wait > to reap the pid namespace init until all it's children had been reaped. > Essentially how we deal with the thread group leader for ordinary > processes. Does that sound like it might help in the fuse case? No, the problem is that the wait code doesn't know to look in the right place, so waiting later still won't help. Tycho