From: Jakub Kicinski <kuba@kernel.org>
To: Luca Boccassi <bluca@debian.org>
Cc: Christian Brauner <brauner@kernel.org>,
Alexander Mikhalitsyn <aleksandr.mikhalitsyn@canonical.com>,
davem@davemloft.net, linux-kernel@vger.kernel.org,
netdev@vger.kernel.org, Eric Dumazet <edumazet@google.com>,
Paolo Abeni <pabeni@redhat.com>,
Leon Romanovsky <leon@kernel.org>,
David Ahern <dsahern@kernel.org>, Arnd Bergmann <arnd@arndb.de>,
Kees Cook <keescook@chromium.org>,
Kuniyuki Iwashima <kuniyu@amazon.com>,
Lennart Poettering <mzxreary@0pointer.de>,
linux-arch@vger.kernel.org
Subject: Re: [PATCH net-next v6 1/3] scm: add SO_PASSPIDFD and SCM_PIDFD
Date: Tue, 23 May 2023 14:08:44 -0700 [thread overview]
Message-ID: <20230523140844.5895d645@kernel.org> (raw)
In-Reply-To: <CAMw=ZnS8GBTDV0rw+Dh6hPv3uLXJVwapRFQHLMYEYGZHNoLNOw@mail.gmail.com>
On Tue, 23 May 2023 11:44:01 +0100 Luca Boccassi wrote:
> > I really would like to avoid that because it will just mean that someone
> > else will abuse that function and then make an argument why we should
> > export the other function.
> >
> > I think it would be ok if we required that unix support is built in
> > because it's not unprecedented either and we're not breaking anything.
> > Bpf has the same requirement:
> >
> > #if IS_BUILTIN(CONFIG_UNIX) && defined(CONFIG_BPF_SYSCALL)
> > struct bpf_unix_iter_state {
> > struct seq_net_private p;
> > unsigned int cur_sk;
> > unsigned int end_sk;
> > unsigned int max_sk;
> > struct sock **batch;
> > bool st_bucket_done;
> > };
> >
> > and
> >
> > #if IS_BUILTIN(CONFIG_UNIX) && defined(CONFIG_BPF_SYSCALL) && defined(CONFIG_PROC_FS)
> > DEFINE_BPF_ITER_FUNC(unix, struct bpf_iter_meta *meta,
> > struct unix_sock *unix_sk, uid_t uid)
Don't think we should bring BPF into arguments about uAPI consistency :S
> Some data points: Debian, Ubuntu, Fedora, RHEL, CentOS, Archlinux all
> ship with CONFIG_UNIX=y, so a missing SCM_PIDFD in unlikely to have a
> widespread impact, and if it does, it might encourage someone to
> review their kconfig.
IDK how you can argue that everyone sets UNIX to =y so hiding SCM_PIDFD
is fine and at the same time not be okay with making UNIX a bool :S
> As mentioned on the v5 thread, we are waiting for this API to get the
> userspace side sorted (systemd/dbus/dbus-broker/polkit), so I'd be
> really grateful if we could start with the simplest and most
> conservative approach (which seems to be the current one in v6 to me),
> and then eventually later decide whether to export more functions, or
> to deprecate CONFIG_UNIX=m, or something else entirely, as that
> doesn't really affect the shape of the UAPI, just the details of its
> availability. Thank you.
Just throw in a patch to make UNIX a bool and stop arguing then.
next prev parent reply other threads:[~2023-05-23 21:08 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-05-22 13:24 [PATCH net-next v6 0/3] Add SCM_PIDFD and SO_PEERPIDFD Alexander Mikhalitsyn
2023-05-22 13:24 ` [PATCH net-next v6 1/3] scm: add SO_PASSPIDFD and SCM_PIDFD Alexander Mikhalitsyn
2023-05-22 20:34 ` Jakub Kicinski
2023-05-23 9:49 ` Christian Brauner
2023-05-23 10:44 ` Luca Boccassi
2023-05-23 21:08 ` Jakub Kicinski [this message]
2023-05-24 10:43 ` Aleksandr Mikhalitsyn
2023-05-24 10:47 ` Luca Boccassi
2023-05-24 15:19 ` Jakub Kicinski
2023-05-24 15:45 ` Aleksandr Mikhalitsyn
2023-06-04 18:02 ` Jakub Kicinski
2023-06-04 18:07 ` Aleksandr Mikhalitsyn
2023-06-08 20:28 ` Aleksandr Mikhalitsyn
2023-05-22 13:24 ` [PATCH net-next v6 2/3] net: core: add getsockopt SO_PEERPIDFD Alexander Mikhalitsyn
2023-05-22 13:24 ` [PATCH net-next v6 3/3] selftests: net: add SCM_PIDFD / SO_PEERPIDFD test Alexander Mikhalitsyn
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=20230523140844.5895d645@kernel.org \
--to=kuba@kernel.org \
--cc=aleksandr.mikhalitsyn@canonical.com \
--cc=arnd@arndb.de \
--cc=bluca@debian.org \
--cc=brauner@kernel.org \
--cc=davem@davemloft.net \
--cc=dsahern@kernel.org \
--cc=edumazet@google.com \
--cc=keescook@chromium.org \
--cc=kuniyu@amazon.com \
--cc=leon@kernel.org \
--cc=linux-arch@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mzxreary@0pointer.de \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
/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.