svn commit: r304519 - stable/11/usr.bin/netstat
Author: tuexen
Date: Sat Aug 20 07:44:41 2016
New Revision: 304519
URL: https://svnweb.freebsd.org/changeset/base/304519
Log:
MFC r304292:
Use names for SCTP and UDPLite when reporting the input histogram.
MFC r304295:
Fix the output for scope statistics.
Modified:
stable/11/usr.bin/netstat/inet6.c
Directory Properties:
stable/11/ (props changed)
Modified: stable/11/usr.bin/netstat/inet6.c
==
--- stable/11/usr.bin/netstat/inet6.c Sat Aug 20 02:21:45 2016
(r304518)
+++ stable/11/usr.bin/netstat/inet6.c Sat Aug 20 07:44:41 2016
(r304519)
@@ -207,11 +207,11 @@ staticconst char *ip6nh[] = {
"#129",
"#130",
"#131",
- "#132",
+ "SCTP",
"#133",
"#134",
"#135",
- "#136",
+ "UDPLite",
"#137",
"#138",
"#139",
@@ -488,8 +488,8 @@ ip6_stats(u_long off, const char *name,
"{N:/global%s}\n");\
break;\
default:\
- xo_emit("\t\t{qke:name/%x}{:count/%ju} " \
- "addresses scope=%x\n",\
+ xo_emit("\t\t{qke:name/%#x}{:count/%ju} " \
+ "{N:/addresses scope=%#x}\n",\
i, (uintmax_t)ip6stat.s, i); \
}\
} while (0);
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
svn commit: r304520 - head/cddl/contrib/opensolaris/lib/libzfs/common
Author: avg
Date: Sat Aug 20 09:12:01 2016
New Revision: 304520
URL: https://svnweb.freebsd.org/changeset/base/304520
Log:
fix bug introduced in r297521, set canmount=on doesn't mount filesystem
There are two cases where changing canmount should result in an action:
- canmount is set to off for a mounted filesystem
- canmount is set to on for an unmounted filesystem
Before r297521 we could unmount and re-mount a filesystem when that was
not necessary, but after r297521 we only handled the first of the above
cases.
MFC after:5 days
Modified:
head/cddl/contrib/opensolaris/lib/libzfs/common/libzfs_dataset.c
Modified: head/cddl/contrib/opensolaris/lib/libzfs/common/libzfs_dataset.c
==
--- head/cddl/contrib/opensolaris/lib/libzfs/common/libzfs_dataset.cSat Aug
20 07:44:41 2016(r304519)
+++ head/cddl/contrib/opensolaris/lib/libzfs/common/libzfs_dataset.cSat Aug
20 09:12:01 2016(r304520)
@@ -1630,12 +1630,17 @@ zfs_prop_set_list(zfs_handle_t *zhp, nvl
assert(cl_idx < nvl_len);
/*
* We don't want to unmount & remount the dataset when changing
-* its canmount property to 'on' or 'noauto'. We only use
-* the changelist logic to unmount when setting canmount=off.
+* its canmount property. We only use the changelist logic to
+* unmount when setting canmount=off for a mounted filesystem
+* or when setting canmount=on for an unmounted filesystem.
+* For all other changes to canmount property the filesystem
+* remains the same.
*/
if (prop != ZFS_PROP_CANMOUNT ||
(fnvpair_value_uint64(elem) == ZFS_CANMOUNT_OFF &&
-zfs_is_mounted(zhp, NULL))) {
+zfs_is_mounted(zhp, NULL)) ||
+ (fnvpair_value_uint64(elem) == ZFS_CANMOUNT_ON &&
+!zfs_is_mounted(zhp, NULL))) {
cls[cl_idx] = changelist_gather(zhp, prop, 0, 0);
if (cls[cl_idx] == NULL)
goto error;
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
svn commit: r304521 - head/sys/dev/ahci
Author: avg
Date: Sat Aug 20 09:13:14 2016
New Revision: 304521
URL: https://svnweb.freebsd.org/changeset/base/304521
Log:
JMicron JMB361 has only a single SATA port
Discussed with: mav
MFC after:3 days
Modified:
head/sys/dev/ahci/ahci_pci.c
Modified: head/sys/dev/ahci/ahci_pci.c
==
--- head/sys/dev/ahci/ahci_pci.cSat Aug 20 09:12:01 2016
(r304520)
+++ head/sys/dev/ahci/ahci_pci.cSat Aug 20 09:13:14 2016
(r304521)
@@ -187,7 +187,7 @@ static const struct {
{0xa10f8086, 0x00, "Intel Sunrise Point (RAID)",0},
{0x23238086, 0x00, "Intel DH89xxCC",0},
{0x2360197b, 0x00, "JMicron JMB360",0},
- {0x2361197b, 0x00, "JMicron JMB361",AHCI_Q_NOFORCE},
+ {0x2361197b, 0x00, "JMicron JMB361",AHCI_Q_NOFORCE | AHCI_Q_1CH},
{0x2362197b, 0x00, "JMicron JMB362",0},
{0x2363197b, 0x00, "JMicron JMB363",AHCI_Q_NOFORCE},
{0x2365197b, 0x00, "JMicron JMB365",AHCI_Q_NOFORCE},
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r304435 - head/sys/netinet
On 19/08/2016 8:59 AM, Ryan Stone wrote: > Author: rstone > Date: Thu Aug 18 22:59:00 2016 > New Revision: 304435 > URL: https://svnweb.freebsd.org/changeset/base/304435 > > Log: > Don't iterate over the ifnet addr list in ip_output() > > For almost every packet that is transmitted through ip_output(), > a call to in_broadcast() was made to decide if the destination > IP was a broadcast address. in_broadcast() iterates over the > ifnet's address to find a source IP matching the subnet of the > destination IP, and then checks if the IP is a broadcast in that > subnet. > > This is completely redundant as we have already performed the > route lookup, so the source IP is already known. Just use that > address to directly check whether the destination IP is a > broadcast address or not. Hi Ryan, Could you elaborate on any of the potential performance implications of this? > MFC after: 2 months > Sponsored By: EMC / Isilon Storage Division > Differential Revision: https://reviews.freebsd.org/D7266 > > Modified: > head/sys/netinet/in.c > head/sys/netinet/in.h > head/sys/netinet/ip_output.c > > Modified: head/sys/netinet/in.c ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
svn commit: r304522 - releng/11.0/usr.bin/netstat
Author: tuexen
Date: Sat Aug 20 11:42:08 2016
New Revision: 304522
URL: https://svnweb.freebsd.org/changeset/base/304522
Log:
MFC r304519:
* Use names for SCTP and UDPLite when reporting the input histogram.
* Fix the output for scope statistics.
Approved by: re (kib)
Modified:
releng/11.0/usr.bin/netstat/inet6.c
Directory Properties:
releng/11.0/ (props changed)
Modified: releng/11.0/usr.bin/netstat/inet6.c
==
--- releng/11.0/usr.bin/netstat/inet6.c Sat Aug 20 09:13:14 2016
(r304521)
+++ releng/11.0/usr.bin/netstat/inet6.c Sat Aug 20 11:42:08 2016
(r304522)
@@ -207,11 +207,11 @@ staticconst char *ip6nh[] = {
"#129",
"#130",
"#131",
- "#132",
+ "SCTP",
"#133",
"#134",
"#135",
- "#136",
+ "UDPLite",
"#137",
"#138",
"#139",
@@ -488,8 +488,8 @@ ip6_stats(u_long off, const char *name,
"{N:/global%s}\n");\
break;\
default:\
- xo_emit("\t\t{qke:name/%x}{:count/%ju} " \
- "addresses scope=%x\n",\
+ xo_emit("\t\t{qke:name/%#x}{:count/%ju} " \
+ "{N:/addresses scope=%#x}\n",\
i, (uintmax_t)ip6stat.s, i); \
}\
} while (0);
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r304436 - in head: . sys/netinet
This potentially breaks reception of IPv4 broadcasts where FreeBSD is
the endpoint at the end of a P2P interface, or other forms of links,
where there is no guarantee that the link layer will set M_BCAST (or
indeed M_MCAST).
On 18/08/16 23:59, Ryan Stone wrote:
Author: rstone
Date: Thu Aug 18 22:59:05 2016
New Revision: 304436
URL: https://svnweb.freebsd.org/changeset/base/304436
Log:
Don't check for broadcast IPs on non-bcast pkts
in_broadcast() can be quite expensive, so skip calling it if the
incoming mbuf wasn't sent to a broadcast L2 address in the first
place.
Reviewed by: gnn
MFC after: 2 months
Sponsored by: EMC / Isilon Storage Division
Differential Revision: https://reviews.freebsd.org/D7309
Modified:
head/UPDATING
head/sys/netinet/udp_usrreq.c
Modified: head/UPDATING
==
--- head/UPDATING Thu Aug 18 22:59:00 2016(r304435)
+++ head/UPDATING Thu Aug 18 22:59:05 2016(r304436)
@@ -32,6 +32,14 @@ NOTE TO PEOPLE WHO THINK THAT FreeBSD 12
"ln -s 'abort:false,junk:false' /etc/malloc.conf".)
20160818:
+ The UDP receive code has been updated to only treat incoming UDP
+ packets that were addressed to an L2 broadcast address as L3
+ broadcast packets. It is not expected that this will affect any
+ standards-conforming UDP application. The new behaviour can be
+ disabled by setting the sysctl net.inet.udp.require_l2_bcast to
+ 0.
+
+20160818:
Remove the openbsd_poll system call.
__FreeBSD_version has been bumped because of this.
Modified: head/sys/netinet/udp_usrreq.c
==
--- head/sys/netinet/udp_usrreq.c Thu Aug 18 22:59:00 2016
(r304435)
+++ head/sys/netinet/udp_usrreq.c Thu Aug 18 22:59:05 2016
(r304436)
@@ -126,6 +126,11 @@ SYSCTL_INT(_net_inet_udp, OID_AUTO, blac
&VNET_NAME(udp_blackhole), 0,
"Do not send port unreachables for refused connects");
+static VNET_DEFINE(int, udp_require_l2_bcast) = 1;
+SYSCTL_INT(_net_inet_udp, OID_AUTO, require_l2_bcast, CTLFLAG_VNET |
CTLFLAG_RW,
+&VNET_NAME(udp_require_l2_bcast), 0,
+"Only treat packets sent to an L2 broadcast address as broadcast packets");
+
u_long udp_sendspace = 9216; /* really max datagram size */
SYSCTL_ULONG(_net_inet_udp, UDPCTL_MAXDGRAM, maxdgram, CTLFLAG_RW,
&udp_sendspace, 0, "Maximum outgoing UDP datagram size");
@@ -523,7 +528,8 @@ udp_input(struct mbuf **mp, int *offp, i
pcbinfo = udp_get_inpcbinfo(proto);
if (IN_MULTICAST(ntohl(ip->ip_dst.s_addr)) ||
- in_broadcast(ip->ip_dst, ifp)) {
+ ((!VNET_NAME(udp_require_l2_bcast) || m->m_flags & M_BCAST) &&
+ in_broadcast(ip->ip_dst, ifp))) {
struct inpcb *last;
struct inpcbhead *pcblist;
struct ip_moptions *imo;
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r304436 - in head: . sys/netinet
On 20/08/16 12:33, Bruce Simpson wrote: This potentially breaks reception of IPv4 broadcasts where FreeBSD is the endpoint at the end of a P2P interface, or other forms of links, where there is no guarantee that the link layer will set M_BCAST (or indeed M_MCAST). I appreciate it probably looks like a quick win, but if it's only been tested with Ethernet (it looks like it has only been written with Ethernet in mind), it does strongly look as if it breaks broadcast for UDP/IPv4 in other situations. So, maybe it should be backed out ASAP. (I haven't tested this code.) It is perfectly legal for broadcast packets to be addressed to the end of a P2P or non-Ethernet link, which may not set M_BCAST or M_MCAST. The classic example is ATM (Non-Broadcast, Multiple Access (NBMA)) but the situation may be readily observed with loopback or tunnels. The same issue doesn't exist in your output path change, which looks sane. The same issue doesn't exist with IPv6 where broadcast is dead. ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
svn commit: r304523 - stable/11/lib/libc
Author: kib
Date: Sat Aug 20 11:54:11 2016
New Revision: 304523
URL: https://svnweb.freebsd.org/changeset/base/304523
Log:
MFC r303794:
Create namespace for the symbols added during 12-CURRENT cycle.
Modified:
stable/11/lib/libc/Versions.def
Directory Properties:
stable/11/ (props changed)
Modified: stable/11/lib/libc/Versions.def
==
--- stable/11/lib/libc/Versions.def Sat Aug 20 11:42:08 2016
(r304522)
+++ stable/11/lib/libc/Versions.def Sat Aug 20 11:54:11 2016
(r304523)
@@ -27,6 +27,10 @@ FBSD_1.3 {
FBSD_1.4 {
} FBSD_1.3;
+# This version was first added to 12.0-current.
+FBSD_1.5 {
+} FBSD_1.4;
+
# This is our private namespace. Any global interfaces that are
# strictly for use only by other FreeBSD applications and libraries
@@ -35,4 +39,4 @@ FBSD_1.4 {
#
# Please do NOT increment the version of this namespace.
FBSDprivate_1.0 {
-} FBSD_1.4;
+} FBSD_1.5;
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
svn commit: r304524 - in stable/11/lib: libc/include libc/stdlib libc/tests/stdlib libthr/thread
Author: kib
Date: Sat Aug 20 11:58:23 2016
New Revision: 304524
URL: https://svnweb.freebsd.org/changeset/base/304524
Log:
MFC r303795:
Add __cxa_thread_atexit(3) API implementation.
Added:
stable/11/lib/libc/stdlib/cxa_thread_atexit.c
- copied unchanged from r303795, head/lib/libc/stdlib/cxa_thread_atexit.c
stable/11/lib/libc/tests/stdlib/cxa_thread_atexit_nothr_test.cc
- copied unchanged from r303795,
head/lib/libc/tests/stdlib/cxa_thread_atexit_nothr_test.cc
stable/11/lib/libc/tests/stdlib/cxa_thread_atexit_test.cc
- copied unchanged from r303795,
head/lib/libc/tests/stdlib/cxa_thread_atexit_test.cc
Modified:
stable/11/lib/libc/include/libc_private.h
stable/11/lib/libc/stdlib/Makefile.inc
stable/11/lib/libc/stdlib/Symbol.map
stable/11/lib/libc/stdlib/exit.c
stable/11/lib/libc/tests/stdlib/Makefile
stable/11/lib/libc/tests/stdlib/Makefile.depend
stable/11/lib/libthr/thread/thr_exit.c
Directory Properties:
stable/11/ (props changed)
Modified: stable/11/lib/libc/include/libc_private.h
==
--- stable/11/lib/libc/include/libc_private.h Sat Aug 20 11:54:11 2016
(r304523)
+++ stable/11/lib/libc/include/libc_private.h Sat Aug 20 11:58:23 2016
(r304524)
@@ -267,6 +267,12 @@ extern const char *__progname;
void _malloc_thread_cleanup(void);
/*
+ * This function is used by the threading libraries to notify libc that a
+ * thread is exiting, so its thread-local dtors should be called.
+ */
+void __cxa_thread_call_dtors(void);
+
+/*
* These functions are used by the threading libraries in order to protect
* malloc across fork().
*/
Modified: stable/11/lib/libc/stdlib/Makefile.inc
==
--- stable/11/lib/libc/stdlib/Makefile.inc Sat Aug 20 11:54:11 2016
(r304523)
+++ stable/11/lib/libc/stdlib/Makefile.inc Sat Aug 20 11:58:23 2016
(r304524)
@@ -5,7 +5,7 @@
.PATH: ${LIBC_SRCTOP}/${LIBC_ARCH}/stdlib ${LIBC_SRCTOP}/stdlib
MISRCS+=_Exit.c a64l.c abort.c abs.c atexit.c atof.c atoi.c atol.c atoll.c \
- bsearch.c div.c exit.c getenv.c getopt.c getopt_long.c \
+ bsearch.c cxa_thread_atexit.c div.c exit.c getenv.c getopt.c
getopt_long.c \
getsubopt.c hcreate.c hcreate_r.c hdestroy_r.c heapsort.c heapsort_b.c \
hsearch_r.c imaxabs.c imaxdiv.c \
insque.c l64a.c labs.c ldiv.c llabs.c lldiv.c lsearch.c \
Modified: stable/11/lib/libc/stdlib/Symbol.map
==
--- stable/11/lib/libc/stdlib/Symbol.mapSat Aug 20 11:54:11 2016
(r304523)
+++ stable/11/lib/libc/stdlib/Symbol.mapSat Aug 20 11:58:23 2016
(r304524)
@@ -116,8 +116,13 @@ FBSD_1.4 {
reallocarray;
};
+FBSD_1.5 {
+ __cxa_thread_atexit;
+};
+
FBSDprivate_1.0 {
__system;
_system;
__libc_system;
+ __cxa_thread_call_dtors;
};
Copied: stable/11/lib/libc/stdlib/cxa_thread_atexit.c (from r303795,
head/lib/libc/stdlib/cxa_thread_atexit.c)
==
--- /dev/null 00:00:00 1970 (empty, because file is newly added)
+++ stable/11/lib/libc/stdlib/cxa_thread_atexit.c Sat Aug 20 11:58:23
2016(r304524, copy of r303795, head/lib/libc/stdlib/cxa_thread_atexit.c)
@@ -0,0 +1,140 @@
+/*-
+ * Copyright (c) 2016 Mahdi Mokhtari
+ * All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *notice, this list of conditions and the following disclaimer.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *notice, this list of conditions and the following disclaimer in the
+ *documentation and/or other materials provided with the distribution.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
+ * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+ * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
+ * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+ * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
+ * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+ * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
+ * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
+ * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
+ * SUCH DAMAGE.
+ */
+
+#include
+__FBSDID("$FreeBSD$");
+
+#include
+#include "namespace.h"
+#include
+#include
+#include
+#include
+#include
+#include
svn commit: r304525 - in releng/11.0: lib/libc/sys sys/kern
Author: bdrewery
Date: Sat Aug 20 11:59:19 2016
New Revision: 304525
URL: https://svnweb.freebsd.org/changeset/base/304525
Log:
MFS r304512:
MFC r304288:
Garbage collect _umtx_lock(2)/_umtx_unlock(2) references removed in
r263318.
Approved by: re (gjb)
Modified:
releng/11.0/lib/libc/sys/Symbol.map
releng/11.0/sys/kern/capabilities.conf
Directory Properties:
releng/11.0/ (props changed)
Modified: releng/11.0/lib/libc/sys/Symbol.map
==
--- releng/11.0/lib/libc/sys/Symbol.map Sat Aug 20 11:58:23 2016
(r304524)
+++ releng/11.0/lib/libc/sys/Symbol.map Sat Aug 20 11:59:19 2016
(r304525)
@@ -34,9 +34,7 @@ FBSD_1.0 {
__setugid;
__syscall;
__sysctl;
- _umtx_lock;
_umtx_op;
- _umtx_unlock;
abort2;
accept;
access;
@@ -455,12 +453,8 @@ FBSDprivate_1.0 {
__sys___syscall;
___sysctl;
__sys___sysctl;
- __umtx_lock;
- __sys__umtx_lock;
__umtx_op;
__sys__umtx_op;
- __umtx_unlock;
- __sys__umtx_unlock;
_abort2;
__sys_abort2;
_accept;
Modified: releng/11.0/sys/kern/capabilities.conf
==
--- releng/11.0/sys/kern/capabilities.conf Sat Aug 20 11:58:23 2016
(r304524)
+++ releng/11.0/sys/kern/capabilities.conf Sat Aug 20 11:59:19 2016
(r304525)
@@ -64,9 +64,7 @@ __sysctl
##
## XXRW: Need to check this very carefully.
##
-_umtx_lock
_umtx_op
-_umtx_unlock
##
## Allow process termination using abort2(2).
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
svn commit: r304526 - stable/10/lib/libc
Author: kib
Date: Sat Aug 20 12:23:27 2016
New Revision: 304526
URL: https://svnweb.freebsd.org/changeset/base/304526
Log:
MFC r303794:
Create namespace for the symbols added during 12-CURRENT cycle.
Modified:
stable/10/lib/libc/Versions.def
Directory Properties:
stable/10/ (props changed)
Modified: stable/10/lib/libc/Versions.def
==
--- stable/10/lib/libc/Versions.def Sat Aug 20 11:59:19 2016
(r304525)
+++ stable/10/lib/libc/Versions.def Sat Aug 20 12:23:27 2016
(r304526)
@@ -27,6 +27,10 @@ FBSD_1.3 {
FBSD_1.4 {
} FBSD_1.3;
+# This version was first added to 12.0-current.
+FBSD_1.5 {
+} FBSD_1.4;
+
# This is our private namespace. Any global interfaces that are
# strictly for use only by other FreeBSD applications and libraries
@@ -35,4 +39,4 @@ FBSD_1.4 {
#
# Please do NOT increment the version of this namespace.
FBSDprivate_1.0 {
-} FBSD_1.4;
+} FBSD_1.5;
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
svn commit: r304527 - in stable/10/lib: libc/include libc/stdlib libc/tests/stdlib libthr/thread
Author: kib
Date: Sat Aug 20 12:26:44 2016
New Revision: 304527
URL: https://svnweb.freebsd.org/changeset/base/304527
Log:
MFC r303795:
Add __cxa_thread_atexit(3) API implementation.
Added:
stable/10/lib/libc/stdlib/cxa_thread_atexit.c
- copied unchanged from r303795, head/lib/libc/stdlib/cxa_thread_atexit.c
stable/10/lib/libc/tests/stdlib/cxa_thread_atexit_nothr_test.cc
- copied unchanged from r303795,
head/lib/libc/tests/stdlib/cxa_thread_atexit_nothr_test.cc
stable/10/lib/libc/tests/stdlib/cxa_thread_atexit_test.cc
- copied unchanged from r303795,
head/lib/libc/tests/stdlib/cxa_thread_atexit_test.cc
Modified:
stable/10/lib/libc/include/libc_private.h
stable/10/lib/libc/stdlib/Makefile.inc
stable/10/lib/libc/stdlib/Symbol.map
stable/10/lib/libc/stdlib/exit.c
stable/10/lib/libc/tests/stdlib/Makefile
stable/10/lib/libthr/thread/thr_exit.c
Directory Properties:
stable/10/ (props changed)
Modified: stable/10/lib/libc/include/libc_private.h
==
--- stable/10/lib/libc/include/libc_private.h Sat Aug 20 12:23:27 2016
(r304526)
+++ stable/10/lib/libc/include/libc_private.h Sat Aug 20 12:26:44 2016
(r304527)
@@ -264,6 +264,12 @@ extern const char *__progname;
void _malloc_thread_cleanup(void);
/*
+ * This function is used by the threading libraries to notify libc that a
+ * thread is exiting, so its thread-local dtors should be called.
+ */
+void __cxa_thread_call_dtors(void);
+
+/*
* These functions are used by the threading libraries in order to protect
* malloc across fork().
*/
Modified: stable/10/lib/libc/stdlib/Makefile.inc
==
--- stable/10/lib/libc/stdlib/Makefile.inc Sat Aug 20 12:23:27 2016
(r304526)
+++ stable/10/lib/libc/stdlib/Makefile.inc Sat Aug 20 12:26:44 2016
(r304527)
@@ -5,7 +5,7 @@
.PATH: ${.CURDIR}/${LIBC_ARCH}/stdlib ${.CURDIR}/stdlib
MISRCS+=_Exit.c a64l.c abort.c abs.c atexit.c atof.c atoi.c atol.c atoll.c \
- bsearch.c div.c exit.c getenv.c getopt.c getopt_long.c \
+ bsearch.c cxa_thread_atexit.c div.c exit.c getenv.c getopt.c
getopt_long.c \
getsubopt.c hcreate.c heapsort.c imaxabs.c imaxdiv.c \
insque.c l64a.c labs.c ldiv.c llabs.c lldiv.c lsearch.c \
merge.c ptsname.c qsort.c qsort_r.c quick_exit.c radixsort.c rand.c \
Modified: stable/10/lib/libc/stdlib/Symbol.map
==
--- stable/10/lib/libc/stdlib/Symbol.mapSat Aug 20 12:23:27 2016
(r304526)
+++ stable/10/lib/libc/stdlib/Symbol.mapSat Aug 20 12:26:44 2016
(r304527)
@@ -104,8 +104,13 @@ FBSD_1.3 {
strtouq_l;
};
+FBSD_1.5 {
+ __cxa_thread_atexit;
+};
+
FBSDprivate_1.0 {
__system;
_system;
__libc_system;
+ __cxa_thread_call_dtors;
};
Copied: stable/10/lib/libc/stdlib/cxa_thread_atexit.c (from r303795,
head/lib/libc/stdlib/cxa_thread_atexit.c)
==
--- /dev/null 00:00:00 1970 (empty, because file is newly added)
+++ stable/10/lib/libc/stdlib/cxa_thread_atexit.c Sat Aug 20 12:26:44
2016(r304527, copy of r303795, head/lib/libc/stdlib/cxa_thread_atexit.c)
@@ -0,0 +1,140 @@
+/*-
+ * Copyright (c) 2016 Mahdi Mokhtari
+ * All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *notice, this list of conditions and the following disclaimer.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *notice, this list of conditions and the following disclaimer in the
+ *documentation and/or other materials provided with the distribution.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
+ * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+ * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
+ * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+ * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
+ * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+ * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
+ * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
+ * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
+ * SUCH DAMAGE.
+ */
+
+#include
+__FBSDID("$FreeBSD$");
+
+#include
+#include "namespace.h"
+#include
+#include
+#include
+#include
+#include
+#include
+#include "un-namespace.h"
+#include "lib
svn commit: r304528 - in stable/11: contrib/llvm/lib/Target/X86 contrib/llvm/tools/clang/lib/Basic lib/clang
Author: dim Date: Sat Aug 20 12:49:05 2016 New Revision: 304528 URL: https://svnweb.freebsd.org/changeset/base/304528 Log: MFC r304319: Pull in r262772 from upstream clang trunk (by Simon Pilgrim): [X86] AMD Bobcat CPU (btver1) doesn't support XSAVE btver1 is a SSSE3/SSE4a only CPU - it doesn't have AVX and doesn't support XSAVE. Differential Revision: http://reviews.llvm.org/D17682 Pull in r262782 from upstream llvm trunk (by Simon Pilgrim): [X86] AMD Bobcat CPU (btver1) doesn't support XSAVE btver1 is a SSSE3/SSE4a only CPU - it doesn't have AVX and doesn't support XSAVE. Differential Revision: http://reviews.llvm.org/D17683 This ensures clang does not emit AVX instructions for CPUTYPE=btver1. Reported by: Michel Depeige PR: 211864 Modified: stable/11/contrib/llvm/lib/Target/X86/X86.td stable/11/contrib/llvm/tools/clang/lib/Basic/Targets.cpp stable/11/lib/clang/freebsd_cc_version.h Directory Properties: stable/11/ (props changed) Modified: stable/11/contrib/llvm/lib/Target/X86/X86.td == --- stable/11/contrib/llvm/lib/Target/X86/X86.tdSat Aug 20 12:26:44 2016(r304527) +++ stable/11/contrib/llvm/lib/Target/X86/X86.tdSat Aug 20 12:49:05 2016(r304528) @@ -576,7 +576,6 @@ def : Proc<"btver1", [ FeaturePRFCHW, FeatureLZCNT, FeaturePOPCNT, - FeatureXSAVE, FeatureSlowSHLD, FeatureLAHFSAHF ]>; Modified: stable/11/contrib/llvm/tools/clang/lib/Basic/Targets.cpp == --- stable/11/contrib/llvm/tools/clang/lib/Basic/Targets.cppSat Aug 20 12:26:44 2016(r304527) +++ stable/11/contrib/llvm/tools/clang/lib/Basic/Targets.cppSat Aug 20 12:49:05 2016(r304528) @@ -2731,7 +2731,6 @@ bool X86TargetInfo::initFeatureMap( setFeatureEnabledImpl(Features, "prfchw", true); setFeatureEnabledImpl(Features, "cx16", true); setFeatureEnabledImpl(Features, "fxsr", true); -setFeatureEnabledImpl(Features, "xsave", true); break; case CK_BDVER4: setFeatureEnabledImpl(Features, "avx2", true); Modified: stable/11/lib/clang/freebsd_cc_version.h == --- stable/11/lib/clang/freebsd_cc_version.hSat Aug 20 12:26:44 2016 (r304527) +++ stable/11/lib/clang/freebsd_cc_version.hSat Aug 20 12:49:05 2016 (r304528) @@ -1,3 +1,3 @@ /* $FreeBSD$ */ -#defineFREEBSD_CC_VERSION 1100500 +#defineFREEBSD_CC_VERSION 1100501 ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
svn commit: r304529 - in releng/11.0: contrib/llvm/lib/Target/X86 contrib/llvm/tools/clang/lib/Basic lib/clang
Author: dim Date: Sat Aug 20 13:29:58 2016 New Revision: 304529 URL: https://svnweb.freebsd.org/changeset/base/304529 Log: MFC r304319: Pull in r262772 from upstream clang trunk (by Simon Pilgrim): [X86] AMD Bobcat CPU (btver1) doesn't support XSAVE btver1 is a SSSE3/SSE4a only CPU - it doesn't have AVX and doesn't support XSAVE. Differential Revision: http://reviews.llvm.org/D17682 Pull in r262782 from upstream llvm trunk (by Simon Pilgrim): [X86] AMD Bobcat CPU (btver1) doesn't support XSAVE btver1 is a SSSE3/SSE4a only CPU - it doesn't have AVX and doesn't support XSAVE. Differential Revision: http://reviews.llvm.org/D17683 This ensures clang does not emit AVX instructions for CPUTYPE=btver1. Approved by: re (kib) Reported by: Michel Depeige PR: 211864 Modified: releng/11.0/contrib/llvm/lib/Target/X86/X86.td releng/11.0/contrib/llvm/tools/clang/lib/Basic/Targets.cpp releng/11.0/lib/clang/freebsd_cc_version.h Directory Properties: releng/11.0/ (props changed) Modified: releng/11.0/contrib/llvm/lib/Target/X86/X86.td == --- releng/11.0/contrib/llvm/lib/Target/X86/X86.td Sat Aug 20 12:49:05 2016(r304528) +++ releng/11.0/contrib/llvm/lib/Target/X86/X86.td Sat Aug 20 13:29:58 2016(r304529) @@ -576,7 +576,6 @@ def : Proc<"btver1", [ FeaturePRFCHW, FeatureLZCNT, FeaturePOPCNT, - FeatureXSAVE, FeatureSlowSHLD, FeatureLAHFSAHF ]>; Modified: releng/11.0/contrib/llvm/tools/clang/lib/Basic/Targets.cpp == --- releng/11.0/contrib/llvm/tools/clang/lib/Basic/Targets.cpp Sat Aug 20 12:49:05 2016(r304528) +++ releng/11.0/contrib/llvm/tools/clang/lib/Basic/Targets.cpp Sat Aug 20 13:29:58 2016(r304529) @@ -2731,7 +2731,6 @@ bool X86TargetInfo::initFeatureMap( setFeatureEnabledImpl(Features, "prfchw", true); setFeatureEnabledImpl(Features, "cx16", true); setFeatureEnabledImpl(Features, "fxsr", true); -setFeatureEnabledImpl(Features, "xsave", true); break; case CK_BDVER4: setFeatureEnabledImpl(Features, "avx2", true); Modified: releng/11.0/lib/clang/freebsd_cc_version.h == --- releng/11.0/lib/clang/freebsd_cc_version.h Sat Aug 20 12:49:05 2016 (r304528) +++ releng/11.0/lib/clang/freebsd_cc_version.h Sat Aug 20 13:29:58 2016 (r304529) @@ -1,3 +1,3 @@ /* $FreeBSD$ */ -#defineFREEBSD_CC_VERSION 115 +#defineFREEBSD_CC_VERSION 116 ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
svn commit: r304530 - in head: contrib/llvm/lib/Target/ARM/MCTargetDesc lib/clang
Author: dim
Date: Sat Aug 20 14:04:51 2016
New Revision: 304530
URL: https://svnweb.freebsd.org/changeset/base/304530
Log:
Pull in r265122 from upstream llvm trunk (by James Molloy):
Fix for pr24346: arm asm label calculation error in sub
Some ARM instructions encode 32-bit immediates as a 8-bit integer
(0-255) and a 4-bit rotation (0-30, even) in its least significant 12
bits. The original fixup, FK_Data_4, patches the instruction by the
value bit-to-bit, regardless of the encoding. For example, assuming
the label L1 and L2 are 0x0 and 0x104 respectively, the following
instruction:
add r0, r0, #(L2 - L1) ; expects 0x104, i.e., 260
would be assembled to the following, which adds 1 to r0, instead of
260:
e2800104 add r0, r0, #4, 2 ; equivalently 1
The new fixup kind fixup_arm_mod_imm takes care of the encoding:
e2800f41 add r0, r0, #260
Patch by Ting-Yuan Huang!
This fixes label calculation for ARM assembly, and is needed to enable
ARM assembly sources for OpenSSL.
Requested by: jkim
MFC after:3 days
Modified:
head/contrib/llvm/lib/Target/ARM/MCTargetDesc/ARMAsmBackend.cpp
head/contrib/llvm/lib/Target/ARM/MCTargetDesc/ARMFixupKinds.h
head/contrib/llvm/lib/Target/ARM/MCTargetDesc/ARMMCCodeEmitter.cpp
head/lib/clang/freebsd_cc_version.h
Modified: head/contrib/llvm/lib/Target/ARM/MCTargetDesc/ARMAsmBackend.cpp
==
--- head/contrib/llvm/lib/Target/ARM/MCTargetDesc/ARMAsmBackend.cpp Sat Aug
20 13:29:58 2016(r304529)
+++ head/contrib/llvm/lib/Target/ARM/MCTargetDesc/ARMAsmBackend.cpp Sat Aug
20 14:04:51 2016(r304530)
@@ -90,6 +90,7 @@ const MCFixupKindInfo &ARMAsmBackend::ge
{"fixup_arm_movw_lo16", 0, 20, 0},
{"fixup_t2_movt_hi16", 0, 20, 0},
{"fixup_t2_movw_lo16", 0, 20, 0},
+ {"fixup_arm_mod_imm", 0, 12, 0},
};
const static MCFixupKindInfo InfosBE[ARM::NumTargetFixupKinds] = {
// This table *must* be in the order that the fixup_* kinds are defined
in
@@ -133,6 +134,7 @@ const MCFixupKindInfo &ARMAsmBackend::ge
{"fixup_arm_movw_lo16", 12, 20, 0},
{"fixup_t2_movt_hi16", 12, 20, 0},
{"fixup_t2_movw_lo16", 12, 20, 0},
+ {"fixup_arm_mod_imm", 20, 12, 0},
};
if (Kind < FirstTargetFixupKind)
@@ -624,6 +626,13 @@ unsigned ARMAsmBackend::adjustFixupValue
return Value;
}
+ case ARM::fixup_arm_mod_imm:
+Value = ARM_AM::getSOImmVal(Value);
+if (Ctx && Value >> 12) {
+ Ctx->reportError(Fixup.getLoc(), "out of range immediate fixup value");
+ return 0;
+}
+return Value;
}
}
@@ -690,6 +699,7 @@ static unsigned getFixupKindNumBytes(uns
case FK_Data_2:
case ARM::fixup_arm_thumb_br:
case ARM::fixup_arm_thumb_cb:
+ case ARM::fixup_arm_mod_imm:
return 2;
case ARM::fixup_arm_pcrel_10_unscaled:
@@ -766,6 +776,7 @@ static unsigned getFixupKindContainerSiz
case ARM::fixup_arm_movw_lo16:
case ARM::fixup_t2_movt_hi16:
case ARM::fixup_t2_movw_lo16:
+ case ARM::fixup_arm_mod_imm:
// Instruction size is 4 bytes.
return 4;
}
Modified: head/contrib/llvm/lib/Target/ARM/MCTargetDesc/ARMFixupKinds.h
==
--- head/contrib/llvm/lib/Target/ARM/MCTargetDesc/ARMFixupKinds.h Sat Aug
20 13:29:58 2016(r304529)
+++ head/contrib/llvm/lib/Target/ARM/MCTargetDesc/ARMFixupKinds.h Sat Aug
20 14:04:51 2016(r304530)
@@ -100,6 +100,9 @@ enum Fixups {
fixup_t2_movt_hi16, // :upper16:
fixup_t2_movw_lo16, // :lower16:
+ // fixup_arm_mod_imm - Fixup for mod_imm
+ fixup_arm_mod_imm,
+
// Marker
LastTargetFixupKind,
NumTargetFixupKinds = LastTargetFixupKind - FirstTargetFixupKind
Modified: head/contrib/llvm/lib/Target/ARM/MCTargetDesc/ARMMCCodeEmitter.cpp
==
--- head/contrib/llvm/lib/Target/ARM/MCTargetDesc/ARMMCCodeEmitter.cpp Sat Aug
20 13:29:58 2016(r304529)
+++ head/contrib/llvm/lib/Target/ARM/MCTargetDesc/ARMMCCodeEmitter.cpp Sat Aug
20 14:04:51 2016(r304530)
@@ -312,12 +312,8 @@ public:
// Support for fixups (MCFixup)
if (MO.isExpr()) {
const MCExpr *Expr = MO.getExpr();
- // In instruction code this value always encoded as lowest 12 bits,
- // so we don't have to perform any specific adjustments.
- // Due to requirements of relocatable records we have to use FK_Data_4.
- // See ARMELFObjectWriter::ExplicitRelSym and
- // ARMELFObjectWriter::GetRelocTypeInner for more details.
- MCFixupKind Kind = MCFixupKind(FK_Data_4);
+ // Fixups resolve to plain values that need to be encoded.
+ MCFixupKind Kind = MCFixupKind(ARM::fixup_arm_mod_imm);
Fixups.push_back(MCFixup::create(0, Expr, Kind, MI.getLoc()));
Re: svn commit: r304513 - in head: . share/man/man4/man4.i386 sys/conf sys/dev/ie sys/i386/conf sys/modules sys/modules/ie sys/pc98/conf
On Saturday, August 20, 2016 12:49:30 AM John Baldwin wrote: > Author: jhb > Date: Sat Aug 20 00:49:29 2016 > New Revision: 304513 > URL: https://svnweb.freebsd.org/changeset/base/304513 > > Log: > Remove the ie(4) driver for Intel 82586 ISA Ethernet adapters. > > This driver only supports 10Mb Ethernet using PIO (the hardware supports > DMA, but the driver only does PIO). There are not any PCCard adapters > supported by this driver, only ISA cards. In addition, it does not use > bus_space but instead uses bcopy with volatile pointers triggering a > host of warnings. (if_ie.c is one of 3 files always built with > -Wno-error) > > Relnotes: yes This concludes the list of older drivers I had from earlier after working on the timeout(9) -> callout(9) changes (almost finished with that, just a few things left to test changes for, one of them being fail points before we can remove timeout()/untimeout() entirely). I do not have plans for removing any other drivers, though am open to suggestions. Some possibilities include: - tty drivers that haven't been updated to new tty and have been disconnected from the build since 8.0 including digi(4) and cy(4). I know Bruce has patches for sio(4) that I just haven't merged, so I'm inclined to leave sio(4), but the other disconnected drivers are candidates I think. - Older storage adapters: - aha (ISA) - ahb (EISA) - adv (ISA / EISA / PCI) - adw (PCI)? - bt (ISA / EISA / PCI) - aic (ISA / PCCard) - ct (ISA / CBUS) - dpt (ISA / EISA / PCI) - ncv (PCCard / PCI) - nsp (PCCard) - stg (ISA / PCCard / PCI) (Note: some of these are PC-98 related and might remove too much of the PC-98 ecosystem if removed?) - mse(4) (ISA-only non-PS-2, non-serial mouse) - joy(4) (ISA-only, was on various Sound Cards, etc., but I haven't seen a "game port" on a modern box in a long while) -- John Baldwin ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r304506 - in head: . release/doc/en_US.ISO8859-1/hardware share/man/man4/man4.i386 sys/conf sys/dev/wl sys/i386/conf sys/modules sys/modules/wl targets/pseudo/userland tools/build/mk t
On Friday, August 19, 2016 06:38:01 PM Warner Losh wrote: > On Fri, Aug 19, 2016 at 4:27 PM, John Baldwin wrote: > > Author: jhb > > Date: Fri Aug 19 22:27:14 2016 > > New Revision: 304506 > > URL: https://svnweb.freebsd.org/changeset/base/304506 > > > > Log: > > Remove the wl(4) driver and wlconfig(8) utility. > > > > The wl(4) driver supports pre-802.11 PCCard wireless adapters that > > are slower than 802.11b. They do not work with any of the 802.11 > > framework and the driver hasn't been reported to actually work in a > > long time. > > s/PC Card/ISA/g > > There never were any PC Card wl cards. These cards were ISA only > and ran at up to 1Mbps. Wow, even worse than I thought. -- John Baldwin ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r304436 - in head: . sys/netinet
On Sat, Aug 20, 2016 at 7:48 AM, Bruce Simpson wrote: > It is perfectly legal for broadcast packets to be addressed to the end of > a P2P or non-Ethernet link, which may not set M_BCAST or M_MCAST. The > classic example is ATM (Non-Broadcast, Multiple Access (NBMA)) but the > situation may be readily observed with loopback or tunnels. > Can you give an example of a tunneling protocol support by FreeBSD that may be affected? I looked and didn't see any. OpenVPN, as best that I can tell, injects frames into a tap interface, which appears as a Ethernet interface, for example. ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r304435 - head/sys/netinet
On Sat, Aug 20, 2016 at 6:08 AM, Kubilay Kocak wrote: > Hi Ryan, > > Could you elaborate on any of the potential performance implications of > this? > As if r304437, skipping the call to in_broadcast() means that we avoid an additional (potentially heavily contended) rlock acquire and release on the ifnet address list. ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r304436 - in head: . sys/netinet
On 20/08/16 15:52, Ryan Stone wrote: It is perfectly legal for broadcast packets to be addressed to the end of a P2P or non-Ethernet link, which may not set M_BCAST or M_MCAST. The classic example is ATM (Non-Broadcast, Multiple Access (NBMA)) but the situation may be readily observed with loopback or tunnels. Can you give an example of a tunneling protocol support by FreeBSD that may be affected? I looked and didn't see any. OpenVPN, as best that I can tell, injects frames into a tap interface, which appears as a Ethernet interface, for example. Potentially any and all PPP, tun(4); any link layer with plain IP on top of it other than Ethernet, which may not set M_BCAST for an IPv4 broadcast packet (or does not distinguish between broadcast and unicast/multicast packets). if_ethersubr.c does set M_BCAST correctly for Ethernet broadcast packets in the receive path. That is guaranteed, and the majority of Ethernet network drivers will pass packets up the stack through it more or less directly. tap(4) is an exception because, as you rightly point out, it is pretty faithfully Ethernet, although I may have had to add code around Ethernet address conditions like this to it in the very distant past. tun(4) on the other hand is a plain, PPP-like, IP tunnel. But this mbuf flag is not guaranteed to be set in all situations; e.g. where the link layer does not have the concept of broadcast being distinct from other kinds of network traffic. PPP and ATM are the most obvious examples. ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r304513 - in head: . share/man/man4/man4.i386 sys/conf sys/dev/ie sys/i386/conf sys/modules sys/modules/ie sys/pc98/conf
On Sat, Aug 20, 2016 at 07:51:55AM -0700, John Baldwin wrote: > - aha (ISA) > - bt (ISA / EISA / PCI) If anyone complains, tell them I'll ship them cards. If they consider that a threat ... so be it :-) (I *am* in the middle of a big decluttering, you know. I can find them ...) mcl ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r304436 - in head: . sys/netinet
On Sat, Aug 20, 2016 at 11:01 AM, Bruce Simpson wrote: > tun(4) on the other hand is a plain, PPP-like, IP tunnel. > Can you send a broadcast packet through an L3 tunnel? I thought that a L2 tunnel was required. But this mbuf flag is not guaranteed to be set in all situations; e.g. > where the link layer does not have the concept of broadcast being distinct > from other kinds of network traffic. PPP and ATM are the most obvious > examples. > We don't support ATM, but PPP is a good example. I hadn't thought of that. Hm, ip_input() already has to check for a broadcast IP. What it set M_BCAST on the mbuf at that time? ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r304436 - in head: . sys/netinet
On 20/08/16 16:27, Ryan Stone wrote: Can you send a broadcast packet through an L3 tunnel? I thought that a L2 tunnel was required. Yes. This is perfectly legal and necessary for forwarding of IPv4 broadcasts to work. (it is Internet Protocol after all, not Infernal-ethernet-extension Protocol. ;-)) The change is in UDP input so it will not affect routers. But if a FreeBSD system were at the end of a link layer, and was the final recipient of the IPv4 broadcast packet, then if that link layer is not Ethernet, all bets are off. That situation could occur very easily where FreeBSD is hanging off the end of a PPPoE link: e.g. consumer DSL, microwave, etc. The underlying link layer for the tunnel might be Ethernet, but it will be demuxed as a PPP tunnel. PPP is treated as a bit pipe and does not normally distinguish between unicast, broadcast, multicast. Broadcast destined for the host on its PPP address would be transported inside the tunnel, encapsulated as a normal unicast Ethernet packet. But this mbuf flag is not guaranteed to be set in all situations; e.g. where the link layer does not have the concept of broadcast being distinct from other kinds of network traffic. PPP and ATM are the most obvious examples. We don't support ATM, but PPP is a good example. I hadn't thought of that. Hm, ip_input() already has to check for a broadcast IP. What it set M_BCAST on the mbuf at that time? ATM is one of those things everyone kind of has to support by default in some way because of the ITU ADSL specs. It is literally written into G.992.x. Linux can do it, FreeBSD can't. PPP over ATM is something BT inflicted on the UK all by themselves, though, and we wish it would just go away. Whilst your suggestion may work, it may be dangerous, as you are then stepping on the meaning of the flags. Some of them are intended to be used for one layer to signal another. M_BCAST is pretty rigidly defined in mbuf.h as "The link layer received this as a broadcast / I intended for link layer to send this as a broadcast". M_PROTOFLAGS is normally used to clear flags with different meaning in different protocol layers. M_MCAST also has similar status. On my PhD, I wrote code which uses a private Ethernet link between FreeBSD routers for load distribution; it distributes unicast traffic using IPv6 multicast. It uses multicast both as convenience, and as a way to 'channelise' traffic if the Ethernet link supports it, using multicast groups. (Modern shared memory switches can slice L2 multicast traffic like this quite efficiently. So one slice of unicast traffic could be switched across locations purely at L2. However, the distribution of actual IPv6 multicast was out of scope.) The routers have to very carefully clear M_MCAST on egress, to ensure normal L2 next-hop resolution for IPv6 destinations. ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r304506 - in head: . release/doc/en_US.ISO8859-1/hardware share/man/man4/man4.i386 sys/conf sys/dev/wl sys/i386/conf sys/modules sys/modules/wl targets/pseudo/userland tools/build/mk t
On Sat, Aug 20, 2016 at 8:33 AM, John Baldwin wrote: > On Friday, August 19, 2016 06:38:01 PM Warner Losh wrote: >> On Fri, Aug 19, 2016 at 4:27 PM, John Baldwin wrote: >> > Author: jhb >> > Date: Fri Aug 19 22:27:14 2016 >> > New Revision: 304506 >> > URL: https://svnweb.freebsd.org/changeset/base/304506 >> > >> > Log: >> > Remove the wl(4) driver and wlconfig(8) utility. >> > >> > The wl(4) driver supports pre-802.11 PCCard wireless adapters that >> > are slower than 802.11b. They do not work with any of the 802.11 >> > framework and the driver hasn't been reported to actually work in a >> > long time. >> >> s/PC Card/ISA/g >> >> There never were any PC Card wl cards. These cards were ISA only >> and ran at up to 1Mbps. > > Wow, even worse than I thought. In the days of 144kbps ISDN lines being the best you could get many places, 1Mbps was awesome. I had one for a 7 mile link to a friend's house in town who had better connectivity. Cards supported by the awi driver were 2Mbps and were the first 802.11 cards. wi blew that away with 10Mbps and a variety of suppliers... wl lost its relevance in 2000 or so. wi was committed in 1999 for hardware that had been around a couple of years in various forms. There was a fast adaptation of it. I moved from my wl-based system to wi-based in 2000 or so once I was able to get a ISA to PC Card adapter and the right connectors to go from the funky tiny connectors on the WaveLan cards to the N connectors that the rest of the gear was setup with. Heck, wi hasn't been all that relevant since ath went into the tree with the boatload of features it supported and way better features... And that's been since 2003 or 2004 or so. Warner ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
svn commit: r304532 - in head/sys/boot: common efi/loader/arch/amd64 fdt
Author: tsoome
Date: Sat Aug 20 16:23:19 2016
New Revision: 304532
URL: https://svnweb.freebsd.org/changeset/base/304532
Log:
loader is filling fixed length command_errbuf with sprintf() and is trusting
strings provided by user/config files. This update is replacing sprintf with
snprintf for cases the command_errbuf is built from dynamic content.
PR: 211958
Reported by: ect...@gmail.com
Reviewed by: imp, allanjude
Approved by: imp (mentor), allanjude (mentor)
Differential Revision:https://reviews.freebsd.org/D7563
Modified:
head/sys/boot/common/boot.c
head/sys/boot/common/bootstrap.h
head/sys/boot/common/commands.c
head/sys/boot/common/interp.c
head/sys/boot/common/ls.c
head/sys/boot/common/module.c
head/sys/boot/efi/loader/arch/amd64/framebuffer.c
head/sys/boot/fdt/fdt_loader_cmd.c
Modified: head/sys/boot/common/boot.c
==
--- head/sys/boot/common/boot.c Sat Aug 20 15:20:01 2016(r304531)
+++ head/sys/boot/common/boot.c Sat Aug 20 16:23:19 2016(r304532)
@@ -61,7 +61,8 @@ command_boot(int argc, char *argv[])
/* XXX maybe we should discard everything and start again? */
if (file_findfile(NULL, NULL) != NULL) {
- sprintf(command_errbuf, "can't boot '%s', kernel module already
loaded", argv[1]);
+ snprintf(command_errbuf, sizeof(command_errbuf),
+ "can't boot '%s', kernel module already loaded", argv[1]);
return(CMD_ERROR);
}
@@ -129,7 +130,8 @@ command_autoboot(int argc, char *argv[])
case 2:
howlong = strtol(argv[1], &cp, 0);
if (*cp != 0) {
- sprintf(command_errbuf, "bad delay '%s'", argv[1]);
+ snprintf(command_errbuf, sizeof(command_errbuf),
+ "bad delay '%s'", argv[1]);
return(CMD_ERROR);
}
/* FALLTHROUGH */
Modified: head/sys/boot/common/bootstrap.h
==
--- head/sys/boot/common/bootstrap.hSat Aug 20 15:20:01 2016
(r304531)
+++ head/sys/boot/common/bootstrap.hSat Aug 20 16:23:19 2016
(r304532)
@@ -35,8 +35,9 @@
/* Commands and return values; nonzero return sets command_errmsg != NULL */
typedef int(bootblk_cmd_t)(int argc, char *argv[]);
+#defineCOMMAND_ERRBUFSZ(256)
extern char*command_errmsg;
-extern charcommand_errbuf[]; /* XXX blah, length */
+extern charcommand_errbuf[COMMAND_ERRBUFSZ];
#define CMD_OK 0
#define CMD_WARN 1
#define CMD_ERROR 2
Modified: head/sys/boot/common/commands.c
==
--- head/sys/boot/common/commands.c Sat Aug 20 15:20:01 2016
(r304531)
+++ head/sys/boot/common/commands.c Sat Aug 20 16:23:19 2016
(r304532)
@@ -33,7 +33,8 @@ __FBSDID("$FreeBSD$");
#include "bootstrap.h"
char *command_errmsg;
-char command_errbuf[256];/* XXX should have procedural interface
for setting, size limit? */
+/* XXX should have procedural interface for setting, size limit? */
+char command_errbuf[COMMAND_ERRBUFSZ];
static int page_file(char *filename);
@@ -196,7 +197,8 @@ command_help(int argc, char *argv[])
pager_close();
close(hfd);
if (!matched) {
- sprintf(command_errbuf, "no help available for '%s'", topic);
+ snprintf(command_errbuf, sizeof(command_errbuf),
+ "no help available for '%s'", topic);
free(topic);
if (subtopic)
free(subtopic);
@@ -276,7 +278,8 @@ command_show(int argc, char *argv[])
if ((cp = getenv(argv[1])) != NULL) {
printf("%s\n", cp);
} else {
- sprintf(command_errbuf, "variable '%s' not found", argv[1]);
+ snprintf(command_errbuf, sizeof(command_errbuf),
+ "variable '%s' not found", argv[1]);
return(CMD_ERROR);
}
}
@@ -386,7 +389,8 @@ command_read(int argc, char *argv[])
case 't':
timeout = strtol(optarg, &cp, 0);
if (cp == optarg) {
- sprintf(command_errbuf, "bad timeout '%s'", optarg);
+ snprintf(command_errbuf, sizeof(command_errbuf),
+ "bad timeout '%s'", optarg);
return(CMD_ERROR);
}
break;
@@ -454,8 +458,10 @@ page_file(char *filename)
result = pager_file(filename);
-if (result == -1)
- sprintf(command_errbuf, "error showing %s", filename);
+if (result == -1) {
+ snprintf(command_errbuf, sizeof(command_errbuf),
+ "error showing %s", filename);
+}
return result;
}
Modified: head/sys/boot/common/interp.c
==
--- head/sys/boot/common/interp.c Sat Aug 20 15:20:01 2016
Re: svn commit: r304513 - in head: . share/man/man4/man4.i386 sys/conf sys/dev/ie sys/i386/conf sys/modules sys/modules/ie sys/pc98/conf
On Sat, Aug 20, 2016 at 8:51 AM, John Baldwin wrote: > On Saturday, August 20, 2016 12:49:30 AM John Baldwin wrote: >> Author: jhb >> Date: Sat Aug 20 00:49:29 2016 >> New Revision: 304513 >> URL: https://svnweb.freebsd.org/changeset/base/304513 >> >> Log: >> Remove the ie(4) driver for Intel 82586 ISA Ethernet adapters. >> >> This driver only supports 10Mb Ethernet using PIO (the hardware supports >> DMA, but the driver only does PIO). There are not any PCCard adapters >> supported by this driver, only ISA cards. In addition, it does not use >> bus_space but instead uses bcopy with volatile pointers triggering a >> host of warnings. (if_ie.c is one of 3 files always built with >> -Wno-error) >> >> Relnotes: yes > > This concludes the list of older drivers I had from earlier after working > on the timeout(9) -> callout(9) changes (almost finished with that, just > a few things left to test changes for, one of them being fail points before > we can remove timeout()/untimeout() entirely). > > I do not have plans for removing any other drivers, though am open to > suggestions. Some possibilities include: > > - tty drivers that haven't been updated to new tty and have been disconnected > from the build since 8.0 including digi(4) and cy(4). I know Bruce has > patches for sio(4) that I just haven't merged, so I'm inclined to leave > sio(4), but the other disconnected drivers are candidates I think. These should be removed. > - Older storage adapters: > - aha (ISA) > - ahb (EISA) > - adv (ISA / EISA / PCI) > - adw (PCI)? > - bt (ISA / EISA / PCI) > - aic (ISA / PCCard) Most of these can go. There were PC Card versions of adv, but I never got around to getting the adv attachment working. Mostly because the cards were expensive and the one that fell into my hands lacked the dongle. aic was a workhorse, but I think is no longer. > - ct (ISA / CBUS) ct likely should stay. It's used in a lot of PC-98 gear that I think is still deployed. > - dpt (ISA / EISA / PCI) Not sure on this one. > - ncv (PCCard / PCI) > - nsp (PCCard) > - stg (ISA / PCCard / PCI) > (Note: some of these are PC-98 related and might remove too much of the >PC-98 ecosystem if removed?) That's hard to say. They were widely used on PC-9821 laptops back in the day, but I'm not sure how much. I'd be inclined to keep them in pending discussions with the pc98 folks. > - mse(4) (ISA-only non-PS-2, non-serial mouse) This is the PC-98 mouse. > - joy(4) (ISA-only, was on various Sound Cards, etc., but I haven't seen > a "game port" on a modern box in a long while) If it still works, what's the rush? Then again, I doubt it's been attached to in many years. EISA can likely be safely removed in 12. It was deprecated in 11 when I made it opt-in. MCA likely can go too. I used to have a boatload of aha and bt cards, but gave up on them years ago. It would be a shame to see them go, but it would help to cleanup CAM a bit since many of the dark corner cases in CAM exist for one ancient SIM or another. While I'd like my aic card to keep working, I've long since tossed the SCSI gear I used to connect with it. The PC Card network drivers, on the other hand, do all still work and I've tested them recently. I'll send pics of my wall of drawers that I keep them all in. My only request is that if there's any PC Card related removals to please put me on the reviews. Warner ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r304436 - in head: . sys/netinet
On 20/08/16 16:42, Bruce Simpson wrote: On 20/08/16 16:27, Ryan Stone wrote: Can you send a broadcast packet through an L3 tunnel? I thought that a L2 tunnel was required. Yes. This is perfectly legal and necessary for forwarding of IPv4 broadcasts to work. (it is Internet Protocol after all, not Infernal-ethernet-extension Protocol. ;-)) For completeness: This does not hold true for L2 in L2, the most obvious example being Metro Ethernet VMAN style service. There, Ethernet is the transport (link layer), as well as the payload. That's a concrete example of the kind of L2 'tunnel' you may be referring to. Sometimes, specific Ethernet [broad|multi]cast destinations -- notably L2 control protocols, e.g. RSTP within the customer VLAN, may need to be tunnelled (Provider-Backbone-Bridges (PBB) style). Alternatively, the L2 destination MAC may be rewritten for that specific address, to avoid the destination being interpreted by routers in the Metro Ethernet core. It can be considered a crude form of Ethernet NAT, but it's common practice. But, for IP, forwarding IPv4 directed broadcast packets over a non-broadcast link is completely legal (and required for normal operation). ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
svn commit: r304533 - vendor/dma/dist
Author: bapt
Date: Sat Aug 20 16:28:17 2016
New Revision: 304533
URL: https://svnweb.freebsd.org/changeset/base/304533
Log:
Import Dragonfly Mail agent snapshot from 2016-08-16
Modified:
vendor/dma/dist/VERSION
vendor/dma/dist/dma-mbox-create.c
vendor/dma/dist/dma.c
vendor/dma/dist/dma.h
vendor/dma/dist/dns.c
vendor/dma/dist/local.c
vendor/dma/dist/net.c
Modified: vendor/dma/dist/VERSION
==
--- vendor/dma/dist/VERSION Sat Aug 20 16:23:19 2016(r304532)
+++ vendor/dma/dist/VERSION Sat Aug 20 16:28:17 2016(r304533)
@@ -1 +1 @@
-v0.10
+v0.11
Modified: vendor/dma/dist/dma-mbox-create.c
==
--- vendor/dma/dist/dma-mbox-create.c Sat Aug 20 16:23:19 2016
(r304532)
+++ vendor/dma/dist/dma-mbox-create.c Sat Aug 20 16:28:17 2016
(r304533)
@@ -142,7 +142,7 @@ main(int argc, char **argv)
logfail(EX_CANTCREAT, "cannot build mbox path for `%s/%s'",
_PATH_MAILDIR, user);
}
- f = open(fn, O_RDONLY|O_CREAT, 0600);
+ f = open(fn, O_RDONLY|O_CREAT|O_NOFOLLOW, 0600);
if (f < 0)
logfail(EX_NOINPUT, "cannt open mbox `%s'", fn);
Modified: vendor/dma/dist/dma.c
==
--- vendor/dma/dist/dma.c Sat Aug 20 16:23:19 2016(r304532)
+++ vendor/dma/dist/dma.c Sat Aug 20 16:28:17 2016(r304533)
@@ -321,7 +321,7 @@ deliver(struct qitem *it)
snprintf(errmsg, sizeof(errmsg), "unknown bounce reason");
retry:
- syslog(LOG_INFO, "trying delivery");
+ syslog(LOG_INFO, "<%s> trying delivery", it->addr);
if (it->remote)
error = deliver_remote(it);
@@ -331,7 +331,7 @@ retry:
switch (error) {
case 0:
delqueue(it);
- syslog(LOG_INFO, "delivery successful");
+ syslog(LOG_INFO, "<%s> delivery successful", it->addr);
exit(EX_OK);
case 1:
Modified: vendor/dma/dist/dma.h
==
--- vendor/dma/dist/dma.h Sat Aug 20 16:23:19 2016(r304532)
+++ vendor/dma/dist/dma.h Sat Aug 20 16:28:17 2016(r304533)
@@ -49,7 +49,7 @@
#define VERSION"DragonFly Mail Agent " DMA_VERSION
#define BUF_SIZE 2048
-#define ERRMSG_SIZE200
+#define ERRMSG_SIZE1024
#define USERNAME_SIZE 50
#define MIN_RETRY 300 /* 5 minutes */
#define MAX_RETRY (3*60*60) /* retry at least every 3 hours */
Modified: vendor/dma/dist/dns.c
==
--- vendor/dma/dist/dns.c Sat Aug 20 16:23:19 2016(r304532)
+++ vendor/dma/dist/dns.c Sat Aug 20 16:28:17 2016(r304533)
@@ -34,6 +34,7 @@
*/
#include
+#include
#include
#include
#include
Modified: vendor/dma/dist/local.c
==
--- vendor/dma/dist/local.c Sat Aug 20 16:23:19 2016(r304532)
+++ vendor/dma/dist/local.c Sat Aug 20 16:28:17 2016(r304533)
@@ -196,7 +196,7 @@ retry:
goto out;
}
- error = snprintf(line, sizeof(line), "%sFrom %s\t%s", newline, sender,
ctime(&now));
+ error = snprintf(line, sizeof(line), "%sFrom %s %s", newline, sender,
ctime(&now));
if (error < 0 || (size_t)error >= sizeof(line)) {
syslog(LOG_NOTICE, "local delivery deferred: can not write
header: %m");
goto out;
Modified: vendor/dma/dist/net.c
==
--- vendor/dma/dist/net.c Sat Aug 20 16:23:19 2016(r304532)
+++ vendor/dma/dist/net.c Sat Aug 20 16:28:17 2016(r304533)
@@ -372,11 +372,13 @@ deliver_to_host(struct qitem *it, struct
host->host, host->addr, c, neterr); \
snprintf(errmsg, sizeof(errmsg), "%s [%s] did not like our
%s:\n%s", \
host->host, host->addr, c, neterr); \
- return (-1); \
+ error = -1; \
+ goto out; \
} else if (res != exp) { \
syslog(LOG_NOTICE, "remote delivery deferred: %s [%s] failed
after %s: %s", \
host->host, host->addr, c, neterr); \
- return (1); \
+ error = 1; \
+ goto out; \
}
/* Check first reply from remote host */
@@ -426,7 +428,8 @@ deliver_to_host(struct qitem *it, struct
syslog(LOG_ERR, "remote delivery failed:"
" SMTP login failed: %m");
snprintf(errmsg, sizeof(errmsg), "SMTP login to %s
failed", host->host);
svn commit: r304534 - vendor/dma/20160806
Author: bapt
Date: Sat Aug 20 16:29:08 2016
New Revision: 304534
URL: https://svnweb.freebsd.org/changeset/base/304534
Log:
tag import of Dragonfly Mail Agent 20160806
Added:
vendor/dma/20160806/
- copied from r304532, vendor/dma/dist/
Replaced:
vendor/dma/20160806/VERSION
- copied unchanged from r304533, vendor/dma/dist/VERSION
vendor/dma/20160806/dma-mbox-create.c
- copied unchanged from r304533, vendor/dma/dist/dma-mbox-create.c
vendor/dma/20160806/dma.c
- copied unchanged from r304533, vendor/dma/dist/dma.c
vendor/dma/20160806/dma.h
- copied unchanged from r304533, vendor/dma/dist/dma.h
vendor/dma/20160806/dns.c
- copied unchanged from r304533, vendor/dma/dist/dns.c
vendor/dma/20160806/local.c
- copied unchanged from r304533, vendor/dma/dist/local.c
vendor/dma/20160806/net.c
- copied unchanged from r304533, vendor/dma/dist/net.c
Copied: vendor/dma/20160806/VERSION (from r304533, vendor/dma/dist/VERSION)
==
--- /dev/null 00:00:00 1970 (empty, because file is newly added)
+++ vendor/dma/20160806/VERSION Sat Aug 20 16:29:08 2016(r304534, copy
of r304533, vendor/dma/dist/VERSION)
@@ -0,0 +1 @@
+v0.11
Copied: vendor/dma/20160806/dma-mbox-create.c (from r304533,
vendor/dma/dist/dma-mbox-create.c)
==
--- /dev/null 00:00:00 1970 (empty, because file is newly added)
+++ vendor/dma/20160806/dma-mbox-create.c Sat Aug 20 16:29:08 2016
(r304534, copy of r304533, vendor/dma/dist/dma-mbox-create.c)
@@ -0,0 +1,160 @@
+/*
+ * Copyright (c) 2010-2014, Simon Schubert <2...@0x2c.org>.
+ * Copyright (c) 2008 The DragonFly Project. All rights reserved.
+ *
+ * This code is derived from software contributed to The DragonFly Project
+ * by Simon Schubert <2...@0x2c.org>.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ *
+ * 1. Redistributions of source code must retain the above copyright
+ *notice, this list of conditions and the following disclaimer.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *notice, this list of conditions and the following disclaimer in
+ *the documentation and/or other materials provided with the
+ *distribution.
+ * 3. Neither the name of The DragonFly Project nor the names of its
+ *contributors may be used to endorse or promote products derived
+ *from this software without specific, prior written permission.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+ * ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+ * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS
+ * FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE
+ * COPYRIGHT HOLDERS OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT,
+ * INCIDENTAL, SPECIAL, EXEMPLARY OR CONSEQUENTIAL DAMAGES (INCLUDING,
+ * BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
+ * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED
+ * AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
+ * OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT
+ * OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
+ * SUCH DAMAGE.
+ */
+
+/*
+ * This binary is setuid root. Use extreme caution when touching
+ * user-supplied information. Keep the root window as small as possible.
+ */
+
+#include
+#include
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "dma.h"
+
+
+static void
+logfail(int exitcode, const char *fmt, ...)
+{
+ int oerrno = errno;
+ va_list ap;
+ char outs[1024];
+
+ outs[0] = 0;
+ if (fmt != NULL) {
+ va_start(ap, fmt);
+ vsnprintf(outs, sizeof(outs), fmt, ap);
+ va_end(ap);
+ }
+
+ errno = oerrno;
+ if (*outs != 0)
+ syslog(LOG_ERR, errno ? "%s: %m" : "%s", outs);
+ else
+ syslog(LOG_ERR, errno ? "%m" : "unknown error");
+
+ exit(exitcode);
+}
+
+/*
+ * Create a mbox in /var/mail for a given user, or make sure
+ * the permissions are correct for dma.
+ */
+
+int
+main(int argc, char **argv)
+{
+ const char *user;
+ struct passwd *pw;
+ struct group *gr;
+ uid_t user_uid;
+ gid_t mail_gid;
+ int error;
+ char fn[PATH_MAX+1];
+ int f;
+
+ openlog("dma-mbox-create", 0, LOG_MAIL);
+
+ errno = 0;
+ gr = getgrnam(DMA_GROUP);
+ if (!gr)
+ logfail(EX_CONFIG, "cannot find dma group `%s'", DMA_GROUP);
+
+ mail_gid = gr->gr_gid;
+
+ if (setgid(mail_gid) != 0)
+ logfail(EX_NOPERM, "cannot set gid to %d (%s)", mail_gid,
Re: svn commit: r304436 - in head: . sys/netinet
On 20/08/16 17:27, Bruce Simpson wrote: Alternatively, the L2 destination MAC may be rewritten for that specific address, to avoid the destination being interpreted by routers in the Metro Ethernet core. s/routers/switches/ -- in some views of the world, they are the same :) PBB is also known as 'MAC-in-MAC' for this reason. There's also L2TP pseudowires, but we're not really there yet. ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
svn commit: r304535 - in head: contrib/dma libexec/dma
Author: bapt
Date: Sat Aug 20 16:36:05 2016
New Revision: 304535
URL: https://svnweb.freebsd.org/changeset/base/304535
Log:
Import Dragonfly Mail Agent snapshort from 20160806 aka v0.11+
Most important change being:
dma - Fix security hole (#46)
Affecting DragonFly 4.6 and earlier, Matt Dillon fixed this in base after
finding out from BSDNow Episode 152. Comments following were from his commit
which explains better than I. Just taking his change and putting it here as
well.
* dma makes an age-old mistake of not properly checking whether a file
owned by a user is a symlink or not, a bug which the original mail.local
also had.
* Add O_NOFOLLOW to disallow symlinks.
Thanks-to: BSDNow Episode 152, made me dive dma to check when they talked
about the mail.local bug.
MFC After:2 days
Modified:
head/contrib/dma/VERSION
head/contrib/dma/dma-mbox-create.c
head/contrib/dma/dma.c
head/contrib/dma/dma.h
head/contrib/dma/dns.c
head/contrib/dma/local.c
head/contrib/dma/net.c
head/libexec/dma/Makefile.inc
Directory Properties:
head/contrib/dma/ (props changed)
Modified: head/contrib/dma/VERSION
==
--- head/contrib/dma/VERSIONSat Aug 20 16:29:08 2016(r304534)
+++ head/contrib/dma/VERSIONSat Aug 20 16:36:05 2016(r304535)
@@ -1 +1 @@
-v0.10
+v0.11
Modified: head/contrib/dma/dma-mbox-create.c
==
--- head/contrib/dma/dma-mbox-create.c Sat Aug 20 16:29:08 2016
(r304534)
+++ head/contrib/dma/dma-mbox-create.c Sat Aug 20 16:36:05 2016
(r304535)
@@ -142,7 +142,7 @@ main(int argc, char **argv)
logfail(EX_CANTCREAT, "cannot build mbox path for `%s/%s'",
_PATH_MAILDIR, user);
}
- f = open(fn, O_RDONLY|O_CREAT, 0600);
+ f = open(fn, O_RDONLY|O_CREAT|O_NOFOLLOW, 0600);
if (f < 0)
logfail(EX_NOINPUT, "cannt open mbox `%s'", fn);
Modified: head/contrib/dma/dma.c
==
--- head/contrib/dma/dma.c Sat Aug 20 16:29:08 2016(r304534)
+++ head/contrib/dma/dma.c Sat Aug 20 16:36:05 2016(r304535)
@@ -321,7 +321,7 @@ deliver(struct qitem *it)
snprintf(errmsg, sizeof(errmsg), "unknown bounce reason");
retry:
- syslog(LOG_INFO, "trying delivery");
+ syslog(LOG_INFO, "<%s> trying delivery", it->addr);
if (it->remote)
error = deliver_remote(it);
@@ -331,7 +331,7 @@ retry:
switch (error) {
case 0:
delqueue(it);
- syslog(LOG_INFO, "delivery successful");
+ syslog(LOG_INFO, "<%s> delivery successful", it->addr);
exit(EX_OK);
case 1:
Modified: head/contrib/dma/dma.h
==
--- head/contrib/dma/dma.h Sat Aug 20 16:29:08 2016(r304534)
+++ head/contrib/dma/dma.h Sat Aug 20 16:36:05 2016(r304535)
@@ -49,7 +49,7 @@
#define VERSION"DragonFly Mail Agent " DMA_VERSION
#define BUF_SIZE 2048
-#define ERRMSG_SIZE200
+#define ERRMSG_SIZE1024
#define USERNAME_SIZE 50
#define MIN_RETRY 300 /* 5 minutes */
#define MAX_RETRY (3*60*60) /* retry at least every 3 hours */
Modified: head/contrib/dma/dns.c
==
--- head/contrib/dma/dns.c Sat Aug 20 16:29:08 2016(r304534)
+++ head/contrib/dma/dns.c Sat Aug 20 16:36:05 2016(r304535)
@@ -34,6 +34,7 @@
*/
#include
+#include
#include
#include
#include
Modified: head/contrib/dma/local.c
==
--- head/contrib/dma/local.cSat Aug 20 16:29:08 2016(r304534)
+++ head/contrib/dma/local.cSat Aug 20 16:36:05 2016(r304535)
@@ -196,7 +196,7 @@ retry:
goto out;
}
- error = snprintf(line, sizeof(line), "%sFrom %s\t%s", newline, sender,
ctime(&now));
+ error = snprintf(line, sizeof(line), "%sFrom %s %s", newline, sender,
ctime(&now));
if (error < 0 || (size_t)error >= sizeof(line)) {
syslog(LOG_NOTICE, "local delivery deferred: can not write
header: %m");
goto out;
Modified: head/contrib/dma/net.c
==
--- head/contrib/dma/net.c Sat Aug 20 16:29:08 2016(r304534)
+++ head/contrib/dma/net.c Sat Aug 20 16:36:05 2016(r304535)
@@ -372,11 +372,13 @@ deliver_to_host(struct qitem *it, struct
host->host, host->addr, c, neterr); \
snprintf(errmsg, sizeof(errmsg), "%s [%s] did not like our
%s:\n%s", \
Re: svn commit: r304436 - in head: . sys/netinet
+ adrian@, who prompted me to look at UDP in the first place I'm really not sure what my next step should be. I'm willing to revert r304436, but I really don't want to revert r304437 because we've seen crashes in the real world due to the missing locking. Unfortunately, reverting r304436 would mean that every UDP packet would incur the overhead of an additional rlock/runlock call, which is what I've been trying to avoid. I don't see a particularly good path forward. - The if_addr_lock would appear to be an excellent candidate to be converted into an rmlock, but unfortunately we made the mistake of exposing the lock through the ifnet KPI. Fixing that would require rototilling every single Ethernet/WiFi/etc driver in the tree. - Providing a mechanism for ip_input() to signal to udp_input() that the packet was addressed to an L3 broadcast address would require rototilling the pr_input interface, and I'd have to carefully ensure that if anything might interpose itself between the two layers (IPSec?) that the flag would have to be passed through correctly. - mbuf flags are far too precious to allocate a new one for such a narrow use-case On Sat, Aug 20, 2016 at 11:42 AM, Bruce Simpson wrote: > On 20/08/16 16:27, Ryan Stone wrote: > >> Can you send a broadcast packet through an L3 tunnel? I thought that a >> L2 tunnel was required. >> > > Yes. This is perfectly legal and necessary for forwarding of IPv4 > broadcasts to work. (it is Internet Protocol after all, not > Infernal-ethernet-extension Protocol. ;-)) > > The change is in UDP input so it will not affect routers. But if a FreeBSD > system were at the end of a link layer, and was the final recipient of the > IPv4 broadcast packet, then if that link layer is not Ethernet, all bets > are off. > > That situation could occur very easily where FreeBSD is hanging off the > end of a PPPoE link: e.g. consumer DSL, microwave, etc. > > The underlying link layer for the tunnel might be Ethernet, but it will be > demuxed as a PPP tunnel. PPP is treated as a bit pipe and does not normally > distinguish between unicast, broadcast, multicast. > > Broadcast destined for the host on its PPP address would be transported > inside the tunnel, encapsulated as a normal unicast Ethernet packet. > > But this mbuf flag is not guaranteed to be set in all situations; >> e.g. where the link layer does not have the concept of broadcast >> being distinct from other kinds of network traffic. PPP and ATM are >> the most obvious examples. >> >> >> We don't support ATM, but PPP is a good example. I hadn't thought of >> that. Hm, ip_input() already has to check for a broadcast IP. What it >> set M_BCAST on the mbuf at that time? >> > > ATM is one of those things everyone kind of has to support by default in > some way because of the ITU ADSL specs. It is literally written into > G.992.x. > > Linux can do it, FreeBSD can't. PPP over ATM is something BT inflicted on > the UK all by themselves, though, and we wish it would just go away. > > Whilst your suggestion may work, it may be dangerous, as you are then > stepping on the meaning of the flags. Some of them are intended to be used > for one layer to signal another. > > M_BCAST is pretty rigidly defined in mbuf.h as "The link layer received > this as a broadcast / I intended for link layer to send this as a > broadcast". M_PROTOFLAGS is normally used to clear flags with different > meaning in different protocol layers. > > M_MCAST also has similar status. On my PhD, I wrote code which uses a > private Ethernet link between FreeBSD routers for load distribution; it > distributes unicast traffic using IPv6 multicast. > > It uses multicast both as convenience, and as a way to 'channelise' > traffic if the Ethernet link supports it, using multicast groups. (Modern > shared memory switches can slice L2 multicast traffic like this quite > efficiently. So one slice of unicast traffic could be switched across > locations purely at L2. However, the distribution of actual IPv6 multicast > was out of scope.) > > The routers have to very carefully clear M_MCAST on egress, to ensure > normal L2 next-hop resolution for IPv6 destinations. > > ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r304436 - in head: . sys/netinet
On 20/08/16 17:36, Ryan Stone wrote: + adrian@, who prompted me to look at UDP in the first place I'm really not sure what my next step should be. I'm willing to revert r304436, but I really don't want to revert r304437 because we've seen crashes in the real world due to the missing locking. Unfortunately, reverting r304436 would mean that every UDP packet would incur the overhead of an additional rlock/runlock call, which is what I've been trying to avoid. I don't see a particularly good path forward. Your changes have the same motivations as my historical change to move group-level IP multicast lookups (and locking) out of the output path. Source-specific multicast (SSM) requires support for reception filters on individual sockets, so I moved those multicast-specific input checks into the socket layer. - The if_addr_lock would appear to be an excellent candidate to be converted into an rmlock, but unfortunately we made the mistake of exposing the lock through the ifnet KPI. Fixing that would require rototilling every single Ethernet/WiFi/etc driver in the tree. Oops... - Providing a mechanism for ip_input() to signal to udp_input() that the packet was addressed to an L3 broadcast address would require rototilling the pr_input interface, and I'd have to carefully ensure that if anything might interpose itself between the two layers (IPSec?) that the flag would have to be passed through correctly. - mbuf flags are far too precious to allocate a new one for such a narrow use-case Agree. Then it may be that slipping the definition of M_BCAST to mean 'And IP identified that this is network-layer broadcast' is the most expedient solution. A quick look around suggests you may be able to get away with it. You'd essentially be widening the definition of the existing M_BCAST flag. Given the ultimate consumer of the mbuf in the case you are addressing in the code (bad pun) is udp_input(), that may be fine. (We had to do something similar for ILNPv6, because of how IPv6 input works, so it allocates an unused bit from the IPv6 flow label.) But it has to be qualified very carefully. If L2 is re-entered from IP (e.g. a netgraph IP-level hook), it may have unexpected side-effects. I have not given this the KScope treatment, just a quick fxr.watson.org. ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r304436 - in head: . sys/netinet
On 20/08/16 17:49, Bruce Simpson wrote: - Providing a mechanism for ip_input() to signal to udp_input() that the packet was addressed to an L3 broadcast address would require rototilling the pr_input interface, and I'd have to carefully ensure that if anything might interpose itself between the two layers (IPSec?) that the flag would have to be passed through correctly. (We had to do something similar for ILNPv6, because of how IPv6 input works, so it allocates an unused bit from the IPv6 flow label.) In case anyone's interested, IPSEC is one big reason we had to do this. Performance was another; without marking ILNPv6 traffic, demultiplexing an ILNPv6 packet -- even 'just enough' to forward it -- would have required processing all IPv6 extension headers, and additional state lookups. Using a bit from the flow label means ILNPv6 routers don't need to do any of that, and it got translated into an M_ILNP mbuf flag internally. I shudder to think what gymnastics the FreeBSD stack may have to endure to accommodate modern Ethernet switching capabilities, though. ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r304244 - head/sys/kern
On 8/16/2016 2:55 PM, Gleb Smirnoff wrote:
> Author: glebius
> Date: Tue Aug 16 21:55:34 2016
> New Revision: 304244
> URL: https://svnweb.freebsd.org/changeset/base/304244
>
> Log:
> We should not be allowing a timeout to reset when a drain is in progress on
> it (either async or sync drain).
>
> At this moment the only user of drain is TCP, but TCP wouldn't reschedule a
> callout after it has drained it, since it drains only when a tcpcb is
> closed.
> This for now the problem isn't observed.
>
> Submitted by: rrs
Should this be MFC'd into 11.0?
>
> Modified:
> head/sys/kern/kern_timeout.c
>
> Modified: head/sys/kern/kern_timeout.c
> ==
> --- head/sys/kern/kern_timeout.c Tue Aug 16 21:32:05 2016
> (r304243)
> +++ head/sys/kern/kern_timeout.c Tue Aug 16 21:55:34 2016
> (r304244)
> @@ -1061,7 +1061,7 @@ callout_reset_sbt_on(struct callout *c,
>*/
> if (c->c_lock != NULL && !cc_exec_cancel(cc, direct))
> cancelled = cc_exec_cancel(cc, direct) = true;
> - if (cc_exec_waiting(cc, direct)) {
> + if (cc_exec_waiting(cc, direct) || cc_exec_drain(cc, dir)) {
> /*
>* Someone has called callout_drain to kill this
>* callout. Don't reschedule.
>
--
Regards,
Bryan Drewery
signature.asc
Description: OpenPGP digital signature
Re: svn commit: r304436 - in head: . sys/netinet
On Sat, Aug 20, 2016 at 12:36:58PM -0400, Ryan Stone wrote: > + adrian@, who prompted me to look at UDP in the first place > > > I'm really not sure what my next step should be. I'm willing to revert > r304436, but I really don't want to revert r304437 because we've seen > crashes in the real world due to the missing locking. Unfortunately, > reverting r304436 would mean that every UDP packet would incur the overhead > of an additional rlock/runlock call, which is what I've been trying to > avoid. I don't see a particularly good path forward. As I understund specific handling of broadcast required only for routers (by RFC1812). For host enought have [hidden] alias with broadcsts bits. Anyway, don't should relay on the L2 information, you can recive L3 unicast addressed packets (with alien dst IP address) in L2 broadcas packet. Sorry if I am miss something in you discurs. ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r304436 - in head: . sys/netinet
On 20/08/16 18:30, Slawa Olhovchenkov wrote: Anyway, don't should relay on the L2 information, you can recive L3 unicast addressed packets (with alien dst IP address) in L2 broadcas packet. That is exactly what the egress routers in chapter 6 of my PhD do, but in a very controlled way -- by setting and clearing M_MCAST ! http://hdl.handle.net/10023/8681 In Ch6, ILNPv6 packets are effective being routed, using a multicast next-hop address (as distinct from the destination I-LV, which in turn is distinct from an IPv6 destination -- it just uses the same format.) It's counter-intuitive (and should not happen outside of that constrained scenario), but it has real world applications. ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r304436 - in head: . sys/netinet
On Sat, Aug 20, 2016 at 1:30 PM, Slawa Olhovchenkov wrote: > For host enought have [hidden] alias with broadcsts bits. > Anyway, don't should relay on the L2 information, you can recive L3 > unicast addressed packets (with alien dst IP address) in L2 broadcas > packet. > This is still handled correctly. The new code only checks for L3 broadcast addresses on L2 broadcast packets, but we still check the L3 address before treating it as a broadcast. The problem is that I assumed that all paths into the IP stack would set M_BCAST, but as Bruce has pointed out there are cases like PPP which do not. ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r304436 - in head: . sys/netinet
On 20 August 2016 at 11:02, Ryan Stone wrote: > On Sat, Aug 20, 2016 at 1:30 PM, Slawa Olhovchenkov wrote: >> >> For host enought have [hidden] alias with broadcsts bits. >> Anyway, don't should relay on the L2 information, you can recive L3 >> unicast addressed packets (with alien dst IP address) in L2 broadcas >> packet. > > > This is still handled correctly. The new code only checks for L3 broadcast > addresses on L2 broadcast packets, but we still check the L3 address before > treating it as a broadcast. The problem is that I assumed that all paths > into the IP stack would set M_BCAST, but as Bruce has pointed out there are > cases like PPP which do not. Hi, So why not fix those paths? -adrian ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r304436 - in head: . sys/netinet
On 20/08/16 19:09, Adrian Chadd wrote: On 20 August 2016 at 11:02, Ryan Stone wrote: On Sat, Aug 20, 2016 at 1:30 PM, Slawa Olhovchenkov wrote: For host enought have [hidden] alias with broadcsts bits. Anyway, don't should relay on the L2 information, you can recive L3 unicast addressed packets (with alien dst IP address) in L2 broadcas packet. This is still handled correctly. The new code only checks for L3 broadcast addresses on L2 broadcast packets, but we still check the L3 address before treating it as a broadcast. The problem is that I assumed that all paths into the IP stack would set M_BCAST, but as Bruce has pointed out there are cases like PPP which do not. So why not fix those paths? Because it would involve doing something similar to what if_ethersubr.c does right now: a direct comparison with FF:FF:FF:FF:FF:FF. Doing so outside of Ethernet would be invasive and one of those 'bad' layer crossings. This is tricky to get right. NetBSD introduced the M_PROMISC flag to cover situations which can occur when Ethernet can be re-entered by layers 'above' its original invocation. (I merged it here.) Ryan proposes slipping the definition of M_BCAST to include the network layer, inside ip_input() itself. That would not strictly violate layering, but bends the original meaning of the flag somewhat. That may work, provided it doesn't tread on the toes of anything above it. However the situation is somewhat similar to that of M_PROMISC. ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r304506 - in head: . release/doc/en_US.ISO8859-1/hardware share/man/man4/man4.i386 sys/conf sys/dev/wl sys/i386/conf sys/modules sys/modules/wl targets/pseudo/userland tools/build/mk t
[snip] I ... may do some kind of anniversary related work to fix up wi support again. Because - and this is pretty god damned hilarious - the same stack features (no raw frames, 802.3 encapsulation, scan/join/etc done via commands only, etc) that I need to 'fix' for wi are also required for almost all the 11ac hardware. ... -a ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r304436 - in head: . sys/netinet
On Sat, Aug 20, 2016 at 2:09 PM, Adrian Chadd wrote: > Hi, > > So why not fix those paths? > > > > -adrian > Is there even a fix that can be done there? I wouldn't expect a point-to-point protocol like PPP to have any need to explicitly signal that a packet is a broadcast. Is the information even available at that layer? ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r304506 - in head: . release/doc/en_US.ISO8859-1/hardware share/man/man4/man4.i386 sys/conf sys/dev/wl sys/i386/conf sys/modules sys/modules/wl targets/pseudo/userland tools/build/mk t
On Sat, Aug 20, 2016 at 12:14 PM, Adrian Chadd wrote: > [snip] > > I ... may do some kind of anniversary related work to fix up wi support again. > > Because - and this is pretty god damned hilarious - the same stack > features (no raw frames, 802.3 encapsulation, scan/join/etc done via > commands only, etc) that I need to 'fix' for wi are also required for > almost all the 11ac hardware. I'm not saying don't fix it. There's a bunch of older laptops that still have these cards in them (much to my amazement). Just that it shouldn't be a priority. If it works, keep it in the tree. If it is broken, though, the time has come to ditch it... Warner ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r304436 - in head: . sys/netinet
On Sat, Aug 20, 2016 at 02:02:16PM -0400, Ryan Stone wrote: > On Sat, Aug 20, 2016 at 1:30 PM, Slawa Olhovchenkov wrote: > > > For host enought have [hidden] alias with broadcsts bits. > > Anyway, don't should relay on the L2 information, you can recive L3 > > unicast addressed packets (with alien dst IP address) in L2 broadcas > > packet. > > > > This is still handled correctly. The new code only checks for L3 broadcast > addresses on L2 broadcast packets, but we still check the L3 address before > treating it as a broadcast. The problem is that I assumed that all paths > into the IP stack would set M_BCAST, but as Bruce has pointed out there are > cases like PPP which do not. You also can recive this on ethernet too, IMHO, in case of /32. Receiving L3 broadcst in L2 unicast is legitime (IMHO) and we must be relaxed on this. ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
svn commit: r304537 - head/sys/kern
Author: rwatson
Date: Sat Aug 20 18:51:48 2016
New Revision: 304537
URL: https://svnweb.freebsd.org/changeset/base/304537
Log:
Audit additional vnode information in the implementation of the
ftruncate(2) system call. This was not required by the Common
Criteria, which needed only open-time audit.
MFC after:2 weeks
Sponsored by: DARPA, AFRL
Modified:
head/sys/kern/vfs_vnops.c
Modified: head/sys/kern/vfs_vnops.c
==
--- head/sys/kern/vfs_vnops.c Sat Aug 20 18:45:25 2016(r304536)
+++ head/sys/kern/vfs_vnops.c Sat Aug 20 18:51:48 2016(r304537)
@@ -1302,6 +1302,7 @@ vn_truncate(struct file *fp, off_t lengt
if (error)
goto out1;
vn_lock(vp, LK_EXCLUSIVE | LK_RETRY);
+ AUDIT_ARG_VNODE1(vp);
if (vp->v_type == VDIR) {
error = EISDIR;
goto out;
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r304436 - in head: . sys/netinet
On Sat, Aug 20, 2016 at 2:45 PM, Slawa Olhovchenkov wrote: > You also can recive this on ethernet too, IMHO, in case of /32. > Receiving L3 broadcst in L2 unicast is legitime (IMHO) and we must be > relaxed on this. > There is no broadcast address on a /32 network. Independent of my change, we would not treat a packet received on a /32 network as a broadcast here because in_broadcast() will return 0 for it. ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r304436 - in head: . sys/netinet
On Sat, Aug 20, 2016 at 02:57:36PM -0400, Ryan Stone wrote: > On Sat, Aug 20, 2016 at 2:45 PM, Slawa Olhovchenkov wrote: > > > You also can recive this on ethernet too, IMHO, in case of /32. > > Receiving L3 broadcst in L2 unicast is legitime (IMHO) and we must be > > relaxed on this. > > > > There is no broadcast address on a /32 network. Independent of my change, > we would not treat a packet received on a /32 network as a broadcast here > because in_broadcast() will return 0 for it. /32 only from router side (+proxy arp). host configured for /24 ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r304513 - in head: . share/man/man4/man4.i386 sys/conf sys/dev/ie sys/i386/conf sys/modules sys/modules/ie sys/pc98/conf
In message <1699917.hhfokya...@ralph.baldwin.cx>, John Baldwin writes: > On Saturday, August 20, 2016 12:49:30 AM John Baldwin wrote: > > Author: jhb > > Date: Sat Aug 20 00:49:29 2016 > > New Revision: 304513 > > URL: https://svnweb.freebsd.org/changeset/base/304513 > > > > Log: > > Remove the ie(4) driver for Intel 82586 ISA Ethernet adapters. > > > > This driver only supports 10Mb Ethernet using PIO (the hardware supports > > DMA, but the driver only does PIO). There are not any PCCard adapters > > supported by this driver, only ISA cards. In addition, it does not use > > bus_space but instead uses bcopy with volatile pointers triggering a > > host of warnings. (if_ie.c is one of 3 files always built with > > -Wno-error) > > > > Relnotes: yes > > This concludes the list of older drivers I had from earlier after working > on the timeout(9) -> callout(9) changes (almost finished with that, just > a few things left to test changes for, one of them being fail points before > we can remove timeout()/untimeout() entirely). > > I do not have plans for removing any other drivers, though am open to > suggestions. Some possibilities include: > > - tty drivers that haven't been updated to new tty and have been disconnected > from the build since 8.0 including digi(4) and cy(4). I know Bruce has > patches for sio(4) that I just haven't merged, so I'm inclined to leave > sio(4), but the other disconnected drivers are candidates I think. > - Older storage adapters: > - aha (ISA) I have a bunch of AHA-1542s in a storage locker (along with the contents of my house when I sold it). I recall that SCSI was better behaved on my first FreeBSD machine (FreeBSD 2.0.5) than was IDE. (Except for IDE support, Linux sucked badly in all other areas at the time, thus my introduction to FreeBSD, thanks to jkh@. But that's going down memory lane...) I digress... > - ahb (EISA) > - adv (ISA / EISA / PCI) > - adw (PCI)? > - bt (ISA / EISA / PCI) I have one of these. IIRC, a 948 PCI card. Though I don't use it any more. The Adaptec 2940s -- ahc -- of which I have many -- were my mainstay. > - aic (ISA / PCCard) > - ct (ISA / CBUS) > - dpt (ISA / EISA / PCI) > - ncv (PCCard / PCI) > - nsp (PCCard) > - stg (ISA / PCCard / PCI) > (Note: some of these are PC-98 related and might remove too much of the >PC-98 ecosystem if removed?) > - mse(4) (ISA-only non-PS-2, non-serial mouse) > - joy(4) (ISA-only, was on various Sound Cards, etc., but I haven't seen > a "game port" on a modern box in a long while) > Hmmm. I could open another bikeshed here. I'd better not. -- Cheers, Cy Schubert FreeBSD UNIX: Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few. ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r304513 - in head: . share/man/man4/man4.i386 sys/conf sys/dev/ie sys/i386/conf sys/modules sys/modules/ie sys/pc98/conf
In message <20160820152406.ga8...@lonesome.com>, Mark Linimon writes: > On Sat, Aug 20, 2016 at 07:51:55AM -0700, John Baldwin wrote: > > - aha (ISA) > > - bt (ISA / EISA / PCI) > > If anyone complains, tell them I'll ship them cards. > > If they consider that a threat ... so be it :-) > > (I *am* in the middle of a big decluttering, you know. I can find > them ...) Add my BT-948 to the list. -- Cheers, Cy Schubert FreeBSD UNIX: Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few. ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r304436 - in head: . sys/netinet
On 20/08/16 19:57, Ryan Stone wrote: On Sat, Aug 20, 2016 at 2:45 PM, Slawa Olhovchenkov mailto:s...@zxy.spb.ru>> wrote: You also can recive this on ethernet too, IMHO, in case of /32. Receiving L3 broadcst in L2 unicast is legitime (IMHO) and we must be relaxed on this. There is no broadcast address on a /32 network. Independent of my change, we would not treat a packet received on a /32 network as a broadcast here because in_broadcast() will return 0 for it. Hmm. That is not entirely true for /32. Even though the link layer might be Ethernet in that case, in the traditional BSD ifnet sense, while the broadcast address slot may have the same value (and actual location) as the peer end of a P2P (as in generically IFF_PPP, not just pppd(8)) interface), because it's on an Ethernet (IFF_BROADCAST) interface, the host part of the /32's value in in the broadcast address is still valid, and will probably get mapped that way if M_BCAST is set on outgoing traffic. (You are, after all, going to go through ARP on Ethernet, even for a /32, so that mapping will be triggered.) Unless I am missing something crucial here? As far as I can tell, arpresolve() unconditionally resolves L2 next-hop to the value of ifp->if_broadcastaddr. And that is always set to 'etherbroadcastaddr' by default for Ethernet ifnets: FF:FF:FF:FF:FF:FF. Would that not get past the M_BCAST check which replaced the call to in_broadcast()? ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
svn commit: r304543 - head/sys/netinet
Author: tuexen
Date: Sat Aug 20 20:15:36 2016
New Revision: 304543
URL: https://svnweb.freebsd.org/changeset/base/304543
Log:
Unbreak sctp_connectx().
MFC after: 3 days
Modified:
head/sys/netinet/sctputil.c
Modified: head/sys/netinet/sctputil.c
==
--- head/sys/netinet/sctputil.c Sat Aug 20 19:48:03 2016(r304542)
+++ head/sys/netinet/sctputil.c Sat Aug 20 20:15:36 2016(r304543)
@@ -6356,7 +6356,7 @@ sctp_connectx_helper_find(struct sctp_in
struct sctp_tcb *stcb = NULL;
unsigned int incr, at, i;
- at = incr = 0;
+ at = 0;
sa = addr;
*error = *num_v6 = *num_v4 = 0;
/* account and validate addresses */
@@ -6364,6 +6364,7 @@ sctp_connectx_helper_find(struct sctp_in
switch (sa->sa_family) {
#ifdef INET
case AF_INET:
+ incr = (unsigned int)sizeof(struct sockaddr_in);
if (sa->sa_len != incr) {
SCTP_LTRACE_ERR_RET(inp, NULL, NULL,
SCTP_FROM_SCTPUTIL, EINVAL);
*error = EINVAL;
@@ -6371,7 +6372,6 @@ sctp_connectx_helper_find(struct sctp_in
return (NULL);
}
(*num_v4) += 1;
- incr = (unsigned int)sizeof(struct sockaddr_in);
break;
#endif
#ifdef INET6
@@ -6387,6 +6387,7 @@ sctp_connectx_helper_find(struct sctp_in
*bad_addr = 1;
return (NULL);
}
+ incr = (unsigned int)sizeof(struct
sockaddr_in6);
if (sa->sa_len != incr) {
SCTP_LTRACE_ERR_RET(inp, NULL, NULL,
SCTP_FROM_SCTPUTIL, EINVAL);
*error = EINVAL;
@@ -6394,7 +6395,6 @@ sctp_connectx_helper_find(struct sctp_in
return (NULL);
}
(*num_v6) += 1;
- incr = (unsigned int)sizeof(struct
sockaddr_in6);
break;
}
#endif
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
svn commit: r304544 - in head/sys: kern security/audit
Author: rwatson
Date: Sat Aug 20 20:28:08 2016
New Revision: 304544
URL: https://svnweb.freebsd.org/changeset/base/304544
Log:
Audit the accepted (or rejected) username argument to setlogin(2).
(NB: This was likely a mismerge from XNU in audit support, where the
text argument to setlogin(2) is captured -- but as a text token,
whereas this change uses the dedicated login-name field in struct
audit_record.)
MFC after:2 weeks
Sponsored by: DARPA, AFRL
Modified:
head/sys/kern/kern_prot.c
head/sys/security/audit/audit.h
head/sys/security/audit/audit_bsm.c
Modified: head/sys/kern/kern_prot.c
==
--- head/sys/kern/kern_prot.c Sat Aug 20 20:15:36 2016(r304543)
+++ head/sys/kern/kern_prot.c Sat Aug 20 20:28:08 2016(r304544)
@@ -2105,6 +2105,7 @@ sys_setlogin(struct thread *td, struct s
error = EINVAL;
return (error);
}
+ AUDIT_ARG_LOGIN(logintmp);
PROC_LOCK(p);
SESS_LOCK(p->p_session);
strcpy(p->p_session->s_login, logintmp);
Modified: head/sys/security/audit/audit.h
==
--- head/sys/security/audit/audit.h Sat Aug 20 20:15:36 2016
(r304543)
+++ head/sys/security/audit/audit.h Sat Aug 20 20:28:08 2016
(r304544)
@@ -212,6 +212,11 @@ voidaudit_thread_free(struct thread *t
audit_arg_groupset((gidset), (gidset_size));\
} while (0)
+#defineAUDIT_ARG_LOGIN(login) do {
\
+ if (AUDITING_TD(curthread)) \
+ audit_arg_login((login)); \
+} while (0)
+
#defineAUDIT_ARG_MODE(mode) do {
\
if (AUDITING_TD(curthread)) \
audit_arg_mode((mode)); \
@@ -354,6 +359,7 @@ void audit_thread_free(struct thread *t
#defineAUDIT_ARG_FFLAGS(fflags)
#defineAUDIT_ARG_GID(gid)
#defineAUDIT_ARG_GROUPSET(gidset, gidset_size)
+#defineAUDIT_ARG_LOGIN(login)
#defineAUDIT_ARG_MODE(mode)
#defineAUDIT_ARG_OWNER(uid, gid)
#defineAUDIT_ARG_PID(pid)
Modified: head/sys/security/audit/audit_bsm.c
==
--- head/sys/security/audit/audit_bsm.c Sat Aug 20 20:15:36 2016
(r304543)
+++ head/sys/security/audit/audit_bsm.c Sat Aug 20 20:28:08 2016
(r304544)
@@ -1394,8 +1394,8 @@ kaudit_to_bsm(struct kaudit_record *kar,
break;
case AUE_SETLOGIN:
- if (ARG_IS_VALID(kar, ARG_TEXT)) {
- tok = au_to_text(ar->ar_arg_text);
+ if (ARG_IS_VALID(kar, ARG_LOGIN)) {
+ tok = au_to_text(ar->ar_arg_login);
kau_write(rec, tok);
}
break;
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r304436 - in head: . sys/netinet
On 20/08/16 21:05, Bruce Simpson wrote: Unless I am missing something crucial here? As far as I can tell, arpresolve() unconditionally resolves L2 next-hop to the value of ifp->if_broadcastaddr. And that is always set to 'etherbroadcastaddr' by default for Ethernet ifnets: FF:FF:FF:FF:FF:FF. Would that not get past the M_BCAST check which replaced the call to in_broadcast()? Based on my reading of the UDP-and-plumbing layer, it looks like we will only see FF:FF:FF:FF:FF:FF being used by the undirected IPv4 broadcast address, 255.255.255.255. But, in fact, this is probably a far more valid address to use for discovery services than the x.x.x.255-style IPv4 directed broadcast address, as, for Ethernet at least, it is guaranteed not to propagate beyond 1 union-of (on-link broadcast domain (layer 2, hop 1) & other ways that IPv4 subnet is bridged). So, Ryan -- your original reading of how in_broadcast() behaves is correct, modulo the all-ones bypassing it. (I believe dhclient and isc-dhcpd bypass it at BPF injection, though.) ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r304436 - in head: . sys/netinet
On Sat, Aug 20, 2016 at 09:34:06PM +0100, Bruce Simpson wrote: > On 20/08/16 21:05, Bruce Simpson wrote: > > Unless I am missing something crucial here? As far as I can tell, > > arpresolve() unconditionally resolves L2 next-hop to the value of > > ifp->if_broadcastaddr. And that is always set to 'etherbroadcastaddr' by > > default for Ethernet ifnets: FF:FF:FF:FF:FF:FF. > > > > Would that not get past the M_BCAST check which replaced the call to > > in_broadcast()? > > Based on my reading of the UDP-and-plumbing layer, it looks like we will > only see FF:FF:FF:FF:FF:FF being used by the undirected IPv4 broadcast > address, 255.255.255.255. > > But, in fact, this is probably a far more valid address to use for > discovery services than the x.x.x.255-style IPv4 directed broadcast > address, as, for Ethernet at least, it is guaranteed not to propagate > beyond 1 union-of (on-link broadcast domain (layer 2, hop 1) & other > ways that IPv4 subnet is bridged). > > So, Ryan -- your original reading of how in_broadcast() behaves is > correct, modulo the all-ones bypassing it. > > (I believe dhclient and isc-dhcpd bypass it at BPF injection, though.) What purpose to analyse L2 header? Yes, curently FreeBSD don't support multiaccess media other then ethernet (i.e. ATM, FrameRelay), but in case of mGRE L2 header will be absent. ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
svn commit: r304545 - head/sys/netinet6
Author: karels Date: Sat Aug 20 20:46:53 2016 New Revision: 304545 URL: https://svnweb.freebsd.org/changeset/base/304545 Log: Disable L2 caching for UDP over IPv6 The ip6_output routine is missing L2 cache invalication as done in ip_output. Even with that code, some problems with UDP over IPv6 have been reported. Diabling L2 cache for that problem works around the problem for now. PR: 211872 211926 Reviewed by: gnn Approved by: gnn (mentor) MFC after:immediate Modified: head/sys/netinet6/udp6_usrreq.c Modified: head/sys/netinet6/udp6_usrreq.c == --- head/sys/netinet6/udp6_usrreq.c Sat Aug 20 20:28:08 2016 (r304544) +++ head/sys/netinet6/udp6_usrreq.c Sat Aug 20 20:46:53 2016 (r304545) @@ -898,7 +898,7 @@ udp6_output(struct inpcb *inp, struct mb UDP_PROBE(send, NULL, inp, ip6, inp, udp6); UDPSTAT_INC(udps_opackets); - error = ip6_output(m, optp, &inp->inp_route6, flags, + error = ip6_output(m, optp, NULL, flags, inp->in6p_moptions, NULL, inp); break; case AF_INET: ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
svn commit: r304546 - stable/11/sys/netinet6
Author: karels Date: Sat Aug 20 20:56:36 2016 New Revision: 304546 URL: https://svnweb.freebsd.org/changeset/base/304546 Log: MFC r304545: Disable L2 caching for UDP over IPv6 The ip6_output routine is missing L2 cache invalication as done in ip_output. Even with that code, some problems with UDP over IPv6 have been reported. Diabling L2 cache for that problem works around the problem for now. PR: 211872 211926 Reviewed by: gnn Approved by: gnn (mentor) Tested by:peter@, Mike Andrews MFC after:immediate Modified: stable/11/sys/netinet6/udp6_usrreq.c Directory Properties: stable/11/ (props changed) Modified: stable/11/sys/netinet6/udp6_usrreq.c == --- stable/11/sys/netinet6/udp6_usrreq.cSat Aug 20 20:46:53 2016 (r304545) +++ stable/11/sys/netinet6/udp6_usrreq.cSat Aug 20 20:56:36 2016 (r304546) @@ -898,7 +898,7 @@ udp6_output(struct inpcb *inp, struct mb UDP_PROBE(send, NULL, inp, ip6, inp, udp6); UDPSTAT_INC(udps_opackets); - error = ip6_output(m, optp, &inp->inp_route6, flags, + error = ip6_output(m, optp, NULL, flags, inp->in6p_moptions, NULL, inp); break; case AF_INET: ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r304436 - in head: . sys/netinet
On 20/08/16 21:41, Slawa Olhovchenkov wrote: On Sat, Aug 20, 2016 at 09:34:06PM +0100, Bruce Simpson wrote: So, Ryan -- your original reading of how in_broadcast() behaves is correct, modulo the all-ones bypassing it. What purpose to analyse L2 header? I was just checking for possible edge cases for a substitution of the in_broadcast() check with some other way of logically summarising the real broadcast disposition of the interface in bits, given your mGRE example below. Like M_BCAST, but 'This packet is flagged as broadcast, but only by a proxy method, not L2'. Yes, curently FreeBSD don't support multiaccess media other then ethernet (i.e. ATM, FrameRelay), but in case of mGRE L2 header will be absent. Exactly! People forget that certain legitimate multipoint protocols already exist as overlays already. It is easy when all we grow up with is Ethernet. :-) Until we peek under the hood, we may not know. Slawa, you have hit the nail on the head. The situation can naturally arise anywhere we bridge L2/L3 in certain directions, be that in VPN aggregation or PPPoE aggregation. In many ways I regret never being able to have executed work on a design for ng_pppoa in 2005/6. But, given the pain people in the UK are having with BT and VDSL modem provision right now... it comes as no surprise that the next generation of DSL access, for us, can be as bad. For some, multipoint is less important now we have SR-IOV VFs and other means of allocating discrete unicast Ethernet MACs and using them as links, but... Roundabout the time I merged M_PROMISC from NetBSD to FreeBSD in 2006/7, I considered that we should add an abstraction to ifnet to permit multiple unicast (or special) MACs to be bound to existing ifnets, and -- where the card permits it, expedite that MAC in some way. That capability was present on the (legacy) Adaptec Starfire quad 100TX from that era. Today, it exists in e.g. Chelsio T4/5 TCAM filter, or multiple perfect hashes on the previous generations of cards. (Currently the FreeBSD stack does nothing about such.) I suspect it is less important now we have RSS for raw TCP throughput, but, for those of us -- e.g. in internet service provider (ISP) type environments, we have to keep a careful eye on how well FreeBSD plays nice with other Ethernet equipment, with a view to these types of potential optimizations in future. However, we still have to keep the FreeBSD-on-Ethernet ship sailing smoothly. The intent of the original input path change is clearly for performance, but perhaps slipping the M_BCAST tag in the stack is the right way forward. I would also suggest: we add ability to qualify where in the stack M_BCAST was raised (in case of any possible re-entry), by allocating one more MBUF flag to Layer 2. Then, the same M_PROMISC flag trick can be applied... and Ryan's broadcast performance boost could perhaps even carry across L2 bridging tiers, e.g. stacked if_bridge or netgraph, providing we know what direction in the stack it's traveling in (and its absolute ifnet origin). ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r304436 - in head: . sys/netinet
On 20/08/16 22:17, Bruce Simpson wrote: However, we still have to keep the FreeBSD-on-Ethernet ship sailing smoothly. The intent of the original input path change is clearly for performance, but perhaps slipping the M_BCAST tag in the stack is the right way forward. I would also suggest: we add ability to qualify where in the stack M_BCAST was raised (in case of any possible re-entry), by allocating one more MBUF flag to Layer 2. Then, the same M_PROMISC flag trick can be applied... and Ryan's broadcast performance boost could perhaps even carry across L2 bridging tiers, e.g. stacked if_bridge or netgraph, providing we know what direction in the stack it's traveling in (and its absolute ifnet origin) The main motivation for this: retain the original meaning of M_BCAST. (in addition to Ryan's intended new meaning that IP indicate to itself "This is IPv4 broadcast" and to others - it could be used to expedite delivery with some form of map). But, say, let's add a second flag which allows for controlled stacking of L2 in situations like this. Let's call it M_BCPROXY. It can be tracked for the original meaning, i.e. without the new meaning Ryan proposes for M_BCAST. When M_BCAST is set and M_BCPROXY is clear, we know the packet is broadcast, but we don't know for sure that this isn't because IP inspected it, and set the M_BCAST flag due to the destination IPv4 address being identified as such (and valid for its link, if you are enforcing the Strong IP End-Station model, RFC 1122 style, as is the BSD default). However, if we set M_BCPROXY at the same time, then, in situations where we might potentially re-enter the stack holding the same broadcast packet, we know that IP marked the packet as broadcast, and - on entry - can change our routing/switching/allocation/replication strategies accordingly. (This is not information which, on its own, holding the origin ifnet pointer provides; the flag is needed to sense direction in the stack.) So, as the mbuf chain is handed-off between other L2 entities (this can easily happen with stacked VLAN tags, in Q-in-Q and provider environments, which pfSense can service very well) - and, if the node itself determines that it is also a recipient of the broadcast, for correct hand-off if the broadcast does need to be forwarded by some other FreeBSD subsystem. It could also be checked by firewalls: e.g. for a corroborated check, from the mask of these two flags, where in the stack (or link forest) a purported broadcast packet actually originated from. (Pretty much essential for maintaining audit trail if a Smurf-like amplification attack is caught in the act, or if an NTP relay (or other association) terminates in an NTP broadcast association. And, of course, to trace dodgy broadcast Sun-style XDR RPC back to its source.) ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r304436 - in head: . sys/netinet
On Sat, Aug 20, 2016 at 10:17:27PM +0100, Bruce Simpson wrote: > On 20/08/16 21:41, Slawa Olhovchenkov wrote: > > On Sat, Aug 20, 2016 at 09:34:06PM +0100, Bruce Simpson wrote: > >> So, Ryan -- your original reading of how in_broadcast() behaves is > >> correct, modulo the all-ones bypassing it. > > What purpose to analyse L2 header? > > I was just checking for possible edge cases for a substitution of the > in_broadcast() check with some other way of logically summarising the > real broadcast disposition of the interface in bits, given your mGRE > example below. I am think this substitution is very bad idea (by design). Also, on transmit side this is must be irrelevant on received L2 header (and this in many cases this is will be L2 unicast packet). For other cases packet will be created on host and don't have any received information. On received side for host relaing on L2 information for accepting packet as host targeting sound like security hole. In router case receiving broadcast packet in any way need additional check for dst IP address (host part is all zero or all one? what about handling this broadcast type (RFC talk about conroling variation of this)? what about sysctl control of receiving routed broadcast packets? what about handling 255.255.255.255?) In any way, this is irrelevant to L2 broadcast MAC and present L2 broadcast flags. > Like M_BCAST, but 'This packet is flagged as broadcast, but only by a > proxy method, not L2'. > > > Yes, curently FreeBSD don't support multiaccess media other then > > ethernet (i.e. ATM, FrameRelay), but in case of mGRE L2 header will be > > absent. > > Exactly! People forget that certain legitimate multipoint protocols > already exist as overlays already. It is easy when all we grow up with > is Ethernet. :-) Until we peek under the hood, we may not know. > > Slawa, you have hit the nail on the head. > > The situation can naturally arise anywhere we bridge L2/L3 in certain > directions, be that in VPN aggregation or PPPoE aggregation. > > In many ways I regret never being able to have executed work on a design > for ng_pppoa in 2005/6. But, given the pain people in the UK are having > with BT and VDSL modem provision right now... it comes as no surprise > that the next generation of DSL access, for us, can be as bad. > > For some, multipoint is less important now we have SR-IOV VFs and other > means of allocating discrete unicast Ethernet MACs and using them as > links, but... Multipoint is mandatory for DMVPN. > Roundabout the time I merged M_PROMISC from NetBSD to FreeBSD in 2006/7, > I considered that we should add an abstraction to ifnet to permit > multiple unicast (or special) MACs to be bound to existing ifnets, and > -- where the card permits it, expedite that MAC in some way. > > That capability was present on the (legacy) Adaptec Starfire quad 100TX > from that era. Today, it exists in e.g. Chelsio T4/5 TCAM filter, or > multiple perfect hashes on the previous generations of cards. (Currently > the FreeBSD stack does nothing about such.) > > I suspect it is less important now we have RSS for raw TCP throughput, > but, for those of us -- e.g. in internet service provider (ISP) type > environments, we have to keep a careful eye on how well FreeBSD plays > nice with other Ethernet equipment, with a view to these types of > potential optimizations in future. May be only as options, per NIC based? I.e. check for L3 broadcasy only when NIC flaged? w/o check L2 dst MAC for broadcasting, because this is excessively and don't give any speed up (in any case need check for L3 broadcast). > However, we still have to keep the FreeBSD-on-Ethernet ship sailing > smoothly. The intent of the original input path change is clearly for > performance, but perhaps slipping the M_BCAST tag in the stack is the > right way forward. > > I would also suggest: we add ability to qualify where in the stack > M_BCAST was raised (in case of any possible re-entry), by allocating one > more MBUF flag to Layer 2. > > Then, the same M_PROMISC flag trick can be applied... and Ryan's > broadcast performance boost could perhaps even carry across L2 bridging > tiers, e.g. stacked if_bridge or netgraph, providing we know what > direction in the stack it's traveling in (and its absolute ifnet origin). > Because L3 broadcast check need be in any case (and can be perform by hash lookup in same time as host ip check) L2 broadcaste check needless. ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r304527 - in stable/10/lib: libc/include libc/stdlib libc/tests/stdlib libthr/thread
On 8/20/16, Konstantin Belousov wrote:
> Author: kib
> Date: Sat Aug 20 12:26:44 2016
> New Revision: 304527
> URL: https://svnweb.freebsd.org/changeset/base/304527
>
> Log:
> MFC r303795:
> Add __cxa_thread_atexit(3) API implementation.
>
> Added:
> stable/10/lib/libc/stdlib/cxa_thread_atexit.c
> - copied unchanged from r303795,
> head/lib/libc/stdlib/cxa_thread_atexit.c
> stable/10/lib/libc/tests/stdlib/cxa_thread_atexit_nothr_test.cc
> - copied unchanged from r303795,
> head/lib/libc/tests/stdlib/cxa_thread_atexit_nothr_test.cc
> stable/10/lib/libc/tests/stdlib/cxa_thread_atexit_test.cc
> - copied unchanged from r303795,
> head/lib/libc/tests/stdlib/cxa_thread_atexit_test.cc
> Modified:
> stable/10/lib/libc/include/libc_private.h
> stable/10/lib/libc/stdlib/Makefile.inc
> stable/10/lib/libc/stdlib/Symbol.map
> stable/10/lib/libc/stdlib/exit.c
> stable/10/lib/libc/tests/stdlib/Makefile
> stable/10/lib/libthr/thread/thr_exit.c
> Directory Properties:
> stable/10/ (props changed)
>
make[6]:
"/jenkins/workspace/HardenedBSD-stable-10-STABLE-master-amd64/lib/libc/tests/stdlib/Makefile"
line 3: Could not find src.opts.mk
make[6]:
"/jenkins/workspace/HardenedBSD-stable-10-STABLE-master-amd64/lib/libc/tests/stdlib/Makefile"
line 8: Malformed conditional (${COMPILER_FEATURES:Mc++11})
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
svn commit: r304548 - head/sys/netinet
Author: zec
Date: Sat Aug 20 22:12:26 2016
New Revision: 304548
URL: https://svnweb.freebsd.org/changeset/base/304548
Log:
Permit disabling net.inet.udp.require_l2_bcast in VIMAGE kernels.
The default value of the tunable introduced in r304436 couldn't be
effectively overrided on VIMAGE kernels, because instead of being
accessed via the appropriate VNET() accessor macro, it was accessed
via the VNET_NAME() macro, which resolves to the (should-be) read-only
master template of initial values of per-VNET data. Hence, while the
value of udp_require_l2_bcast could be altered on per-VNET basis, the
code in udp_input() would ignore it as it would always read the default
value (one) from the VNET master template.
Silence from: rstone
Modified:
head/sys/netinet/udp_usrreq.c
Modified: head/sys/netinet/udp_usrreq.c
==
--- head/sys/netinet/udp_usrreq.c Sat Aug 20 21:34:41 2016
(r304547)
+++ head/sys/netinet/udp_usrreq.c Sat Aug 20 22:12:26 2016
(r304548)
@@ -127,6 +127,7 @@ SYSCTL_INT(_net_inet_udp, OID_AUTO, blac
"Do not send port unreachables for refused connects");
static VNET_DEFINE(int, udp_require_l2_bcast) = 1;
+#defineV_udp_require_l2_bcast VNET(udp_require_l2_bcast)
SYSCTL_INT(_net_inet_udp, OID_AUTO, require_l2_bcast, CTLFLAG_VNET |
CTLFLAG_RW,
&VNET_NAME(udp_require_l2_bcast), 0,
"Only treat packets sent to an L2 broadcast address as broadcast packets");
@@ -528,7 +529,7 @@ udp_input(struct mbuf **mp, int *offp, i
pcbinfo = udp_get_inpcbinfo(proto);
if (IN_MULTICAST(ntohl(ip->ip_dst.s_addr)) ||
- ((!VNET_NAME(udp_require_l2_bcast) || m->m_flags & M_BCAST) &&
+ ((!V_udp_require_l2_bcast || m->m_flags & M_BCAST) &&
in_broadcast(ip->ip_dst, ifp))) {
struct inpcb *last;
struct inpcbhead *pcblist;
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r304527 - in stable/10/lib: libc/include libc/stdlib libc/tests/stdlib libthr/thread
On 8/21/16, Oliver Pinter wrote:
> On 8/20/16, Konstantin Belousov wrote:
>> Author: kib
>> Date: Sat Aug 20 12:26:44 2016
>> New Revision: 304527
>> URL: https://svnweb.freebsd.org/changeset/base/304527
>>
>> Log:
>> MFC r303795:
>> Add __cxa_thread_atexit(3) API implementation.
>>
>> Added:
>> stable/10/lib/libc/stdlib/cxa_thread_atexit.c
>> - copied unchanged from r303795,
>> head/lib/libc/stdlib/cxa_thread_atexit.c
>> stable/10/lib/libc/tests/stdlib/cxa_thread_atexit_nothr_test.cc
>> - copied unchanged from r303795,
>> head/lib/libc/tests/stdlib/cxa_thread_atexit_nothr_test.cc
>> stable/10/lib/libc/tests/stdlib/cxa_thread_atexit_test.cc
>> - copied unchanged from r303795,
>> head/lib/libc/tests/stdlib/cxa_thread_atexit_test.cc
>> Modified:
>> stable/10/lib/libc/include/libc_private.h
>> stable/10/lib/libc/stdlib/Makefile.inc
>> stable/10/lib/libc/stdlib/Symbol.map
>> stable/10/lib/libc/stdlib/exit.c
>> stable/10/lib/libc/tests/stdlib/Makefile
>> stable/10/lib/libthr/thread/thr_exit.c
>> Directory Properties:
>> stable/10/ (props changed)
>>
>
>
> make[6]:
> "/jenkins/workspace/HardenedBSD-stable-10-STABLE-master-amd64/lib/libc/tests/stdlib/Makefile"
> line 3: Could not find src.opts.mk
> make[6]:
> "/jenkins/workspace/HardenedBSD-stable-10-STABLE-master-amd64/lib/libc/tests/stdlib/Makefile"
> line 8: Malformed conditional (${COMPILER_FEATURES:Mc++11})
>
0001-HBSD-fix-build-error-after-kib-s-8ef9c6fc5bcfe1b6062.patch
Description: Binary data
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r304527 - in stable/10/lib: libc/include libc/stdlib libc/tests/stdlib libthr/thread
On 8/21/16, Oliver Pinter wrote:
> On 8/21/16, Oliver Pinter wrote:
>> On 8/20/16, Konstantin Belousov wrote:
>>> Author: kib
>>> Date: Sat Aug 20 12:26:44 2016
>>> New Revision: 304527
>>> URL: https://svnweb.freebsd.org/changeset/base/304527
>>>
>>> Log:
>>> MFC r303795:
>>> Add __cxa_thread_atexit(3) API implementation.
>>>
>>> Added:
>>> stable/10/lib/libc/stdlib/cxa_thread_atexit.c
>>> - copied unchanged from r303795,
>>> head/lib/libc/stdlib/cxa_thread_atexit.c
>>> stable/10/lib/libc/tests/stdlib/cxa_thread_atexit_nothr_test.cc
>>> - copied unchanged from r303795,
>>> head/lib/libc/tests/stdlib/cxa_thread_atexit_nothr_test.cc
>>> stable/10/lib/libc/tests/stdlib/cxa_thread_atexit_test.cc
>>> - copied unchanged from r303795,
>>> head/lib/libc/tests/stdlib/cxa_thread_atexit_test.cc
>>> Modified:
>>> stable/10/lib/libc/include/libc_private.h
>>> stable/10/lib/libc/stdlib/Makefile.inc
>>> stable/10/lib/libc/stdlib/Symbol.map
>>> stable/10/lib/libc/stdlib/exit.c
>>> stable/10/lib/libc/tests/stdlib/Makefile
>>> stable/10/lib/libthr/thread/thr_exit.c
>>> Directory Properties:
>>> stable/10/ (props changed)
>>>
>>
>>
>> make[6]:
>> "/jenkins/workspace/HardenedBSD-stable-10-STABLE-master-amd64/lib/libc/tests/stdlib/Makefile"
>> line 3: Could not find src.opts.mk
>> make[6]:
>> "/jenkins/workspace/HardenedBSD-stable-10-STABLE-master-amd64/lib/libc/tests/stdlib/Makefile"
>> line 8: Malformed conditional (${COMPILER_FEATURES:Mc++11})
>>
>
And the next build error from the same MFC:
18:36:12 cxa_thread_atexit_test.o: In function `(anonymous
namespace)::atfu_tc_cxx__thread_inf_dtors::body() const':
18:36:12
/jenkins/workspace/HardenedBSD-10-STABLE-amd64/lib/libc/tests/stdlib/cxa_thread_atexit_test.cc:(.text+0x335):
undefined reference to `pthread_create'
18:36:12 cxa_thread_atexit_test.o: In function `(anonymous
namespace)::atfu_tc_cxx__thread_local_add_while_calling_dtors::body()
const':
18:36:12
/jenkins/workspace/HardenedBSD-10-STABLE-amd64/lib/libc/tests/stdlib/cxa_thread_atexit_test.cc:(.text+0x4b0):
undefined reference to `pthread_create'
18:36:12 cxa_thread_atexit_test.o: In function `(anonymous
namespace)::atfu_tc_cxx__thread_local_after::body() const':
18:36:12
/jenkins/workspace/HardenedBSD-10-STABLE-amd64/lib/libc/tests/stdlib/cxa_thread_atexit_test.cc:(.text+0xa50):
undefined reference to `pthread_create'
18:36:12 cxa_thread_atexit_test.o: In function `(anonymous
namespace)::atfu_tc_cxx__thread_local_before::body() const':
18:36:12
/jenkins/workspace/HardenedBSD-10-STABLE-amd64/lib/libc/tests/stdlib/cxa_thread_atexit_test.cc:(.text+0x102a):
undefined reference to `pthread_create'
18:36:12 c++: error: linker command failed with exit code 1 (use -v to
see invocation)
18:36:12 --- cxa_thread_atexit_test ---
18:36:12 *** [cxa_thread_atexit_test] Error code 1
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r304527 - in stable/10/lib: libc/include libc/stdlib libc/tests/stdlib libthr/thread
And one more.
On 8/21/16, Oliver Pinter wrote:
> On 8/21/16, Oliver Pinter wrote:
>> On 8/21/16, Oliver Pinter wrote:
>>> On 8/20/16, Konstantin Belousov wrote:
Author: kib
Date: Sat Aug 20 12:26:44 2016
New Revision: 304527
URL: https://svnweb.freebsd.org/changeset/base/304527
Log:
MFC r303795:
Add __cxa_thread_atexit(3) API implementation.
Added:
stable/10/lib/libc/stdlib/cxa_thread_atexit.c
- copied unchanged from r303795,
head/lib/libc/stdlib/cxa_thread_atexit.c
stable/10/lib/libc/tests/stdlib/cxa_thread_atexit_nothr_test.cc
- copied unchanged from r303795,
head/lib/libc/tests/stdlib/cxa_thread_atexit_nothr_test.cc
stable/10/lib/libc/tests/stdlib/cxa_thread_atexit_test.cc
- copied unchanged from r303795,
head/lib/libc/tests/stdlib/cxa_thread_atexit_test.cc
Modified:
stable/10/lib/libc/include/libc_private.h
stable/10/lib/libc/stdlib/Makefile.inc
stable/10/lib/libc/stdlib/Symbol.map
stable/10/lib/libc/stdlib/exit.c
stable/10/lib/libc/tests/stdlib/Makefile
stable/10/lib/libthr/thread/thr_exit.c
Directory Properties:
stable/10/ (props changed)
>>>
>>>
>>> make[6]:
>>> "/jenkins/workspace/HardenedBSD-stable-10-STABLE-master-amd64/lib/libc/tests/stdlib/Makefile"
>>> line 3: Could not find src.opts.mk
>>> make[6]:
>>> "/jenkins/workspace/HardenedBSD-stable-10-STABLE-master-amd64/lib/libc/tests/stdlib/Makefile"
>>> line 8: Malformed conditional (${COMPILER_FEATURES:Mc++11})
>>>
>>
>
> And the next build error from the same MFC:
> 18:36:12 cxa_thread_atexit_test.o: In function `(anonymous
> namespace)::atfu_tc_cxx__thread_inf_dtors::body() const':
> 18:36:12
> /jenkins/workspace/HardenedBSD-10-STABLE-amd64/lib/libc/tests/stdlib/cxa_thread_atexit_test.cc:(.text+0x335):
> undefined reference to `pthread_create'
> 18:36:12 cxa_thread_atexit_test.o: In function `(anonymous
> namespace)::atfu_tc_cxx__thread_local_add_while_calling_dtors::body()
> const':
> 18:36:12
> /jenkins/workspace/HardenedBSD-10-STABLE-amd64/lib/libc/tests/stdlib/cxa_thread_atexit_test.cc:(.text+0x4b0):
> undefined reference to `pthread_create'
> 18:36:12 cxa_thread_atexit_test.o: In function `(anonymous
> namespace)::atfu_tc_cxx__thread_local_after::body() const':
> 18:36:12
> /jenkins/workspace/HardenedBSD-10-STABLE-amd64/lib/libc/tests/stdlib/cxa_thread_atexit_test.cc:(.text+0xa50):
> undefined reference to `pthread_create'
> 18:36:12 cxa_thread_atexit_test.o: In function `(anonymous
> namespace)::atfu_tc_cxx__thread_local_before::body() const':
> 18:36:12
> /jenkins/workspace/HardenedBSD-10-STABLE-amd64/lib/libc/tests/stdlib/cxa_thread_atexit_test.cc:(.text+0x102a):
> undefined reference to `pthread_create'
> 18:36:12 c++: error: linker command failed with exit code 1 (use -v to
> see invocation)
> 18:36:12 --- cxa_thread_atexit_test ---
> 18:36:12 *** [cxa_thread_atexit_test] Error code 1
>
0002-HBSD-fix-build-error-after-kib-s-8ef9c6fc5bcfe1b6062.patch
Description: Binary data
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r304436 - in head: . sys/netinet
On 20/08/16 23:05, Slawa Olhovchenkov wrote: I am think this substitution is very bad idea (by design). Also, on transmit side this is must be irrelevant on received L2 header (and this in many cases this is will be L2 unicast packet). For other cases packet will be created on host and don't have any received information. Whilst I agree with your concerns about multipoint, I support the motivation behind Ryan's original change: optimize the common case. On the other hand, I'm suggesting a slight extension to it -- one which would probably require adoption across some L2-exposed subsystems, or anywhere which might reinterpret an M_BCAST from re-entrant encapsulation (i.e. I receive a UDP broadcast packet, but my VPN daemon then decides it needs to be NATted and forwarded somewhere else). Whilst I believe the scope for problems like this are limited (and perhaps to Netgraph permutations), I do believe they exist, and should be defensively coded for. And: If, the logic for this can be factored out into one additional bit, in a conditional branch (or small set of those) in terms of delta to the existing FreeBSD data plane path -- i.e. my suggestion; Then: we should be able to preserve correctness for multipoint configurations, without sacrificing performance. Or, a possible tie-breaker: ...we ensure that M_BCAST is cleared at all times before possible re-entry, and use a separate M_BCASTL3 bit. Let the ethernet protocols decide themselves if re-entered about M_BCAST based on DMAC. On received side for host relaing on L2 information for accepting packet as host targeting sound like security hole. In router case receiving broadcast packet in any way need additional check for dst IP address (host part is all zero or all one? what about handling this broadcast type (RFC talk about conroling variation of this)? what about sysctl control of receiving routed broadcast packets? what about handling 255.255.255.255?) I believe most of this is already special-cased in ip_fastfwd.c (which gnn@ of course has merged, as it's full of sensible FIB-like operators which most router forwarding planes adopt on *their* IP input paths up to the forwarding decision), assuming the Ethernet input path colours packets with the right flags. Although, no direct distinction between IPv4 directed or undirected broadcast is made, until that code (or a full rtalloc()) is hit. In the past, I have tried to "hack around" the issue on the output (send) side, by introducing IP_ONESBCAST from BSD/OS. The fundamental problem there is that the IPv4 socket APIs were never designed to deal with 'with link' as well as 'with destination' particularly well -- i.e. to direct traffic to a particular host, with correct L2 resolution, but over a specific choice of link (or even, class of link). So, for correct behaviour when handling packets like this, the XORP FEA and libfeaclient frameworks would attempt to fully-bind control sockets requiring broadcast input where possible (OLSR being one candidate, but there are also other protocols requiring them). In any way, this is irrelevant to L2 broadcast MAC and present L2 broadcast flags. On the contrary, I believe in teasing as much explanation about the Layer 2 Soup 'out there' and how in FreeBSD it is treated, as this lends much background to the original problem posed by Ryan's change, to those who may not be from a primarily networking-oriented background. ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r304436 - in head: . sys/netinet
On 21/08/16 00:25, Bruce Simpson wrote: [Use a predicted branch in favour of Ethernet to optimize common case comments snipped] ...we ensure that M_BCAST is cleared at all times before possible re-entry, and use a separate M_BCASTL3 bit. Let the ethernet protocols decide themselves if re-entered about M_BCAST based on DMAC. Better still, rename it to M_IPBCAST, because that is exactly what that flag would be. Treat it like M_PROMISC, hands off, use THAT test instead of M_BCAST in the code (but predictive branch the original in_broadcast() call), make sure M_BCAST is cleared before possible Netgraph handoff, but leave M_IPBCAST set. That way, anyone can tell IP set the M_BCAST bit - not Ethernet - just by XORing them together. I'd code this, but I don't have a -CURRENT box. :-( ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r304436 - in head: . sys/netinet
On 21/08/16 00:25, Bruce Simpson wrote: On 20/08/16 23:05, Slawa Olhovchenkov wrote: In router case receiving broadcast packet in any way need additional check for dst IP address (host part is all zero or all one? what about handling this broadcast type (RFC talk about conroling variation of this)? what about sysctl control of receiving routed broadcast packets? what about handling 255.255.255.255?) I believe most of this is already special-cased in ip_fastfwd.c (which gnn@ of course has merged, as it's full of sensible FIB-like operators which most router forwarding planes adopt on *their* IP input paths up to the forwarding decision), assuming the Ethernet input path colours packets with the right flags. Just for reference, many of these 'sensible FIB operators' in the former ip_fastfwd.c came from the experience of James Jun at Towardex Systems. I merged his patch on the job whilst staying in Berkeley, CA and working on XORP at ICSI. I was only too happy to do that on their ticket, as it covered a lot of little performance cases which the pure rtalloc() fallthrough made us wince about. ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r304436 - in head: . sys/netinet
[snip] Just for everyone else on the list, would you mind distilling the original versus now-from-ryan meaning of M_BCAST and M_MCAST ? And how they're supposed to be used? thanks, -adrian ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r304436 - in head: . sys/netinet
On 21/08/16 00:47, Adrian Chadd wrote: [snip] Just for everyone else on the list, would you mind distilling the original versus now-from-ryan meaning of M_BCAST and M_MCAST ? And how they're supposed to be used? (With my best Liam Neeson 'Dad' voice from Fallout 3) They stay as-is, but IP is allowed to slip the tag. But it has to slip another tag in there, to say it slipped the tag. The rest is M_PROTOFLAG style hand-off hygeine, along the mbuf pipeline. ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r304527 - in stable/10/lib: libc/include libc/stdlib libc/tests/stdlib libthr/thread
And an updated version of the fix.
On 8/21/16, Oliver Pinter wrote:
> And one more.
>
> On 8/21/16, Oliver Pinter wrote:
>> On 8/21/16, Oliver Pinter wrote:
>>> On 8/21/16, Oliver Pinter wrote:
On 8/20/16, Konstantin Belousov wrote:
> Author: kib
> Date: Sat Aug 20 12:26:44 2016
> New Revision: 304527
> URL: https://svnweb.freebsd.org/changeset/base/304527
>
> Log:
> MFC r303795:
> Add __cxa_thread_atexit(3) API implementation.
>
> Added:
> stable/10/lib/libc/stdlib/cxa_thread_atexit.c
> - copied unchanged from r303795,
> head/lib/libc/stdlib/cxa_thread_atexit.c
> stable/10/lib/libc/tests/stdlib/cxa_thread_atexit_nothr_test.cc
> - copied unchanged from r303795,
> head/lib/libc/tests/stdlib/cxa_thread_atexit_nothr_test.cc
> stable/10/lib/libc/tests/stdlib/cxa_thread_atexit_test.cc
> - copied unchanged from r303795,
> head/lib/libc/tests/stdlib/cxa_thread_atexit_test.cc
> Modified:
> stable/10/lib/libc/include/libc_private.h
> stable/10/lib/libc/stdlib/Makefile.inc
> stable/10/lib/libc/stdlib/Symbol.map
> stable/10/lib/libc/stdlib/exit.c
> stable/10/lib/libc/tests/stdlib/Makefile
> stable/10/lib/libthr/thread/thr_exit.c
> Directory Properties:
> stable/10/ (props changed)
>
make[6]:
"/jenkins/workspace/HardenedBSD-stable-10-STABLE-master-amd64/lib/libc/tests/stdlib/Makefile"
line 3: Could not find src.opts.mk
make[6]:
"/jenkins/workspace/HardenedBSD-stable-10-STABLE-master-amd64/lib/libc/tests/stdlib/Makefile"
line 8: Malformed conditional (${COMPILER_FEATURES:Mc++11})
>>>
>>
>> And the next build error from the same MFC:
>> 18:36:12 cxa_thread_atexit_test.o: In function `(anonymous
>> namespace)::atfu_tc_cxx__thread_inf_dtors::body() const':
>> 18:36:12
>> /jenkins/workspace/HardenedBSD-10-STABLE-amd64/lib/libc/tests/stdlib/cxa_thread_atexit_test.cc:(.text+0x335):
>> undefined reference to `pthread_create'
>> 18:36:12 cxa_thread_atexit_test.o: In function `(anonymous
>> namespace)::atfu_tc_cxx__thread_local_add_while_calling_dtors::body()
>> const':
>> 18:36:12
>> /jenkins/workspace/HardenedBSD-10-STABLE-amd64/lib/libc/tests/stdlib/cxa_thread_atexit_test.cc:(.text+0x4b0):
>> undefined reference to `pthread_create'
>> 18:36:12 cxa_thread_atexit_test.o: In function `(anonymous
>> namespace)::atfu_tc_cxx__thread_local_after::body() const':
>> 18:36:12
>> /jenkins/workspace/HardenedBSD-10-STABLE-amd64/lib/libc/tests/stdlib/cxa_thread_atexit_test.cc:(.text+0xa50):
>> undefined reference to `pthread_create'
>> 18:36:12 cxa_thread_atexit_test.o: In function `(anonymous
>> namespace)::atfu_tc_cxx__thread_local_before::body() const':
>> 18:36:12
>> /jenkins/workspace/HardenedBSD-10-STABLE-amd64/lib/libc/tests/stdlib/cxa_thread_atexit_test.cc:(.text+0x102a):
>> undefined reference to `pthread_create'
>> 18:36:12 c++: error: linker command failed with exit code 1 (use -v to
>> see invocation)
>> 18:36:12 --- cxa_thread_atexit_test ---
>> 18:36:12 *** [cxa_thread_atexit_test] Error code 1
>>
>
0002-HBSD-fix-build-error-after-kib-s-8ef9c6fc5bcfe1b6062.patch
Description: Binary data
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r304436 - in head: . sys/netinet
On Sun, Aug 21, 2016 at 12:25:46AM +0100, Bruce Simpson wrote: > On 20/08/16 23:05, Slawa Olhovchenkov wrote: > > I am think this substitution is very bad idea (by design). > > Also, on transmit side this is must be irrelevant on received L2 > > header (and this in many cases this is will be L2 unicast packet). For > > other cases packet will be created on host and don't have any received > > information. > > > > Whilst I agree with your concerns about multipoint, I support the > motivation behind Ryan's original change: optimize the common case. Oh, common case... I am have pmc profiling for TCP output and see on this SVG picture and don't find any simple way. You want to watch too? What benefits from this optimisation? I both cases we need check IP DST for broadcast address. This check my break some network setup (we already have broken tunnel interface in case of overlap remote inner and outer tunnel address). > On the other hand, I'm suggesting a slight extension to it -- one which > would probably require adoption across some L2-exposed subsystems, or > anywhere which might reinterpret an M_BCAST from re-entrant > encapsulation (i.e. I receive a UDP broadcast packet, but my VPN daemon > then decides it needs to be NATted and forwarded somewhere else). I think this is seperate task and forward or drop must be controlled separatly. In some cases broadcast must be forwarded. > Whilst I believe the scope for problems like this are limited (and > perhaps to Netgraph permutations), I do believe they exist, and should > be defensively coded for. > > And: If, the logic for this can be factored out into one additional bit, > in a conditional branch (or small set of those) in terms of delta to the > existing FreeBSD data plane path -- i.e. my suggestion; > > Then: we should be able to preserve correctness for multipoint > configurations, without sacrificing performance. I am fear about perforance impact, code complexy and network setup break. > Or, a possible tie-breaker: > > ...we ensure that M_BCAST is cleared at all times before possible > re-entry, and use a separate M_BCASTL3 bit. Let the ethernet protocols > decide themselves if re-entered about M_BCAST based on DMAC. And set only by NIC? By performance view. > > On received side for host relaing on L2 information for accepting > > packet as host targeting sound like security hole. > > > > In router case receiving broadcast packet in any way need additional > > check for dst IP address (host part is all zero or all one? what about > > handling this broadcast type (RFC talk about conroling variation of > > this)? what about sysctl control of receiving routed broadcast > > packets? what about handling 255.255.255.255?) > > I believe most of this is already special-cased in ip_fastfwd.c (which > gnn@ of course has merged, as it's full of sensible FIB-like operators > which most router forwarding planes adopt on *their* IP input paths up > to the forwarding decision), assuming the Ethernet input path colours > packets with the right flags. Yes. And MAC broadcast independed. And can't be depend on this. > Although, no direct distinction between IPv4 directed or undirected > broadcast is made, until that code (or a full rtalloc()) is hit. I am just about RFC1812 4.2.2.11 "a router MAY have a configuration option to prevent reception of these [Directed Broadcast] packets" and absent like options for Limited broadcast packets. > In the past, I have tried to "hack around" the issue on the output > (send) side, by introducing IP_ONESBCAST from BSD/OS. > > The fundamental problem there is that the IPv4 socket APIs were never > designed to deal with 'with link' as well as 'with destination' > particularly well -- i.e. to direct traffic to a particular host, with > correct L2 resolution, but over a specific choice of link (or even, > class of link). For load sharing over multiple NIC in one subnet? > So, for correct behaviour when handling packets like this, the XORP FEA > and libfeaclient frameworks would attempt to fully-bind control sockets > requiring broadcast input where possible (OLSR being one candidate, but > there are also other protocols requiring them). > > > In any way, this is irrelevant to L2 broadcast MAC and present L2 > > broadcast flags. > > On the contrary, I believe in teasing as much explanation about the > Layer 2 Soup 'out there' and how in FreeBSD it is treated, as this lends > much background to the original problem posed by Ryan's change, to those > who may not be from a primarily networking-oriented background. ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
svn commit: r304552 - head/sys/mips/mips
Author: adrian
Date: Sun Aug 21 00:48:41 2016
New Revision: 304552
URL: https://svnweb.freebsd.org/changeset/base/304552
Log:
[mips] add support for the "creative" GNU extensions and IRIX hilarity around
MIPS LO16/HI16 relocations.
This was .. an interesting headache.
There are two halves:
* The earlier IRIX stuff (yes, early) occasionally would do dead
code removal and generate multiple consecutive LO16 entries.
If this is done for REL entries then it's fine - there's no
state kept between them. But gcc 5.x seems to do this for
RELA entries.
eg:
HI1 LO1 HI2 LO2 LO3 HI4 LO4
.. in this instance, LO2 should affect HI2, but LO3 doesn't at all
affect anything. The matching HI3 was in code that was deleted
as "dead code".
Then, the next one:
* A "GCC extension" allows for multiple HI entries before a LO entry;
and all of those HI entries use the first LO entry as their basis
for RELA offset calculations.
It does this so GCC can also do dead code deletion without necessarily
having to geneate fake relocation entries for balanced HI/LO RELA
entries.
eg:
HI1 LO1 HI2 HI3 HI4 LO4 LO5 HI6 LO6 LO7
in this instance, HI{2,3,4} are the same relocation as LO4 (eg .bss)
and need to be buffered until LO4 - then the RELA offset is applied
from LO4 to HI{2,3,4} calculations.
/And/, the AHL from HI4 is used during the LO4 relocation calculation,
just like in the normal (ie, before this commit) implementation.
Then, LO5 doesn't trigger anything - the HI "buffer" is empty,
so there are no HI relocations to flush out.
HI6/LO6 are normal, and LO7 doesn't trigger any HI updates.
Tested:
* AR9344 SoC, kernel modules, using gcc-5.3 (mips-gcc-5.3.0 package)
Notes:
* Yes, I do feel dirty having written this code.
Reviewed by: imp (after a handful of "this should be on fire" moments wrt
gcc and this code)
Modified:
head/sys/mips/mips/elf_machdep.c
Modified: head/sys/mips/mips/elf_machdep.c
==
--- head/sys/mips/mips/elf_machdep.cSun Aug 21 00:00:04 2016
(r304551)
+++ head/sys/mips/mips/elf_machdep.cSun Aug 21 00:48:41 2016
(r304552)
@@ -161,6 +161,136 @@ elf32_dump_thread(struct thread *td __un
}
#endif
+/*
+ * The following MIPS relocation code for tracking multiple
+ * consecutive HI32/LO32 entries is because of the following:
+ *
+ * https://dmz-portal.mips.com/wiki/MIPS_relocation_types
+ *
+ * ===
+ *
+ * + R_MIPS_HI16
+ *
+ * An R_MIPS_HI16 must be followed eventually by an associated R_MIPS_LO16
+ * relocation record in the same SHT_REL section. The contents of the two
+ * fields to be relocated are combined to form a full 32-bit addend AHL.
+ * An R_MIPS_LO16 entry which does not immediately follow a R_MIPS_HI16 is
+ * combined with the most recent one encountered, i.e. multiple R_MIPS_LO16
+ * entries may be associated with a single R_MIPS_HI16. Use of these
+ * relocation types in a SHT_REL section is discouraged and may be
+ * forbidden to avoid this complication.
+ *
+ * A GNU extension allows multiple R_MIPS_HI16 records to share the same
+ * R_MIPS_LO16 relocation record(s). The association works like this within
+ * a single relocation section:
+ *
+ * + From the beginning of the section moving to the end of the section,
+ * until R_MIPS_LO16 is not found each found R_MIPS_HI16 relocation will
+ * be associated with the first R_MIPS_LO16.
+ *
+ * + Until another R_MIPS_HI16 record is found all found R_MIPS_LO16
+ * relocations found are associated with the last R_MIPS_HI16.
+ *
+ * ===
+ *
+ * This is so gcc can do dead code detection/removal without having to
+ * generate HI/LO pairs even if one of them would be deleted.
+ *
+ * So, the summary is:
+ *
+ * + A HI16 entry must occur before any LO16 entries;
+ * + Multiple consecutive HI16 RELA entries need to be buffered until the
+ * first LO16 RELA entry occurs - and then all HI16 RELA relocations use
+ * the offset in the LOW16 RELA for calculating their offsets;
+ * + The last HI16 RELA entry before a LO16 RELA entry is used (the AHL)
+ * for the first subsequent LO16 calculation;
+ * + If multiple consecutive LO16 RELA entries occur, only the first
+ * LO16 RELA entry triggers an update of buffered HI16 RELA entries;
+ * any subsequent LO16 RELA entry before another HI16 RELA entry will
+ * not cause any further updates to the HI16 RELA entries.
+ *
+ * Additionally, flush out any outstanding HI16 entries that don't have
+ * a LO16 entry in case some garbage entries are left in the file.
+ */
+
+struct mips_tmp_reloc;
+struct mips_tmp_reloc {
+ struct mips_tmp_reloc *next;
+
+ Elf_Addr ahl;
+ Elf32_Addr *where_hi16;
+};
+
+static struct mips_tmp_reloc *ml = NULL;
+
+/*
+ * Add a temporary relocation (ie, a HI16 reloc type.)
+ */
+static int
+mips_tmp_reloc_add(Elf_Addr ahl, Elf32_A
Re: svn commit: r304505 - head/release/doc/en_US.ISO8859-1/hardware
On Fri, Aug 19, 2016 at 5:13 PM, John Baldwin wrote: > Author: jhb > Date: Fri Aug 19 22:13:01 2016 > New Revision: 304505 > URL: https://svnweb.freebsd.org/changeset/base/304505 > > Log: > Remove mentions of the mcd(4), scd(4), and si(4) drivers. > Hmm, looks like ie(4) also needs removal (in order to fix the build)? -Ben ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r304425 - stable/10/usr.sbin/bhyve
On Thu, 18 Aug 2016, Alexander Motin wrote:
Author: mav
Date: Thu Aug 18 11:56:07 2016
New Revision: 304425
URL: https://svnweb.freebsd.org/changeset/base/304425
Log:
MFC r302504, r302666, r302668, r302932, r302933:
Add emulation for Intel e1000 (e82545) network adapter.
The code was successfully tested with FreeBSD, Linux, Solaris and Windows
guests. This interface is predictably slower (about 2x) then virtio-net,
but it is very helpful for guests not supporting virtio-net by default.
Thanks to Jeremiah Lott and Peter Grehan for doing original heavy lifting.
Added:
stable/10/usr.sbin/bhyve/pci_e82545.c
- copied, changed from r302504, head/usr.sbin/bhyve/pci_e82545.c
Modified:
stable/10/usr.sbin/bhyve/Makefile
stable/10/usr.sbin/bhyve/bhyve.8
Directory Properties:
stable/10/ (props changed)
Modified: stable/10/usr.sbin/bhyve/Makefile
==
--- stable/10/usr.sbin/bhyve/Makefile Thu Aug 18 11:51:14 2016
(r304424)
+++ stable/10/usr.sbin/bhyve/Makefile Thu Aug 18 11:56:07 2016
(r304425)
@@ -23,6 +23,7 @@ SRCS= \
mevent.c\
mptbl.c \
pci_ahci.c \
+ pci_e82545.c\
pci_emul.c \
pci_hostbridge.c\
pci_irq.c \
@@ -48,6 +49,10 @@ SRCS+= vmm_instruction_emul.c
DPADD= ${LIBVMMAPI} ${LIBMD} ${LIBUTIL} ${LIBPTHREAD}
LDADD= -lvmmapi -lmd -lutil -lpthread
+CFLAGS+= -I${BHYVE_SYSDIR}/sys/dev/e1000
+CFLAGS+= -I${BHYVE_SYSDIR}/sys/dev/mii
+CFLAGS+= -I${BHYVE_SYSDIR}/sys/dev/usb/controller
+
WARNS?= 2
.include
Alexander,
The MFC is a tiny bit incomplete. I cannot build stable/10 world since
BHYVE_SYSDIR is not defined in the usr.sbin/bhyve/Makefile as it is in
HEAD. The issue was only noticed because I do not have the source tree
in /usr/src. I presume the symlink that exists for /sys to usr/src/sys
masks this for most people.
===> usr.sbin/bhyve (depend)
rm -f .depend
CC='cc ' mkdep -f .depend -a-I/sys/dev/e1000 -I/sys/dev/mii
-I/sys/dev/usb/controller -std=gnu99
/usr/FreeBSD/branches/stable/10/src/usr.sbin/bhyve/atkbdc.c
/usr/FreeBSD/branches/stable/10/src/usr.sbin/bhyve/acpi.c
/usr/FreeBSD/branches/stable/10/src/usr.sbin/bhyve/bhyverun.c
/usr/FreeBSD/branches/stable/10/src/usr.sbin/bhyve/block_if.c
/usr/FreeBSD/branches/stable/10/src/usr.sbin/bhyve/bootrom.c
/usr/FreeBSD/branches/stable/10/src/usr.sbin/bhyve/consport.c
/usr/FreeBSD/branches/stable/10/src/usr.sbin/bhyve/dbgport.c
/usr/FreeBSD/branches/stable/10/src/usr.sbin/bhyve/fwctl.c
/usr/FreeBSD/branches/stable/10/src/usr.sbin/bhyve/inout.c
/usr/FreeBSD/branches/stable/10/src/usr.sbin/bhyve/ioapic.c
/usr/FreeBSD/branches/stable/10/src/usr.sbin/bhyve/mem.c
/usr/FreeBSD/branches/stable/10/src/usr.sbin/bhyve/mevent.c
/usr/FreeBSD/branches/stable/10/src/usr.sbin/bhyve/mptbl.c
/usr/FreeBSD/branches/stable/10/src/usr.sbin/bhyve/pci_ahci.c
/usr/FreeBSD/branches/stable/10/src/usr.sb!
in/bhyve/pci_e82545.c
/usr/FreeBSD/branches/stable/10/src/usr.sbin/bhyve/pci_emul.c
/usr/FreeBSD/branches/stable/10/src/usr.sbin/bhyve/pci_hostbridge.c
/usr/FreeBSD/branches/stable/10/src/usr.sbin/bhyve/pci_irq.c
/usr/FreeBSD/branches/stable/10/src/usr.sbin/bhyve/pci_lpc.c
/usr/FreeBSD/branches/stable/10/src/usr.sbin/bhyve/pci_passthru.c
/usr/FreeBSD/branches/stable/10/src/usr.sbin/bhyve/pci_virtio_block.c
/usr/FreeBSD/branches/stable/10/src/usr.sbin/bhyve/pci_virtio_net.c
/usr/FreeBSD/branches/stable/10/src/usr.sbin/bhyve/pci_virtio_rnd.c
/usr/FreeBSD/branches/stable/10/src/usr.sbin/bhyve/pci_uart.c
/usr/FreeBSD/branches/stable/10/src/usr.sbin/bhyve/pm.c
/usr/FreeBSD/branches/stable/10/src/usr.sbin/bhyve/post.c
/usr/FreeBSD/branches/stable/10/src/usr.sbin/bhyve/rtc.c
/usr/FreeBSD/branches/stable/10/src/usr.sbin/bhyve/smbiostbl.c
/usr/FreeBSD/branches/stable/10/src/usr.sbin/bhyve/task_switch.c
/usr/FreeBSD/branches/stable/10/src/usr.sbin/bhyve/uart_emul.c
/usr/FreeBSD/branc!
hes/stable/10/src/usr.sbin/bhyve/virtio.c
/usr/FreeBSD/branches/stable/10/src/usr.sbin/bhyve/xmsr.c
/usr/FreeBSD/branches/stable/10/src/usr.sbin/bhyve/spinup_ap.c
/usr/FreeBSD/branches/stable/10/src/usr.sbin/bhyve/../../sys/amd64/vmm/vmm_instruction_emul.c
/usr/FreeBSD/branches/stable/10/src/usr.sbin/bhyve/pci_e82545.c:51:10: fatal
error: 'e1000_regs.h' file not found
#include "e1000_regs.h"
^
1 error generated.
mkdep: compile failed
*** [.depend] Error code 1
This missing line completes the build, but I do not know if anything
else needs merging. The missing merge to the .PATH variable did not
appear to affect the buildworld.
+ BHYVE_SYSDIR?=${SRCTOP}
Thank you.
Sean
--
s...@freebsd.org
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd
svn commit: r304553 - stable/10/lib/libc/tests/stdlib
Author: ngie
Date: Sun Aug 21 05:08:37 2016
New Revision: 304553
URL: https://svnweb.freebsd.org/changeset/base/304553
Log:
Unbreak the build when MK_TESTS != no after r304527
- src.opts.mk should be bsd.own.mk on ^/stable/10
- LIBADD should be DPADD/LDADD on ^/stable/10
Pointyhat to: kib
Reported by: Olivier Pinter
Sponsored by: EMC / Isilon Storage Division
Modified:
stable/10/lib/libc/tests/stdlib/Makefile
Modified: stable/10/lib/libc/tests/stdlib/Makefile
==
--- stable/10/lib/libc/tests/stdlib/MakefileSun Aug 21 00:48:41 2016
(r304552)
+++ stable/10/lib/libc/tests/stdlib/MakefileSun Aug 21 05:08:37 2016
(r304553)
@@ -1,6 +1,6 @@
# $FreeBSD$
-.include
+.include
ATF_TESTS_C+= heapsort_test
ATF_TESTS_C+= mergesort_test
@@ -42,7 +42,8 @@ CFLAGS+= -I${.CURDIR}
CXXFLAGS.cxa_thread_atexit_test+= -std=c++11
CXXFLAGS.cxa_thread_atexit_nothr_test+=-std=c++11
-LIBADD.cxa_thread_atexit_test+=pthread
+DPADD.cxa_thread_atexit_test+= ${LIBPTHREAD}
+LDADD.cxa_thread_atexit_test+= -lpthread
.for t in h_getopt h_getopt_long
CFLAGS.$t+=-I${LIBNETBSD_SRCDIR} -I${SRCTOP}/contrib/netbsd-tests
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r304527 - in stable/10/lib: libc/include libc/stdlib libc/tests/stdlib libthr/thread
> On Aug 20, 2016, at 16:50, Oliver Pinter > wrote: > > And an updated version of the fix. Fixed in r304553 — thanks! -Ngie signature.asc Description: Message signed with OpenPGP using GPGMail
