All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jakub Kicinski <kuba@kernel.org>
To: Shoaib Rao <rao.shoaib@oracle.com>
Cc: "Matthew Wilcox (Oracle)" <willy@infradead.org>,
	linux-kernel@vger.kernel.org, linux-api@vger.kernel.org,
	netdev@vger.kernel.org, "David S. Miller" <davem@davemloft.net>,
	andy.rudoff@intel.com
Subject: Re: [PATCH] af_unix: Allow Unix sockets to raise SIGURG
Date: Fri, 29 Jan 2021 11:06:05 -0800	[thread overview]
Message-ID: <20210129110605.54df8409@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com> (raw)
In-Reply-To: <23fc3de2-7541-04c9-a56f-4006a7dc773f@oracle.com>

On Fri, 29 Jan 2021 09:56:48 -0800 Shoaib Rao wrote:
> On 1/25/21 3:36 PM, Jakub Kicinski wrote:
> > On Fri, 22 Jan 2021 15:06:37 +0000 Matthew Wilcox (Oracle) wrote:  
> >> From: Rao Shoaib <rao.shoaib@oracle.com>
> >>
> >> TCP sockets allow SIGURG to be sent to the process holding the other
> >> end of the socket.  Extend Unix sockets to have the same ability.
> >>
> >> The API is the same in that the sender uses sendmsg() with MSG_OOB to
> >> raise SIGURG.  Unix sockets behave in the same way as TCP sockets with
> >> SO_OOBINLINE set.  
> > Noob question, if we only want to support the inline mode, why don't we
> > require SO_OOBINLINE to have been called on @other? Wouldn't that
> > provide more consistent behavior across address families?
> >
> > With the current implementation the receiver will also not see MSG_OOB
> > set in msg->msg_flags, right?  
> 
> SO_OOBINLINE does not control the delivery of signal, It controls how
> OOB Byte is delivered. It may not be obvious but this change does not
> deliver any Byte, just a signal. So, as long as sendmsg flag contains
> MSG_OOB, signal will be delivered just like it happens for TCP.

Not as far as I can read this code. If MSG_OOB is set the data from the
message used to be discarded, and EOPNOTSUPP returned. Now the data gets
queued to the socket, and will be read inline.

Sure, you also add firing of the signal, which is fine. The removal of
the error check is the code I'm pointing at, so to speak.

> >> SIGURG is ignored by default, so applications which do not know about this
> >> feature will be unaffected.  In addition to installing a SIGURG handler,
> >> the receiving application must call F_SETOWN or F_SETOWN_EX to indicate
> >> which process or thread should receive the signal.
> >>
> >> Signed-off-by: Rao Shoaib <rao.shoaib@oracle.com>
> >> Signed-off-by: Matthew Wilcox (Oracle) <willy@infradead.org>
> >> ---
> >>   net/unix/af_unix.c | 5 +++--
> >>   1 file changed, 3 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/net/unix/af_unix.c b/net/unix/af_unix.c
> >> index 41c3303c3357..849dff688c2c 100644
> >> --- a/net/unix/af_unix.c
> >> +++ b/net/unix/af_unix.c
> >> @@ -1837,8 +1837,6 @@ static int unix_stream_sendmsg(struct socket *sock, struct msghdr *msg,
> >>   		return err;
> >>   
> >>   	err = -EOPNOTSUPP;
> >> -	if (msg->msg_flags&MSG_OOB)
> >> -		goto out_err;
> >>   
> >>   	if (msg->msg_namelen) {
> >>   		err = sk->sk_state == TCP_ESTABLISHED ? -EISCONN : -EOPNOTSUPP;
> >> @@ -1903,6 +1901,9 @@ static int unix_stream_sendmsg(struct socket *sock, struct msghdr *msg,
> >>   		sent += size;
> >>   	}
> >>   
> >> +	if (msg->msg_flags & MSG_OOB)
> >> +		sk_send_sigurg(other);
> >> +
> >>   	scm_destroy(&scm);
> >>   
> >>   	return sent;  


  reply	other threads:[~2021-01-29 19:08 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-22 15:06 [PATCH] af_unix: Allow Unix sockets to raise SIGURG Matthew Wilcox (Oracle)
2021-01-25 23:36 ` Jakub Kicinski
2021-01-29 17:56   ` Shoaib Rao
2021-01-29 19:06     ` Jakub Kicinski [this message]
2021-01-29 19:48       ` Shoaib Rao
2021-01-29 20:02         ` Jakub Kicinski
2021-01-29 20:10           ` Shoaib Rao
2021-01-29 20:18             ` Jakub Kicinski
2021-01-29 20:44               ` Shoaib Rao
2021-01-29 20:49                 ` Shoaib Rao
2021-01-29 21:18                 ` Jakub Kicinski
2021-01-29 21:32                   ` Matthew Wilcox
2021-01-29 23:47                     ` David Laight
2021-01-29 21:54                   ` Shoaib Rao
2021-01-29 19:19     ` Matthew Wilcox
2021-01-29 19:54       ` Shoaib Rao
2021-01-29 20:01         ` Shoaib Rao

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=20210129110605.54df8409@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com \
    --to=kuba@kernel.org \
    --cc=andy.rudoff@intel.com \
    --cc=davem@davemloft.net \
    --cc=linux-api@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=rao.shoaib@oracle.com \
    --cc=willy@infradead.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.