[PATCH 5/5] fs: Convert struct file::f_count to refcount_long_t
Kees Cook
keescook at chromium.org
Thu May 2 22:52:21 UTC 2024
On Thu, May 02, 2024 at 11:42:50PM +0100, Al Viro wrote:
> On Thu, May 02, 2024 at 03:33:40PM -0700, Kees Cook wrote:
> > Underflow of f_count needs to be more carefully detected than it
> > currently is. The results of get_file() should be checked, but the
> > first step is detection. Redefine f_count from atomic_long_t to
> > refcount_long_t.
>
> It is used on fairly hot paths. What's more, it's not
> at all obvious what the hell would right semantics be.
I think we've put performance concerns between refcount_t and atomic_t
to rest long ago. If there is a real workload where it's a problem,
let's find it! :)
As for semantics, what do you mean? Detecting dec-below-zero means we
catch underflow, and detected inc-from-zero means we catch resurrection
attempts. In both cases we avoid double-free, but we have already lost
to a potential dangling reference to a freed struct file. But just
letting f_count go bad seems dangerous.
--
Kees Cook
More information about the Intel-gfx
mailing list