Re: [PATCH RFC 0/4] fs: port files to rcuref_long_t

[Christian Brauner <brauner@kernel.org>]

On Sat, Oct 05, 2024 at 03:43:16PM GMT, Linus Torvalds wrote:
> On Sat, 5 Oct 2024 at 15:28, Al Viro <viro@zeniv.linux.org.uk> wrote:
> >
> > You can keep sending SCM_RIGHTS packets filled with references
> > to the same file, for example...
> 
> Yeah, it's always SCM_RIGHTS or splice() that ends up having those
> issues.  But it's a really easy place to go "Oh, no, you can't do
> that".
> 
> > Anyway, which error would you return?  EBADF?
> 
> I really don't think it matters.
> 
> Come on - the only possible reason for two billion files is a bad
> user. Do we care what error return an attacker gets? No. We're not
> talking about breaking existing programs.
> 
> So EBADF sounds fine to me particularly from fget() and friends, since
> they have that whole case of "no such file" anyway.
> 
> For try_get_page(), we also still have the WARN_ON_ONCE() if it ever
> triggers. I don't recall having ever heard a report of it actually
> triggering, but I do think we would do the same thing for the file ref
> counting.

I really don't see the issue in making fget() _theoretically_ fail. And
I agree it would be a bug. We already have that WARN_ON() in get_file()
just to protect against completely theoretical overflow issues. If that
ever triggers anywhere we should worry about it.

> 
> Anyway, maybe making f_count a 32-bit thing isn't worth it, simply
> because 'struct file' is so much bigger (and less critical) than
> 'struct page' is anyway.
> 
> So I don't think that's actually the important thing here. If we keep
> it a 'long', I won't lose any sleep over it.

struct file is significantly smaller since the work I did the last two
cycles. So I don't think there's any pressure to go from long to int.