LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Brent Casavant <bcasavan@sgi.com>
To: Herbert Xu <herbert@gondor.apana.org.au>
Cc: penguin-kernel@i-love.sakura.ne.jp, netdev@vger.kernel.org,
	davem@davemloft.net, linux-kernel@vger.kernel.org
Subject: Re: AF_UNIX MSG_PEEK bug?
Date: Thu, 10 Jan 2008 16:35:55 -0600 (CST)	[thread overview]
Message-ID: <alpine.BSF.1.00.0801101554100.52456@pkunk.americas.sgi.com> (raw)
In-Reply-To: <alpine.BSF.1.00.0801092031290.35527@pkunk.americas.sgi.com>

Here's what I think is a better patch.  Or maybe just simpler.

However, I'm still unsure what the effect of this patch on
file descriptor passing might be.  Reading the prior code,
and the parallel portions/comments in unix_dgram_recvmsg(),
it looks like there's been a lot of uncertainty as to how
file descriptor passing should be handled durning MSG_PEEK
operations.  To quote:

	/* It is questionable: on PEEK we could:
	   - do not return fds - good, but too simple 8)
	   - return fds, and do not return them on read (old strategy,
	     apparently wrong)
	   - clone fds (I chose it for now, it is the most universal
	     solution)

	   POSIX 1003.1g does not actually define this clearly
	   at all. POSIX 1003.1g doesn't define a lot of things
	   clearly however!
	*/

With this patch, passed file descriptors are ignored during MSG_PEEK.
This is essentially the first case in the comment above.  What I
can't seem to figure out is why this is incorrect.  I suspect there's
some history here that I can't find via Google, mailing list archives,
or revision logs.

So, that said, here's a cleaner patch.  It's still not ready for
application until the file descriptor passing is better understood.

Thanks,
Brent

diff --git a/net/unix/af_unix.c b/net/unix/af_unix.c
index 060bba4..6d6cdb4 100644
--- a/net/unix/af_unix.c
+++ b/net/unix/af_unix.c
@@ -1750,6 +1750,8 @@ static int unix_stream_recvmsg(struct ki
 	int target;
 	int err = 0;
 	long timeo;
+	struct sk_buff *skb;
+	struct sk_buff_head peek_stack;
 
 	err = -EINVAL;
 	if (sk->sk_state != TCP_ESTABLISHED)
@@ -1759,6 +1761,9 @@ static int unix_stream_recvmsg(struct ki
 	if (flags&MSG_OOB)
 		goto out;
 
+	if (flags & MSG_PEEK)
+		skb_queue_head_init(&peek_stack);
+
 	target = sock_rcvlowat(sk, flags&MSG_WAITALL, size);
 	timeo = sock_rcvtimeo(sk, flags&MSG_DONTWAIT);
 
@@ -1778,7 +1783,6 @@ static int unix_stream_recvmsg(struct ki
 	do
 	{
 		int chunk;
-		struct sk_buff *skb;
 
 		unix_state_lock(sk);
 		skb = skb_dequeue(&sk->sk_receive_queue);
@@ -1864,19 +1868,14 @@ static int unix_stream_recvmsg(struct ki
 
 			if (siocb->scm->fp)
 				break;
-		}
-		else
-		{
-			/* It is questionable, see note in unix_dgram_recvmsg.
-			 */
-			if (UNIXCB(skb).fp)
-				siocb->scm->fp = scm_fp_dup(UNIXCB(skb).fp);
+		} else
+			__skb_queue_head(&peek_stack, skb);
+	} while (size);
 
-			/* put message back and return */
+	/* Push all peeked skbs back onto receive queue */
+	if (flags & MSG_PEEK)
+		while ((skb = __skb_dequeue(&peek_stack)))
 			skb_queue_head(&sk->sk_receive_queue, skb);
-			break;
-		}
-	} while (size);
 
 	mutex_unlock(&u->readlock);
 	scm_recv(sock, msg, siocb->scm, flags);

  reply	other threads:[~2008-01-10 22:36 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-01-08 22:27 Brent Casavant
2008-01-08 22:40 ` Rick Jones
2008-01-08 22:53   ` Tom Spink
2008-01-08 23:18     ` Brent Casavant
2008-01-08 23:39       ` Tom Spink
2008-01-08 23:46         ` Tom Spink
2008-01-09  0:08           ` Brent Casavant
2008-01-08 23:20   ` Brent Casavant
2008-01-09 11:04 ` Tetsuo Handa
2008-01-09 18:01   ` Brent Casavant
2008-01-10  0:01     ` Herbert Xu
2008-01-10  1:19       ` Brent Casavant
2008-01-10  2:50       ` Brent Casavant
2008-01-10 22:35         ` Brent Casavant [this message]
2008-01-10 22:36           ` Alan Cox

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=alpine.BSF.1.00.0801101554100.52456@pkunk.americas.sgi.com \
    --to=bcasavan@sgi.com \
    --cc=davem@davemloft.net \
    --cc=herbert@gondor.apana.org.au \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=penguin-kernel@i-love.sakura.ne.jp \
    --subject='Re: AF_UNIX MSG_PEEK bug?' \
    /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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).