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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.

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.

But using the rcuref code doesn't work (regardless of whether 32-bit
or 'long' ref), because of the memory ordering issues.

             Linus




[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [NTFS 3]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [NTFS 3]     [Samba]     [Device Mapper]     [CEPH Development]

  Powered by Linux