From nobody@FreeBSD.org  Tue Jan 29 18:03:45 2013
Return-Path: <nobody@FreeBSD.org>
Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115])
	by hub.freebsd.org (Postfix) with ESMTP id 7FC06CC2
	for <freebsd-gnats-submit@FreeBSD.org>; Tue, 29 Jan 2013 18:03:45 +0000 (UTC)
	(envelope-from nobody@FreeBSD.org)
Received: from red.freebsd.org (red.freebsd.org [IPv6:2001:4f8:fff6::22])
	by mx1.freebsd.org (Postfix) with ESMTP id 7044FD65
	for <freebsd-gnats-submit@FreeBSD.org>; Tue, 29 Jan 2013 18:03:45 +0000 (UTC)
Received: from red.freebsd.org (localhost [127.0.0.1])
	by red.freebsd.org (8.14.5/8.14.5) with ESMTP id r0TI3hIB088949
	for <freebsd-gnats-submit@FreeBSD.org>; Tue, 29 Jan 2013 18:03:43 GMT
	(envelope-from nobody@red.freebsd.org)
Received: (from nobody@localhost)
	by red.freebsd.org (8.14.5/8.14.5/Submit) id r0TI3h2A088948;
	Tue, 29 Jan 2013 18:03:43 GMT
	(envelope-from nobody)
Message-Id: <201301291803.r0TI3h2A088948@red.freebsd.org>
Date: Tue, 29 Jan 2013 18:03:43 GMT
From: Jukka Ukkonen <jau@iki.fi>
To: freebsd-gnats-submit@FreeBSD.org
Subject: sem_open() should use O_EXLOCK with open() instead of a separate flock() call
X-Send-Pr-Version: www-3.1
X-GNATS-Notify:

>Number:         175674
>Category:       kern
>Synopsis:       [libc] [patch] sem_open() should use O_EXLOCK with open() instead of a separate flock() call
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    freebsd-bugs
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          change-request
>Submitter-Id:   current-users
>Arrival-Date:   Tue Jan 29 18:10:00 UTC 2013
>Closed-Date:    Sun Apr 13 21:25:00 UTC 2014
>Last-Modified:  Sun Apr 13 21:25:00 UTC 2014
>Originator:     Jukka Ukkonen
>Release:        9.1-STABLE
>Organization:
-----
>Environment:
FreeBSD sleipnir 9.1-STABLE FreeBSD 9.1-STABLE #2 r246056M: Tue Jan 29 07:33:01 EET 2013     root@sleipnir:/usr/obj/usr/src/sys/Sleipnir  amd64
>Description:
sem_open() is calling flock() to set a lock on a newly created file descriptor.
That is pointless. The open() call a few lines before the flock() could, and
in my opinion should, be done with the O_EXLOCK flag set.

>How-To-Repeat:
See "full description" above.
>Fix:
Simply apply the attached patch.
Notice, though, that the patch assumes kern/170369 has been applied first.


Patch attached with submission follows:

--- lib/libc/gen/sem_new.c.flock	2012-11-09 18:50:05.000000000 +0200
+++ lib/libc/gen/sem_new.c	2012-11-09 18:44:59.000000000 +0200
@@ -198,11 +198,13 @@
 		goto error;
 	}
 
-	fd = _open(path, flags|O_RDWR|O_CLOEXEC, mode);
+	fd = _open(path, flags|O_RDWR|O_CLOEXEC|O_EXLOCK, mode);
 	if (fd == -1)
 		goto error;
+#if 0
 	if (flock(fd, LOCK_EX) == -1)
 		goto error;
+#endif
 	if (_fstat(fd, &sb)) {
 		flock(fd, LOCK_UN);
 		goto error;


>Release-Note:
>Audit-Trail:

From: Giorgos Keramidas <keramida@FreeBSD.org>
To: Jukka Ukkonen <jau@iki.fi>
Cc: freebsd-gnats-submit@FreeBSD.org, jilles@FreeBSD.org,
	davidxu@FreeBSD.org
Subject: Re: kern/175674: sem_open() should use O_EXLOCK with open() instead
 of a separate flock() call
Date: Sun, 3 Feb 2013 06:25:25 +0100

 On 2013-01-29 18:03, Jukka Ukkonen <jau@iki.fi> wrote:
 > >Number:         175674
 > >Category:       kern
 > >Synopsis:       sem_open() should use O_EXLOCK with open() instead of a separate flock() call
 
 > >Environment:
 > FreeBSD sleipnir 9.1-STABLE FreeBSD 9.1-STABLE #2 r246056M: Tue Jan 29 07:33:01 EET 2013     root@sleipnir:/usr/obj/usr/src/sys/Sleipnir  amd64
 > >Description:
 > sem_open() is calling flock() to set a lock on a newly created file descriptor.
 > That is pointless. The open() call a few lines before the flock() could, and
 > in my opinion should, be done with the O_EXLOCK flag set.
 
 It's also a bit safer to obtain the exclusive lock atomically before
 open() returns. Waiting for open() to complete and then calling flock()
 has a race condition.
 
 Jilles and David, do you think this patch looks ok for libc?
 
 > Patch attached with submission follows:
 > 
 > --- lib/libc/gen/sem_new.c.flock	2012-11-09 18:50:05.000000000 +0200
 > +++ lib/libc/gen/sem_new.c	2012-11-09 18:44:59.000000000 +0200
 > @@ -198,11 +198,13 @@
 >  		goto error;
 >  	}
 >  
 > -	fd = _open(path, flags|O_RDWR|O_CLOEXEC, mode);
 > +	fd = _open(path, flags|O_RDWR|O_CLOEXEC|O_EXLOCK, mode);
 >  	if (fd == -1)
 >  		goto error;
 > +#if 0
 >  	if (flock(fd, LOCK_EX) == -1)
 >  		goto error;
 > +#endif
 >  	if (_fstat(fd, &sb)) {
 >  		flock(fd, LOCK_UN);
 >  		goto error;
 

From: Eitan Adler <lists@eitanadler.com>
To: Giorgos Keramidas <keramida@freebsd.org>
Cc: freebsd-bugs@freebsd.org, bug-followup <bug-followup@freebsd.org>
Subject: Re: kern/175674: sem_open() should use O_EXLOCK with open() instead
 of a separate flock() call
Date: Sun, 3 Feb 2013 01:18:17 -0500

 On 3 February 2013 00:30, Giorgos Keramidas <keramida@freebsd.org> wrote:
 >  Jilles and David, do you think this patch looks ok for libc?
 
 Why bother keeping the contents of the #if 0?  Remove it.  Then it
 looks good to me.
 
 
 -- 
 Eitan Adler

From: Jilles Tjoelker <jilles@stack.nl>
To: Giorgos Keramidas <keramida@FreeBSD.org>
Cc: Jukka Ukkonen <jau@iki.fi>, freebsd-gnats-submit@FreeBSD.org,
	davidxu@FreeBSD.org
Subject: Re: kern/175674: sem_open() should use O_EXLOCK with open() instead
 of a separate flock() call
Date: Sun, 3 Feb 2013 21:20:31 +0100

 On Sun, Feb 03, 2013 at 06:25:25AM +0100, Giorgos Keramidas wrote:
 > On 2013-01-29 18:03, Jukka Ukkonen <jau@iki.fi> wrote:
 > > >Number:         175674
 > > >Category:       kern
 > > >Synopsis:       sem_open() should use O_EXLOCK with open() instead of a separate flock() call
 > 
 > > >Environment:
 > > FreeBSD sleipnir 9.1-STABLE FreeBSD 9.1-STABLE #2 r246056M: Tue Jan 29 07:33:01 EET 2013     root@sleipnir:/usr/obj/usr/src/sys/Sleipnir  amd64
 > > >Description:
 > > sem_open() is calling flock() to set a lock on a newly created file descriptor.
 > > That is pointless. The open() call a few lines before the flock() could, and
 > > in my opinion should, be done with the O_EXLOCK flag set.
 
 > It's also a bit safer to obtain the exclusive lock atomically before
 > open() returns. Waiting for open() to complete and then calling flock()
 > has a race condition.
 
 > Jilles and David, do you think this patch looks ok for libc?
 
 > > Patch attached with submission follows:
 > > 
 > > --- lib/libc/gen/sem_new.c.flock	2012-11-09 18:50:05.000000000 +0200
 > > +++ lib/libc/gen/sem_new.c	2012-11-09 18:44:59.000000000 +0200
 > > @@ -198,11 +198,13 @@
 > >  		goto error;
 > >  	}
 > >  
 > > -	fd = _open(path, flags|O_RDWR|O_CLOEXEC, mode);
 > > +	fd = _open(path, flags|O_RDWR|O_CLOEXEC|O_EXLOCK, mode);
 > >  	if (fd == -1)
 > >  		goto error;
 > > +#if 0
 > >  	if (flock(fd, LOCK_EX) == -1)
 > >  		goto error;
 > > +#endif
 > >  	if (_fstat(fd, &sb)) {
 > >  		flock(fd, LOCK_UN);
 > >  		goto error;
 
 For a reason unknown to me, open(2) does not restart but always returns
 [EINTR] when a signal is caught. This is not POSIX-compliant. On the
 other hand, flock(2) is not broken in this way. So this change breaks
 sem_open(3) in the unlikely case that a signal with SA_RESTART arrives
 while it is waiting for the lock.
 
 The best way to fix this is in kern_openat() in the kernel but this
 might cause compatibility issues.
 
 The #if 0 is silly; we have version control to restore old code if need
 be.
 
 -- 
 Jilles Tjoelker

From: Giorgos Keramidas <keramida@FreeBSD.org>
To: Jilles Tjoelker <jilles@stack.nl>
Cc: Jukka Ukkonen <jau@iki.fi>, freebsd-gnats-submit@FreeBSD.org,
	davidxu@FreeBSD.org
Subject: Re: kern/175674: sem_open() should use O_EXLOCK with open() instead
 of a separate flock() call
Date: Sun, 3 Feb 2013 21:49:55 +0100

 On 2013-02-03 21:20, Jilles Tjoelker <jilles@stack.nl> wrote:
 > On Sun, Feb 03, 2013 at 06:25:25AM +0100, Giorgos Keramidas wrote:
 > > On 2013-01-29 18:03, Jukka Ukkonen <jau@iki.fi> wrote:
 > > > >Number:         175674
 > > > >Category:       kern
 > > > >Synopsis:       sem_open() should use O_EXLOCK with open() instead of a separate flock() call
 > > 
 > > > >Environment:
 > > > FreeBSD sleipnir 9.1-STABLE FreeBSD 9.1-STABLE #2 r246056M: Tue Jan 29 07:33:01 EET 2013     root@sleipnir:/usr/obj/usr/src/sys/Sleipnir  amd64
 > > > >Description:
 > > > sem_open() is calling flock() to set a lock on a newly created file descriptor.
 > > > That is pointless. The open() call a few lines before the flock() could, and
 > > > in my opinion should, be done with the O_EXLOCK flag set.
 > 
 > > It's also a bit safer to obtain the exclusive lock atomically before
 > > open() returns. Waiting for open() to complete and then calling flock()
 > > has a race condition.
 > 
 > > Jilles and David, do you think this patch looks ok for libc?
 > 
 > > > Patch attached with submission follows:
 > > > 
 > > > --- lib/libc/gen/sem_new.c.flock	2012-11-09 18:50:05.000000000 +0200
 > > > +++ lib/libc/gen/sem_new.c	2012-11-09 18:44:59.000000000 +0200
 > > > @@ -198,11 +198,13 @@
 > > >  		goto error;
 > > >  	}
 > > >  
 > > > -	fd = _open(path, flags|O_RDWR|O_CLOEXEC, mode);
 > > > +	fd = _open(path, flags|O_RDWR|O_CLOEXEC|O_EXLOCK, mode);
 > > >  	if (fd == -1)
 > > >  		goto error;
 > > > +#if 0
 > > >  	if (flock(fd, LOCK_EX) == -1)
 > > >  		goto error;
 > > > +#endif
 > > >  	if (_fstat(fd, &sb)) {
 > > >  		flock(fd, LOCK_UN);
 > > >  		goto error;
 > 
 > For a reason unknown to me, open(2) does not restart but always
 > returns [EINTR] when a signal is caught. This is not POSIX-compliant.
 > On the other hand, flock(2) is not broken in this way. So this change
 > breaks sem_open(3) in the unlikely case that a signal with SA_RESTART
 > arrives while it is waiting for the lock.
 
 I see where kern_openat() returns an error when vn_open is interrupted:
 
 1083         error = vn_open(&nd, &flags, cmode, fp);
 1084         if (error) {
 ....
 1109                 if (error == ERESTART)
 1110                         error = EINTR;
 1111                 goto bad;
 1112         }
 
 > The best way to fix this is in kern_openat() in the kernel but this
 > might cause compatibility issues.
 
 Not sure if there would be serious compatibility problems if open() would
 automatically restart instead of returning EINTR.  It definitely seems a rather
 intrusive change though.
 
 > The #if 0 is silly; we have version control to restore old code if
 > need be.
 
 That's true.  I'm guessing the OP wanted to keep this around for testing
 purposes.  We don't really need the old code in an #if 0 block.
 

From: David Xu <davidxu@freebsd.org>
To: Jilles Tjoelker <jilles@stack.nl>
Cc: Giorgos Keramidas <keramida@FreeBSD.org>, Jukka Ukkonen <jau@iki.fi>,
        freebsd-gnats-submit@FreeBSD.org
Subject: Re: kern/175674: sem_open() should use O_EXLOCK with open() instead
 of a separate flock() call
Date: Mon, 04 Feb 2013 10:08:54 +0800

 On 2013/02/04 04:20, Jilles Tjoelker wrote:
 > On Sun, Feb 03, 2013 at 06:25:25AM +0100, Giorgos Keramidas wrote:
 >> On 2013-01-29 18:03, Jukka Ukkonen <jau@iki.fi> wrote:
 >>>> Number:         175674
 >>>> Category:       kern
 >>>> Synopsis:       sem_open() should use O_EXLOCK with open() instead of a separate flock() call
 >>
 >>>> Environment:
 >>> FreeBSD sleipnir 9.1-STABLE FreeBSD 9.1-STABLE #2 r246056M: Tue Jan 29 07:33:01 EET 2013     root@sleipnir:/usr/obj/usr/src/sys/Sleipnir  amd64
 >>>> Description:
 >>> sem_open() is calling flock() to set a lock on a newly created file descriptor.
 >>> That is pointless. The open() call a few lines before the flock() could, and
 >>> in my opinion should, be done with the O_EXLOCK flag set.
 >
 >> It's also a bit safer to obtain the exclusive lock atomically before
 >> open() returns. Waiting for open() to complete and then calling flock()
 >> has a race condition.
 >
 >> Jilles and David, do you think this patch looks ok for libc?
 >
 >>> Patch attached with submission follows:
 >>>
 >>> --- lib/libc/gen/sem_new.c.flock	2012-11-09 18:50:05.000000000 +0200
 >>> +++ lib/libc/gen/sem_new.c	2012-11-09 18:44:59.000000000 +0200
 >>> @@ -198,11 +198,13 @@
 >>>   		goto error;
 >>>   	}
 >>>
 >>> -	fd = _open(path, flags|O_RDWR|O_CLOEXEC, mode);
 >>> +	fd = _open(path, flags|O_RDWR|O_CLOEXEC|O_EXLOCK, mode);
 >>>   	if (fd == -1)
 >>>   		goto error;
 >>> +#if 0
 >>>   	if (flock(fd, LOCK_EX) == -1)
 >>>   		goto error;
 >>> +#endif
 >>>   	if (_fstat(fd, &sb)) {
 >>>   		flock(fd, LOCK_UN);
 >>>   		goto error;
 >
 > For a reason unknown to me, open(2) does not restart but always returns
 > [EINTR] when a signal is caught. This is not POSIX-compliant. On the
 > other hand, flock(2) is not broken in this way. So this change breaks
 > sem_open(3) in the unlikely case that a signal with SA_RESTART arrives
 > while it is waiting for the lock.
 >
 > The best way to fix this is in kern_openat() in the kernel but this
 > might cause compatibility issues.
 >
 > The #if 0 is silly; we have version control to restore old code if need
 > be.
 >
 Note that EINTR is allowed to be returned for sem_open().
 http://pubs.opengroup.org/onlinepubs/009604499/functions/sem_open.html
 
 
 Regards,
 David Xu
 

From: David Xu <davidxu@freebsd.org>
To: Giorgos Keramidas <keramida@FreeBSD.org>
Cc: Jukka Ukkonen <jau@iki.fi>, freebsd-gnats-submit@FreeBSD.org,
        jilles@FreeBSD.org
Subject: Re: kern/175674: sem_open() should use O_EXLOCK with open() instead
 of a separate flock() call
Date: Mon, 04 Feb 2013 10:05:31 +0800

 On 2013/02/03 13:25, Giorgos Keramidas wrote:
 > On 2013-01-29 18:03, Jukka Ukkonen <jau@iki.fi> wrote:
 >>> Number:         175674
 >>> Category:       kern
 >>> Synopsis:       sem_open() should use O_EXLOCK with open() instead of a separate flock() call
 >
 >>> Environment:
 >> FreeBSD sleipnir 9.1-STABLE FreeBSD 9.1-STABLE #2 r246056M: Tue Jan 29 07:33:01 EET 2013     root@sleipnir:/usr/obj/usr/src/sys/Sleipnir  amd64
 >>> Description:
 >> sem_open() is calling flock() to set a lock on a newly created file descriptor.
 >> That is pointless. The open() call a few lines before the flock() could, and
 >> in my opinion should, be done with the O_EXLOCK flag set.
 >
 > It's also a bit safer to obtain the exclusive lock atomically before
 > open() returns. Waiting for open() to complete and then calling flock()
 > has a race condition.
 >
 > Jilles and David, do you think this patch looks ok for libc?
 >
 >> Patch attached with submission follows:
 >>
 >> --- lib/libc/gen/sem_new.c.flock	2012-11-09 18:50:05.000000000 +0200
 >> +++ lib/libc/gen/sem_new.c	2012-11-09 18:44:59.000000000 +0200
 >> @@ -198,11 +198,13 @@
 >>   		goto error;
 >>   	}
 >>
 >> -	fd = _open(path, flags|O_RDWR|O_CLOEXEC, mode);
 >> +	fd = _open(path, flags|O_RDWR|O_CLOEXEC|O_EXLOCK, mode);
 >>   	if (fd == -1)
 >>   		goto error;
 >> +#if 0
 >>   	if (flock(fd, LOCK_EX) == -1)
 >>   		goto error;
 >> +#endif
 >>   	if (_fstat(fd, &sb)) {
 >>   		flock(fd, LOCK_UN);
 >>   		goto error;
 >
 >
 I don't think there is a race condition, the flock is used to ensure
 the semaphore is already initialized, whether you use flock or E_EXLOCK,
 they are same, because only one thread can lock the file at same time,
 and in locked state, the code checks and initializes semaphore if it is
 needed.
 
 Regards,
 David Xu
 

From: Eitan Adler <lists@eitanadler.com>
To: bug-followup <bug-followup@freebsd.org>
Cc:  
Subject: Re: kern/175674: sem_open() should use O_EXLOCK with open() instead
 of a separate flock() call
Date: Sun, 3 Feb 2013 21:30:28 -0500

 ---------- Forwarded message ----------
 From: Eitan Adler <lists@eitanadler.com>
 Date: 3 February 2013 20:52
 Subject: Re: kern/175674: sem_open() should use O_EXLOCK with open()
 instead of a separate flock() call
 To: Giorgos Keramidas <keramida@freebsd.org>, Jilles Tjoelker <jilles@stack.nl>
 Cc: freebsd-bugs@freebsd.org
 
 
 On 3 February 2013 16:00, Giorgos Keramidas <keramida@freebsd.org> wrote:
 > The following reply was made to PR kern/175674; it has been noted by GNATS.
 >  > The best way to fix this is in kern_openat() in the kernel but this
 >  > might cause compatibility issues.
 >
 >  Not sure if there would be serious compatibility problems if open() would
 >  automatically restart instead of returning EINTR.  It definitely seems a rather
 >  intrusive change though.
 
 I can not see major application breakage should open(3) be changed.
 
 That said,  I am confused by jilles' comment:
 http://pubs.opengroup.org/onlinepubs/000095399/functions/open.html
 open(3) is permitted to return EINTR.
 
 --
 Eitan Adler
 
 
 -- 
 Eitan Adler

From: Jilles Tjoelker <jilles@stack.nl>
To: Giorgos Keramidas <keramida@FreeBSD.org>
Cc: Jukka Ukkonen <jau@iki.fi>, freebsd-gnats-submit@FreeBSD.org,
	davidxu@FreeBSD.org
Subject: Re: kern/175674: sem_open() should use O_EXLOCK with open() instead
 of a separate flock() call
Date: Tue, 12 Feb 2013 00:56:42 +0100

 On Sun, Feb 03, 2013 at 09:49:55PM +0100, Giorgos Keramidas wrote:
 > On 2013-02-03 21:20, Jilles Tjoelker <jilles@stack.nl> wrote:
 > > For a reason unknown to me, open(2) does not restart but always
 > > returns [EINTR] when a signal is caught. This is not POSIX-compliant.
 > > On the other hand, flock(2) is not broken in this way. So this change
 > > breaks sem_open(3) in the unlikely case that a signal with SA_RESTART
 > > arrives while it is waiting for the lock.
 
 > I see where kern_openat() returns an error when vn_open is interrupted:
 
 > 1083         error = vn_open(&nd, &flags, cmode, fp);
 > 1084         if (error) {
 > ....
 > 1109                 if (error == ERESTART)
 > 1110                         error = EINTR;
 > 1111                 goto bad;
 > 1112         }
 
 > > The best way to fix this is in kern_openat() in the kernel but this
 > > might cause compatibility issues.
 
 > Not sure if there would be serious compatibility problems if open()
 > would automatically restart instead of returning EINTR.  It definitely
 > seems a rather intrusive change though.
 
 As of r246472, open() is now sufficiently fixed that O_EXLOCK can be
 used.
 
 Although it is not a problem if a different thread than the file creator
 initializes the semaphore, the change reduces system calls and code
 size.
 
 On another note, the flock(fd, LOCK_UN) calls can go away because they
 are implicit in the close(fd).
 
 -- 
 Jilles Tjoelker

From: dfilter@FreeBSD.ORG (dfilter service)
To: bug-followup@FreeBSD.org
Cc:  
Subject: Re: kern/175674: commit references a PR
Date: Sat, 16 Feb 2013 06:07:16 +0000 (UTC)

 Author: davidxu
 Date: Sat Feb 16 06:07:07 2013
 New Revision: 246872
 URL: http://svnweb.freebsd.org/changeset/base/246872
 
 Log:
   Simplify code by using flag O_EXLOCK.
   
   PR: kern/175674
 
 Modified:
   head/lib/libc/gen/sem_new.c
 
 Modified: head/lib/libc/gen/sem_new.c
 ==============================================================================
 --- head/lib/libc/gen/sem_new.c	Sat Feb 16 05:22:48 2013	(r246871)
 +++ head/lib/libc/gen/sem_new.c	Sat Feb 16 06:07:07 2013	(r246872)
 @@ -198,15 +198,11 @@ _sem_open(const char *name, int flags, .
  		goto error;
  	}
  
 -	fd = _open(path, flags|O_RDWR|O_CLOEXEC, mode);
 +	fd = _open(path, flags|O_RDWR|O_CLOEXEC|O_EXLOCK, mode);
  	if (fd == -1)
  		goto error;
 -	if (flock(fd, LOCK_EX) == -1)
 +	if (_fstat(fd, &sb))
  		goto error;
 -	if (_fstat(fd, &sb)) {
 -		flock(fd, LOCK_UN);
 -		goto error;
 -	}
  	if (sb.st_size < sizeof(sem_t)) {
  		sem_t tmp;
  
 @@ -214,10 +210,8 @@ _sem_open(const char *name, int flags, .
  		tmp._kern._has_waiters = 0;
  		tmp._kern._count = value;
  		tmp._kern._flags = USYNC_PROCESS_SHARED | SEM_NAMED;
 -		if (_write(fd, &tmp, sizeof(tmp)) != sizeof(tmp)) {
 -			flock(fd, LOCK_UN);
 +		if (_write(fd, &tmp, sizeof(tmp)) != sizeof(tmp))
  			goto error;
 -		}
  	}
  	flock(fd, LOCK_UN);
  	sem = (sem_t *)mmap(NULL, sizeof(sem_t), PROT_READ|PROT_WRITE,
 _______________________________________________
 svn-src-all@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/svn-src-all
 To unsubscribe, send any mail to "svn-src-all-unsubscribe@freebsd.org"
 
State-Changed-From-To: open->closed 
State-Changed-By: jilles 
State-Changed-When: Sun Apr 13 21:24:03 UTC 2014 
State-Changed-Why:  
This was applied to 10-current. An MFC seems unnecessary to me. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=175674 
>Unformatted:
