From: "John Ericson" <mail@johnericson.me>
To: "Cong Wang" <cwang@multikernel.io>
Cc: "Li Chen" <me@linux.beauty>, "Andy Lutomirski" <luto@kernel.org>,
"Christian Brauner" <brauner@kernel.org>,
"Jens Axboe" <axboe@kernel.dk>,
"network dev" <netdev@vger.kernel.org>,
linux-fsdevel <linux-fsdevel@vger.kernel.org>
Subject: Re: [RFC] connectat()/bindat() or an alternative design
Date: Tue, 30 Jun 2026 16:22:25 -0400 [thread overview]
Message-ID: <e396ce86-ec84-4189-9da2-98af7cfa6c41@app.fastmail.com> (raw)
In-Reply-To: <66eb8227-85b6-4684-a4fa-e3e17ac2fa45@app.fastmail.com>
I'm bumping this and adding new recipients again in light of the
discussion happening elsewhere in
<https://lore.kernel.org/all/a49ce818-f38d-41b0-bbf7-80b8aad998b1@app.fastmail.com/>.
I don't want to count my chickens before they are hatched, but it is
looking to me like a consensus in that thread is building around the
ability to opt into intentionally empty/unusable root and working
directories (at least with nullfs, maybe but less likely with other
mechanisms instead).
That new functionality concretizes the motivation for what I am
proposing in this thread: in such a world, there is little to no point
binding listening sockets in the file system, because the containing
directory would have to be conveyed by file descriptor anyways --- might
as well just directly convey the socket to connect to by file
descriptor. Likewise, abstract sockets are not appealing, because the
abstract socket namespace is either too coarse-grained (leaking info in
the same way root/cwd would), or too cumbersome to keep it from leaking.
To recap (with some slight changes, like renames), my latest proposal (a
new version, not either of the two variations in the original email) is
new syscalls `bind_unix_anon` and `connectat`, supporting a workflow
like this:
/* server */
int lfd = socket(AF_UNIX, SOCK_STREAM | SOCK_CLOEXEC, 0);
int addrfd = bind_unix_anon(
lfd,
/*flags, for the future*/0);
listen(lfd, 64);
/* client, handed `addrfd` */
int cfd = socket(AF_UNIX, SOCK_STREAM | SOCK_CLOEXEC, 0);
connectat(addrfd, cfd, AT_EMPTY_PATH);
Or, more radically, `bind_unix_anon` and `connectat` could let one skip
the initial `socket` calls by returning those new sockets directly:
/* server */
int fds[2];
bind_unix_anon(
SOCK_STREAM | SOCK_CLOEXEC,
/*flags, for the future*/0,
fds);
int lfd = fds[0], addrfd = fds[1];
listen(lfd, 64);
/* client, handed `addrfd` */
int cfd = connectat(
addrfd,
SOCK_STREAM | SOCK_CLOEXEC,
AT_EMPTY_PATH);
(Note that in this variation `bind_unix_anon` would return *two* file
descriptors: one for the server, with the permission to listen, and the
other for clients, with just the privilege to `connectat`.) (Maybe
`bind_unix_anon` should furthermore `listen` right away on `lfd` too?)
Of course, it would be nice to have io_uring versions of these too. But
I don't know what the usual process is for that (regular first? io_uring
first? both at the same time?)
Thanks,
John
P.S. For anyone just getting CC'd now, the first message in this thread
is
<https://lore.kernel.org/all/b1af80fc-a57c-408d-bdfe-fa6bae26eaca@app.fastmail.com/>.
Hope that might save people a few keypresses :).
next prev parent reply other threads:[~2026-06-30 20:22 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-18 19:09 [RFC] connectat()/bindat() or an alternative design John Ericson
2026-06-08 19:45 ` Cong Wang
2026-06-11 2:08 ` John Ericson
2026-06-12 18:50 ` Cong Wang
2026-06-23 17:40 ` John Ericson
2026-06-30 20:22 ` John Ericson [this message]
2026-07-01 19:41 ` John Ericson
2026-07-02 0:32 ` Cong Wang
2026-07-02 3:22 ` John Ericson
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=e396ce86-ec84-4189-9da2-98af7cfa6c41@app.fastmail.com \
--to=mail@johnericson.me \
--cc=axboe@kernel.dk \
--cc=brauner@kernel.org \
--cc=cwang@multikernel.io \
--cc=linux-fsdevel@vger.kernel.org \
--cc=luto@kernel.org \
--cc=me@linux.beauty \
--cc=netdev@vger.kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox