From: Al Viro <viro@zeniv.linux.org.uk>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: netdev@vger.kernel.org, linux-fsdevel@vger.kernel.org
Subject: Re: [PATCH][CFT][experimental] net/socket.c: use straight fdget/fdput (resend)
Date: Mon, 27 May 2024 17:31:16 +0100 [thread overview]
Message-ID: <20240527163116.GD2118490@ZenIV> (raw)
In-Reply-To: <20240526231641.GB2118490@ZenIV>
On Mon, May 27, 2024 at 12:16:41AM +0100, Al Viro wrote:
> > What would make more sense is if you make the "fd_empty()" test be
> > about the _flags_, and then both the fp_empty() test and the test
> > inside fdput() would be testing the same things.
>
> Umm... What encoding would you use?
FWIW, _if_ we go for replacement of struct fd with struct-wrapped
unsigned long and actually steal another bit from pointer, we could
actually use that to encode errors as well...
If bit 0 is clear for file reference and set for an error, we could
use bit 1 to represent borrowed vs. cloned and bit 2 for need to
unlock...
overlayfs would be happier that way - we could have those functions
return struct fd directly, and pass the error value that way.
fdget() would report EBADF explicitly on empty slot - not a big
deal. Hmm...
Let me play with that a bit and see if I can come up with something
tolerable.
We could add that in parallel to existing struct fd; we'd need a name
for replacement, though - anything like "rawfd" is asking for confusion
around fdget_raw(), and we'd need replacements for fdget() et.al.
that would yield those.
Alternatively, with a sane set of helpers we could actually _replace_
struct fd definition without a huge flagday commit - start with adding
#define fd_file(fd) ((fd).file)
#define fd_valid(fd) (fd_file(fd) != NULL)
convert the current users, one by one (fairly mechanical patches),
then change the definition of struct fd. The last step would affect
* definitions of helpers
* adding fd-constructing macros (ERR_FD, etc.)
* converting the few places that really construct those
suckers (fdget() et.al., overlayfs, a couple of explicit
initializers to {NULL, 0}).
It's not a huge amount of work and the flagday step would be fairly
small, but we'd probably need to split that over a couple of cycles -
helpers in one, along with renaming fd.file to e.g.
fd.__file_use_the_damn_helpers, then in the next cycle do the
switchover.
Hell knows; let me play with that a bit and let's see what falls out...
next prev parent reply other threads:[~2024-05-27 16:31 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-26 3:45 [PATCH][CFT][experimental] net/socket.c: use straight fdget/fdput (resend) Al Viro
2024-05-26 5:07 ` Linus Torvalds
2024-05-26 5:31 ` Linus Torvalds
2024-05-26 19:27 ` Al Viro
2024-05-26 22:16 ` Linus Torvalds
2024-05-26 23:16 ` Al Viro
2024-05-27 15:23 ` Linus Torvalds
2024-05-27 16:31 ` Al Viro [this message]
2024-05-27 19:20 ` Linus Torvalds
2024-05-27 19:35 ` Linus Torvalds
2024-05-27 21:25 ` Al Viro
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20240527163116.GD2118490@ZenIV \
--to=viro@zeniv.linux.org.uk \
--cc=linux-fsdevel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=torvalds@linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.