Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.35 as permitted sender) client-ip=23.128.96.35;
MIME-Version: 1.0
In-Reply-To: <20230926-worum-angezapft-5c3f7770ad29@brauner>
References: <20230925205545.4135472-1-mjguzik@gmail.com> <20230926-anforderungen-obgleich-47e465f0bd47@brauner>
 <CAGudoHG0-BWTVRG8uZk5Gy8xSwpT8JO5Z=VfY3_dFcCaqhLf5Q@mail.gmail.com> <20230926-worum-angezapft-5c3f7770ad29@brauner>
From:   Mateusz Guzik <mjguzik@gmail.com>
Date:   Tue, 26 Sep 2023 17:40:33 +0200
Message-ID: <CAGudoHFWJWdE26kEGdj=83KJ_gJi9BwRiOUQ1Gy=1i9u4fgJSA@mail.gmail.com>
Subject: Re: [PATCH] vfs: shave work on failed file open
To:     Christian Brauner <brauner@kernel.org>
Cc:     viro@zeniv.linux.org.uk, linux-kernel@vger.kernel.org,
        linux-fsdevel@vger.kernel.org, torvalds@linux-foundation.org
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

On 9/26/23, Christian Brauner <brauner@kernel.org> wrote:
>> > if (WARN_ON_ONCE(atomic_long_cmpxchg(&file->f_count, 1, 0) != 1)) {
>
>> bench again.
>
> Can you see how much of a difference it makes because imho it really
> looks a lot nicer then this ugly atomic_read followed by atomic_set...
>

Huh, turns out to be in the noise here and I see why.

Immediately following this there are several atomic ops anyway,
notably to unref creds and apparmor labels. So happens top of the
profile is the allocator(!).

These can be fixed but that's perhaps for another time.

If going this route then perhaps atomic_long_dec_and_test just like
fput? Although one could argue if that cmpxchg failed then something
fishy is going on and "real" fput would be safer. Ultimately there is
a lot of handwaving possible whichever way, so just pick something and
I'll send a v2.

-- 
Mateusz Guzik <mjguzik gmail.com>