On Sat, Oct 05, 2024 at 03:43:16PM GMT, Linus Torvalds wrote: > On Sat, 5 Oct 2024 at 15:28, Al Viro <viro@xxxxxxxxxxxxxxxxxx> 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.
