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 34183E732D0 for ; Fri, 29 Sep 2023 09:21:00 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232949AbjI2JVA (ORCPT ); Fri, 29 Sep 2023 05:21:00 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:37298 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232490AbjI2JU6 (ORCPT ); Fri, 29 Sep 2023 05:20:58 -0400 Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 3E8E019F; Fri, 29 Sep 2023 02:20:56 -0700 (PDT) Received: by smtp.kernel.org (Postfix) with ESMTPSA id CCD19C433C8; Fri, 29 Sep 2023 09:20:53 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1695979255; bh=ixqemPBH+Yg3YxK8N4iZBEZPhv5OujAqEu9rexAdDbQ=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=GIMtzk+H6WnoeyiP7YtkRG5RIlr6lMjdgpmFCmotRRSzhFSHDrnxt4AxfFTAxNYqn wNuolRwkNNjaj2CqIEO2Ie20qub2K2zBxKnWbIpQ2RVPPri/JcDTBUxel/gwj6UlJj xxWoeeQ2Y+AkyS8iwQ+klD7M9fIFbRNKcvqgRpKJu8JT2kTIaiEQGlBhanuf23D7KU i6kLzgntHi9U0Q+ISvpVhh0l0dqtgxmN7fdvREQem0GoGwxHaoa1ICU9Ndida6u2Hf TymisZxBVP1BDxajl2hVFG0NtME0Ljg8T4VZxEnr3dttIGRQOUUtNt3Stra5W8ZQDt lyjU/Koh6J4vQ== Date: Fri, 29 Sep 2023 11:20:48 +0200 From: Christian Brauner To: Linus Torvalds Cc: Jann Horn , Mateusz Guzik , viro@zeniv.linux.org.uk, linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org Subject: Re: [PATCH v2] vfs: shave work on failed file open Message-ID: <20230929-kerzen-fachjargon-ca17177e9eeb@brauner> References: <20230927-kosmetik-babypuppen-75bee530b9f0@brauner> <20230928-kulleraugen-restaurant-dd14e2a9c0b0@brauner> <20230928-themen-dilettanten-16bf329ab370@brauner> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > But yes, that protection would be broken by SLAB_TYPESAFE_BY_RCU, > since then the "f_count is zero" is no longer a final thing. I've tried coming up with a patch that is simple enough so the pattern is easy to follow and then converting all places to rely on a pattern that combine lookup_fd_rcu() or similar with get_file_rcu(). The obvious thing is that we'll force a few places to now always acquire a reference when they don't really need one right now and that already may cause performance issues. We also can't fully get rid of plain get_file_rcu() uses itself because of users such as mm->exe_file. They don't go from one of the rcu fdtable lookup helpers to the struct file obviously. They rcu replace the file pointer in their struct ofc so we could change get_file_rcu() to take a struct file __rcu **f and then comparing that the passed in pointer hasn't changed before we managed to do atomic_long_inc_not_zero(). Which afaict should work for such cases. But overall we would introduce a fairly big and at the same time subtle semantic change. The idea is pretty neat and it was fun to do but I'm just not convinced we should do it given how ubiquitous struct file is used and now to make the semanics even more special by allowing refcounts. I've kept your original release_empty_file() proposal in vfs.misc which I think is a really nice change. Let me know if you all passionately disagree. ;)