From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id C4C7834889F for ; Wed, 4 Feb 2026 17:05:45 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=18.9.28.11 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770224746; cv=none; b=baziuQV4ugwthxZwuOKGy6LZis5yAr4v3Gt+TIfEK2G5UAtgXgSksjb9IMa+QIY0T2C/eHUHZsBvNbcXDaNKhwuzNdmMv1n0KiuqWvWvMHy2OhqGqz4VVtLweITYK/K1jTLxxtCGwnTiuPZpz5/Z8ceijq6c4svmmQg/NNmwdBc= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770224746; c=relaxed/simple; bh=xFQM54uGaR/iYy8YOmQaUKV73kfJeQv/WoyPYNqwXBI=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=usuKeXosWyKg/aoKhEvn0G+9VK8AgYaiy//f7B2UhGO5q/krJmgFt44iHAz2huYjbsfY7a34SiihGH3Ly5hZMbt/MXqFHAH9WY0dA5Ua5gBFBVnrMR0GpNh8Yd1ez8f765r5nAzizYGtjp0oafY2c62Bhcy730irbR9aBxQdN+A= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=mit.edu; spf=pass smtp.mailfrom=mit.edu; dkim=pass (2048-bit key) header.d=mit.edu header.i=@mit.edu header.b=XSvW+/Tm; arc=none smtp.client-ip=18.9.28.11 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=mit.edu Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=mit.edu Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=mit.edu header.i=@mit.edu header.b="XSvW+/Tm" Received: from macsyma.thunk.org (pool-173-48-119-77.bstnma.fios.verizon.net [173.48.119.77]) (authenticated bits=0) (User authenticated as tytso@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 614H5BIR023448 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 4 Feb 2026 12:05:13 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mit.edu; s=outgoing; t=1770224714; bh=FJ3l4j3asswhM7XjwUVXUk5e7OhriV8G+Oiht6GM9xY=; h=Date:From:Subject:Message-ID:MIME-Version:Content-Type; b=XSvW+/TmM5z/lRQHdkTU5AkYvflunoywwW4VEjZ7mOj2d6jBDXJyaPqZviQG1xUD5 ALqW4v85qBHo2o1ncEHVqA5uTz6WDkJ/7yIfm1oE4HpgajkRn7UkHDoZWE9mEpUCzK 7IwsBd+t2EUJUORqF2lWOBSqWs6lT8Wl53Npn5M/WC4q1yRR5EfmcGcS9zBa722dN4 ZQQN4mF5lynJecNEvw4Pi8HGXN58BaH0fQVBlQ9/aawjZGzzt577rE3WIi6tHt6fGI kI9R79SK2uXBq9MvH4cyFhBt1Ul8fHUxn8qttJEyVM6V1CbButT2iWP6g2vIjdp06z sA2qZlsJvKQkw== Received: by macsyma.thunk.org (Postfix, from userid 15806) id 6119A5738D5B; Wed, 4 Feb 2026 12:04:11 -0500 (EST) Date: Wed, 4 Feb 2026 12:04:11 -0500 From: "Theodore Tso" To: Christian Brauner Cc: Kiryl Shutsemau , Alexander Viro , Jan Kara , Hugh Dickins , Baolin Wang , linux-mm@kvack.org, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: Orphan filesystems after mount namespace destruction and tmpfs "leak" Message-ID: <20260204170411.GC31420@macsyma.lan> References: <20260203-bestanden-ballhaus-941e4c365701@brauner> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20260203-bestanden-ballhaus-941e4c365701@brauner> On Tue, Feb 03, 2026 at 03:58:52PM +0100, Christian Brauner wrote: > I don't believe we need to do anything here unless you want some tmpfs > specific black magic where you can issue a shutdown ioctl on tmpfs that > magically frees memory. And I'd still expect that this would fsck > userspace over that doesn't expect this behavior. I think if we were going to do anything like this, adding support to FS_IOC_SHUTDOWN to tmpfs is the only way we could go. Yeah, it will fsck over userspace that's not expecting it, but normally, if you're tearing down a file system, whether it's a read-only iSCSI device that provides a software package that needs to go away because the iSCSI target has gone away, or zapping a tmpfs file system, killing the userspace which depends on it with extreme perjudice *is* actually the right thing. We use FS_IOC_SHUTDWN on an ext4 file system that is being served via iSCSI, and when that happens, killing the container and the userspace processes running in it as quickly as possble without harming other containers is the goal. It might make fsck over userspace, granted, but so does "kill -9". :-) - Ted