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 lists.ozlabs.org (lists.ozlabs.org [112.213.38.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 058E9C88E75 for ; Tue, 15 Sep 2026 12:44:14 +0000 (UTC) Received: from boromir.ozlabs.org (localhost [127.0.0.1]) by lists.ozlabs.org (Postfix) with ESMTP id 4hkhXl6CSgz30Tm; Tue, 15 Sep 2026 22:44:07 +1000 (AEST) Authentication-Results: lists.ozlabs.org; arc=none smtp.remote-ip=172.234.252.31 ARC-Seal: i=1; a=rsa-sha256; d=lists.ozlabs.org; s=201707; t=1789473308; cv=none; b=M7ZpIQuzwJqcCmkaoSEDHp7YZQDd8QQDqi2crJApMlexOUj2dr5VFqB5ipy/EBElEu7n0aZlBE8xxsnRODUMbvw+13MQFNi5M69yQBaJX0vm7EMAwhK3XCJKiiJeHWYIhHPqsetZEgGOI0DswU/EMTA4M7d5O3cb5rwXBszAaaXPmqi9IwbVTBAVqcowjq0lZaWULKruK0zIzCOfNggv+MR8Y7VRYwKc4u7ro6SoRv0oDCmgIMG7wUUX/6pmBRNv6pLqA5MUihkffa8LE3/n623UcltHq9rocuzPsxaxGnlCu3dzhUQee8igvpRRn3s/dJfDLctSZfXpiBTSQoLeMg== ARC-Message-Signature: i=1; a=rsa-sha256; d=lists.ozlabs.org; s=201707; t=1789473308; c=relaxed/relaxed; bh=z5q8YTazTS0g58MAO23KPqH00t77+r0Qm1szy+uSGx8=; h=From:Subject:To:Cc:In-Reply-To:References:Content-Type:Date: Message-Id; b=k64uhdj2DegQenA8neyhDM/ARmd/S4ZF0OAonFFZh6vMEzngHYgGmthH8Wpec6lYBFILiCZOm1b89+InaOFxl7tdTuK+1Pdf5beSTjufCbSJenuzkMmSpRoaet5wf/GX/Ee4/3aLcupZbCOs8AUDW72fzy2ObEji06wSmSVGnqSN254CpXVJgkzkCkvmz7Yu5ElHgJtzOMCJGKzrHGrHNEwNoM+KQo/X78nWPl09Suw+IWkhRWxns07n1dgXXciPdbbZ2napk8qXmKEAtacpl5BZPBxNc4Oa+an1vOZYvQKtVsoFL0jm7I0PBcGDMz0EUhxRJH+k7HU6eFjXtkwHMA== ARC-Authentication-Results: i=1; lists.ozlabs.org; dmarc=pass (p=quarantine dis=none) header.from=kernel.org; dkim=pass (2048-bit key; unprotected) header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256 header.s=k20260515 header.b=ZuWOcXAx; dkim-atps=neutral; spf=pass (client-ip=172.234.252.31; helo=sea.source.kernel.org; envelope-from=sashiko-bot@kernel.org; receiver=lists.ozlabs.org) smtp.mailfrom=kernel.org Authentication-Results: lists.ozlabs.org; dmarc=pass (p=quarantine dis=none) header.from=kernel.org Authentication-Results: lists.ozlabs.org; dkim=pass (2048-bit key; unprotected) header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256 header.s=k20260515 header.b=ZuWOcXAx; dkim-atps=neutral Authentication-Results: lists.ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=kernel.org (client-ip=172.234.252.31; helo=sea.source.kernel.org; envelope-from=sashiko-bot@kernel.org; receiver=lists.ozlabs.org) Received: from sea.source.kernel.org (sea.source.kernel.org [172.234.252.31]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange x25519) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 4hkgSC3ZDnz2y8F for ; Tue, 15 Sep 2026 21:55:07 +1000 (AEST) Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) by sea.source.kernel.org (Postfix) with ESMTP id 05F6A44503; Tue, 15 Sep 2026 11:55:06 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 148F91F00893; Tue, 15 Sep 2026 11:55:04 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1789473305; bh=z5q8YTazTS0g58MAO23KPqH00t77+r0Qm1szy+uSGx8=; h=From:Subject:Reply-To:To:Cc:In-Reply-To:References:Date; b=ZuWOcXAxSUf8U369yMDLM5CrTH3NJo6vFF48Zf7qsB7e9dLLAU7rmbvFKGtSwEN54 mrXyu8/sUo7qSyMhvbEGo+56h3zo92SZrUdXQDVHKmZsSL1yip9FieQwDFx3xFr6W4 tBOqKBhe78D3RbDLNy/MZGAQn79PhMCfv5ZbZLoxyQiJCVFGpeYe2T3W8SPiGli1OE NJ9s1R/i1hoZ9yPqcd3D1GgTWMiPLPMS4hdNI6X7OCZH/p2PAhMdHWisK0u0w1/QXC YOxwO8oP0q6Czx2WnOyHnYHMCetkSnm/+kFJHxdJpz1jYA9qFglwCwZ6hc4JzfujT3 h2LUQd6qFe6SA== From: sashiko-bot@kernel.org Subject: Re: [PATCH RFC POC 01/50] file: install files on syscall exit Reply-To: sashiko-reviews@lists.linux.dev To: "Linus Torvalds" , "Christian Brauner" Cc: linux-fsdevel@vger.kernel.org, linux-m68k@lists.linux-m68k.org, linux-kernel@vger.kernel.org, linux-snps-arc@lists.infradead.org, kvm@vger.kernel.org, bpf@vger.kernel.org, io-uring@vger.kernel.org, linux-alpha@vger.kernel.org, kexec@lists.infradead.org, "Jens Axboe" , "Michael S. Tsirkin" , dri-devel@lists.freedesktop.org, sparclinux@vger.kernel.org, linux-parisc@vger.kernel.org, linux-mm@kvack.org, linux-openrisc@vger.kernel.org, linux-gpio@vger.kernel.org, linux-arm-msm@vger.kernel.org, linux-hexagon@vger.kernel.org, "Jann Horn" , "Ingo Molnar" , "Oleg Nesterov" , "David Airlie" , "Eugenio Perez" , linux-csky@vger.kernel.org, "Alexander Viro" , linux-mips@vger.kernel.org, linux-um@lists.infradead.org, linuxppc-dev@lists.ozlabs.org, "Peter Zijlstra" , virtualization@lists.linux.dev, "Jan Kara" , linux-hyperv@vger.kernel.org, linux-sh@vger.kernel.org, linux-arm-kernel@lists.infradead.org, =?utf-8?b?Q2hyaXN0aWFuIEJyYXVuZXIgKEFtdXRhYmxlKQ==?= In-Reply-To: <20260915-work-fd-reserve-unify-folded-v1-1-4d5217d6b246@kernel.org> References: <20260915-work-fd-reserve-unify-folded-v1-0-4d5217d6b246@kernel.org> <20260915-work-fd-reserve-unify-folded-v1-1-4d5217d6b246@kernel.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Date: Tue, 15 Sep 2026 11:55:03 +0000 Message-Id: <20260915115504.148F91F00893@smtp.kernel.org> X-Mailing-List: linuxppc-dev@lists.ozlabs.org List-Id: List-Help: List-Owner: List-Post: List-Archive: , List-Subscribe: , , List-Unsubscribe: Precedence: list > So we've spoken about this idea quite a few times over the years that > we could reserve fds and files on a task and then install or a clean > them up on syscall success or error and get rid of most of the > complicated cleanup dance that we have. >=20 > My original approach to this had been to implement FD_PREPARE() based on > cleanup guards and use scopes to make this happen. The other idea was > what I'm illustrating here. It is overall equally robust and makes the > install fd and file pattern work even if it there's a ton of cleanup or > setup work happening in the middle. This is particular evident in the > conversions of various dma/drm code later in the series. >=20 > So this lets the syscall path do the install. fd_prepare() allocates a > descriptor like get_unused_fd_flags() does and records it in a slot on > the task. fd_stage() attaches the file to that slot and returns the > [ ... ] > fdtagble with outstanding reservations. Kernel threads never return to > userspace so nothing would commit. Anything left at exit is a bug and > gets warned about and dropped. >=20 > Signed-off-by: Christian Brauner (Amutable) Sashiko has reviewed this patch and found no issues. It looks great! --=20 Sashiko AI review =C2=B7 https://sashiko.dev/#/patchset/20260915-work-fd-re= serve-unify-folded-v1-0-4d5217d6b246@kernel.org?part=3D1