From mbsd@pacbell.net  Sun Mar  6 02:50:15 2005
Return-Path: <mbsd@pacbell.net>
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP id 54AAB16A4CE
	for <FreeBSD-gnats-submit@freebsd.org>; Sun,  6 Mar 2005 02:50:15 +0000 (GMT)
Received: from ylpvm15.prodigy.net (ylpvm15-ext.prodigy.net [207.115.57.46])
	by mx1.FreeBSD.org (Postfix) with ESMTP id DE63043D2D
	for <FreeBSD-gnats-submit@freebsd.org>; Sun,  6 Mar 2005 02:50:14 +0000 (GMT)
	(envelope-from mbsd@pacbell.net)
Received: from antec.home (adsl-64-168-24-254.dsl.snfc21.pacbell.net [64.168.24.254])
	by ylpvm15.prodigy.net (8.12.10 outbound/8.12.10) with ESMTP id j262k6EN029585
	for <FreeBSD-gnats-submit@freebsd.org>; Sat, 5 Mar 2005 21:46:06 -0500
Message-Id: <20050305184839.N693@antec.home>
Date: Sat, 5 Mar 2005 18:50:12 -0800 (PST)
From: =?ISO-8859-1?Q?Mikko_Ty=F6l=E4j=E4rvi?= <mbsd@pacbell.net>
To: FreeBSD-gnats-submit@freebsd.org
Subject: Writing to closed socket does not generate SIGPIPE

>Number:         78478
>Category:       kern
>Synopsis:       writing to closed socket does not generate SIGPIPE
>Confidential:   no
>Severity:       serious
>Priority:       high
>Responsible:    bms
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Sun Mar 06 02:50:17 GMT 2005
>Closed-Date:    Mon Mar 05 11:15:57 GMT 2007
>Last-Modified:  Mon Mar  5 11:20:03 GMT 2007
>Originator:     Mikko Tyolajarvi
>Release:        FreeBSD 6.0-CURRENT i386
>Organization:
>Environment:
System: FreeBSD sotec.home 6.0-CURRENT FreeBSD 6.0-CURRENT #28: Sat Mar 5 16:58:15 PST 2005 mikko@sotec.home:/usr/obj/usr/src/sys/SOTEC i386

5.3-RELEASE, 5-STABLE, 6-CURRENT all behave the same.

>Description:

Using write(2) to write to a connected socket, IP or unix domain,
where the other end has closed the connection should result in a
SIGPIPE signal being generated, and does so on FreeBSD 4.11 (as well
as Solaris 2.6, 8 & 10, HPUX 11.00 & 11.22, Linux 2.4 & 2.6 etc).

Using send(2) instead of write(2) does produce the signal, as does
write(2) to a pipe.  It is only the combination of write(2) and
a stream socket that does not work.


>How-To-Repeat:


#include <sys/types.h>
#include <sys/socket.h>
#include <sys/time.h>
#include <netinet/in.h>
#include <netinet/tcp.h>
#include <arpa/inet.h>
#include <errno.h>
#include <unistd.h>
#include <signal.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>

static void
gotpipe(int sig)
{
     printf("SIGPIPE\n");
     exit(0);
}

int
main(int argc, char *argv[])
{
     char data[32 * 1024];
     int sock, lsock, asock;
     socklen_t len;
     int i, use_send, set_nosigpipe;
     struct sockaddr_in ia;

     use_send = (argc > 1 && strchr(argv[1], 's'));
     set_nosigpipe = (argc > 1 && strchr(argv[1], 'n'));

     signal(SIGPIPE, gotpipe);

     lsock = socket(AF_INET, SOCK_STREAM, 0);
     memset(&ia, 0, sizeof(ia));
     ia.sin_addr.s_addr = htonl(INADDR_LOOPBACK);
     bind(lsock, (struct sockaddr *)&ia, sizeof(ia));
     listen(lsock, 5);
     len = sizeof(ia);
     if (getsockname(lsock, (struct sockaddr *)&ia, &len) < 0) {
 	perror("getsockname");
 	return 1;
     }

     sock = socket(AF_INET, SOCK_STREAM, 0);
     if (connect(sock, (struct sockaddr *)&ia, sizeof(ia)) < 0) {
 	perror("connect");
 	return 1;
     }
     asock = accept(lsock, NULL, NULL);
     close(lsock);
     close(asock);

#ifdef SO_NOSIGPIPE
     if (set_nosigpipe) {
 	i = 1;
 	if (setsockopt(sock, SOL_SOCKET, SO_NOSIGPIPE, &i, sizeof(i)) < 0) {
 	    perror("setsockopt");
 	}
     }
     len = sizeof(i);
     if (getsockopt(sock, SOL_SOCKET, SO_NOSIGPIPE, &i, &len) < 0) {
 	perror("getsockopt");
 	return 1;
     }
     printf("SO_NOSIGPIPE is %d\n", i);
#else
     printf("SO_NOSIGPIPE not supported\n");
#endif

     for (i = 0; i < 4; i++) {
 	if (use_send) {
 	    if (send(sock, data, sizeof(data), 0) < 0) {
 		perror("send");
 	    }
 	} else {
 	    if (write(sock, data, sizeof(data)) < 0) {
 		perror("write");
 	    }
 	}
     }

     printf("No sigpipe\n");

     return 1;
}


>Fix:

This seems to be one way to solve the problem:

Index: sys_socket.c
===================================================================
RCS file: /home/ncvs/src/sys/kern/sys_socket.c,v
retrieving revision 1.67
diff -b -u -r1.67 sys_socket.c
--- sys_socket.c	6 Jan 2005 23:35:39 -0000	1.67
+++ sys_socket.c	6 Mar 2005 02:44:58 -0000
@@ -39,8 +39,11 @@
  #include <sys/file.h>
  #include <sys/filedesc.h>
  #include <sys/mac.h>
+#include <sys/proc.h>
  #include <sys/protosw.h>
  #include <sys/sigio.h>
+#include <sys/signal.h>
+#include <sys/signalvar.h>
  #include <sys/socket.h>
  #include <sys/socketvar.h>
  #include <sys/filio.h>			/* XXX */
@@ -115,6 +118,13 @@
  	error = so->so_proto->pr_usrreqs->pru_sosend(so, 0, uio, 0, 0, 0,
  						    uio->uio_td);
  	NET_UNLOCK_GIANT();
+
+	/* Generation of SIGPIPE can be controlled per socket */
+	if (error == EPIPE && !(so->so_options & SO_NOSIGPIPE)) {
+		PROC_LOCK(td->td_proc);
+		psignal(td->td_proc, SIGPIPE);
+		PROC_UNLOCK(td->td_proc);
+	}
  	return (error);
  }
>Release-Note:
>Audit-Trail:
Responsible-Changed-From-To: freebsd-bugs->rwatson 
Responsible-Changed-By: glebius 
Responsible-Changed-When: Wed Mar 9 10:54:36 GMT 2005 
Responsible-Changed-Why:  
I think Robert is right person to pass this PR to. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=78478 

From: Robert Watson <rwatson@FreeBSD.org>
To: Gleb Smirnoff <glebius@FreeBSD.org>
Cc: freebsd-gnats-submit@FreeBSD.org, alfred@FreeBSD.org
Subject: Re: kern/78478: writing to closed socket does not generate SIGPIPE
Date: Wed, 9 Mar 2005 11:36:32 +0000 (GMT)

 On Wed, 9 Mar 2005, Gleb Smirnoff wrote:
 
 > Synopsis: writing to closed socket does not generate SIGPIPE
 > 
 > Responsible-Changed-From-To: freebsd-bugs->rwatson
 > Responsible-Changed-By: glebius
 > Responsible-Changed-When: Wed Mar 9 10:54:36 GMT 2005
 > Responsible-Changed-Why: 
 > I think Robert is right person to pass this PR to.
 > 
 > http://www.freebsd.org/cgi/query-pr.cgi?pr=78478
 
 It looks like this bug was introduced in the following change:
 
   revision 1.103
   date: 2002/06/20 18:52:54;  author: alfred;  state: Exp;  lines: +2 -1
   Implement SO_NOSIGPIPE option for sockets.  This allows one to request
   that an EPIPE error return not generate SIGPIPE on sockets.
 
   Submitted by: lioux
   Inspired by: Darwin
 
 This moves the responsibility for generating the SIGPIPE into the socket
 layer, but seems not to modify the socket layer to generate SIGPIPE.  I've
 CC'd Alfred since this was his commit, since I'm wondering if I missed a
 sibling commit that was intended to do the other half, or if perhaps he
 did.  The proposed patch to add SIGPIPE support to soo_write probably is
 the right answer, but I want to make sure I understand the Big Picture
 (tm) before introducing a change.
 
 Robert N M Watson
 
 

From: Alfred Perlstein <alfred@freebsd.org>
To: Robert Watson <rwatson@FreeBSD.org>
Cc: Gleb Smirnoff <glebius@FreeBSD.org>,
	freebsd-gnats-submit@FreeBSD.org
Subject: Re: kern/78478: writing to closed socket does not generate SIGPIPE
Date: Wed, 9 Mar 2005 04:35:07 -0800

 * Robert Watson <rwatson@FreeBSD.org> [050309 03:38] wrote:
 > 
 > On Wed, 9 Mar 2005, Gleb Smirnoff wrote:
 > 
 > > Synopsis: writing to closed socket does not generate SIGPIPE
 > > 
 > > Responsible-Changed-From-To: freebsd-bugs->rwatson
 > > Responsible-Changed-By: glebius
 > > Responsible-Changed-When: Wed Mar 9 10:54:36 GMT 2005
 > > Responsible-Changed-Why: 
 > > I think Robert is right person to pass this PR to.
 > > 
 > > http://www.freebsd.org/cgi/query-pr.cgi?pr=78478
 > 
 > It looks like this bug was introduced in the following change:
 > 
 >   revision 1.103
 >   date: 2002/06/20 18:52:54;  author: alfred;  state: Exp;  lines: +2 -1
 >   Implement SO_NOSIGPIPE option for sockets.  This allows one to request
 >   that an EPIPE error return not generate SIGPIPE on sockets.
 > 
 >   Submitted by: lioux
 >   Inspired by: Darwin
 > 
 > This moves the responsibility for generating the SIGPIPE into the socket
 > layer, but seems not to modify the socket layer to generate SIGPIPE.  I've
 > CC'd Alfred since this was his commit, since I'm wondering if I missed a
 > sibling commit that was intended to do the other half, or if perhaps he
 > did.  The proposed patch to add SIGPIPE support to soo_write probably is
 > the right answer, but I want to make sure I understand the Big Picture
 > (tm) before introducing a change.
 
 I must have missed the logic to do so.
 
 There's a couple of ways to fix this:
 
 1) fix dofilewrite() to grovel into the socket and check for the option
    instead of bailing when seeing fp->f_type != DTYPE_SOCKET.
 2) fix soo_write()
 3) fix uipc_socket.c:sosend()
 
 Which one do you like?
 
 At a glance I think I like #1.
 
 If you do #2 or #3 it changes the kernel API.
 
 -- 
 - Alfred Perlstein
 - Research Engineering Development Inc.
 - email: bright@mu.org cell: 408-480-4684

From: Robert Watson <rwatson@FreeBSD.org>
To: Alfred Perlstein <alfred@freebsd.org>
Cc: Gleb Smirnoff <glebius@FreeBSD.org>,
	freebsd-gnats-submit@FreeBSD.org
Subject: Re: kern/78478: writing to closed socket does not generate SIGPIPE
Date: Wed, 9 Mar 2005 13:14:09 +0000 (GMT)

 On Wed, 9 Mar 2005, Alfred Perlstein wrote:
 
 > > This moves the responsibility for generating the SIGPIPE into the socket
 > > layer, but seems not to modify the socket layer to generate SIGPIPE.  I've
 > > CC'd Alfred since this was his commit, since I'm wondering if I missed a
 > > sibling commit that was intended to do the other half, or if perhaps he
 > > did.  The proposed patch to add SIGPIPE support to soo_write probably is
 > > the right answer, but I want to make sure I understand the Big Picture
 > > (tm) before introducing a change.
 > 
 > I must have missed the logic to do so. 
 > 
 > There's a couple of ways to fix this: 
 > 
 > 1) fix dofilewrite() to grovel into the socket and check for the option
 >    instead of bailing when seeing fp->f_type != DTYPE_SOCKET.
 > 2) fix soo_write()
 > 3) fix uipc_socket.c:sosend()
 > 
 > Which one do you like?
 > 
 > At a glance I think I like #1. 
 > 
 > If you do #2 or #3 it changes the kernel API. 
 
 The only one I have a concrete objection to is (3), as sosend() is used by
 a lot of code other than the write() system call, and that code may not
 {want, expect} to generate SIGPIPE.  Continuing to have sosend() return
 EPIPE makes sense to me, as it allows the caller to decide on the error
 handling path -- generate a signal or not as it sees fit. 
 
 Similar objections probably apply at the soo_write() layer also: although
 fo_write() is less widely used, it may see more use now that there is
 vnode bypass for various file descriptor types.
 
 I guess this leaves (1) above -- I'm a little uncomfortable with the file
 descriptor layer reaching down to read socket options, but it probably is
 the lesser of three evils.  It seems something of a pity to me that
 SO_NOSIGPIPE is a socket option and not an option on the file
 descriptor...
 
 Robert N M Watson
 
 

From: Giorgos Keramidas <keramida@freebsd.org>
To: Robert Watson <rwatson@freebsd.org>
Cc: bug-followup@freebsd.org
Subject: Re: kern/78478: Writing to closed socket does not generate SIGPIPE
Date: Wed, 9 Mar 2005 16:09:18 +0200

 Robert Watson wrote:
 >On Wed, 9 Mar 2005, Alfred Perlstein wrote:
 >>> This moves the responsibility for generating the SIGPIPE into the
 >>> socket layer, but seems not to modify the socket layer to generate
 >>> SIGPIPE.  I've CC'd Alfred since this was his commit, since I'm
 >>> wondering if I missed a sibling commit that was intended to do the
 >>> other half, or if perhaps he did.  The proposed patch to add
 >>> SIGPIPE support to soo_write probably is the right answer, but I
 >>> want to make sure I understand the Big Picture (tm) before
 >>> introducing a change.
 >>
 >> I must have missed the logic to do so.
 >>
 >> There's a couple of ways to fix this:
 >>
 >> 1) fix dofilewrite() to grovel into the socket and check for the option
 >>    instead of bailing when seeing fp->f_type != DTYPE_SOCKET.
 >> 2) fix soo_write()
 >> 3) fix uipc_socket.c:sosend()
 >>
 >> Which one do you like?
 >>
 >> At a glance I think I like #1.
 >>
 >> If you do #2 or #3 it changes the kernel API.
 >
 > The only one I have a concrete objection to is (3), as sosend() is
 > used by a lot of code other than the write() system call, and that
 > code may not {want, expect} to generate SIGPIPE.  Continuing to have
 > sosend() return EPIPE makes sense to me, as it allows the caller to
 > decide on the error handling path -- generate a signal or not as it
 > sees fit.
 >
 > Similar objections probably apply at the soo_write() layer also:
 > although fo_write() is less widely used, it may see more use now that
 > there is vnode bypass for various file descriptor types.
 >
 > I guess this leaves (1) above -- I'm a little uncomfortable with the
 > file descriptor layer reaching down to read socket options, but it
 > probably is the lesser of three evils.  It seems something of a pity
 > to me that SO_NOSIGPIPE is a socket option and not an option on the
 > file descriptor...
 
 How would that be made tunable for file descriptors though?
 
 The natural place seems fcntl(), but there is currently no mention of
 SIGPIPE in the fcntl() interface.  We'd have to add something to fcntl()
 for this, but it would immediately be an unportable extension of FreeBSD.
 
 SuSv2 and SUSv3 only specify a SIGPIPE signal for write requests on pipes
 or fifos.  No mention of a signal is made for sockets :-(
 

From: Robert Watson <rwatson@FreeBSD.org>
To: Giorgos Keramidas <keramida@freebsd.org>
Cc: bug-followup@freebsd.org
Subject: Re: kern/78478: Writing to closed socket does not generate SIGPIPE
Date: Wed, 9 Mar 2005 14:20:09 +0000 (GMT)

 On Wed, 9 Mar 2005, Giorgos Keramidas wrote:
 
 > > I guess this leaves (1) above -- I'm a little uncomfortable with the
 > > file descriptor layer reaching down to read socket options, but it
 > > probably is the lesser of three evils.  It seems something of a pity
 > > to me that SO_NOSIGPIPE is a socket option and not an option on the
 > > file descriptor...
 > 
 > How would that be made tunable for file descriptors though?
 > 
 > The natural place seems fcntl(), but there is currently no mention of
 > SIGPIPE in the fcntl() interface.  We'd have to add something to fcntl() 
 > for this, but it would immediately be an unportable extension of
 > FreeBSD. 
 > 
 > SuSv2 and SUSv3 only specify a SIGPIPE signal for write requests on
 > pipes or fifos.  No mention of a signal is made for sockets :-(
 
 Yeah, I don't suggest adding it to fcntl(), I was just pondering that it
 might make more sense there.  Note also that there's another semantic nit
 in our SIGPIPE code, which might or might not be resolved the same way on
 other platforms: we deliver SIGPIPE to the process that is performing the
 write, but not necessarily the thread.
 
 Robert N M Watson
 
 

From: Alfred Perlstein <alfred@freebsd.org>
To: Robert Watson <rwatson@FreeBSD.org>
Cc: Gleb Smirnoff <glebius@FreeBSD.org>,
	freebsd-gnats-submit@FreeBSD.org
Subject: Re: kern/78478: writing to closed socket does not generate SIGPIPE
Date: Wed, 9 Mar 2005 09:14:59 -0800

 * Robert Watson <rwatson@FreeBSD.org> [050309 05:16] wrote:
 > 
 > On Wed, 9 Mar 2005, Alfred Perlstein wrote:
 > 
 > > I must have missed the logic to do so. 
 > > 
 > > There's a couple of ways to fix this: 
 > > 
 > > 1) fix dofilewrite() to grovel into the socket and check for the option
 > >    instead of bailing when seeing fp->f_type != DTYPE_SOCKET.
 > > 2) fix soo_write()
 > > 3) fix uipc_socket.c:sosend()
 > > 
 > > Which one do you like?
 > > 
 > > At a glance I think I like #1. 
 > > 
 > > If you do #2 or #3 it changes the kernel API. 
 > 
 > The only one I have a concrete objection to is (3), as sosend() is used by
 > a lot of code other than the write() system call, and that code may not
 > {want, expect} to generate SIGPIPE.  Continuing to have sosend() return
 > EPIPE makes sense to me, as it allows the caller to decide on the error
 > handling path -- generate a signal or not as it sees fit. 
 > 
 > Similar objections probably apply at the soo_write() layer also: although
 > fo_write() is less widely used, it may see more use now that there is
 > vnode bypass for various file descriptor types.
 
 So we agree.
 
 > I guess this leaves (1) above -- I'm a little uncomfortable with the file
 > descriptor layer reaching down to read socket options, but it probably is
 > the lesser of three evils.  It seems something of a pity to me that
 > SO_NOSIGPIPE is a socket option and not an option on the file
 > descriptor...
 
 Agreed, but we need to do it.
 
 The reason I brought the code in the first place was because jkh
 asked me to in order to conform with Darwin.
 
 
 -- 
 - Alfred Perlstein
 - Research Engineering Development Inc.
 - email: bright@mu.org cell: 408-480-4684

From: Robert Watson <rwatson@FreeBSD.org>
To: Alfred Perlstein <alfred@freebsd.org>
Cc: Gleb Smirnoff <glebius@FreeBSD.org>,
	freebsd-gnats-submit@FreeBSD.org
Subject: Re: kern/78478: writing to closed socket does not generate SIGPIPE
Date: Thu, 10 Mar 2005 13:01:16 +0000 (GMT)

 On Wed, 9 Mar 2005, Alfred Perlstein wrote:
 
 > > Similar objections probably apply at the soo_write() layer also: although
 > > fo_write() is less widely used, it may see more use now that there is
 > > vnode bypass for various file descriptor types.
 > 
 > So we agree.
 > 
 > > I guess this leaves (1) above -- I'm a little uncomfortable with the file
 > > descriptor layer reaching down to read socket options, but it probably is
 > > the lesser of three evils.  It seems something of a pity to me that
 > > SO_NOSIGPIPE is a socket option and not an option on the file
 > > descriptor...
 > 
 > Agreed, but we need to do it.
 > 
 > The reason I brought the code in the first place was because jkh
 > asked me to in order to conform with Darwin.
 
 This sounds like a plan.  You might want to file a radar if Darwin has the
 same problem?
 
 Also, we should get a copy of two regression tests in the tree: one that
 tests that SIGPIPE works for each of the write mechanisms of interest
 (write, send, sendfile), and a second that checks, given that SIGPIPE
 works, that disabling SIGPIPE with the socket option also works.
 
 Robert N M Watson
 
 

From: Robert Watson <rwatson@FreeBSD.org>
To: freebsd-gnats-submit@FreeBSD.org
Cc:  
Subject: Re: kern/78478: writing to closed socket does not generate SIGPIPE
Date: Fri, 11 Mar 2005 14:40:51 +0000 (GMT)

 Some followups:
 
 On Thu, 10 Mar 2005, Robert Watson wrote:
 
 >  This sounds like a plan.  You might want to file a radar if Darwin has the
 >  same problem?
 
 Darwin does not have the same bug, it generates the signal from
 soo_write() if needed. 
 
 >  Also, we should get a copy of two regression tests in the tree: one that
 >  tests that SIGPIPE works for each of the write mechanisms of interest
 >  (write, send, sendfile), and a second that checks, given that SIGPIPE
 >  works, that disabling SIGPIPE with the socket option also works.
 
 I have committed src/tools/regression/sockets/sigpipe, which tests various
 cases against UNIX domain and TCP sockets.  It currently passes in
 RELENG_4 and fails in HEAD and RELENG_5.
 
 On further looking at the issue, I think modifying soo_write() is the
 easiest approach to getting this fixed -- this also matches the Darwin
 approach.
 
 The one sticky issue has to do with which thread/proc argument to use. 
 soo_write() accepts a thread argument from the caller, but is also passed
 a thread in the uio structure.  We pass the uio thread down to
 pru_sosend().  Darwin uses the process from the uio pointer, and we should
 probably do that also, although it's a bit more messy than using the
 thread argument.  I'm not 100% sure what the duplicate thread pointers
 accomplish.
 
 Robert N M Watson
 
 
State-Changed-From-To: open->patched 
State-Changed-By: rwatson 
State-Changed-When: Fri Mar 11 15:06:50 GMT 2005 
State-Changed-Why:  
Move to patched state as a fix has been committed as sys_socket.c:1.67 
based on this patch.  Please see the commit message for details. 

A regression test has been committed as src/tools/regression/sockets/ 
sigpipe. 

I've scheduled an MFC after one week. 


http://www.freebsd.org/cgi/query-pr.cgi?pr=78478 

From: Matteo Riondato <matteo@FreeBSD.ORG>
To: bug-followup@FreeBSD.org, mbsd@pacbell.net
Cc:  
Subject: Re: kern/78478: writing to closed socket does not generate SIGPIPE
Date: Fri, 26 Aug 2005 14:05:19 +0200

 The regression test has not been MFCed yet. Robert, can you please do it
 so this PR can be closed? Thanks.
 Best Regards
 -- 
 Matteo Riondato
 FreeBSD Volunteer (http://www.FreeBSD.org/)
 GUFI Staff Member (http://www.GUFI.org/)
 FreeSBIE Developer (http://www.FreeSBIE.org/)
Responsible-Changed-From-To: rwatson->bms 
Responsible-Changed-By: bms 
Responsible-Changed-When: Mon Mar 5 10:51:34 UTC 2007 
Responsible-Changed-Why:  
I fixed the bug in the bug fix for this last week. ;-) 

http://www.freebsd.org/cgi/query-pr.cgi?pr=78478 
State-Changed-From-To: patched->closed 
State-Changed-By: bms 
State-Changed-When: Mon Mar 5 11:15:38 UTC 2007 
State-Changed-Why:  
regression test was mfc'd 

http://www.freebsd.org/cgi/query-pr.cgi?pr=78478 

From: dfilter@FreeBSD.ORG (dfilter service)
To: bug-followup@FreeBSD.org
Cc:  
Subject: Re: kern/78478: commit references a PR
Date: Mon,  5 Mar 2007 11:17:39 +0000 (UTC)

 bms         2007-03-05 11:17:31 UTC
 
   FreeBSD src repository
 
   Modified files:        (Branch: RELENG_6)
     sys/kern             sys_generic.c 
   Log:
   MFC rev 1.152:
     Do not dispatch SIGPIPE from the generic write path for a socket; with
     this patch the code behaves according to the comment on the line above.
   
     Without this patch, a socket could cause SIGPIPE to be delivered to its
     process, once with SO_NOSIGPIPE set, and twice without.
   
   With this patch, the kernel now passes the sigpipe regression test in
   both HEAD and RELENG_6.
   
   PR:             78478 (the bug fix for this PR introduced this bug)
   Tested by:      Anton Yuzhaninov
   Reviewed by:    jhb
   
   Revision   Changes    Path
   1.146.2.2  +1 -1      src/sys/kern/sys_generic.c
 _______________________________________________
 cvs-all@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/cvs-all
 To unsubscribe, send any mail to "cvs-all-unsubscribe@freebsd.org"
 
>Unformatted:
