netdev - Re: [PATCH][CFT][experimental] net/socket.c: use straight fdget/fdput (resend)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAHk-=wh1_Sfgr6HsfjsCg_B-5b9sGKuWFpWnkwhdwNaODekraQ@mail.gmail.com>
Date: Sat, 25 May 2024 22:31:32 -0700
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Al Viro <viro@...iv.linux.org.uk>
Cc: netdev@...r.kernel.org, linux-fsdevel@...r.kernel.org
Subject: Re: [PATCH][CFT][experimental] net/socket.c: use straight fdget/fdput (resend)

On Sat, 25 May 2024 at 22:07, Linus Torvalds
<torvalds@...ux-foundation.org> wrote:
>
> IOW, we could do something like the attached. I think it's actually
> almost a cleanup [..]

The reason I say that is this part of the patch:

  -static inline struct fd __to_fd(unsigned long v)
  +static inline struct fd __to_fd(struct rawfd raw)
   {
  -       return (struct fd){(struct file *)(v & ~3),v & 3};
  +       return (struct fd){fdfile(raw),fdflags(raw)};
   }

which I think actually improves on our current situation.

No, my fdfile/fdflags functions aren't pretty, but they have more type
safety than the bare "unsigned long", and in that "__to_fd()" case I
think it actually makes that unpacking operation much more obvious.

It might be good to have the reverse "packing" helper inline function
too, so that __fdget() wouldn't do this:

                return (struct rawfd) { FDPUT_FPUT | (unsigned long)file };

but instead have some kind of "mkrawfd()" helper that does the above,
and we'd have

                return mkrawfd(file, FDPUT_FPUT);

instead. That would obviate my EMPTY_RAWFD macro, and we'd just use
"mkrawfd(NULL, 0)"?

Maybe this is bikeshedding. But I'd rather have this kind of explicit
one-word interface with a wrapped tagged pointer than have something
as subtle as your fd_empty() that magically generates better code in
certain very specific circumstances.

                     Linus