Re: svn commit: r312296 - in head: lib/libc/sys sys/kern sys/netinet sys/netinet6 sys/sys tools/regression/sockets/udp_pingpong tools/regression/sockets/unix_cmsg

[Daniel Eischen]

On Tue, 17 Jan 2017, Maxim Sobolev wrote:


Also there is at least one thing that makes enum less desirable from the
point of view of application developer. Particularly it makes it impossible
to use preprocessor to do a conditional compilation, which is especially
important for the FreeBSD-specific options. With the "old" way, I can
easily have something like:

#if defined(SO_TS_CLOCK)
...
setsockopt(SO_TS_CLOCK, ...);
#else
[do something else]
#endif

This does not work with enums for obvious reasons, one would need to resort
to using some kind of autoconfigure mechanism to figure out if the enum in
question is defined.


Great point, we (at $JOB) have code that this, and would break
if changed to enums.

--
DE
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r302194 - head/lib/libthr/thread

[Daniel Eischen]

On Sat, 25 Jun 2016, Konstantin Belousov wrote:


On Sat, Jun 25, 2016 at 07:14:40PM +0200, Jilles Tjoelker wrote:

On Sat, Jun 25, 2016 at 11:30:40AM +, Konstantin Belousov wrote:

Author: kib
Date: Sat Jun 25 11:30:40 2016
New Revision: 302194
URL: https://svnweb.freebsd.org/changeset/base/302194



Log:
  For pthread_mutex_trylock() call on owned error-check or non-portable
  adaptive mutex, return EDEADLK as required by POSIX.  The
  pthread_mutex_lock() is already compliant.



  Tested by:Guy Yur 
  Sponsored by: The FreeBSD Foundation
  MFC after:2 weeks
  Approved by:  re (gjb)



Modified:
  head/lib/libthr/thread/thr_mutex.c



Modified: head/lib/libthr/thread/thr_mutex.c
==
--- head/lib/libthr/thread/thr_mutex.c  Sat Jun 25 10:08:04 2016
(r302193)
+++ head/lib/libthr/thread/thr_mutex.c  Sat Jun 25 11:30:40 2016
(r302194)
@@ -850,9 +850,12 @@ mutex_self_trylock(struct pthread_mutex

switch (PMUTEX_TYPE(m->m_flags)) {
case PTHREAD_MUTEX_ERRORCHECK:
-   case PTHREAD_MUTEX_NORMAL:
case PTHREAD_MUTEX_ADAPTIVE_NP:
-   ret = EBUSY;
+   ret = EDEADLK;
+   break;
+
+   case PTHREAD_MUTEX_NORMAL:
+   ret = EBUSY;
break;

case PTHREAD_MUTEX_RECURSIVE:


I think POSIX (SUSv4tc1, XSH 3 pthread_mutex_lock) is clear that only
pthread_mutex_lock() can fail with [EDEADLK], not
pthread_mutex_trylock(). Instead, the error [EBUSY] listed for
pthread_mutex_trylock() applies whenever the mutex could not be acquired
because it was already locked. This includes the case where the mutex is
owned by the current thread. Note that POSIX intends to allow not
storing the owning thread's ID in non-recursive non-robust mutexes.

Failing pthread_mutex_trylock() on owned mutexes only with [EBUSY] also
matches our code before this commit and NetBSD's code, and is apparently
expected by other code.

Therefore, I think this commit should be reverted.



I already asked re for approval of the reversal and got it.  But I am still
hesitating doing the revert vs. returning EDEADLK for error-checking
mutexes.

My initial mistake was reading the statement about PTHREAD_MUTEX_ERRORCHECK
returning EDEADLK as the requirement for both functions.  It was induced
by reading the following code in samba:
https://github.com/samba-team/samba/blob/master/lib/tdb/common/mutex.c#L928
I did extracted this into stand-alone test and checked that glibc does
return EDEADLK in this case.  BTW, if somebody has Solaris machine available
to test this, I would be grateful.  Code is available at
https://www.kib.kiev.ua/kib/pshared/pthread_samba.c

I.e., plain revert would disable the only known to me consumer of the
robust mutexes. The patch which I mailed last time, returns EDEADLK for
trylock on ERRORCHECKed mutexes only. And I am tending toward glibc
compatibility there, over the literal POSIX compliance, but I want to
see the confirmation from the Klimenko' test first.


That doesn't make glibc correct.  Unless the standards change,
we should return EBUSY in this case.  It is also unexpected if an
implementation's default mutex scheme is PTHREAD_MUTEX_ERRORCHECK
and it returns EDEADLK in this case.  It's not mentioned in the
standard, and no portable application will be expecting it.

--
DE
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r302194 - head/lib/libthr/thread

[Daniel Eischen]

On Sat, 25 Jun 2016, Konstantin Belousov wrote:


On Sat, Jun 25, 2016 at 07:03:46PM +0300, Ivan Klymenko wrote:

On Sat, 25 Jun 2016 18:20:06 +0300
Konstantin Belousov  wrote:

diff --git a/lib/libthr/thread/thr_mutex.c
b/lib/libthr/thread/thr_mutex.c index 2ad05ca..1ae75fb 100644
--- a/lib/libthr/thread/thr_mutex.c
+++ b/lib/libthr/thread/thr_mutex.c
@@ -850,10 +871,10 @@ mutex_self_trylock(struct pthread_mutex *m)

switch (PMUTEX_TYPE(m->m_flags)) {
case PTHREAD_MUTEX_ERRORCHECK:
-   case PTHREAD_MUTEX_ADAPTIVE_NP:
ret = EDEADLK;
break;

+   case PTHREAD_MUTEX_ADAPTIVE_NP:
case PTHREAD_MUTEX_NORMAL:
ret = EBUSY;
break;


Strange, it's not helped http://pastebin.com/jbzP0JW2


Are you sure that the new libthr was installed ?  Compile and run the
following test, please, and show me the results.  On the patched libthr,
the program must not output anything and exits with error code 0.


Sorry for not noticing and coming in late, but I think the
original change is wrong.  I don't see in the 2013 POSIX spec
or Solaris 11 man page (haven't checked Linux yet) where
pthread_mutex_trylock() returns EDEADLK under any
circumstance.

  
http://pubs.opengroup.org/onlinepubs/9699919799/functions/pthread_mutex_trylock.html
  
http://docs.oracle.com/cd/E23824_01/html/821-1465/pthread-mutex-trylock-3c.html#scrolltoc

--
DE
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r292723 - in head: lib/libc share/mk

[Daniel Eischen]

On Fri, 25 Dec 2015, Colin Percival wrote:


On 12/25/15 13:03, Daniel Eischen wrote:

On Fri, 25 Dec 2015, Ed Schouten wrote:

2015-12-25 12:29 GMT+01:00 Colin Percival <cperc...@freebsd.org>:

  Make libxnet.so a symlink to libc.so.  This makes `-lxnet` a no-op, as
  POSIX requires for the c99 compiler.


I seem to remember I had some issues in the past where I was linking
against libc explicitly. Maybe it had something to do with linking
both against -lpthread and -lc, but if you pass in -lc later on the
command line, libc overrides the symbols that have to be provided by
-lpthread?


I just did some tests with one of my pthread-using tools, and it passes
all of my tests with -lc added before or after -lpthread.  Can you
remember any details of how the problems showed up?  Is it possible that
this has been fixed since then?  I know there's a lot of tricks to make
sure that the right versions of functions get called.


If that's (still) the case, would it make sense to just provide
libxnet in the form of an empty .a file instead?


I think that's a good point.  Using -lanything shouldn't introduce an
unexpected link order.


Yes, adding a dummy library was my first thought, but kib pointed out
that a symlink was much simpler.  Obviously it never occurred to me that
linking to a library which we were going to be linking to anyway would
cause problems...


It is hard to contemplate a way this could cause problems (after
reading Konstantin's response with regard to threads).  The only
thought I have is if the application is trying to override libc
symbols (which are weak) with other weak symbols.  The first
weak wins.

--
DE
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r292723 - in head: lib/libc share/mk

[Daniel Eischen]

On Fri, 25 Dec 2015, Ed Schouten wrote:


Hi Colin,

First of all: I Am Not A Linker Expert.

2015-12-25 12:29 GMT+01:00 Colin Percival :

  Make libxnet.so a symlink to libc.so.  This makes `-lxnet` a no-op, as
  POSIX requires for the c99 compiler.


I seem to remember I had some issues in the past where I was linking
against libc explicitly. Maybe it had something to do with linking
both against -lpthread and -lc, but if you pass in -lc later on the
command line, libc overrides the symbols that have to be provided by
-lpthread?

If that's (still) the case, would it make sense to just provide
libxnet in the form of an empty .a file instead?


I think that's a good point.  Using -lanything shouldn't introduce an
unexpected link order.

--
DE
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

svn commit: r291440 - head/tests/sys/mqueue

[Daniel Eischen]

Author: deischen
Date: Sun Nov 29 06:16:25 2015
New Revision: 291440
URL: https://svnweb.freebsd.org/changeset/base/291440

Log:
  Disable a couple of tests, perhaps temporarily, since they use private
  symbols that are not exported from librt.

Modified:
  head/tests/sys/mqueue/Makefile

Modified: head/tests/sys/mqueue/Makefile
==
--- head/tests/sys/mqueue/Makefile  Sun Nov 29 06:14:51 2015
(r291439)
+++ head/tests/sys/mqueue/Makefile  Sun Nov 29 06:16:25 2015
(r291440)
@@ -10,8 +10,8 @@ CFLAGS+=  -I${SRCTOP}/tests
 
 PROGS+=mqtest1
 PROGS+=mqtest2
-PROGS+=mqtest3
-PROGS+=mqtest4
+#PROGS+=   mqtest3
+#PROGS+=   mqtest4
 PROGS+=mqtest5
 
 LDADD+=-lrt
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

svn commit: r291439 - head/lib/librt

[Daniel Eischen]

Author: deischen
Date: Sun Nov 29 06:14:51 2015
New Revision: 291439
URL: https://svnweb.freebsd.org/changeset/base/291439

Log:
  Unbreak symbol versioning.  I have no idea when it was broken, but it's been
  at least a few months if not a year or more.

Added:
  head/lib/librt/Symbol.map   (contents, props changed)
Deleted:
  head/lib/librt/Version.map
Modified:
  head/lib/librt/Makefile

Modified: head/lib/librt/Makefile
==
--- head/lib/librt/Makefile Sun Nov 29 05:49:49 2015(r291438)
+++ head/lib/librt/Makefile Sun Nov 29 06:14:51 2015(r291439)
@@ -17,7 +17,8 @@ SRCS+= aio.c mq.c sigev_thread.c timer.c
 
 PRECIOUSLIB=
 
-VERSION_MAP=   ${.CURDIR}/Version.map
+VERSION_DEF=${.CURDIR}/../libc/Versions.def
+SYMBOL_MAPS=${.CURDIR}/Symbol.map
 
 .if ${MK_TESTS} != "no"
 SUBDIR+=   tests

Added: head/lib/librt/Symbol.map
==
--- /dev/null   00:00:00 1970   (empty, because file is newly added)
+++ head/lib/librt/Symbol.map   Sun Nov 29 06:14:51 2015(r291439)
@@ -0,0 +1,69 @@
+/*
+ * $FreeBSD$
+ */
+
+FBSD_1.0 {
+   aio_read;
+   aio_write;
+   aio_return;
+   aio_waitcomplete;
+   aio_fsync;
+   mq_open;
+   mq_close;
+   mq_notify;
+   mq_getattr;
+   mq_setattr;
+   mq_timedreceive;
+   mq_timedsend;
+   mq_unlink;
+   mq_send;
+   mq_receive;
+   timer_create;
+   timer_delete;
+   timer_gettime;
+   timer_settime;
+   timer_getoverrun;
+};
+
+FBSDprivate_1.0 {
+   _aio_read;
+   _aio_write;
+   _aio_return;
+   _aio_waitcomplete;
+   _aio_fsync;
+   __aio_read;
+   __aio_write;
+   __aio_return;
+   __aio_waitcomplete;
+   __aio_fsync;
+   _mq_open;
+   _mq_close;
+   _mq_notify;
+   _mq_getattr;
+   _mq_setattr;
+   _mq_timedreceive;
+   _mq_timedsend;
+   _mq_unlink;
+   _mq_send;
+   _mq_receive;
+   __mq_open;
+   __mq_close;
+   __mq_notify;
+   __mq_getattr;
+   __mq_setattr;
+   __mq_timedreceive;
+   __mq_timedsend;
+   __mq_unlink;
+   __mq_send;
+   __mq_receive;
+   _timer_create;
+   _timer_delete;
+   _timer_gettime;
+   _timer_settime;
+   _timer_getoverrun;
+   __timer_create;
+   __timer_delete;
+   __timer_gettime;
+   __timer_settime;
+   __timer_getoverrun;
+};
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

svn commit: r269095 - head/sys/kern

[Daniel Eischen]

Author: deischen
Date: Fri Jul 25 20:21:02 2014
New Revision: 269095
URL: http://svnweb.freebsd.org/changeset/base/269095

Log:
  Insert new threads at the end of the thread list in the process
  instead of at the beginning.  This allows an intra process signal
  to be sent to the oldest thread with the signal unmasked - which,
  if it still exists, is the main thread.  This mimics behavior
  found in Linux and Solaris.

Modified:
  head/sys/kern/kern_thread.c

Modified: head/sys/kern/kern_thread.c
==
--- head/sys/kern/kern_thread.c Fri Jul 25 20:18:35 2014(r269094)
+++ head/sys/kern/kern_thread.c Fri Jul 25 20:21:02 2014(r269095)
@@ -546,7 +546,7 @@ thread_link(struct thread *td, struct pr
LIST_INIT(td-td_lprof[1]);
sigqueue_init(td-td_sigqueue, p);
callout_init(td-td_slpcallout, CALLOUT_MPSAFE);
-   TAILQ_INSERT_HEAD(p-p_threads, td, td_plist);
+   TAILQ_INSERT_TAIL(p-p_threads, td, td_plist);
p-p_numthreads++;
 }
 
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org

svn commit: r246192 - head/usr.sbin/pw

[Daniel Eischen]

Author: deischen
Date: Fri Feb  1 05:19:49 2013
New Revision: 246192
URL: http://svnweb.freebsd.org/changeset/base/246192

Log:
  Prevent a null pointer dereference in pw userdel when deleting
  a user whose group != username.

Modified:
  head/usr.sbin/pw/pw_user.c

Modified: head/usr.sbin/pw/pw_user.c
==
--- head/usr.sbin/pw/pw_user.c  Fri Feb  1 03:49:09 2013(r246191)
+++ head/usr.sbin/pw/pw_user.c  Fri Feb  1 05:19:49 2013(r246192)
@@ -425,7 +425,7 @@ pw_user(struct userconf * cnf, int mode,
}
 
grp = GETGRNAM(a_name-val);
-   if (*grp-gr_mem == NULL)
+   if (grp != NULL  *grp-gr_mem == NULL)
delgrent(GETGRNAM(a_name-val));
SETGRENT();
while ((grp = GETGRENT()) != NULL) {
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org

svn commit: r232146 - head/usr.sbin/adduser

[Daniel Eischen]

Author: deischen
Date: Sat Feb 25 07:58:59 2012
New Revision: 232146
URL: http://svn.freebsd.org/changeset/base/232146

Log:
  When using uidstart in /etc/adduser.conf, get the next
  available user id and show it in the Uid [xxx] prompt.
  
  PR:   163863
  Submitted by: Moritz Wilhelmy (mw at wzff dot de)
  MFC after:2 weeks

Modified:
  head/usr.sbin/adduser/adduser.sh

Modified: head/usr.sbin/adduser/adduser.sh
==
--- head/usr.sbin/adduser/adduser.shSat Feb 25 04:54:51 2012
(r232145)
+++ head/usr.sbin/adduser/adduser.shSat Feb 25 07:58:59 2012
(r232146)
@@ -488,6 +488,7 @@ get_uid() {
_prompt=
 
if [ -n $uuid ]; then
+   uuid=`get_nextuid $uuid`
_prompt=Uid [$uuid]: 
else
_prompt=Uid (Leave empty for default): 
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org

Re: cvs commit: src Makefile.inc1 src/lib/libc Makefile src/lib/libc_r Makefile src/lib/libpthread Makefile pthread.map src/lib/libpthread/thread thr_private.h src/lib/librt Makefile src/lib/libthr Ma

[Daniel Eischen]

On Thu, 16 Jun 2011, Jilles Tjoelker wrote:


On Sun, Jun 12, 2011 at 09:38:42PM +, Bjoern A. Zeeb wrote:

http://svnweb.freebsd.org/base?view=revisionrevision=169524



I figured WITHOUT_SYMVER= hs been useless since 201001.  I am no
longer able to do build worlds with WITHOUT_SYMVER= set in src.conf
on a system with symbol versioning.



I'd love someone to fix that and allow us to build libraries without
all the historic stuff in them.  If we cannot get it back working our
libraries will grow bigger and bigger forever.



If one is building images for clean-state systems that will never run
anything older than the current CURRENT build, there is no need for
the extra size.   Contrary to what people think, memory and direct
attached storage can still be expensive in some environments.



Anyone who understands the system can come up with patches to fix this?


I think disabling symver completely is too much: it implies a new
mutually incompatible set of binaries. What should be done instead is
allowing to compile out the compatibility functions. This means all
__sym_compat() directives and all functions referred to by them. A
simple approach would use a yes/no #ifdef, while a more sophisticated
approach would allow choosing the oldest version to retain compatibility
with, for example freebsd7_semctl() in lib/libc/gen/semctl.c would be
compiled in iff compatibility with FreeBSD 7.x was requested.


I like this approach.  But if you can do that, then is it much
more to remove symbol versioning completely?  I've forgotten.
I know there were some potential problems trying to install
a symver-free world over a symver world.

--
DE
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org

Re: cvs commit: src Makefile.inc1 src/lib/libc Makefile src/lib/libc_r Makefile src/lib/libpthread Makefile pthread.map src/lib/libpthread/thread thr_private.h src/lib/librt Makefile src/lib/libthr Ma

[Daniel Eischen]

On Thu, 16 Jun 2011, Jilles Tjoelker wrote:


On Sun, Jun 12, 2011 at 09:38:42PM +, Bjoern A. Zeeb wrote:

http://svnweb.freebsd.org/base?view=revisionrevision=169524



I figured WITHOUT_SYMVER= hs been useless since 201001.  I am no
longer able to do build worlds with WITHOUT_SYMVER= set in src.conf
on a system with symbol versioning.



I'd love someone to fix that and allow us to build libraries without
all the historic stuff in them.  If we cannot get it back working our
libraries will grow bigger and bigger forever.



If one is building images for clean-state systems that will never run
anything older than the current CURRENT build, there is no need for
the extra size.   Contrary to what people think, memory and direct
attached storage can still be expensive in some environments.



Anyone who understands the system can come up with patches to fix this?


BTW, I didn't get bz's email quoted above.  I'm sorry if I
was CC'd and missed it.

--
DE
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org

Re: svn commit: r217592 - head/sys/netinet

[Daniel Eischen]

On Thu, 31 Mar 2011, Randall Stewart wrote:


John:

So I caught up with Dave Thaler here at the IETF...

He said that NO UDP socket that has NOT joined a multicast
group should ever receive a packet sent to a multicast address.
He also said this was part of the POSIX API and the way
all Unix machines worked.

So.. no it is a bug and the fix is correct.


Randall, thank you for following this up.  If we ever meet,
I owe you a beer (or drink of your choice) :-)

--
DE
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org

Re: svn commit: r217592 - head/sys/netinet

[Daniel Eischen]

On Wed, 30 Mar 2011, John Baldwin wrote:


On Wednesday, March 30, 2011 3:50:18 am Daniel Eischen wrote:

On Tue, 29 Mar 2011, John Baldwin wrote:


As to why the packets loop back to the receiver, I believe that is a separate
issue on the output side, not the receive side.


That may be, but the behavior is undesired if the no process
on the system has joined the multicast group.  I believe it
was broke with r189359, and the comment in the code that broke
it says:

/*
 * Loop back multicast datagram if not expressly
 * forbidden to do so, even if we are not a member
 * of the group; ip_input() will filter it later,
 * thus deferring a hash lookup and mutex acquisition
 * at the expense of a cheap copy using m_copym().
 */

The previous revision did a lookup of the multicast address
and looped it if an entry was found for it.


Well, for one, this patch changes the behavior even if there is a socket
joined to the group.


Yes, I understand that.  But before this patch, the behavior
was correct for what you have stated, and for my particular
case.  When we fixed the problem, we took BMS' comment as
guidance and filtered on the input side.


 However, I suspect that in your case your app should
probably be turning IP_MULTICAST_LOOP off explicitly regardless of what the
changes end up being (or do you write to multiple groups and want a subset
of those groups to loop back?).


In the _absence_ of setting multicast loopback on the socket,
we should not be getting looped-back packets.  This is
the behavior we've seen on other OS's.

--
DE
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org

Re: svn commit: r217592 - head/sys/netinet

[Daniel Eischen]

On Wed, 30 Mar 2011, John Baldwin wrote:


On Wednesday, March 30, 2011 7:27:36 am Randall Stewart wrote:

John:

The original complaint on this came from Daniel... I believe he
claimed that up until bms's multi-cast work.. you would NOT
get a packet sent to you if you did not join the multi-cast group.


Not necessarily. :(  See below..


I will also comment in-line below...

On Mar 29, 2011, at 2:01 PM, John Baldwin wrote:


On Wednesday, January 19, 2011 2:07:16 pm Randall Stewart wrote:

Author: rrs
Date: Wed Jan 19 19:07:16 2011
New Revision: 217592
URL: http://svn.freebsd.org/changeset/base/217592

Log:
 Fix a bug where Multicast packets sent from a
 udp endpoint may end up echoing back to the sender
 even with OUT joining the multi-cast group.

 Reviewed by:   gnn, bms, bz?
 Obtained from: deischen (with help from)

Modified:
 head/sys/netinet/udp_usrreq.c

Modified: head/sys/netinet/udp_usrreq.c


==

--- head/sys/netinet/udp_usrreq.c   Wed Jan 19 18:20:11 2011
(r217591)
+++ head/sys/netinet/udp_usrreq.c   Wed Jan 19 19:07:16 2011
(r217592)
@@ -479,11 +479,13 @@ udp_input(struct mbuf *m, int off)
 * and source-specific multicast. [RFC3678]
 */
imo = inp-inp_moptions;
-   if (IN_MULTICAST(ntohl(ip-ip_dst.s_addr)) 
-   imo != NULL) {
+   if (IN_MULTICAST(ntohl(ip-ip_dst.s_addr))) {
struct sockaddr_in   group;
int  blocked;
-
+   if(imo == NULL) {
+   INP_RUNLOCK(inp);
+   continue;
+   }
bzero(group, sizeof(struct sockaddr_in));
group.sin_len = sizeof(struct sockaddr_in);
group.sin_family = AF_INET;


So it turns out that this is a feature, not a bug, and is how multicast has
always worked.  Specifically, if you bind a UDP socket with a wildcard
address, it should receive all traffic for the bound port, unicast or
multicast.  When you join a group, you have switched the socket into a mode
where it now has a whitelist of acceptable multicast groups, but if a socket
has no joined groups, it should receive all multicast traffic, not none.  This
change breaks that.

I did not find this behavior intuitive at first, but it does seem to be
required.  Note the description of IP_ADD_MEMBERSHIP from RFC 3678 for
example:



I agree getting a packet that is coming to your port without joining the
multi-cast group is not intuitive to me...



3.  Overview of APIs

  There are a number of different APIs described in this document that
  are appropriate for a number of different application types and IP
  versions.  Before providing detailed descriptions, this section
  provides a taxonomy with a brief description of each.

  There are two categories of source-filter APIs, both of which are
  designed to allow multicast receiver applications to designate the
  unicast address(es) of sender(s) along with the multicast group
  (destination address) to receive.

 o  Basic (Delta-based): Some applications desire the simplicity of
a delta-based API in which each function call specifies a
single source address which should be added to or removed from
the existing filter for a given multicast group address on
which to listen.  Such applications typically fall into either
of two categories:

+  Any-Source Multicast: By default, all sources are accepted.
   Individual sources may be turned off and back on as needed
   over time.  This is also known as exclude mode, since the
   source filter contains a list of excluded sources.

+  Source-Specific Multicast: Only sources in a given list are
   allowed.  The list may change over time.  This is also known
   as include mode, since the source filter contains a list
   of included sources.

   This API would be used, for example, by single-source
   applications such as audio/video broadcasting.  It would
   also be used for logical multi-source sessions where each
   source independently allocates its own Source-Specific
   Multicast group address.



Not the above document is talking about a receiver that as joined the
multicast group (or is joining it and wants some filtering)... I don't
see how that applies to a UDP socket that has NOT joined the M-cast group..




.

4.1.1.  IPv4 Any-Source Multicast API

  The following socket options are defined in netinet/in.h for
  applications in the Any-Source Multicast category:

  Socket option Argument type
  IP_ADD_MEMBERSHIP

svn commit: r218627 - in head/sys: kern netinet

[Daniel Eischen]

Author: deischen
Date: Sun Feb 13 00:14:13 2011
New Revision: 218627
URL: http://svn.freebsd.org/changeset/base/218627

Log:
  Allow the SO_SETFIB socket option to select the default (0)
  routing table.
  
  Reviewed by:  julian

Modified:
  head/sys/kern/uipc_socket.c
  head/sys/netinet/udp_usrreq.c

Modified: head/sys/kern/uipc_socket.c
==
--- head/sys/kern/uipc_socket.c Sat Feb 12 23:44:05 2011(r218626)
+++ head/sys/kern/uipc_socket.c Sun Feb 13 00:14:13 2011(r218627)
@@ -2449,15 +2449,16 @@ sosetopt(struct socket *so, struct socko
case SO_SETFIB:
error = sooptcopyin(sopt, optval, sizeof optval,
sizeof optval);
-   if (optval  1 || optval  rt_numfibs) {
+   if (optval  0 || optval  rt_numfibs) {
error = EINVAL;
goto bad;
}
-   if ((so-so_proto-pr_domain-dom_family == PF_INET) ||
-   (so-so_proto-pr_domain-dom_family == PF_ROUTE)) {
+   if (so-so_proto != NULL 
+  ((so-so_proto-pr_domain-dom_family == PF_INET) ||
+  (so-so_proto-pr_domain-dom_family == PF_ROUTE))) {
so-so_fibnum = optval;
/* Note: ignore error */
-   if (so-so_proto  so-so_proto-pr_ctloutput)
+   if (so-so_proto-pr_ctloutput)
(*so-so_proto-pr_ctloutput)(so, sopt);
} else {
so-so_fibnum = 0;

Modified: head/sys/netinet/udp_usrreq.c
==
--- head/sys/netinet/udp_usrreq.c   Sat Feb 12 23:44:05 2011
(r218626)
+++ head/sys/netinet/udp_usrreq.c   Sun Feb 13 00:14:13 2011
(r218627)
@@ -486,6 +486,10 @@ udp_input(struct mbuf *m, int off)
INP_RUNLOCK(inp);
continue;
}
+   if (imo == NULL) {
+   INP_RUNLOCK(inp);
+   continue;
+   }
bzero(group, sizeof(struct sockaddr_in));
group.sin_len = sizeof(struct sockaddr_in);
group.sin_family = AF_INET;
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org

svn commit: r218629 - head/sys/netinet

[Daniel Eischen]

Author: deischen
Date: Sun Feb 13 04:44:06 2011
New Revision: 218629
URL: http://svn.freebsd.org/changeset/base/218629

Log:
  Oops, revert an accidental local change that got added in
  my last commit (r218627).  No damage was done in the last
  commit, just some duplicated code was added (which is now
  removed).

Modified:
  head/sys/netinet/udp_usrreq.c

Modified: head/sys/netinet/udp_usrreq.c
==
--- head/sys/netinet/udp_usrreq.c   Sun Feb 13 03:20:44 2011
(r218628)
+++ head/sys/netinet/udp_usrreq.c   Sun Feb 13 04:44:06 2011
(r218629)
@@ -486,10 +486,6 @@ udp_input(struct mbuf *m, int off)
INP_RUNLOCK(inp);
continue;
}
-   if (imo == NULL) {
-   INP_RUNLOCK(inp);
-   continue;
-   }
bzero(group, sizeof(struct sockaddr_in));
group.sin_len = sizeof(struct sockaddr_in);
group.sin_family = AF_INET;
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org

Re: svn commit: r218414 - in head: include lib/libc/include lib/libthr lib/libthr/thread share/man/man3 sys/sys

[Daniel Eischen]

On Mon, 7 Feb 2011, Jung-uk Kim wrote:


On Monday 07 February 2011 06:12 pm, Garrett Cooper wrote:

On Mon, Feb 7, 2011 at 1:26 PM, Jung-uk Kim j...@freebsd.org

wrote:

Author: jkim
Date: Mon Feb �7 21:26:46 2011
New Revision: 218414
URL: http://svn.freebsd.org/changeset/base/218414

Log:
�Introduce a non-portable function pthread_getthreadid_np(3) to
retrieve �calling thread's unique integral ID, which is similar
to AIX function of �the same name. �Bump __FreeBSD_version to
note its introduction.


Stupid question: how is this different from pthread_self() ?
Isn't the pthread_t value returned unique across the system, or is
it relative to the process somehow?


pthread_self(3) returns an opaque type pthread_t, e.g.,
pthread_equal(3) must be used to compare two thread IDs.
pthread_getthreadid_np(3) returns an integral type int, which is
actually td_tid of the calling thread for libthr(3).

Please see the following discussion:

http://docs.freebsd.org/cgi/mid.cgi?201102071558.03573.jkim


Yes, we understand that Linux has it, and IBM has made
some sort of compat functions for accomplishing the same,
but why are developers so lazy that they cannot use
pthread_equal() instead of =?  Or use something like
pthread_[gs]etspecific()?

Yes, this is a rhetorical question.  Since Linux has it,
we must also :-(

--
DE___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org

svn commit: r217888 - head/sys/netinet

[Daniel Eischen]

Author: deischen
Date: Wed Jan 26 17:31:03 2011
New Revision: 217888
URL: http://svn.freebsd.org/changeset/base/217888

Log:
  Prison check addresses set with multicast interface options.
  
  Reviewed by:  bz
  MFC after:1 week

Modified:
  head/sys/netinet/in_pcb.c

Modified: head/sys/netinet/in_pcb.c
==
--- head/sys/netinet/in_pcb.c   Wed Jan 26 17:20:34 2011(r217887)
+++ head/sys/netinet/in_pcb.c   Wed Jan 26 17:31:03 2011(r217888)
@@ -889,17 +889,20 @@ in_pcbconnect_setup(struct inpcb *inp, s
if (imo-imo_multicast_ifp != NULL) {
ifp = imo-imo_multicast_ifp;
IN_IFADDR_RLOCK();
-   TAILQ_FOREACH(ia, V_in_ifaddrhead, ia_link)
-   if (ia-ia_ifp == ifp)
+   TAILQ_FOREACH(ia, V_in_ifaddrhead, ia_link) {
+   if ((ia-ia_ifp == ifp) 
+   (cred == NULL ||
+   prison_check_ip4(cred,
+   ia-ia_addr.sin_addr) == 0))
break;
-   if (ia == NULL) {
-   IN_IFADDR_RUNLOCK();
+   }
+   if (ia == NULL)
error = EADDRNOTAVAIL;
-   } else {
+   else {
laddr = ia-ia_addr.sin_addr;
-   IN_IFADDR_RUNLOCK();
error = 0;
}
+   IN_IFADDR_RUNLOCK();
}
}
if (error)
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org

svn commit: r217169 - head/sys/netinet

[Daniel Eischen]

Author: deischen
Date: Sat Jan  8 22:33:46 2011
New Revision: 217169
URL: http://svn.freebsd.org/changeset/base/217169

Log:
  Make sure to always do source address selection on
  an unbound socket, regardless of any multicast options.
  If an address is specified via a multicast option, then
  let it override normal the source address selection.
  
  This fixes a bug where source address selection was
  not being performed when multicast options were present
  but without an interface being specified.
  
  Reviewed by:  bz
  MFC after:1 day

Modified:
  head/sys/netinet/in_pcb.c

Modified: head/sys/netinet/in_pcb.c
==
--- head/sys/netinet/in_pcb.c   Sat Jan  8 22:08:23 2011(r217168)
+++ head/sys/netinet/in_pcb.c   Sat Jan  8 22:33:46 2011(r217169)
@@ -874,9 +874,10 @@ in_pcbconnect_setup(struct inpcb *inp, s
}
}
if (laddr.s_addr == INADDR_ANY) {
+   error = in_pcbladdr(inp, faddr, laddr, cred);
/*
 * If the destination address is multicast and an outgoing
-* interface has been set as a multicast option, use the
+* interface has been set as a multicast option, prefer the
 * address of that interface as our source address.
 */
if (IN_MULTICAST(ntohl(faddr.s_addr)) 
@@ -893,16 +894,16 @@ in_pcbconnect_setup(struct inpcb *inp, s
break;
if (ia == NULL) {
IN_IFADDR_RUNLOCK();
-   return (EADDRNOTAVAIL);
+   error = EADDRNOTAVAIL;
+   } else {
+   laddr = ia-ia_addr.sin_addr;
+   IN_IFADDR_RUNLOCK();
+   error = 0;
}
-   laddr = ia-ia_addr.sin_addr;
-   IN_IFADDR_RUNLOCK();
}
-   } else {
-   error = in_pcbladdr(inp, faddr, laddr, cred);
-   if (error) 
-   return (error);
}
+   if (error)
+   return (error);
}
oinp = in_pcblookup_hash(inp-inp_pcbinfo, faddr, fport, laddr, lport,
0, NULL);
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org

Re: svn commit: r213241 - in head: include lib/libthr/thread

[Daniel Eischen]

On Wed, 29 Sep 2010, David Xu wrote:


Jung-uk Kim wrote:

On Tuesday 28 September 2010 12:20 pm, Jung-uk Kim wrote:

[ snip ]

Unfortunately, it seems to have a regression:

%cat test.c
#include pthread.h
#include stdio.h

static pthread_cond_t   static_cond = PTHREAD_COND_INITIALIZER;
static pthread_mutex_t  static_mutex = PTHREAD_MUTEX_INITIALIZER;

int
main(void)
{

// pthread_mutex_lock(static_mutex);
printf(%d\n, pthread_cond_wait(static_cond, static_mutex));
pthread_mutex_unlock(static_mutex);

return (0);
}
%cc -o test test.c -pthread
%./test
Segmentation fault (core dumped)

pthread_cond_wait(3) had to return EPERM here. :-(


I realized it is a libthr feature to catch real application bugs and to 
increase performance by not checking rare conditions, I guess. :-/


Sorry for the noise,

Jung-uk Kim


I think your example is legal, I might add checking back, however, it
would return two codes, EINVAL and EPERM.


By default, I think we should check.  I think PTHREAD_MUTEX_DEFAULT
should be equal to PTHREAD_MUTEX_ERRORCHECK.  So
PTHREAD_MUTEX_INITIALIZER would default to error checking.

I also agree -- if the mutex isn't valid, then return EINVAL,
and if not locked, return EPERM.

--
DE
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org

svn commit: r208503 - head/lib/libthr/thread

[Daniel Eischen]

Author: deischen
Date: Mon May 24 13:44:39 2010
New Revision: 208503
URL: http://svn.freebsd.org/changeset/base/208503

Log:
  Coalesce one more broken line.

Modified:
  head/lib/libthr/thread/thr_condattr.c

Modified: head/lib/libthr/thread/thr_condattr.c
==
--- head/lib/libthr/thread/thr_condattr.c   Mon May 24 13:43:11 2010
(r208502)
+++ head/lib/libthr/thread/thr_condattr.c   Mon May 24 13:44:39 2010
(r208503)
@@ -103,8 +103,7 @@ _pthread_condattr_setclock(pthread_conda
 }
 
 int
-_pthread_condattr_getpshared(const pthread_condattr_t *attr,
-   int *pshared)
+_pthread_condattr_getpshared(const pthread_condattr_t *attr, int *pshared)
 {
if (attr == NULL || *attr == NULL)
return (EINVAL);
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org