All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kuniyuki Iwashima <kuniyu@amazon.com>
To: <willemdebruijn.kernel@gmail.com>
Cc: <brauner@kernel.org>, <davem@davemloft.net>,
	<edumazet@google.com>, <horms@kernel.org>, <kuba@kernel.org>,
	<kuni1840@gmail.com>, <kuniyu@amazon.com>,
	<netdev@vger.kernel.org>, <pabeni@redhat.com>,
	<willemb@google.com>
Subject: Re: [PATCH v2 net-next 6/9] af_unix: Move SOCK_PASS{CRED,PIDFD,SEC} to struct sock.
Date: Mon, 12 May 2025 20:18:15 -0700	[thread overview]
Message-ID: <20250513031837.95186-1-kuniyu@amazon.com> (raw)
In-Reply-To: <6822b1f41c3c0_104f1029470@willemb.c.googlers.com.notmuch>

From: Willem de Bruijn <willemdebruijn.kernel@gmail.com>
Date: Mon, 12 May 2025 22:44:04 -0400
> Kuniyuki Iwashima wrote:
> > From: Willem de Bruijn <willemdebruijn.kernel@gmail.com>
> > Date: Mon, 12 May 2025 15:20:54 -0400
> > > Kuniyuki Iwashima wrote:
> > > > As explained in the next patch, SO_PASSRIGHTS would have a problem
> > > > if we assigned a corresponding bit to socket->flags, so it must be
> > > > managed in struct sock.
> > > > 
> > > > Mixing socket->flags and sk->sk_flags for similar options will look
> > > > confusing, and sk->sk_flags does not have enough space on 32bit system.
> > > > 
> > > > Also, as mentioned in commit 16e572626961 ("af_unix: dont send
> > > > SCM_CREDENTIALS by default"), SOCK_PASSCRED and SOCK_PASSPID handling
> > > > is known to be slow, and managing the flags in struct socket cannot
> > > > avoid that for embryo sockets.
> > > > 
> > > > Let's move SOCK_PASS{CRED,PIDFD,SEC} to struct sock.
> > > > 
> > > > While at it, other SOCK_XXX flags in net.h are grouped as enum.
> > > > 
> > > > Signed-off-by: Kuniyuki Iwashima <kuniyu@amazon.com>
> > > 
> > > > diff --git a/net/core/sock.c b/net/core/sock.c
> > > > index 1ab59efbafc5..9540cbe3d83e 100644
> > > > --- a/net/core/sock.c
> > > > +++ b/net/core/sock.c
> > > > @@ -1224,19 +1224,19 @@ int sk_setsockopt(struct sock *sk, int level, int optname,
> > > >  		if (!sk_may_scm_recv(sk))
> > > >  			return -EOPNOTSUPP;
> > > >  
> > > > -		assign_bit(SOCK_PASSSEC, &sock->flags, valbool);
> > > > +		sk->sk_scm_security = valbool;
> > > 
> > > Is it safe to switch from atomic to non-atomic updates?
> > > 
> > > Reads and writes can race. Especially given that these are bit stores, so RMW.
> > 
> > Exactly, will move them down after sockopt_lock_sock().
> 
> So all reads in the datapath are with the socket locked? Okay, that
> was not immediately obvious to me. If respinning, please add a
> comment.

Sure, will add a comment.

  reply	other threads:[~2025-05-13  3:18 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-05-10  1:56 [PATCH v2 net-next 0/9] af_unix: Introduce SO_PASSRIGHTS Kuniyuki Iwashima
2025-05-10  1:56 ` [PATCH v2 net-next 1/9] af_unix: Factorise test_bit() for SOCK_PASSCRED and SOCK_PASSPIDFD Kuniyuki Iwashima
2025-05-10  1:56 ` [PATCH v2 net-next 2/9] af_unix: Don't pass struct socket to maybe_add_creds() Kuniyuki Iwashima
2025-05-10  1:56 ` [PATCH v2 net-next 3/9] scm: Move scm_recv() from scm.h to scm.c Kuniyuki Iwashima
2025-05-10  1:56 ` [PATCH v2 net-next 4/9] tcp: Restrict SO_TXREHASH to TCP socket Kuniyuki Iwashima
2025-05-12 19:18   ` Willem de Bruijn
2025-05-12 22:14     ` Kuniyuki Iwashima
2025-05-13  2:42       ` Willem de Bruijn
2025-05-13  3:11         ` Kuniyuki Iwashima
2025-05-10  1:56 ` [PATCH v2 net-next 5/9] net: Restrict SO_PASS{CRED,PIDFD,SEC} to AF_{UNIX,NETLINK,BLUETOOTH} Kuniyuki Iwashima
2025-05-10  1:56 ` [PATCH v2 net-next 6/9] af_unix: Move SOCK_PASS{CRED,PIDFD,SEC} to struct sock Kuniyuki Iwashima
2025-05-12 19:20   ` Willem de Bruijn
2025-05-12 22:20     ` Kuniyuki Iwashima
2025-05-13  2:44       ` Willem de Bruijn
2025-05-13  3:18         ` Kuniyuki Iwashima [this message]
2025-05-13  2:03   ` kernel test robot
2025-05-10  1:56 ` [PATCH v2 net-next 7/9] af_unix: Inherit sk_flags at connect() Kuniyuki Iwashima
2025-05-12 19:38   ` Willem de Bruijn
2025-05-12 22:34     ` Kuniyuki Iwashima
2025-05-13  2:48       ` Willem de Bruijn
2025-05-13  3:20         ` Kuniyuki Iwashima
2025-05-10  1:56 ` [PATCH v2 net-next 8/9] af_unix: Introduce SO_PASSRIGHTS Kuniyuki Iwashima
2025-05-10  1:56 ` [PATCH v2 net-next 9/9] selftest: af_unix: Test SO_PASSRIGHTS Kuniyuki Iwashima

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=20250513031837.95186-1-kuniyu@amazon.com \
    --to=kuniyu@amazon.com \
    --cc=brauner@kernel.org \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=horms@kernel.org \
    --cc=kuba@kernel.org \
    --cc=kuni1840@gmail.com \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=willemb@google.com \
    --cc=willemdebruijn.kernel@gmail.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.