svn commit: r341840 - head/sys/geom/mirror

2018-12-11 Thread Conrad Meyer 
Author: cem
Date: Wed Dec 12 05:48:27 2018
New Revision: 341840
URL: https://svnweb.freebsd.org/changeset/base/341840

Log:
  gmirror: Fix a bug introduced in r341674
  
  r341674 inadvertently introduced a bug where newer mirror components being
  tasted would clear the high sc_flags that are not controlled by component
  metadata, such as G_MIRROR_DEVICE_FLAG_TASTING.  This could plausibly expose
  a small window of time during STARTING where device destruction might race
  with mirror component addition, probably resulting in a crash.
  
  Reviewed by:  markj
  X-MFC-With:   r341674
  Differential Revision:https://reviews.freebsd.org/D18521

Modified:
  head/sys/geom/mirror/g_mirror.c

Modified: head/sys/geom/mirror/g_mirror.c
==
--- head/sys/geom/mirror/g_mirror.c Wed Dec 12 05:18:53 2018
(r341839)
+++ head/sys/geom/mirror/g_mirror.c Wed Dec 12 05:48:27 2018
(r341840)
@@ -3061,6 +3061,8 @@ g_mirror_reinit_from_metadata(struct g_mirror_softc *s
 const struct g_mirror_metadata *md)
 {
 
+   sx_assert(>sc_lock, SX_XLOCKED);
+
sc->sc_genid = md->md_genid;
sc->sc_syncid = md->md_syncid;
 
@@ -3068,7 +3070,8 @@ g_mirror_reinit_from_metadata(struct g_mirror_softc *s
sc->sc_balance = md->md_balance;
sc->sc_mediasize = md->md_mediasize;
sc->sc_ndisks = md->md_all;
-   sc->sc_flags = md->md_mflags;
+   sc->sc_flags &= ~G_MIRROR_DEVICE_FLAG_MASK;
+   sc->sc_flags |= (md->md_mflags & G_MIRROR_DEVICE_FLAG_MASK);
 }
 
 struct g_geom *
___
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: r341759 - in head: contrib/wpa contrib/wpa/hostapd contrib/wpa/hs20/client contrib/wpa/src/ap contrib/wpa/src/common contrib/wpa/src/crypto contrib/wpa/src/drivers contrib/wpa/src/eap_

2018-12-11 Thread Jung-uk Kim 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 18. 12. 12., Jung-uk Kim wrote:
> On 18. 12. 12., Jung-uk Kim wrote:
>> On 18. 12. 9., Cy Schubert wrote:
>>> Author: cy Date: Sun Dec  9 06:45:49 2018 New Revision: 341759 
>>> URL: https://svnweb.freebsd.org/changeset/base/341759
>>> 
>>> Log: MFV r341618:
>>> 
>>> Update wpa 2.6 --> 2.7.
>> 
>> ...
>> 
>> This broke my network configuration and I found the following
>> messages from /dev/log/message.
> 
> ...
> 
> I meant /var/log/message, of course. :-(

...

Doh!  /var/log/messages

Sorry for typos.  I guess I need some sleep...

Jung-uk Kim
-BEGIN PGP SIGNATURE-

iQEzBAEBCAAdFiEEl1bqgKaRyqfWXu/CfJ+WJvzb8UYFAlwQmvEACgkQfJ+WJvzb
8UaOQgf/YDXVqV7m7EZKISsL0E/2DKsmzoe9vSjZJE5WE2fNEmPwpbt0QU/MexGY
F8HrClLDJhQqsvbQB3fjLPDB+v+Qg64eIJ1YwGHPu7qvbRGvsKCYWYT79Eiejh0f
68tAkLj5GKCBb53awug+Jn79sBzfeUC7BPLRPbkfoF4vp7/gWBsEpU8zbIMgPjuk
5r6PM4exKN1mYM9950WSDlkpcJbUku6B3RLneRZKMDJYi68B/POb88KEGtaEkMfQ
2Kv7vi+IBLlceTmUYa8Mm2A5Rtf6g3UuG7hg+YAQZeIR/SPxraVIosUONrz5NIHd
e8Baav1oi7sFPnY2VwdtnuOmX18saA==
=Am+x
-END PGP SIGNATURE-
___
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: r341759 - in head: contrib/wpa contrib/wpa/hostapd contrib/wpa/hs20/client contrib/wpa/src/ap contrib/wpa/src/common contrib/wpa/src/crypto contrib/wpa/src/drivers contrib/wpa/src/e

2018-12-11 Thread Cy Schubert 
In message , Jung-uk 
Kim writ
es:
> This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
> --1WzVlQChcwPiBmKooCiYuMNrbS28KVujs
> Content-Type: multipart/mixed; boundary="mK5ijTqRdq36SSbJEKLOKtLDhMyjY2IRB";
>  protected-headers="v1"
> From: Jung-uk Kim 
> To: Cy Schubert , src-committ...@freebsd.org,
>  svn-src-all@freebsd.org, svn-src-h...@freebsd.org
> Message-ID: 
> Subject: Re: svn commit: r341759 - in head: contrib/wpa contrib/wpa/hostapd
>  contrib/wpa/hs20/client contrib/wpa/src/ap contrib/wpa/src/common
>  contrib/wpa/src/crypto contrib/wpa/src/drivers contrib/wpa/src/eap_c...
> References: <201812090645.wb96jnso066...@repo.freebsd.org>
> In-Reply-To: <201812090645.wb96jnso066...@repo.freebsd.org>
>
> --mK5ijTqRdq36SSbJEKLOKtLDhMyjY2IRB
> Content-Type: multipart/mixed;
>  boundary="875BC694AF1AFD327ADF2704"
> Content-Language: en-US
>
> This is a multi-part message in MIME format.
> --875BC694AF1AFD327ADF2704
> Content-Type: text/plain; charset=utf-8
> Content-Transfer-Encoding: quoted-printable
>
> On 18. 12. 9., Cy Schubert wrote:
> > Author: cy
> > Date: Sun Dec  9 06:45:49 2018
> > New Revision: 341759
> > URL: https://svnweb.freebsd.org/changeset/base/341759
> >=20
> > Log:
> >   MFV r341618:
> >  =20
> >   Update wpa 2.6 --> 2.7.
>
> =2E..
>
> This broke my network configuration and I found the following messages
> from /dev/log/message.
>
> =2E.. bge0: CTRL-EVENT-EAP-PROPOSED-METHOD vendor=3D0 method=3D25
> =2E.. bge0: CTRL-EVENT-EAP-METHOD EAP vendor 0 method 25 (PEAP) selected
> =2E.. SSL: SSL3 alert: write (local SSL3 detected an error):fatal:interna=
> l
> error
> =2E.. OpenSSL: openssl_handshake - SSL_connect error:141A90B5:SSL
> routines:ssl_cipher_list_to_bytes:no ciphers available
> =2E.. bge0: CTRL-EVENT-EAP-FAILURE EAP authentication failed
>
> I tracked it down and found default ciphers were not set because
> usr.sbin/wpa/Makefile.inc added an empty string, i.e.,
> -DTLS_DEFAULT_CIPHERS=3D\"\".
>
> With the attached patch, I got my connection back.
>
> Jung-uk Kim

Thanks for that jkim@. It's in r341839 now.


-- 
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"

svn commit: r341839 - head/usr.sbin/wpa

2018-12-11 Thread Cy Schubert 
Author: cy
Date: Wed Dec 12 05:18:53 2018
New Revision: 341839
URL: https://svnweb.freebsd.org/changeset/base/341839

Log:
  Set default ciphers.
  
  Submitted by: jkim@

Modified:
  head/usr.sbin/wpa/Makefile.inc

Modified: head/usr.sbin/wpa/Makefile.inc
==
--- head/usr.sbin/wpa/Makefile.inc  Wed Dec 12 04:23:00 2018
(r341838)
+++ head/usr.sbin/wpa/Makefile.inc  Wed Dec 12 05:18:53 2018
(r341839)
@@ -32,6 +32,6 @@ CFLAGS+=-I${WPA_DISTDIR}/src/wps
 CFLAGS+= -DCONFIG_CTRL_IFACE
 CFLAGS+= -DCONFIG_CTRL_IFACE_UNIX
 CFLAGS+= -DNEED_AP_MLME
-CFLAGS+= -DTLS_DEFAULT_CIPHERS=\"$(CONFIG_TLS_DEFAULT_CIPHERS)\"
+CFLAGS+= -DTLS_DEFAULT_CIPHERS=\"DEFAULT:!EXP:!LOW\"
 
 .include 
___
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: r341759 - in head: contrib/wpa contrib/wpa/hostapd contrib/wpa/hs20/client contrib/wpa/src/ap contrib/wpa/src/common contrib/wpa/src/crypto contrib/wpa/src/drivers contrib/wpa/src/eap_

2018-12-11 Thread Jung-uk Kim 
On 18. 12. 12., Jung-uk Kim wrote:
> On 18. 12. 9., Cy Schubert wrote:
>> Author: cy
>> Date: Sun Dec  9 06:45:49 2018
>> New Revision: 341759
>> URL: https://svnweb.freebsd.org/changeset/base/341759
>>
>> Log:
>>   MFV r341618:
>>   
>>   Update wpa 2.6 --> 2.7.
> 
> ...
> 
> This broke my network configuration and I found the following messages
> from /dev/log/message.

...

I meant /var/log/message, of course. :-(

Jung-uk Kim

> ... bge0: CTRL-EVENT-EAP-PROPOSED-METHOD vendor=0 method=25
> ... bge0: CTRL-EVENT-EAP-METHOD EAP vendor 0 method 25 (PEAP) selected
> ... SSL: SSL3 alert: write (local SSL3 detected an error):fatal:internal
> error
> ... OpenSSL: openssl_handshake - SSL_connect error:141A90B5:SSL
> routines:ssl_cipher_list_to_bytes:no ciphers available
> ... bge0: CTRL-EVENT-EAP-FAILURE EAP authentication failed
> 
> I tracked it down and found default ciphers were not set because
> usr.sbin/wpa/Makefile.inc added an empty string, i.e.,
> -DTLS_DEFAULT_CIPHERS=\"\".
> 
> With the attached patch, I got my connection back.
> 
> Jung-uk Kim
> 




signature.asc
Description: OpenPGP digital signature

Re: svn commit: r341759 - in head: contrib/wpa contrib/wpa/hostapd contrib/wpa/hs20/client contrib/wpa/src/ap contrib/wpa/src/common contrib/wpa/src/crypto contrib/wpa/src/drivers contrib/wpa/src/eap_

2018-12-11 Thread Jung-uk Kim 
On 18. 12. 9., Cy Schubert wrote:
> Author: cy
> Date: Sun Dec  9 06:45:49 2018
> New Revision: 341759
> URL: https://svnweb.freebsd.org/changeset/base/341759
> 
> Log:
>   MFV r341618:
>   
>   Update wpa 2.6 --> 2.7.

...

This broke my network configuration and I found the following messages
from /dev/log/message.

... bge0: CTRL-EVENT-EAP-PROPOSED-METHOD vendor=0 method=25
... bge0: CTRL-EVENT-EAP-METHOD EAP vendor 0 method 25 (PEAP) selected
... SSL: SSL3 alert: write (local SSL3 detected an error):fatal:internal
error
... OpenSSL: openssl_handshake - SSL_connect error:141A90B5:SSL
routines:ssl_cipher_list_to_bytes:no ciphers available
... bge0: CTRL-EVENT-EAP-FAILURE EAP authentication failed

I tracked it down and found default ciphers were not set because
usr.sbin/wpa/Makefile.inc added an empty string, i.e.,
-DTLS_DEFAULT_CIPHERS=\"\".

With the attached patch, I got my connection back.

Jung-uk Kim
Index: usr.sbin/wpa/Makefile.inc
===
--- usr.sbin/wpa/Makefile.inc	(revision 341826)
+++ usr.sbin/wpa/Makefile.inc	(working copy)
@@ -32,6 +32,6 @@ CFLAGS+=-I${WPA_DISTDIR}/src/wps
 CFLAGS+= -DCONFIG_CTRL_IFACE
 CFLAGS+= -DCONFIG_CTRL_IFACE_UNIX
 CFLAGS+= -DNEED_AP_MLME
-CFLAGS+= -DTLS_DEFAULT_CIPHERS=\"$(CONFIG_TLS_DEFAULT_CIPHERS)\"
+CFLAGS+= -DTLS_DEFAULT_CIPHERS=\"DEFAULT:!EXP:!LOW\"
 
 .include 


signature.asc
Description: OpenPGP digital signature

svn commit: r341838 - in head/lib/libc: regex tests/regex

2018-12-11 Thread Yuri Pankov 
Author: yuripv
Date: Wed Dec 12 04:23:00 2018
New Revision: 341838
URL: https://svnweb.freebsd.org/changeset/base/341838

Log:
  regcomp: reduce size of bitmap for multibyte locales
  
  This fixes the obscure endless loop seen with case-insensitive
  patterns containing characters in 128-255 range;  originally
  found running GNU grep test suite.
  
  Our regex implementation being kludgy translates the characters
  in case-insensitive pattern to bracket expression containing both
  cases for the character and doesn't correctly handle the case when
  original character is in bitmap and the other case is not, falling
  into the endless loop going through in p_bracket(), ordinary(),
  and bothcases().
  
  Reducing the bitmap to 0-127 range for multibyte locales solves this
  as none of these characters have other case mapping outside of bitmap.
  We are also safe in the case when the original character outside of
  bitmap has other case mapping in the bitmap (there are several of those
  in our current ctype maps having unidirectional mapping into bitmap).
  
  Reviewed by:  bapt, kevans, pfg
  Differential revision:https://reviews.freebsd.org/D18302

Modified:
  head/lib/libc/regex/regcomp.c
  head/lib/libc/regex/regex2.h
  head/lib/libc/regex/utils.h
  head/lib/libc/tests/regex/multibyte.sh

Modified: head/lib/libc/regex/regcomp.c
==
--- head/lib/libc/regex/regcomp.c   Wed Dec 12 02:33:01 2018
(r341837)
+++ head/lib/libc/regex/regcomp.c   Wed Dec 12 04:23:00 2018
(r341838)
@@ -1841,21 +1841,29 @@ computejumps(struct parse *p, struct re_guts *g)
 {
int ch;
int mindex;
+   int cmin, cmax;
 
+   /*
+* For UTF-8 we process only the first 128 characters corresponding to
+* the POSIX locale.
+*/
+   cmin = MB_CUR_MAX == 1 ? CHAR_MIN : 0;
+   cmax = MB_CUR_MAX == 1 ? CHAR_MAX : 127;
+
/* Avoid making errors worse */
if (p->error != 0)
return;
 
-   g->charjump = (int*) malloc((NC + 1) * sizeof(int));
+   g->charjump = (int *)malloc((cmax - cmin + 1) * sizeof(int));
if (g->charjump == NULL)/* Not a fatal error */
return;
/* Adjust for signed chars, if necessary */
-   g->charjump = >charjump[-(CHAR_MIN)];
+   g->charjump = >charjump[-(cmin)];
 
/* If the character does not exist in the pattern, the jump
 * is equal to the number of characters in the pattern.
 */
-   for (ch = CHAR_MIN; ch < (CHAR_MAX + 1); ch++)
+   for (ch = cmin; ch < cmax + 1; ch++)
g->charjump[ch] = g->mlen;
 
/* If the character does exist, compute the jump that would

Modified: head/lib/libc/regex/regex2.h
==
--- head/lib/libc/regex/regex2.hWed Dec 12 02:33:01 2018
(r341837)
+++ head/lib/libc/regex/regex2.hWed Dec 12 04:23:00 2018
(r341838)
@@ -113,7 +113,7 @@ typedef struct {
wint_t  max;
 } crange;
 typedef struct {
-   unsigned char   bmp[NC / 8];
+   unsigned char   bmp[NC_MAX / 8];
wctype_t*types;
unsigned intntypes;
wint_t  *wides;
@@ -133,9 +133,14 @@ CHIN1(cset *cs, wint_t ch)
if (ch < NC)
return (((cs->bmp[ch >> 3] & (1 << (ch & 7))) != 0) ^
cs->invert);
-   for (i = 0; i < cs->nwides; i++)
-   if (ch == cs->wides[i])
+   for (i = 0; i < cs->nwides; i++) {
+   if (cs->icase) {
+   if (ch == towlower(cs->wides[i]) ||
+   ch == towupper(cs->wides[i]))
+   return (!cs->invert);
+   } else if (ch == cs->wides[i])
return (!cs->invert);
+   }
for (i = 0; i < cs->nranges; i++)
if (cs->ranges[i].min <= ch && ch <= cs->ranges[i].max)
return (!cs->invert);

Modified: head/lib/libc/regex/utils.h
==
--- head/lib/libc/regex/utils.h Wed Dec 12 02:33:01 2018(r341837)
+++ head/lib/libc/regex/utils.h Wed Dec 12 04:23:00 2018(r341838)
@@ -39,7 +39,9 @@
 /* utility definitions */
 #defineDUPMAX  _POSIX2_RE_DUP_MAX  /* xxx is this right? */
 #defineINFINITY(DUPMAX + 1)
-#defineNC  (CHAR_MAX - CHAR_MIN + 1)
+
+#defineNC_MAX  (CHAR_MAX - CHAR_MIN + 1)
+#defineNC  ((MB_CUR_MAX) == 1 ? (NC_MAX) : (128))
 typedef unsigned char uch;
 
 /* switch off assertions (if not already off) if no REDEBUG */

Modified: head/lib/libc/tests/regex/multibyte.sh
==
--- head/lib/libc/tests/regex/multibyte.sh

svn commit: r341837 - head/sbin/ping

2018-12-11 Thread Mark Johnston 
Author: markj
Date: Wed Dec 12 02:33:01 2018
New Revision: 341837
URL: https://svnweb.freebsd.org/changeset/base/341837

Log:
  Use Capsicum helpers in ping(8).
  
  Also use caph_cache_catpages() to ensure that strerror() works when
  run with kern.trap_enotcap=1.
  
  Reviewed by:  oshogbo
  MFC after:1 week
  Sponsored by: The FreeBSD Foundation
  Differential Revision:https://reviews.freebsd.org/D18514

Modified:
  head/sbin/ping/ping.c

Modified: head/sbin/ping/ping.c
==
--- head/sbin/ping/ping.c   Tue Dec 11 22:14:37 2018(r341836)
+++ head/sbin/ping/ping.c   Wed Dec 12 02:33:01 2018(r341837)
@@ -85,6 +85,7 @@ __FBSDID("$FreeBSD$");
 #include 
 #endif /*IPSEC*/
 
+#include 
 #include 
 #include 
 #include 
@@ -258,7 +259,6 @@ main(int argc, char *const *argv)
policy_in = policy_out = NULL;
 #endif
cap_rights_t rights;
-   bool cansandbox;
 
/*
 * Do the stuff that we need root priv's for *first*, and
@@ -702,27 +702,20 @@ main(int argc, char *const *argv)
ip->ip_dst = to->sin_addr;
 }
 
-   if (options & F_NUMERIC)
-   cansandbox = true;
-   else if (capdns != NULL)
-   cansandbox = CASPER_SUPPORT;
-   else
-   cansandbox = false;
-
/*
 * Here we enter capability mode. Further down access to global
 * namespaces (e.g filesystem) is restricted (see capsicum(4)).
 * We must connect(2) our socket before this point.
 */
-   if (cansandbox && cap_enter() < 0 && errno != ENOSYS)
+   caph_cache_catpages();
+   if (caph_enter() < 0)
err(1, "cap_enter");
 
cap_rights_init(, CAP_RECV, CAP_EVENT, CAP_SETSOCKOPT);
-   if (cap_rights_limit(srecv, ) < 0 && errno != ENOSYS)
+   if (caph_rights_limit(srecv, ) < 0)
err(1, "cap_rights_limit srecv");
-
cap_rights_init(, CAP_SEND, CAP_SETSOCKOPT);
-   if (cap_rights_limit(ssend, ) < 0 && errno != ENOSYS)
+   if (caph_rights_limit(ssend, ) < 0)
err(1, "cap_rights_limit ssend");
 
/* record route option */
@@ -807,14 +800,14 @@ main(int argc, char *const *argv)
sizeof(hold));
/* CAP_SETSOCKOPT removed */
cap_rights_init(, CAP_RECV, CAP_EVENT);
-   if (cap_rights_limit(srecv, ) < 0 && errno != ENOSYS)
+   if (caph_rights_limit(srecv, ) < 0)
err(1, "cap_rights_limit srecv setsockopt");
if (uid == 0)
(void)setsockopt(ssend, SOL_SOCKET, SO_SNDBUF, (char *),
sizeof(hold));
/* CAP_SETSOCKOPT removed */
cap_rights_init(, CAP_SEND);
-   if (cap_rights_limit(ssend, ) < 0 && errno != ENOSYS)
+   if (caph_rights_limit(ssend, ) < 0)
err(1, "cap_rights_limit ssend setsockopt");
 
if (to->sin_family == 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: r341803 - head/libexec/rc

2018-12-11 Thread Simon J. Gerraty 
Just caught the tail of this thread so sorry for
chiming in from the peanut gallery...

blah | while read x; do ...; done

behaves very differently to the for loop variant in that the body of the
loop runs in a sub-shell and thus cannot affect the outer scope.
In many cases that's exactly what you want.
Sometimes though, it isn't.

Conrad Meyer  wrote:
> On Tue, Dec 11, 2018 at 2:42 PM Devin Teske  wrote:
> > In that case, would it be appropriate to say that:
> >
> > blah | while read x; do ...; done
> >
> > Is always more efficiently written as:
> >
> > IFS=$'\n'
> > for x in $( blah ); do ...; done
> 
> I don't know.  The suggestion came from jilles@, who is much more
> familiar with sh(1) than I am.
> 
> My understanding is that it's important that 'set -o noglob' is set,
> or else 'blah' lines that include globs may be evaluated against the
> filesystem.  There is also a caveat if 'blah' is the 'set' command, or
> similar, in that IFS' own value itself will be split across multiple
> for loop iteration 'x' values ("IFS='", "'").
> 
> I would hesitate to say "always" given my limited understanding of the
> shell, but it might be true.
___
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: r341682 - head/sys/sys

2018-12-11 Thread Konstantin Belousov 
On Mon, Dec 10, 2018 at 09:57:08PM -0700, Scott Long wrote:
> 
> 
> > On Dec 10, 2018, at 4:47 PM, Konstantin Belousov  
> > wrote:
> > 
> > On Mon, Dec 10, 2018 at 02:15:20PM -0800, John Baldwin wrote:
> >> On 12/8/18 7:43 PM, Warner Losh wrote:
> >>> 
> >>> 
> >>> On Sat, Dec 8, 2018, 8:36 PM Kevin Bowling  >>>  wrote:
> >>> 
> >>>On Sat, Dec 8, 2018 at 12:09 AM Mateusz Guzik  >>> > wrote:
> >>> 
>  
>  Fully satisfying solution would be that all architectures get 64-bit
>  ops, even if in the worst case they end up taking a lock. Then
>  subsystems would not have to ifdef on anything. However, there
>  was some opposition to this proposal and I don't think this is
>  important enough to push.
> >>> 
> >>>Mateusz,
> >>> 
> >>>Who is opposing this particular polyfill solution?  Scott Long brought
> >>>up a situation in driver development where this would be useful as
> >>>well.  The polyfills lower the cognitive load and #ifdef soup which
> >>>are the right call here regardless of performance on toy ports.
> >>> 
> >>> 
> >>> I don't recall seeing the opposition either. It would have to be a global 
> >>> lock for all 64bit atomics but I think it would only be 2 atomics on 
> >>> those architectures. 
> >> 
> >> It would have to be a spin lock, so in the case of unrl you would be 
> >> trading
> >> an operation on one of N regular mutexes for a single spin lock that was
> >> also contested by other things.  This would be pretty crappy.  For drivers
> >> that aren't actually used on platforms without 32-bit atomics we can simply
> >> not build them in sys/modules/Makefile or not put them in GENERIC.  For
> >> something in the core kernel like unrl I think we will have to do what
> >> Mateusz has done here.
> > 
> > It is worse. All atomics that acess the same location must use the same
> > lock. Otherwise, you could observe torn writes and out of thin air
> > values. Since you cannot know in advance which locations are acceses
> > by the locked variant, all freebsd atomics ops have to be switched to
> > locked variant on the architecture.
> 
> 64bit atomics on I486 already suffer the risk of torn reads; the 
> implementation
> merely does a CLI to protect against local preemption (though you could still
> get unlucky with an NMI).  I suppose you could argue that SMP isn’t really
> viable on I486 and therefore this fact is irrelevant, but it does illustrate
> precedence for having API completeness in a platform.
64bit atomics on 486 are fine, because we only support SMP on machines
which have cmpxchg8b.  Even then, I am not sure that we really support
the kind of SMP configurations from the Pentium times, at least I am certain
that this was not exercised for quite long time.

> 
> Really, this isn’t that hard.  Part of the existing contract of using atomics 
> is
> that you carefully evaluate all uses of the variable and decide when to use
> an atomic instruction.  Arguing that we can’t make this process automatic
> and foolproof for 64bit quantities, especially for a subset of subset of
> platforms/architectures, and therefore we should be even more of a difficult
> landmine, is not…. I don’t know what to say… sensical?

> 
> 64bit operations are a reality for MI code in a modern OS, and I’m tired of
> having to tip-toe around them due to incomplete MD implementations.  The
> instructions have been available on Intel CPUs for 25 years!  My
> very strong preference is to have a complete and functional implementation
> of atomic.h for any architecture that is hooked up to the build.  We can then
> tackle the details of optimization and edge case refinement, just like we do
> with every other API and service that we work on.  It doesn’t have to be
> perfect to be useful, and at this point we’re providing neither perfection nor
> utility, just “buts” and “what ifs”.
I do not understand this rant. Provide working implementation for 64bit
atomics on the arches which lack them, everybody will be happy.

My point is that implementing e.g. only atomic_add_64() using lock
is not a solution. Exactly because it makes inconsistent KPI which
does not satisfy basic guarantees which are provided on other arches,
heavily relied upon in FreeBSD code, and documented in atomic(9) in
the free prose, with further references to C11. I.e. instead of the
cross-arch KPI such implementation would require consumers to know arch
pecularities.  Isn't this complete failure of the goals ?

BTW, this is why C11 standard provides lockless predicate for atomic
types and not for atomic ops.  If one atomic op is locked, all of them
must be.

> 
> Going forward, I’m going to start using 64bit atomics where they’re prudent,
> instead of avoiding them due to this niche 32bit argument.  If that means
> more and more of what I do no longer compiles on a mips or a ppc32, then
> that’s a sacrifice that is fine with me.  It still creates

Re: svn commit: r341803 - head/libexec/rc

2018-12-11 Thread Conrad Meyer 
On Tue, Dec 11, 2018 at 2:42 PM Devin Teske  wrote:
> In that case, would it be appropriate to say that:
>
> blah | while read x; do ...; done
>
> Is always more efficiently written as:
>
> IFS=$'\n'
> for x in $( blah ); do ...; done

I don't know.  The suggestion came from jilles@, who is much more
familiar with sh(1) than I am.

My understanding is that it's important that 'set -o noglob' is set,
or else 'blah' lines that include globs may be evaluated against the
filesystem.  There is also a caveat if 'blah' is the 'set' command, or
similar, in that IFS' own value itself will be split across multiple
for loop iteration 'x' values ("IFS='", "'").

I would hesitate to say "always" given my limited understanding of the
shell, but it might be true.

Best,
Conrad
___
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: r341803 - head/libexec/rc

2018-12-11 Thread Devin Teske 



> On Dec 11, 2018, at 1:54 PM, Conrad Meyer  wrote:
> 
> On Tue, Dec 11, 2018 at 12:35 PM Devin Teske  wrote:
>>> On Dec 11, 2018, at 11:57 AM, Conrad Meyer  wrote:
>>> Is there any interest in a tee(2)-like syscall?
>>> 
>> 
>> Linux has vmsplice(2). I know jmg@ also expressed interest in having a
>> vmsplice in FreeBSD.
> 
> Sure; they're related.  See also splice(2).  But tee(2) is probably
> the one that would be most useful here.
> 
>> As for sh not being able to read more than a single byte at a time because
>> it could be reading from a pipe, what if it read into a buffer and returned
>> a line from the buffer. A subsequent read would return more data from the
>> buffer, ad nauseam until the buffer runs out -- in which case another chunk
>> is read to augment the data.
>> 
>> This buffer could be expunged when stdin collapses (e.g., when the sub-
>> shell completes.
> 
> Yeah, this is basically what "buffered input" means.  An example of
> the problem with the naive solution is the scenario Warner pasted a
> few emails ago.  Take:
> 
>foo | (read bar; baz)
> 
> (Where 'baz' is not a built-in.)  To implement this correctly with
> buffered 'read,' you have to somehow flush any input in the buffer
> beyond the end of the first line to the pipe that will be baz's stdin,
> as well as with the remaining contents of the pipe from foo (which
> may be indefinite).  That is what I suggested above as (A).
> 
> One big caveat is that you basically have to spawn a thread or process
> to keep feeding the input from the first pipe to the magical implicit
> pipe.  This overhead can be avoided readily in most scenarios if only
> the 'read' command is buffered.  Also, the described (read bar; baz)
> sub-program is a fairly odd construction, and the feeding isn't needed
> if no non-builtin programs after 'read' will access stdin.
> 
> If it helps paint a more concrete picture, imagine 'foo' as 'yes' and
> 'baz' as 'pv > /dev/null' or something (i.e., indefinite data source,
> indefinite data sink).

Thanks, this definitely illustrates the trouble.

In that case, would it be appropriate to say that:

blah | while read x; do ...; done

Is always more efficiently written as:

IFS=$'\n'
for x in $( blah ); do ...; done

?
-- 
Devin
___
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: r341836 - in head: lib/libufs sbin/fsck_ffs sbin/fsirand sbin/newfs sys/sys sys/ufs/ffs sys/ufs/ufs

2018-12-11 Thread Kirk McKusick 
Author: mckusick
Date: Tue Dec 11 22:14:37 2018
New Revision: 341836
URL: https://svnweb.freebsd.org/changeset/base/341836

Log:
  Continuing efforts to provide hardening of FFS. This change adds a
  check hash to the filesystem inodes. Access attempts to files
  associated with an inode with an invalid check hash will fail with
  EINVAL (Invalid argument). Access is reestablished after an fsck
  is run to find and validate the inodes with invalid check-hashes.
  This check avoids a class of filesystem panics related to corrupted
  inodes. The hash is done using crc32c.
  
  Note this check-hash is for the inode itself and not any of its
  indirect blocks. Check-hash validation may be extended to also
  cover indirect block pointers, but that will be a separate (and
  more costly) feature.
  
  Check hashes are added only to UFS2 and not to UFS1 as UFS1 is
  primarily used in embedded systems with small memories and low-powered
  processors which need as light-weight a filesystem as possible.
  
  Reviewed by:  kib
  Tested by:Peter Holm
  Sponsored by: Netflix

Modified:
  head/lib/libufs/inode.c
  head/lib/libufs/libufs.h
  head/sbin/fsck_ffs/inode.c
  head/sbin/fsck_ffs/main.c
  head/sbin/fsirand/fsirand.c
  head/sbin/newfs/mkfs.c
  head/sys/sys/param.h
  head/sys/ufs/ffs/ffs_extern.h
  head/sys/ufs/ffs/ffs_inode.c
  head/sys/ufs/ffs/ffs_snapshot.c
  head/sys/ufs/ffs/ffs_softdep.c
  head/sys/ufs/ffs/ffs_subr.c
  head/sys/ufs/ffs/ffs_vfsops.c
  head/sys/ufs/ufs/dinode.h

Modified: head/lib/libufs/inode.c
==
--- head/lib/libufs/inode.c Tue Dec 11 21:49:13 2018(r341835)
+++ head/lib/libufs/inode.c Tue Dec 11 22:14:37 2018(r341836)
@@ -90,7 +90,10 @@ gotit:   switch (disk->d_ufs) {
disk->d_dp.dp2 = &((struct ufs2_dinode *)inoblock)[inum - min];
if (dp != NULL)
*dp = disk->d_dp;
-   return (0);
+   if (ffs_verify_dinode_ckhash(fs, disk->d_dp.dp2) == 0)
+   return (0);
+   ERROR(disk, "check-hash failed for inode read from disk");
+   return (-1);
default:
break;
}
@@ -108,6 +111,8 @@ putinode(struct uufsd *disk)
ERROR(disk, "No inode block allocated");
return (-1);
}
+   if (disk->d_ufs == 2)
+   ffs_update_dinode_ckhash(fs, disk->d_dp.dp2);
if (bwrite(disk, fsbtodb(fs, ino_to_fsba(>d_fs, disk->d_inomin)),
disk->d_inoblock, disk->d_fs.fs_bsize) <= 0)
return (-1);

Modified: head/lib/libufs/libufs.h
==
--- head/lib/libufs/libufs.hTue Dec 11 21:49:13 2018(r341835)
+++ head/lib/libufs/libufs.hTue Dec 11 22:14:37 2018(r341836)
@@ -116,6 +116,8 @@ int ffs_sbget(void *, struct fs **, off_t, char *,
int (*)(void *, off_t, void **, int));
 intffs_sbput(void *, struct fs *, off_t,
int (*)(void *, off_t, void *, int));
+void   ffs_update_dinode_ckhash(struct fs *, struct ufs2_dinode *);
+intffs_verify_dinode_ckhash(struct fs *, struct ufs2_dinode *);
 
 /*
  * Request standard superblock location in ffs_sbget

Modified: head/sbin/fsck_ffs/inode.c
==
--- head/sbin/fsck_ffs/inode.c  Tue Dec 11 21:49:13 2018(r341835)
+++ head/sbin/fsck_ffs/inode.c  Tue Dec 11 22:14:37 2018(r341836)
@@ -286,6 +286,7 @@ union dinode *
 ginode(ino_t inumber)
 {
ufs2_daddr_t iblk;
+   union dinode *dp;
 
if (inumber < UFS_ROOTINO || inumber > maxino)
errx(EEXIT, "bad inode number %ju to ginode",
@@ -301,7 +302,17 @@ ginode(ino_t inumber)
if (sblock.fs_magic == FS_UFS1_MAGIC)
return ((union dinode *)
>b_un.b_dinode1[inumber % INOPB()]);
-   return ((union dinode *)>b_un.b_dinode2[inumber % INOPB()]);
+   dp = (union dinode *)>b_un.b_dinode2[inumber % INOPB()];
+   if (ffs_verify_dinode_ckhash(, (struct ufs2_dinode *)dp) != 0) {
+   pwarn("INODE CHECK-HASH FAILED");
+   prtinode(inumber, dp);
+   if (preen || reply("FIX") != 0) {
+   if (preen)
+   printf(" (FIXED)\n");
+   inodirty(dp);
+   }
+   }
+   return (dp);
 }
 
 /*
@@ -347,6 +358,21 @@ getnextinode(ino_t inumber, int rebuildcg)
nextinop += sizeof(struct ufs1_dinode);
else
nextinop += sizeof(struct ufs2_dinode);
+   if ((ckhashadd & CK_INODE) != 0) {
+   ffs_update_dinode_ckhash(, (struct ufs2_dinode *)dp);
+   dirty();
+   }
+   if (ffs_verify_dinode_ckhash(, (struct ufs2_dinode *)dp) != 0) {
+   pwarn("INODE

Re: svn commit: r341803 - head/libexec/rc

2018-12-11 Thread Conrad Meyer 
On Tue, Dec 11, 2018 at 12:35 PM Devin Teske  wrote:
> > On Dec 11, 2018, at 11:57 AM, Conrad Meyer  wrote:
> > Is there any interest in a tee(2)-like syscall?
> >
>
> Linux has vmsplice(2). I know jmg@ also expressed interest in having a
> vmsplice in FreeBSD.

Sure; they're related.  See also splice(2).  But tee(2) is probably
the one that would be most useful here.

> As for sh not being able to read more than a single byte at a time because
> it could be reading from a pipe, what if it read into a buffer and returned
> a line from the buffer. A subsequent read would return more data from the
> buffer, ad nauseam until the buffer runs out -- in which case another chunk
> is read to augment the data.
>
> This buffer could be expunged when stdin collapses (e.g., when the sub-
> shell completes.

Yeah, this is basically what "buffered input" means.  An example of
the problem with the naive solution is the scenario Warner pasted a
few emails ago.  Take:

foo | (read bar; baz)

(Where 'baz' is not a built-in.)  To implement this correctly with
buffered 'read,' you have to somehow flush any input in the buffer
beyond the end of the first line to the pipe that will be baz's stdin,
 as well as with the remaining contents of the pipe from foo (which
may be indefinite).  That is what I suggested above as (A).

One big caveat is that you basically have to spawn a thread or process
to keep feeding the input from the first pipe to the magical implicit
pipe.  This overhead can be avoided readily in most scenarios if only
the 'read' command is buffered.  Also, the described (read bar; baz)
sub-program is a fairly odd construction, and the feeding isn't needed
if no non-builtin programs after 'read' will access stdin.

If it helps paint a more concrete picture, imagine 'foo' as 'yes' and
'baz' as 'pv > /dev/null' or something (i.e., indefinite data source,
indefinite data sink).

Best,
Conrad
___
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: r341835 - head/tests/sys/netpfil/pf/ioctl

2018-12-11 Thread Kristof Provost 
Author: kp
Date: Tue Dec 11 21:49:13 2018
New Revision: 341835
URL: https://svnweb.freebsd.org/changeset/base/341835

Log:
  pf tests: Use the ATF cleanup infrastructure in the ioctl tests
  
  Use ATF_TC_CLEANUP(), because that means the cleanup code will get
  called even if a test fails. Before it would only be executed if every
  test within the body succeeded.
  
  Reported by:  Marie Helene Kvello-Aune 
  MFC after:2 weeks

Modified:
  head/tests/sys/netpfil/pf/ioctl/validation.c

Modified: head/tests/sys/netpfil/pf/ioctl/validation.c
==
--- head/tests/sys/netpfil/pf/ioctl/validation.cTue Dec 11 21:45:56 
2018(r341834)
+++ head/tests/sys/netpfil/pf/ioctl/validation.cTue Dec 11 21:49:13 
2018(r341835)
@@ -61,7 +61,7 @@ common_init_tbl(struct pfr_table *tbl)
tbl->pfrt_fback = 0;
 }
 
-ATF_TC(addtables);
+ATF_TC_WITH_CLEANUP(addtables);
 ATF_TC_HEAD(addtables, tc)
 {
atf_tc_set_md_var(tc, "require.user", "root");
@@ -106,11 +106,14 @@ ATF_TC_BODY(addtables, tc)
 
io.pfrio_buffer = 
ioctl(dev, DIOCRADDTABLES, );
+}
 
+ATF_TC_CLEANUP(addtables, tc)
+{
COMMON_CLEANUP();
 }
 
-ATF_TC(deltables);
+ATF_TC_WITH_CLEANUP(deltables);
 ATF_TC_HEAD(deltables, tc)
 {
atf_tc_set_md_var(tc, "require.user", "root");
@@ -146,11 +149,14 @@ ATF_TC_BODY(deltables, tc)
io.pfrio_buffer = NULL;
if (ioctl(dev, DIOCRDELTABLES, ) == 0)
atf_tc_fail("Request with NULL buffer succeeded");
+}
 
+ATF_TC_CLEANUP(deltables, tc)
+{
COMMON_CLEANUP();
 }
 
-ATF_TC(gettables);
+ATF_TC_WITH_CLEANUP(gettables);
 ATF_TC_HEAD(gettables, tc)
 {
atf_tc_set_md_var(tc, "require.user", "root");
@@ -181,11 +187,14 @@ ATF_TC_BODY(gettables, tc)
io.pfrio_size = 1 << 24;
if (ioctl(dev, DIOCRGETTABLES, ) != 0)
atf_tc_fail("Request with size 1 << 24 failed");
+}
 
+ATF_TC_CLEANUP(gettables, tc)
+{
COMMON_CLEANUP();
 }
 
-ATF_TC(gettstats);
+ATF_TC_WITH_CLEANUP(gettstats);
 ATF_TC_HEAD(gettstats, tc)
 {
atf_tc_set_md_var(tc, "require.user", "root");
@@ -216,11 +225,14 @@ ATF_TC_BODY(gettstats, tc)
io.pfrio_size = 1 << 24;
if (ioctl(dev, DIOCRGETTSTATS, ) != 0)
atf_tc_fail("Request with size 1 << 24 failed");
+}
 
+ATF_TC_CLEANUP(gettstats, tc)
+{
COMMON_CLEANUP();
 }
 
-ATF_TC(clrtstats);
+ATF_TC_WITH_CLEANUP(clrtstats);
 ATF_TC_HEAD(clrtstats, tc)
 {
atf_tc_set_md_var(tc, "require.user", "root");
@@ -253,11 +265,14 @@ ATF_TC_BODY(clrtstats, tc)
io.pfrio_size = 1 << 24;
if (ioctl(dev, DIOCRCLRTSTATS, ) != 0)
atf_tc_fail("Request with size 1 << 24 failed");
+}
 
+ATF_TC_CLEANUP(clrtstats, tc)
+{
COMMON_CLEANUP();
 }
 
-ATF_TC(settflags);
+ATF_TC_WITH_CLEANUP(settflags);
 ATF_TC_HEAD(settflags, tc)
 {
atf_tc_set_md_var(tc, "require.user", "root");
@@ -290,11 +305,14 @@ ATF_TC_BODY(settflags, tc)
io.pfrio_size = 1 << 28;
if (ioctl(dev, DIOCRSETTFLAGS, ) != 0)
atf_tc_fail("Request with size 1 << 24 failed");
+}
 
+ATF_TC_CLEANUP(settflags, tc)
+{
COMMON_CLEANUP();
 }
 
-ATF_TC(addaddrs);
+ATF_TC_WITH_CLEANUP(addaddrs);
 ATF_TC_HEAD(addaddrs, tc)
 {
atf_tc_set_md_var(tc, "require.user", "root");
@@ -322,11 +340,14 @@ ATF_TC_BODY(addaddrs, tc)
io.pfrio_size = 1 << 28;
if (ioctl(dev, DIOCRADDADDRS, ) == 0)
atf_tc_fail("Reuqest with size 1 << 28 failed");
+}
 
+ATF_TC_CLEANUP(addaddrs, tc)
+{
COMMON_CLEANUP();
 }
 
-ATF_TC(deladdrs);
+ATF_TC_WITH_CLEANUP(deladdrs);
 ATF_TC_HEAD(deladdrs, tc)
 {
atf_tc_set_md_var(tc, "require.user", "root");
@@ -354,11 +375,14 @@ ATF_TC_BODY(deladdrs, tc)
io.pfrio_size = 1 << 28;
if (ioctl(dev, DIOCRDELADDRS, ) == 0)
atf_tc_fail("Reuqest with size 1 << 28 failed");
+}
 
+ATF_TC_CLEANUP(deladdrs, tc)
+{
COMMON_CLEANUP();
 }
 
-ATF_TC(setaddrs);
+ATF_TC_WITH_CLEANUP(setaddrs);
 ATF_TC_HEAD(setaddrs, tc)
 {
atf_tc_set_md_var(tc, "require.user", "root");
@@ -386,11 +410,14 @@ ATF_TC_BODY(setaddrs, tc)
io.pfrio_size = 1 << 28;
if (ioctl(dev, DIOCRSETADDRS, ) == 0)
atf_tc_fail("Reuqest with size 1 << 28 failed");
+}
 
+ATF_TC_CLEANUP(setaddrs, tc)
+{
COMMON_CLEANUP();
 }
 
-ATF_TC(getaddrs);
+ATF_TC_WITH_CLEANUP(getaddrs);
 ATF_TC_HEAD(getaddrs, tc)
 {
atf_tc_set_md_var(tc, "require.user", "root");
@@ -420,11 +447,14 @@ ATF_TC_BODY(getaddrs, tc)
io.pfrio_size = 1 << 24;
if (ioctl(dev, DIOCRGETADDRS, ) == 0)
atf_tc_fail("Request with size 1 << 24 failed");
+}
 
+ATF_TC_CLEANUP(getaddrs, tc)
+{
COMMON_CLEANUP();
 }
 
-ATF_TC(getastats);
+ATF_TC_WITH_CLEANUP(getastats);
 ATF_TC_HEAD(getastats, tc)
 {
atf_tc_set_md_var(tc, "require.user", "root");
@@ -454,11

svn commit: r341834 - head/tests/sys/netpfil/pf/ioctl

2018-12-11 Thread Kristof Provost 
Author: kp
Date: Tue Dec 11 21:45:56 2018
New Revision: 341834
URL: https://svnweb.freebsd.org/changeset/base/341834

Log:
  pf tests: ioctl tests require root rights
  
  Explicitly mark these tests as requiring root rights. We need to be able
  to open /dev/pf.
  
  Reported by:  Marie Helene Kvello-Aune 
  MFC after:2 weeks

Modified:
  head/tests/sys/netpfil/pf/ioctl/validation.c

Modified: head/tests/sys/netpfil/pf/ioctl/validation.c
==
--- head/tests/sys/netpfil/pf/ioctl/validation.cTue Dec 11 21:44:39 
2018(r341833)
+++ head/tests/sys/netpfil/pf/ioctl/validation.cTue Dec 11 21:45:56 
2018(r341834)
@@ -61,7 +61,12 @@ common_init_tbl(struct pfr_table *tbl)
tbl->pfrt_fback = 0;
 }
 
-ATF_TC_WITHOUT_HEAD(addtables);
+ATF_TC(addtables);
+ATF_TC_HEAD(addtables, tc)
+{
+   atf_tc_set_md_var(tc, "require.user", "root");
+}
+
 ATF_TC_BODY(addtables, tc)
 {
struct pfioc_table io;
@@ -105,7 +110,12 @@ ATF_TC_BODY(addtables, tc)
COMMON_CLEANUP();
 }
 
-ATF_TC_WITHOUT_HEAD(deltables);
+ATF_TC(deltables);
+ATF_TC_HEAD(deltables, tc)
+{
+   atf_tc_set_md_var(tc, "require.user", "root");
+}
+
 ATF_TC_BODY(deltables, tc)
 {
struct pfioc_table io;
@@ -140,7 +150,12 @@ ATF_TC_BODY(deltables, tc)
COMMON_CLEANUP();
 }
 
-ATF_TC_WITHOUT_HEAD(gettables);
+ATF_TC(gettables);
+ATF_TC_HEAD(gettables, tc)
+{
+   atf_tc_set_md_var(tc, "require.user", "root");
+}
+
 ATF_TC_BODY(gettables, tc)
 {
struct pfioc_table io;
@@ -170,7 +185,12 @@ ATF_TC_BODY(gettables, tc)
COMMON_CLEANUP();
 }
 
-ATF_TC_WITHOUT_HEAD(gettstats);
+ATF_TC(gettstats);
+ATF_TC_HEAD(gettstats, tc)
+{
+   atf_tc_set_md_var(tc, "require.user", "root");
+}
+
 ATF_TC_BODY(gettstats, tc)
 {
struct pfioc_table io;
@@ -200,7 +220,12 @@ ATF_TC_BODY(gettstats, tc)
COMMON_CLEANUP();
 }
 
-ATF_TC_WITHOUT_HEAD(clrtstats);
+ATF_TC(clrtstats);
+ATF_TC_HEAD(clrtstats, tc)
+{
+   atf_tc_set_md_var(tc, "require.user", "root");
+}
+
 ATF_TC_BODY(clrtstats, tc)
 {
struct pfioc_table io;
@@ -232,7 +257,12 @@ ATF_TC_BODY(clrtstats, tc)
COMMON_CLEANUP();
 }
 
-ATF_TC_WITHOUT_HEAD(settflags);
+ATF_TC(settflags);
+ATF_TC_HEAD(settflags, tc)
+{
+   atf_tc_set_md_var(tc, "require.user", "root");
+}
+
 ATF_TC_BODY(settflags, tc)
 {
struct pfioc_table io;
@@ -264,7 +294,12 @@ ATF_TC_BODY(settflags, tc)
COMMON_CLEANUP();
 }
 
-ATF_TC_WITHOUT_HEAD(addaddrs);
+ATF_TC(addaddrs);
+ATF_TC_HEAD(addaddrs, tc)
+{
+   atf_tc_set_md_var(tc, "require.user", "root");
+}
+
 ATF_TC_BODY(addaddrs, tc)
 {
struct pfioc_table io;
@@ -291,7 +326,12 @@ ATF_TC_BODY(addaddrs, tc)
COMMON_CLEANUP();
 }
 
-ATF_TC_WITHOUT_HEAD(deladdrs);
+ATF_TC(deladdrs);
+ATF_TC_HEAD(deladdrs, tc)
+{
+   atf_tc_set_md_var(tc, "require.user", "root");
+}
+
 ATF_TC_BODY(deladdrs, tc)
 {
struct pfioc_table io;
@@ -318,7 +358,12 @@ ATF_TC_BODY(deladdrs, tc)
COMMON_CLEANUP();
 }
 
-ATF_TC_WITHOUT_HEAD(setaddrs);
+ATF_TC(setaddrs);
+ATF_TC_HEAD(setaddrs, tc)
+{
+   atf_tc_set_md_var(tc, "require.user", "root");
+}
+
 ATF_TC_BODY(setaddrs, tc)
 {
struct pfioc_table io;
@@ -345,7 +390,12 @@ ATF_TC_BODY(setaddrs, tc)
COMMON_CLEANUP();
 }
 
-ATF_TC_WITHOUT_HEAD(getaddrs);
+ATF_TC(getaddrs);
+ATF_TC_HEAD(getaddrs, tc)
+{
+   atf_tc_set_md_var(tc, "require.user", "root");
+}
+
 ATF_TC_BODY(getaddrs, tc)
 {
struct pfioc_table io;
@@ -374,7 +424,12 @@ ATF_TC_BODY(getaddrs, tc)
COMMON_CLEANUP();
 }
 
-ATF_TC_WITHOUT_HEAD(getastats);
+ATF_TC(getastats);
+ATF_TC_HEAD(getastats, tc)
+{
+   atf_tc_set_md_var(tc, "require.user", "root");
+}
+
 ATF_TC_BODY(getastats, tc)
 {
struct pfioc_table io;
@@ -403,7 +458,12 @@ ATF_TC_BODY(getastats, tc)
COMMON_CLEANUP();
 }
 
-ATF_TC_WITHOUT_HEAD(clrastats);
+ATF_TC(clrastats);
+ATF_TC_HEAD(clrastats, tc)
+{
+   atf_tc_set_md_var(tc, "require.user", "root");
+}
+
 ATF_TC_BODY(clrastats, tc)
 {
struct pfioc_table io;
@@ -432,7 +492,12 @@ ATF_TC_BODY(clrastats, tc)
COMMON_CLEANUP();
 }
 
-ATF_TC_WITHOUT_HEAD(tstaddrs);
+ATF_TC(tstaddrs);
+ATF_TC_HEAD(tstaddrs, tc)
+{
+   atf_tc_set_md_var(tc, "require.user", "root");
+}
+
 ATF_TC_BODY(tstaddrs, tc)
 {
struct pfioc_table io;
@@ -461,7 +526,12 @@ ATF_TC_BODY(tstaddrs, tc)
COMMON_CLEANUP();
 }
 
-ATF_TC_WITHOUT_HEAD(inadefine);
+ATF_TC(inadefine);
+ATF_TC_HEAD(inadefine, tc)
+{
+   atf_tc_set_md_var(tc, "require.user", "root");
+}
+
 ATF_TC_BODY(inadefine, tc)
 {
struct pfioc_table io;
@@ -490,7 +560,12 @@ ATF_TC_BODY(inadefine, tc)
COMMON_CLEANUP();
 }
 
-ATF_TC_WITHOUT_HEAD(igetifaces);
+ATF_TC(igetifaces);
+ATF_TC_HEAD(igetifaces, tc)
+{
+   atf_tc_set_md_var(tc, "require.user", "root");
+}
+
 ATF_TC_BODY(igetifaces, tc)
 {
struct pfioc_iface io;
@@

svn commit: r341833 - head/sys/netpfil/pf

2018-12-11 Thread Kristof Provost 
Author: kp
Date: Tue Dec 11 21:44:39 2018
New Revision: 341833
URL: https://svnweb.freebsd.org/changeset/base/341833

Log:
  pf: Prevent integer overflow in PF when calculating the adaptive timeout.
  
  Mainly states of established TCP connections would be affected resulting
  in immediate state removal once the number of states is bigger than
  adaptive.start.  Disabling adaptive timeouts is a workaround to avoid this 
bug.
  Issue found and initial diff by Mathieu Blanc (mathieu.blanc at cea dot fr)
  
  Reported by: Andreas Longwitz 
  Obtained from:  OpenBSD
  MFC after:2 weeks

Modified:
  head/sys/netpfil/pf/pf.c

Modified: head/sys/netpfil/pf/pf.c
==
--- head/sys/netpfil/pf/pf.cTue Dec 11 21:16:09 2018(r341832)
+++ head/sys/netpfil/pf/pf.cTue Dec 11 21:44:39 2018(r341833)
@@ -1567,9 +1567,11 @@ pf_state_expires(const struct pf_state *state)
states = V_pf_status.states;
}
if (end && states > start && start < end) {
-   if (states < end)
-   return (state->expire + timeout * (end - states) /
-   (end - start));
+   if (states < end) {
+   timeout = (u_int64_t)timeout * (end - states) /
+   (end - start);
+   return (state->expire + timeout);
+   }
else
return (time_uptime);
}
___
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: r341803 - head/libexec/rc

2018-12-11 Thread Poul-Henning Kamp 

In message <20181212071210.l...@besplex.bde.org>, Bruce Evans writes:

>But software bloat is now outrunning CPU speed increases.  Some bandwidths
>for reading 1 byte at a time run today on the same 2GHz CPU i386 UP hardware
>
>linux-2.1.128 kernel built in 1998: 2500k/sec
>linux-2.4.0t8 kernel built in 2000: 1720k/sec
>linux-2.6.10  kernel built in 2004: 1540k/sec
>FreeBSD-4 kernel built in 2007:  680k/sec
>FreeBSD-~5.2  kernel built in 2018:  700k/sec
>FreeBSD-11kernel built in 2018:  720k/sec (SMP kernel)
>FreeBSD-pre12 kernel built in 2018:  540k/sec (SMP kernel)
>FreeBSD-13kernel built in 2018:  170k/sec (SMP kernel)

It is not just software bloat, it is also caused by the deeper and
deeper pile of kludges between what goes for a "CPU" these days and
what counts as "RAM".

-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
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: r341832 - head/tools/build/options

2018-12-11 Thread Bjoern A. Zeeb 
Author: bz
Date: Tue Dec 11 21:16:09 2018
New Revision: 341832
URL: https://svnweb.freebsd.org/changeset/base/341832

Log:
  Remove a dead file.  CVS was removed in r251794.

Deleted:
  head/tools/build/options/WITHOUT_CVS
___
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: r341803 - head/libexec/rc

2018-12-11 Thread Bruce Evans 

On Tue, 11 Dec 2018, John Baldwin wrote:


On 12/11/18 9:40 AM, Devin Teske wrote:

...
Thank you for the background which was lost by the time I got to the phab.

I can't help but ask though,...

If it was noticed that read(2) processes the stream one byte at a time,
why not just optimize read(2)?

I'm afraid of the prospect of having to hunt down every instance of while-read,
but if we can fix the underlying read(2) inefficiency then we make while-read 
OK.


It's a system call.  A CPU emulator has to do a lot of work for a system call
because it involves two mode switches (user -> kernel and back again).  You
can't "fix" that as it's just a part of the CPU architecture.  There's a reason
that stdio uses buffering by default, it's because system calls have overhead.
The 'read' builtin in sh can't use buffering, so it is always going to be
inefficient.


Syscalls have always been well known to be slow, but slowness is relative.
CPUs are thousands of times slower that in 1980, so systems should be able
to crunch through a few MB of data read 1 byte at a time fast enough that
no one notices the slowness, even when emulated.

But software bloat is now outrunning CPU speed increases.  Some bandwidths
for reading 1 byte at a time run today on the same 2GHz CPU i386 UP hardware

linux-2.1.128 kernel built in 1998: 2500k/sec
linux-2.4.0t8 kernel built in 2000: 1720k/sec
linux-2.6.10  kernel built in 2004: 1540k/sec
FreeBSD-4 kernel built in 2007:  680k/sec
FreeBSD-~5.2  kernel built in 2018:  700k/sec
FreeBSD-11kernel built in 2018:  720k/sec (SMP kernel)
FreeBSD-pre12 kernel built in 2018:  540k/sec (SMP kernel)
FreeBSD-13kernel built in 2018:  170k/sec (SMP kernel)

This is with all recent security-related pessimizations like ibrs turned off,
except the main one for i386 is using separate address spaces for the kernel
and userland and this cannot be turned off.  This is what gives most of the
recent slowdown factor of more than 3.  This slowdown factor is close to
3 for large block sizes, since read() is so slow that it takes about the
same time for all block sizes below a few hundred bytes.

Network bandwidth has similar slowdowns for small packets starting in
FreeBSD-4 (the old Linuxes have low enough syscall overhead for the NIC
to saturate at 640 kpps before the CPU or 1 Gbps ethernet saturates).
amd64 doesn't have the 3-fold slowdown from separate address spaces.

Optimizing syscalls is not very important, but it is convenient for
applications with bad buffering to not be very slow, and it is annoying
to lose benchmarks by a factor of 2 in 1998 and 10 now.

Bruce
___
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: r341831 - stable/12/sys/powerpc/conf

2018-12-11 Thread Niclas Zeising 
Author: zeising (doc,ports committer)
Date: Tue Dec 11 21:01:38 2018
New Revision: 341831
URL: https://svnweb.freebsd.org/changeset/base/341831

Log:
  MFC 340694: Enable evdev on ppc32
  
  Enable evdev on ppc32 as well, similar to what was done i386 and amd64 in
  r340387 and ppc64 in r340632.
  
  Evdev can be used by X and is used by wayland to handle input devices.
  
  Approved by:  jhibbits

Modified:
  stable/12/sys/powerpc/conf/GENERIC
Directory Properties:
  stable/12/   (props changed)

Modified: stable/12/sys/powerpc/conf/GENERIC
==
--- stable/12/sys/powerpc/conf/GENERIC  Tue Dec 11 20:56:05 2018
(r341830)
+++ stable/12/sys/powerpc/conf/GENERIC  Tue Dec 11 21:01:38 2018
(r341831)
@@ -219,3 +219,8 @@ device  sound   # Generic sound driver 
(required)
 device snd_ai2s# Apple I2S audio
 device snd_davbus  # Apple DAVBUS audio
 device snd_uaudio  # USB Audio
+
+# evdev interface
+optionsEVDEV_SUPPORT   # evdev support in legacy drivers
+device evdev   # input event device support
+device uinput  # install /dev/uinput cdev
___
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: r341830 - stable/12/sys/powerpc/conf

2018-12-11 Thread Niclas Zeising 
Author: zeising (doc,ports committer)
Date: Tue Dec 11 20:56:05 2018
New Revision: 341830
URL: https://svnweb.freebsd.org/changeset/base/341830

Log:
  MFC 340632
  
  Enable evdev on ppc64
  
  Enable evdev on ppc64 as well, similar to what was done for amd64 and i386
  in r340387.
  
  Evdev can be used by X and is used by wayland to handle input devices.
  
  Approved by:  mmacy

Modified:
  stable/12/sys/powerpc/conf/GENERIC64
Directory Properties:
  stable/12/   (props changed)

Modified: stable/12/sys/powerpc/conf/GENERIC64
==
--- stable/12/sys/powerpc/conf/GENERIC64Tue Dec 11 20:47:00 2018
(r341829)
+++ stable/12/sys/powerpc/conf/GENERIC64Tue Dec 11 20:56:05 2018
(r341830)
@@ -227,3 +227,7 @@ device  sound   # Generic sound driver 
(required)
 device snd_ai2s# Apple I2S audio
 device snd_uaudio  # USB Audio
 
+# evdev interface
+optionsEVDEV_SUPPORT   # evdev support in legacy drivers
+device evdev   # input event device support
+device uinput  # install /dev/uinput cdev
___
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: r341829 - head/usr.sbin/bhyve

2018-12-11 Thread Alexander Motin 
Author: mav
Date: Tue Dec 11 20:47:00 2018
New Revision: 341829
URL: https://svnweb.freebsd.org/changeset/base/341829

Log:
  Allow CTL device specification in bhyve virtio-scsi.
  
  There was a large refactoring done in CTL to allow multiple ioctl frontend
  ports (and respective devices) to be created, particularly for bhyve.
  Unfortunately, respective part of bhyve functionality got lost somehow from
  the original virtio-scsi commit.  This change allows wanted device path to
  be specified in either of two ways:
   -s 6,virtio-scsi,/dev/cam/ctl1.1
   -s 6,virtio-scsi,dev=/dev/cam/ctl2.3
  If neither is specified, the default /dev/cam/ctl device is used.
  
  While there, remove per-queue CTL device opening, which makes no sense at
  this point.
  
  Reported by:  wg
  Reviewed by:  araujo
  MFC after:3 days
  Sponsored by: iXsystems, Inc.
  Differential Revision:https://reviews.freebsd.org/D18504

Modified:
  head/usr.sbin/bhyve/bhyve.8
  head/usr.sbin/bhyve/pci_virtio_scsi.c

Modified: head/usr.sbin/bhyve/bhyve.8
==
--- head/usr.sbin/bhyve/bhyve.8 Tue Dec 11 19:34:25 2018(r341828)
+++ head/usr.sbin/bhyve/bhyve.8 Tue Dec 11 20:47:00 2018(r341829)
@@ -24,7 +24,7 @@
 .\"
 .\" $FreeBSD$
 .\"
-.Dd October 24, 2018
+.Dd December 11, 2018
 .Dt BHYVE 8
 .Os
 .Sh NAME
@@ -298,7 +298,16 @@ if not explicitly specified.
 .Pp
 SCSI devices:
 .Bl -tag -width 10n
-.It Pa /dev/cam/ Ns Oo , Ns Ar port and initiator_id Oc
+.It Pa /dev/cam/ctl Ns Oo Ar pp . Ns Ar vp Oc Ns Oo , Ns Ar 
scsi-device-options Oc
+.El
+.Pp
+The
+.Ar scsi-device-options
+are:
+.Bl -tag -width 10n
+.It Li iid= Ns Ar IID
+Initiator ID to use when sending requests to specified CTL port.
+The default value is 0.
 .El
 .Pp
 TTY devices:

Modified: head/usr.sbin/bhyve/pci_virtio_scsi.c
==
--- head/usr.sbin/bhyve/pci_virtio_scsi.c   Tue Dec 11 19:34:25 2018
(r341828)
+++ head/usr.sbin/bhyve/pci_virtio_scsi.c   Tue Dec 11 20:47:00 2018
(r341829)
@@ -105,7 +105,6 @@ struct pci_vtscsi_config {
 struct pci_vtscsi_queue {
struct pci_vtscsi_softc * vsq_sc;
struct vqueue_info *  vsq_vq;
-   int   vsq_ctl_fd;
pthread_mutex_t   vsq_mtx;
pthread_mutex_t   vsq_qmtx;
pthread_cond_tvsq_cv;
@@ -529,7 +528,7 @@ pci_vtscsi_request_handle(struct pci_vtscsi_queue *q, 
sbuf_delete(sb);
}
 
-   err = ioctl(q->vsq_ctl_fd, CTL_IO, io);
+   err = ioctl(sc->vss_ctl_fd, CTL_IO, io);
if (err != 0) {
WPRINTF(("CTL_IO: err=%d (%s)\n", errno, strerror(errno)));
cmd_wr->response = VIRTIO_SCSI_S_FAILURE;
@@ -639,14 +638,8 @@ pci_vtscsi_init_queue(struct pci_vtscsi_softc *sc, 
int i;
 
queue->vsq_sc = sc;
-   queue->vsq_ctl_fd = open("/dev/cam/ctl", O_RDWR);
queue->vsq_vq = >vss_vq[num + 2];
 
-   if (queue->vsq_ctl_fd < 0) {
-   WPRINTF(("cannot open /dev/cam/ctl: %s\n", strerror(errno)));
-   return (-1);
-   }
-
pthread_mutex_init(>vsq_mtx, NULL);
pthread_mutex_init(>vsq_qmtx, NULL);
pthread_cond_init(>vsq_cv, NULL);
@@ -672,24 +665,34 @@ static int
 pci_vtscsi_init(struct vmctx *ctx, struct pci_devinst *pi, char *opts)
 {
struct pci_vtscsi_softc *sc;
-   char *optname = NULL;
-   char *opt;
-   int i;
+   char *opt, *optname;
+   const char *devname;
+   int i, optidx = 0;
 
sc = calloc(1, sizeof(struct pci_vtscsi_softc));
-   sc->vss_ctl_fd = open("/dev/cam/ctl", O_RDWR);
+   devname = "/dev/cam/ctl";
+   while ((opt = strsep(, ",")) != NULL) {
+   optname = strsep(, "=");
+   if (opt == NULL && optidx == 0) {
+   if (optname[0] != 0)
+   devname = optname;
+   } else if (strcmp(optname, "dev") == 0 && opt != NULL) {
+   devname = opt;
+   } else if (strcmp(optname, "iid") == 0 && opt != NULL) {
+   sc->vss_iid = strtoul(opt, NULL, 10);
+   } else {
+   fprintf(stderr, "Invalid option %s\n", optname);
+   free(sc);
+   return (1);
+   }
+   optidx++;
+   }
 
+   sc->vss_ctl_fd = open(devname, O_RDWR);
if (sc->vss_ctl_fd < 0) {
-   WPRINTF(("cannot open /dev/cam/ctl: %s\n", strerror(errno)));
+   WPRINTF(("cannot open %s: %s\n", devname, strerror(errno)));
+   free(sc);
return (1);
-   }
-
-   while ((opt = strsep(, ",")) != NULL) {
-   if ((optname = strsep(, "=")) != NULL) {
-   if

Re: svn commit: r341803 - head/libexec/rc

2018-12-11 Thread Devin Teske 


> On Dec 11, 2018, at 11:57 AM, Conrad Meyer  wrote:
> 
> On Tue, Dec 11, 2018 at 10:04 AM Warner Losh  wrote:
>> On Tue, Dec 11, 2018, 9:55 AM John Baldwin >> 
>>> The 'read' builtin in sh can't use buffering, so it is always going to be 
>>> slow
>> 
>> It can't use it because of pipes. The example from the parts of this that 
>> was on IRC was basically:
>> 
>> foo | (read bar; baz)
>> 
>> Which reads one line into the bar variable and then sends the rest to the 
>> bar command.
> 
> It can't trivially, but it's not impossible.  sh could play games and
> buffer its own use of stdin, and then open a fresh pipe for stdin of
> subsequent non-builtins, writing out unused portions of the buffer.[A]
> 
> Some other alternatives that would require kernel support but are
> things we've talked about doing in the kernel before anyway:
> 
> * If we had something like eBPF programs attached to IO, maybe sh's
> read built-in could push a small eBPF program into the kernel that
> determined how many bytes could be read from the pipe in a single
> syscall without reading too far.  It's fairly trivial.  Simply
> returning a number of bytes up to and including the first '\n' would
> be a fine, if sometimes conservative amount.  (Input lines can be
> continued with a trailing backslash, except in -r mode, but as a
> first-cut approximation, reading-until-newline is probably good
> enough.)[B]
> 
> * Heck, even just a read_until_newline(2) syscall would work and
> probably be more broadly useful than just sh(1).  I don't think it
> passes the sniff test — not general enough, and probably not something
> you want beginners stumbling across instead of fgets(3) — but it'd be
> fine, and there are other pipe-abusing programs that care about
> reading ASCII text lines without overconsuming input than just
> sh(1).[C]
> 
> * If we had something like Linux's tee(2) system call (which is as it
> sounds — tee(1) for pipes), sh(1)'s read built-in could tee(2) for
> buffering without impacting stdin, and read(2) stdin only when it knew
> how many bytes were consumed (or when the pipe buffer became full).[D]
> 
> I suspect (C) would be the easiest to implement correctly, followed by
> (D).  (B) is requires some architectural design and bikeshedding and
> the details on the kernel side are tricky.  (A) would be a little
> tricky and probably require extensive changes to sh(1) itself, which
> is a risk to the base system.  But it would not impact the kernel.
> 
> Is there any interest in a tee(2)-like syscall?
> 

Linux has vmsplice(2). I know jmg@ also expressed interest in having a
vmsplice in FreeBSD.

As for sh not being able to read more than a single byte at a time because
it could be reading from a pipe, what if it read into a buffer and returned
a line from the buffer. A subsequent read would return more data from the
buffer, ad nauseam until the buffer runs out -- in which case another chunk
is read to augment the data.

This buffer could be expunged when stdin collapses (e.g., when the sub-
shell completes.
-- 
Devin
___
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: r341803 - head/libexec/rc

2018-12-11 Thread Conrad Meyer 
On Tue, Dec 11, 2018 at 10:04 AM Warner Losh  wrote:
> On Tue, Dec 11, 2018, 9:55 AM John Baldwin >
>> The 'read' builtin in sh can't use buffering, so it is always going to be 
>> slow
>
> It can't use it because of pipes. The example from the parts of this that was 
> on IRC was basically:
>
> foo | (read bar; baz)
>
> Which reads one line into the bar variable and then sends the rest to the bar 
> command.

It can't trivially, but it's not impossible.  sh could play games and
buffer its own use of stdin, and then open a fresh pipe for stdin of
subsequent non-builtins, writing out unused portions of the buffer.[A]

Some other alternatives that would require kernel support but are
things we've talked about doing in the kernel before anyway:

* If we had something like eBPF programs attached to IO, maybe sh's
read built-in could push a small eBPF program into the kernel that
determined how many bytes could be read from the pipe in a single
syscall without reading too far.  It's fairly trivial.  Simply
returning a number of bytes up to and including the first '\n' would
be a fine, if sometimes conservative amount.  (Input lines can be
continued with a trailing backslash, except in -r mode, but as a
first-cut approximation, reading-until-newline is probably good
enough.)[B]

* Heck, even just a read_until_newline(2) syscall would work and
probably be more broadly useful than just sh(1).  I don't think it
passes the sniff test — not general enough, and probably not something
you want beginners stumbling across instead of fgets(3) — but it'd be
fine, and there are other pipe-abusing programs that care about
reading ASCII text lines without overconsuming input than just
sh(1).[C]

* If we had something like Linux's tee(2) system call (which is as it
sounds — tee(1) for pipes), sh(1)'s read built-in could tee(2) for
buffering without impacting stdin, and read(2) stdin only when it knew
how many bytes were consumed (or when the pipe buffer became full).[D]

I suspect (C) would be the easiest to implement correctly, followed by
(D).  (B) is requires some architectural design and bikeshedding and
the details on the kernel side are tricky.  (A) would be a little
tricky and probably require extensive changes to sh(1) itself, which
is a risk to the base system.  But it would not impact the kernel.

Is there any interest in a tee(2)-like syscall?

Thanks,
Conrad
___
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: r341803 - head/libexec/rc

2018-12-11 Thread Conrad Meyer 
On Tue, Dec 11, 2018 at 9:24 AM John Baldwin  wrote:
> list_vars is rarely used outside of
> 'netif', so it probably doesn't make a measurable difference on bare metal.

To clarify: It likely doesn't make a measurable difference *to boot
times* on bare metal, but even on amd64 bare metal the time of
list_vars itself is readily measurable; the 71% reduction quoted in
the commit log was measured on amd64.

Best,
Conrad
___
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: r341828 - stable/11/sys/cddl/contrib/opensolaris/uts/common/fs/zfs

2018-12-11 Thread Allan Jude 
Author: allanjude
Date: Tue Dec 11 19:34:25 2018
New Revision: 341828
URL: https://svnweb.freebsd.org/changeset/base/341828

Log:
  MFC: r339289: Resolve a hang in ZFS during vnode reclaimation
  
This is caused by a deadlock between zil_commit() and zfs_zget()
Add a way for zfs_zget() to break out of the retry loop in the common case
  
  PR:   229614, 231117
  Reported by:  grembo, jhb, Andreas Sommer, others
  Relnotes: yes
  Sponsored by: Klara Systems

Modified:
  stable/11/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_znode.c
Directory Properties:
  stable/11/   (props changed)

Modified: stable/11/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_znode.c
==
--- stable/11/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_znode.c
Tue Dec 11 19:32:16 2018(r341827)
+++ stable/11/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_znode.c
Tue Dec 11 19:34:25 2018(r341828)
@@ -1155,15 +1155,27 @@ again:
 */
ASSERT3P(zp, !=, NULL);
ASSERT3U(zp->z_id, ==, obj_num);
-   *zpp = zp;
-   vp = ZTOV(zp);
+   if (zp->z_unlinked) {
+   err = SET_ERROR(ENOENT);
+   } else {
+   vp = ZTOV(zp);
+   /*
+* Don't let the vnode disappear after
+* ZFS_OBJ_HOLD_EXIT.
+*/
+   VN_HOLD(vp);
+   *zpp = zp;
+   err = 0;
+   }
 
-   /* Don't let the vnode disappear after ZFS_OBJ_HOLD_EXIT. */
-   VN_HOLD(vp);
-
sa_buf_rele(db, NULL);
ZFS_OBJ_HOLD_EXIT(zfsvfs, obj_num);
 
+   if (err) {
+   getnewvnode_drop_reserve();
+   return (err);
+   }
+
locked = VOP_ISLOCKED(vp);
VI_LOCK(vp);
if ((vp->v_iflag & VI_DOOMED) != 0 &&
@@ -1196,7 +1208,7 @@ again:
}
VI_UNLOCK(vp);
getnewvnode_drop_reserve();
-   return (0);
+   return (err);
}
 
/*
___
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: r341827 - in head/sys: cddl/compat/opensolaris/kern cddl/contrib/opensolaris/uts/common/fs/zfs compat/linux dev/filemon fs/ext2fs fs/fuse fs/msdosfs fs/nandfs fs/nfs fs/nfsserver fs/tmp...

2018-12-11 Thread Mateusz Guzik 
Author: mjg
Date: Tue Dec 11 19:32:16 2018
New Revision: 341827
URL: https://svnweb.freebsd.org/changeset/base/341827

Log:
  Remove unused argument to priv_check_cred.
  
  Patch mostly generated with cocinnelle:
  
  @@
  expression E1,E2;
  @@
  
  - priv_check_cred(E1,E2,0)
  + priv_check_cred(E1,E2)
  
  Sponsored by: The FreeBSD Foundation

Modified:
  head/sys/cddl/compat/opensolaris/kern/opensolaris_policy.c
  head/sys/cddl/compat/opensolaris/kern/opensolaris_zone.c
  head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c
  head/sys/compat/linux/linux_misc.c
  head/sys/compat/linux/linux_uid16.c
  head/sys/dev/filemon/filemon_wrapper.c
  head/sys/fs/ext2fs/ext2_vnops.c
  head/sys/fs/fuse/fuse_internal.c
  head/sys/fs/fuse/fuse_vnops.c
  head/sys/fs/msdosfs/msdosfs_vnops.c
  head/sys/fs/nandfs/nandfs_vnops.c
  head/sys/fs/nfs/nfs_commonsubs.c
  head/sys/fs/nfsserver/nfs_nfsdport.c
  head/sys/fs/tmpfs/tmpfs_subr.c
  head/sys/fs/tmpfs/tmpfs_vnops.c
  head/sys/kern/kern_exec.c
  head/sys/kern/kern_fork.c
  head/sys/kern/kern_priv.c
  head/sys/kern/kern_prot.c
  head/sys/kern/subr_acl_nfs4.c
  head/sys/kern/subr_acl_posix1e.c
  head/sys/kern/uipc_mqueue.c
  head/sys/kern/uipc_sem.c
  head/sys/kern/uipc_shm.c
  head/sys/kern/vfs_mount.c
  head/sys/kern/vfs_subr.c
  head/sys/kern/vfs_syscalls.c
  head/sys/net/if_tap.c
  head/sys/net/if_tun.c
  head/sys/netinet/in_pcb.c
  head/sys/netinet6/in6_pcb.c
  head/sys/netinet6/ip6_output.c
  head/sys/netipsec/ipsec_pcb.c
  head/sys/netsmb/smb_subr.h
  head/sys/security/audit/audit_syscalls.c
  head/sys/security/mac/mac_net.c
  head/sys/security/mac_bsdextended/mac_bsdextended.c
  head/sys/security/mac_lomac/mac_lomac.c
  head/sys/security/mac_partition/mac_partition.c
  head/sys/security/mac_portacl/mac_portacl.c
  head/sys/security/mac_seeotheruids/mac_seeotheruids.c
  head/sys/sys/priv.h
  head/sys/ufs/ffs/ffs_alloc.c
  head/sys/ufs/ffs/ffs_softdep.c
  head/sys/ufs/ffs/ffs_vnops.c
  head/sys/ufs/ufs/ufs_quota.c
  head/sys/ufs/ufs/ufs_vnops.c
  head/sys/vm/vm_mmap.c

Modified: head/sys/cddl/compat/opensolaris/kern/opensolaris_policy.c
==
--- head/sys/cddl/compat/opensolaris/kern/opensolaris_policy.c  Tue Dec 11 
19:12:44 2018(r341826)
+++ head/sys/cddl/compat/opensolaris/kern/opensolaris_policy.c  Tue Dec 11 
19:32:16 2018(r341827)
@@ -41,35 +41,35 @@ int
 secpolicy_nfs(cred_t *cr)
 {
 
-   return (priv_check_cred(cr, PRIV_NFS_DAEMON, 0));
+   return (priv_check_cred(cr, PRIV_NFS_DAEMON));
 }
 
 int
 secpolicy_zfs(cred_t *cr)
 {
 
-   return (priv_check_cred(cr, PRIV_VFS_MOUNT, 0));
+   return (priv_check_cred(cr, PRIV_VFS_MOUNT));
 }
 
 int
 secpolicy_sys_config(cred_t *cr, int checkonly __unused)
 {
 
-   return (priv_check_cred(cr, PRIV_ZFS_POOL_CONFIG, 0));
+   return (priv_check_cred(cr, PRIV_ZFS_POOL_CONFIG));
 }
 
 int
 secpolicy_zinject(cred_t *cr)
 {
 
-   return (priv_check_cred(cr, PRIV_ZFS_INJECT, 0));
+   return (priv_check_cred(cr, PRIV_ZFS_INJECT));
 }
 
 int
 secpolicy_fs_unmount(cred_t *cr, struct mount *vfsp __unused)
 {
 
-   return (priv_check_cred(cr, PRIV_VFS_UNMOUNT, 0));
+   return (priv_check_cred(cr, PRIV_VFS_UNMOUNT));
 }
 
 int
@@ -97,7 +97,7 @@ secpolicy_basic_link(vnode_t *vp, cred_t *cr)
return (0);
if (secpolicy_fs_owner(vp->v_mount, cr) == 0)
return (0);
-   return (priv_check_cred(cr, PRIV_VFS_LINK, 0));
+   return (priv_check_cred(cr, PRIV_VFS_LINK));
 }
 
 int
@@ -113,7 +113,7 @@ secpolicy_vnode_remove(vnode_t *vp, cred_t *cr)
 
if (secpolicy_fs_owner(vp->v_mount, cr) == 0)
return (0);
-   return (priv_check_cred(cr, PRIV_VFS_ADMIN, 0));
+   return (priv_check_cred(cr, PRIV_VFS_ADMIN));
 }
 
 int
@@ -123,18 +123,18 @@ secpolicy_vnode_access(cred_t *cr, vnode_t *vp, uid_t 
if (secpolicy_fs_owner(vp->v_mount, cr) == 0)
return (0);
 
-   if ((accmode & VREAD) && priv_check_cred(cr, PRIV_VFS_READ, 0) != 0)
+   if ((accmode & VREAD) && priv_check_cred(cr, PRIV_VFS_READ) != 0)
return (EACCES);
if ((accmode & VWRITE) &&
-   priv_check_cred(cr, PRIV_VFS_WRITE, 0) != 0) {
+   priv_check_cred(cr, PRIV_VFS_WRITE) != 0) {
return (EACCES);
}
if (accmode & VEXEC) {
if (vp->v_type == VDIR) {
-   if (priv_check_cred(cr, PRIV_VFS_LOOKUP, 0) != 0)
+   if (priv_check_cred(cr, PRIV_VFS_LOOKUP) != 0)
return (EACCES);
} else {
-   if (priv_check_cred(cr, PRIV_VFS_EXEC, 0) != 0)
+   if (priv_check_cred(cr, PRIV_VFS_EXEC) != 0)
return (EACCES);
}
}
@@ -192,7 +192,7 @@ secpolicy_vnode_any_access(cred_t *cr, vnode_t *vp, ui

svn commit: r341826 - stable/12/sys/conf

2018-12-11 Thread Glen Barber 
Author: gjb
Date: Tue Dec 11 19:12:44 2018
New Revision: 341826
URL: https://svnweb.freebsd.org/changeset/base/341826

Log:
  Call stable/12 -STABLE now that 12.0-RELEASE is out.
  
  Sponsored by: The FreeBSD Foundation

Modified:
  stable/12/sys/conf/newvers.sh

Modified: stable/12/sys/conf/newvers.sh
==
--- stable/12/sys/conf/newvers.sh   Tue Dec 11 19:05:28 2018
(r341825)
+++ stable/12/sys/conf/newvers.sh   Tue Dec 11 19:12:44 2018
(r341826)
@@ -46,7 +46,7 @@
 
 TYPE="FreeBSD"
 REVISION="12.0"
-BRANCH="PRERELEASE"
+BRANCH="STABLE"
 if [ -n "${BRANCH_OVERRIDE}" ]; then
BRANCH=${BRANCH_OVERRIDE}
 fi
___
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: r341803 - head/libexec/rc

2018-12-11 Thread Warner Losh 
On Tue, Dec 11, 2018, 9:55 AM John Baldwin  The 'read' builtin in sh can't use buffering, so it is always going to be
> slow
>

It can't use it because of pipes. The example from the parts of this that
was on IRC was basically:

foo | (read bar; baz)

Which reads one line into the bar variable and then sends the rest to the
bar command.

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: r341803 - head/libexec/rc

2018-12-11 Thread John Baldwin 
On 12/11/18 9:40 AM, Devin Teske wrote:
> 
> 
>> On Dec 11, 2018, at 9:23 AM, John Baldwin > > wrote:
>>
>> On 12/10/18 5:38 PM, Conrad Meyer wrote:
>>> Author: cem
>>> Date: Tue Dec 11 01:38:50 2018
>>> New Revision: 341803
>>> URL: https://svnweb.freebsd.org/changeset/base/341803
>>>
>>> Log:
>>>  rc.subr: Implement list_vars without using 'read'
>>>
>>>  'read' pessimistically read(2)s one byte at a time, which can be quite
>>>  silly for large environments in slow emulators.
>>>
>>>  In my boring user environment, truss shows that the number of read()
>>>  syscalls to source rc.subr and invoke list_vars is reduced by something 
>>> like
>>>  3400 to 60.  ministat(1) shows a significant time difference of about -71%
>>>  for my environment.
>>>
>>>  Suggested by:jilles
>>>  Discussed with:dteske, jhb, jilles
>>>  Differential Revision:https://reviews.freebsd.org/D18481
>>
>> For some background, one my colleagues reported that it was taking hours in
>> (an admittedly slow) CPU simulator to get through '/etc/rc.d/netif start'.
>> I ended up running that script under truss in a RISC-V qemu machine.  The
>> entire run took 212 seconds (truss did slow it down quite a bit).  Of that
>> 212 seconds, the read side of each list_vars invocation took ~25.5 seconds,
>> and with lo0 and vtnet0 there were 8 list_vars invocations, so 204 out of
>> the 212 seconds were spent in the single-byte read() syscalls in 'while 
>> read'.
>>
>> Even on qemu without truss during bootup 'netif start' took a couple of
>> seconds (long enough to get 2-3 Ctrl-T's in) before this change and is now
>> similar to bare metal with the change.  list_vars is rarely used outside of
>> 'netif', so it probably doesn't make a measurable difference on bare metal.
>>
> 
> Thank you for the background which was lost by the time I got to the phab.
> 
> I can't help but ask though,...
> 
> If it was noticed that read(2) processes the stream one byte at a time,
> why not just optimize read(2)?
> 
> I'm afraid of the prospect of having to hunt down every instance of 
> while-read,
> but if we can fix the underlying read(2) inefficiency then we make while-read 
> OK.

It's a system call.  A CPU emulator has to do a lot of work for a system call
because it involves two mode switches (user -> kernel and back again).  You
can't "fix" that as it's just a part of the CPU architecture.  There's a reason
that stdio uses buffering by default, it's because system calls have overhead.
The 'read' builtin in sh can't use buffering, so it is always going to be
inefficient.

-- 
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"

svn commit: r341824 - head/sys/net

2018-12-11 Thread Stephen Hurd 
Author: shurd
Date: Tue Dec 11 17:46:01 2018
New Revision: 341824
URL: https://svnweb.freebsd.org/changeset/base/341824

Log:
  Fix !tx_abdicate error from r336560
  
  r336560 was supposed to restore pre-r323954 behaviour when tx_abdicate is
  not set (the default case). However, it appears that rather than the drainage
  check being made conditional on tx_abdicate being set, it was duplicated
  so it occured twice if tx_abdicate was set and once if it was not.
  
  Now when !tx_abdicate, drainage is only checked if the doorbell isn't
  pending.
  
  Reported by:lev
  MFC after:  1 week
  Sponsored by:   Limelight Networks

Modified:
  head/sys/net/iflib.c

Modified: head/sys/net/iflib.c
==
--- head/sys/net/iflib.cTue Dec 11 17:39:49 2018(r341823)
+++ head/sys/net/iflib.cTue Dec 11 17:46:01 2018(r341824)
@@ -3582,7 +3582,6 @@ _task_fn_tx(void *context)
 */
if (abdicate)
ifmp_ring_check_drainage(txq->ift_br, TX_BATCH_SIZE);
-   ifmp_ring_check_drainage(txq->ift_br, TX_BATCH_SIZE);
if (ctx->ifc_flags & IFC_LEGACY)
IFDI_INTR_ENABLE(ctx);
else {
___
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: r341803 - head/libexec/rc

2018-12-11 Thread Devin Teske 



> On Dec 11, 2018, at 9:23 AM, John Baldwin  wrote:
> 
> On 12/10/18 5:38 PM, Conrad Meyer wrote:
>> Author: cem
>> Date: Tue Dec 11 01:38:50 2018
>> New Revision: 341803
>> URL: https://svnweb.freebsd.org/changeset/base/341803
>> 
>> Log:
>>  rc.subr: Implement list_vars without using 'read'
>> 
>>  'read' pessimistically read(2)s one byte at a time, which can be quite
>>  silly for large environments in slow emulators.
>> 
>>  In my boring user environment, truss shows that the number of read()
>>  syscalls to source rc.subr and invoke list_vars is reduced by something like
>>  3400 to 60.  ministat(1) shows a significant time difference of about -71%
>>  for my environment.
>> 
>>  Suggested by:   jilles
>>  Discussed with: dteske, jhb, jilles
>>  Differential Revision:  https://reviews.freebsd.org/D18481
> 
> For some background, one my colleagues reported that it was taking hours in
> (an admittedly slow) CPU simulator to get through '/etc/rc.d/netif start'.
> I ended up running that script under truss in a RISC-V qemu machine.  The
> entire run took 212 seconds (truss did slow it down quite a bit).  Of that
> 212 seconds, the read side of each list_vars invocation took ~25.5 seconds,
> and with lo0 and vtnet0 there were 8 list_vars invocations, so 204 out of
> the 212 seconds were spent in the single-byte read() syscalls in 'while read'.
> 
> Even on qemu without truss during bootup 'netif start' took a couple of
> seconds (long enough to get 2-3 Ctrl-T's in) before this change and is now
> similar to bare metal with the change.  list_vars is rarely used outside of
> 'netif', so it probably doesn't make a measurable difference on bare metal.
> 

Thank you for the background which was lost by the time I got to the phab.

I can't help but ask though,...

If it was noticed that read(2) processes the stream one byte at a time,
why not just optimize read(2)?

I'm afraid of the prospect of having to hunt down every instance of while-read,
but if we can fix the underlying read(2) inefficiency then we make while-read 
OK.
-- 
Devin
___
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: r341803 - head/libexec/rc

2018-12-11 Thread John Baldwin 
On 12/10/18 5:38 PM, Conrad Meyer wrote:
> Author: cem
> Date: Tue Dec 11 01:38:50 2018
> New Revision: 341803
> URL: https://svnweb.freebsd.org/changeset/base/341803
> 
> Log:
>   rc.subr: Implement list_vars without using 'read'
>   
>   'read' pessimistically read(2)s one byte at a time, which can be quite
>   silly for large environments in slow emulators.
>   
>   In my boring user environment, truss shows that the number of read()
>   syscalls to source rc.subr and invoke list_vars is reduced by something like
>   3400 to 60.  ministat(1) shows a significant time difference of about -71%
>   for my environment.
>   
>   Suggested by:   jilles
>   Discussed with: dteske, jhb, jilles
>   Differential Revision:  https://reviews.freebsd.org/D18481

For some background, one my colleagues reported that it was taking hours in
(an admittedly slow) CPU simulator to get through '/etc/rc.d/netif start'.
I ended up running that script under truss in a RISC-V qemu machine.  The
entire run took 212 seconds (truss did slow it down quite a bit).  Of that
212 seconds, the read side of each list_vars invocation took ~25.5 seconds,
and with lo0 and vtnet0 there were 8 list_vars invocations, so 204 out of
the 212 seconds were spent in the single-byte read() syscalls in 'while read'.

Even on qemu without truss during bootup 'netif start' took a couple of
seconds (long enough to get 2-3 Ctrl-T's in) before this change and is now
similar to bare metal with the change.  list_vars is rarely used outside of
'netif', so it probably doesn't make a measurable difference on bare metal.

-- 
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"

svn commit: r341822 - head/sys/security/audit

2018-12-11 Thread Mateusz Guzik 
Author: mjg
Date: Tue Dec 11 17:14:12 2018
New Revision: 341822
URL: https://svnweb.freebsd.org/changeset/base/341822

Log:
  audi: replace open-coded TDP_AUDITREC checks with the macro
  
  Sponsored by: The FreeBSD Foundation

Modified:
  head/sys/security/audit/audit.h

Modified: head/sys/security/audit/audit.h
==
--- head/sys/security/audit/audit.h Tue Dec 11 16:49:01 2018
(r341821)
+++ head/sys/security/audit/audit.h Tue Dec 11 17:14:12 2018
(r341822)
@@ -389,7 +389,7 @@ void audit_thread_free(struct thread *td);
  * auditing is disabled, so we don't just check audit_syscalls_enabled here.
  */
 #defineAUDIT_SYSCALL_EXIT(error, td)   do {
\
-   if (td->td_pflags & TDP_AUDITREC)   \
+   if (AUDITING_TD(td))\
audit_syscall_exit(error, td);  \
 } while (0)
 
@@ -397,7 +397,7 @@ void audit_thread_free(struct thread *td);
  * A Macro to wrap the audit_sysclose() function.
  */
 #defineAUDIT_SYSCLOSE(td, fd)  do {
\
-   if (td->td_pflags & TDP_AUDITREC)   \
+   if (AUDITING_TD(td))\
audit_sysclose(td, fd); \
 } 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: r341821 - head/sys/x86/x86

2018-12-11 Thread Mark Johnston 
Author: markj
Date: Tue Dec 11 16:49:01 2018
New Revision: 341821
URL: https://svnweb.freebsd.org/changeset/base/341821

Log:
  Fix the PAE kernel gcc build.
  
  The error was caused by map_ucode() casting a vm_paddr_t to a void *.
  Use a uintptr_t instead to match the caller.  Fix some style bugs while
  here.
  
  Reported by:  bde
  Reviewed by:  bde
  MFC after:1 week
  Sponsored by: The FreeBSD Foundation

Modified:
  head/sys/x86/x86/ucode.c

Modified: head/sys/x86/x86/ucode.c
==
--- head/sys/x86/x86/ucode.cTue Dec 11 16:35:59 2018(r341820)
+++ head/sys/x86/x86/ucode.cTue Dec 11 16:49:01 2018(r341821)
@@ -278,12 +278,13 @@ ucode_load_ap(int cpu)
 }
 
 static void *
-map_ucode(vm_paddr_t free, size_t len)
+map_ucode(uintptr_t free, size_t len)
 {
-
 #ifdef __i386__
-   for (vm_paddr_t pa = free; pa < free + len; pa += PAGE_SIZE)
-   pmap_kenter(pa, pa);
+   uintptr_t va;
+
+   for (va = free; va < free + len; va += PAGE_SIZE)
+   pmap_kenter(va, (vm_paddr_t)va);
 #else
(void)len;
 #endif
@@ -291,12 +292,13 @@ map_ucode(vm_paddr_t free, size_t len)
 }
 
 static void
-unmap_ucode(vm_paddr_t free, size_t len)
+unmap_ucode(uintptr_t free, size_t len)
 {
-
 #ifdef __i386__
-   for (vm_paddr_t pa = free; pa < free + len; pa += PAGE_SIZE)
-   pmap_kremove((vm_offset_t)pa);
+   uintptr_t va;
+
+   for (va = free; va < free + len; va += PAGE_SIZE)
+   pmap_kremove(va);
 #else
(void)free;
(void)len;
___
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: r341820 - head/sys/dev/asmc

2018-12-11 Thread David Bright 
Author: dab
Date: Tue Dec 11 16:35:59 2018
New Revision: 341820
URL: https://svnweb.freebsd.org/changeset/base/341820

Log:
  asmc: Add Support for MacBookAir 7,1 and 7,2
  
  PR:   226172
  Submitted by: James Wright 
  Reported by:  James Wright 
  MFC after:1 week
  Differential Revision:https://reviews.freebsd.org/D18396

Modified:
  head/sys/dev/asmc/asmc.c
  head/sys/dev/asmc/asmcvar.h

Modified: head/sys/dev/asmc/asmc.c
==
--- head/sys/dev/asmc/asmc.cTue Dec 11 12:08:18 2018(r341819)
+++ head/sys/dev/asmc/asmc.cTue Dec 11 16:35:59 2018(r341820)
@@ -300,6 +300,21 @@ struct asmc_model asmc_models[] = {
  ASMC_MBA5_TEMPS, ASMC_MBA5_TEMPNAMES, ASMC_MBA5_TEMPDESCS
},
 
+   {
+ "MacBookAir7,1", "Apple SMC MacBook Air 11-inch (Early 2015)",
+ ASMC_SMS_FUNCS_DISABLED,
+ ASMC_FAN_FUNCS2,
+ ASMC_LIGHT_FUNCS,
+ ASMC_MBA7_TEMPS, ASMC_MBA7_TEMPNAMES, ASMC_MBA7_TEMPDESCS
+   },
+
+   {
+ "MacBookAir7,2", "Apple SMC MacBook Air 13-inch (Early 2015)",
+ ASMC_SMS_FUNCS_DISABLED,
+ ASMC_FAN_FUNCS2,
+ ASMC_LIGHT_FUNCS,
+ ASMC_MBA7_TEMPS, ASMC_MBA7_TEMPNAMES, ASMC_MBA7_TEMPDESCS
+   },
 
{ NULL, NULL }
 };

Modified: head/sys/dev/asmc/asmcvar.h
==
--- head/sys/dev/asmc/asmcvar.h Tue Dec 11 12:08:18 2018(r341819)
+++ head/sys/dev/asmc/asmcvar.h Tue Dec 11 16:35:59 2018(r341820)
@@ -428,3 +428,27 @@ struct asmc_softc {
  "TCXC", "THSP", "Memory Bank A", "PCH Die", \
  "Ta0P", "Heatpipe", "Mainboard Proximity 1", 
"Mainboard Proximity 2", \
  "Palm Rest", "Memory Proximity" }
+
+#defineASMC_MBA7_TEMPS { "TB0T", "TB1T", "TB2T", \
+ "TC0E", "TC0F", "TC0P", \
+ "TC1C", "TC2C", \
+ "TCGC", "TCSA", "TCXC", \
+ "THSP", "TM0P", "TPCD", \
+ "TW0P" "Ta0P", "Th1H", \
+ "Tm0P", "Ts0P", "Ts0S", NULL }
+
+#defineASMC_MBA7_TEMPNAMES { "enclosure1", "enclosure2", 
"enclosure3", \
+ "cputemp1", "cputemp2", "cpuproximity", \
+ "cpucore1", "cpucore2", \
+ "pecigpu", "pecisa", "pecicpu", \
+ "thunderboltproximity", "memorybank", 
"pchdie", \
+ "wirelessproximity", "airflowproximity", 
"heatpipe", \
+ "mainboardproximity", "palmrest", 
"memoryproximity" }
+
+#defineASMC_MBA7_TEMPDESCS { "Enclosure Bottom 1", "Enclosure 
Bottom 2", "Enclosure Bottom 3", \
+ "CPU Temp 1", "CPU Temp 2", "CPU Proximity", \
+ "CPU Core 1", "CPU Core 2", \
+ "PECI GPU", "PECI SA", "PECI CPU", \
+ "Thunderbolt Proximity", "Memory Bank A", 
"PCH Die", \
+ "Wireless Proximity", "Airflow Proxmity", 
"Heatpipe", \
+ "Mainboard Proximity", "Palm Rest", "Memory 
Proximity" }
___
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: r341682 - head/sys/sys

2018-12-11 Thread Poul-Henning Kamp 

In message 
, Warner Losh writes:

>We haven't ever supported SMP on i486, to my knowledge.

There were never any usable i486 SMP hardware.

The i486 CPU was not designed to do SMP so getting two CPUs to talk
together (IPIs and all that) required a lot of glue-logic, which
never got chip-ified.

A few prototypes were built, but nothing ever reached production,
least of all HP's 1000xi486 chip "mainfram" project.

-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
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: r341819 - head/sys/kern

2018-12-11 Thread Mateusz Guzik 
Author: mjg
Date: Tue Dec 11 12:08:18 2018
New Revision: 341819
URL: https://svnweb.freebsd.org/changeset/base/341819

Log:
  fd: dedup code in sys_getdtablesize
  
  Sponsored by: The FreeBSD Foundation

Modified:
  head/sys/kern/kern_descrip.c

Modified: head/sys/kern/kern_descrip.c
==
--- head/sys/kern/kern_descrip.cTue Dec 11 12:01:46 2018
(r341818)
+++ head/sys/kern/kern_descrip.cTue Dec 11 12:08:18 2018
(r341819)
@@ -348,8 +348,7 @@ sys_getdtablesize(struct thread *td, struct getdtables
uint64_t lim;
 #endif
 
-   td->td_retval[0] =
-   min((int)lim_cur(td, RLIMIT_NOFILE), maxfilesperproc);
+   td->td_retval[0] = getmaxfd(td);
 #ifdef RACCT
PROC_LOCK(td->td_proc);
lim = racct_get_limit(td->td_proc, RACCT_NOFILE);
___
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: r341818 - in head/sys: kern sys

2018-12-11 Thread Mateusz Guzik 
Author: mjg
Date: Tue Dec 11 12:01:46 2018
New Revision: 341818
URL: https://svnweb.freebsd.org/changeset/base/341818

Log:
  Make lim_cur inline if possible.
  
  It is a function call only to accomodate *some* ABIs which install a hook.
  They only care for 3 types of limits: DATA, STACK, VMEM
  
  Instead of always calling the func, see at compilation time if the requested
  limit is something else and just do the read if so.
  
  Sponsored by: The FreeBSD Foundation

Modified:
  head/sys/kern/kern_resource.c
  head/sys/sys/resourcevar.h

Modified: head/sys/kern/kern_resource.c
==
--- head/sys/kern/kern_resource.c   Tue Dec 11 11:58:44 2018
(r341817)
+++ head/sys/kern/kern_resource.c   Tue Dec 11 12:01:46 2018
(r341818)
@@ -1168,7 +1168,7 @@ lim_max_proc(struct proc *p, int which)
  * The which parameter which specifies the index into the rlimit array
  */
 rlim_t
-lim_cur(struct thread *td, int which)
+(lim_cur)(struct thread *td, int which)
 {
struct rlimit rl;
 

Modified: head/sys/sys/resourcevar.h
==
--- head/sys/sys/resourcevar.h  Tue Dec 11 11:58:44 2018(r341817)
+++ head/sys/sys/resourcevar.h  Tue Dec 11 12:01:46 2018(r341818)
@@ -132,6 +132,19 @@ struct plimit
*lim_alloc(void);
 voidlim_copy(struct plimit *dst, struct plimit *src);
 rlim_t  lim_cur(struct thread *td, int which);
+#define lim_cur(td, which) ({  \
+   rlim_t _rlim;   \
+   struct thread *_td = (td);  \
+   int _which = (which);   \
+   if (__builtin_constant_p(which) && which != RLIMIT_DATA &&  \
+   which != RLIMIT_STACK && which != RLIMIT_VMEM) {\
+   _rlim = td->td_limit->pl_rlimit[which].rlim_cur;\
+   } else {\
+   _rlim = lim_cur(_td, _which);   \
+   }   \
+   _rlim;  \
+})
+
 rlim_t  lim_cur_proc(struct proc *p, int which);
 voidlim_fork(struct proc *p1, struct proc *p2);
 voidlim_free(struct plimit *limp);
___
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: r341817 - head/sys/kern

2018-12-11 Thread Mateusz Guzik 
Author: mjg
Date: Tue Dec 11 11:58:44 2018
New Revision: 341817
URL: https://svnweb.freebsd.org/changeset/base/341817

Log:
  fd: tidy up closing a fd
  
  - avoid a call to knote_close in the common case
  - annotate mqueue as unlikely
  
  Sponsored by: The FreeBSD Foundation

Modified:
  head/sys/kern/kern_descrip.c

Modified: head/sys/kern/kern_descrip.c
==
--- head/sys/kern/kern_descrip.cTue Dec 11 11:57:12 2018
(r341816)
+++ head/sys/kern/kern_descrip.cTue Dec 11 11:58:44 2018
(r341817)
@@ -1186,12 +1186,13 @@ closefp(struct filedesc *fdp, int fd, struct file *fp,
 * knote_fdclose to prevent a race of the fd getting opened, a knote
 * added, and deleteing a knote for the new fd.
 */
-   knote_fdclose(td, fd);
+   if (__predict_false(!TAILQ_EMPTY(>fd_kqlist)))
+   knote_fdclose(td, fd);
 
/*
 * We need to notify mqueue if the object is of type mqueue.
 */
-   if (fp->f_type == DTYPE_MQUEUE)
+   if (__predict_false(fp->f_type == DTYPE_MQUEUE))
mq_fdclose(td, fd, fp);
FILEDESC_XUNLOCK(fdp);
 
___
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: r341816 - head/sys/kern

2018-12-11 Thread Mateusz Guzik 
Author: mjg
Date: Tue Dec 11 11:57:12 2018
New Revision: 341816
URL: https://svnweb.freebsd.org/changeset/base/341816

Log:
  fd: stop looking for exact freefile after allocation
  
  If a lower fd is closed later, the lookup goes to waste. Allocation
  always performs the lookup anyway.
  
  Sponsored by: The FreeBSD Foundation

Modified:
  head/sys/kern/kern_descrip.c

Modified: head/sys/kern/kern_descrip.c
==
--- head/sys/kern/kern_descrip.cTue Dec 11 11:31:13 2018
(r341815)
+++ head/sys/kern/kern_descrip.cTue Dec 11 11:57:12 2018
(r341816)
@@ -262,7 +262,7 @@ fdused(struct filedesc *fdp, int fd)
if (fd > fdp->fd_lastfile)
fdp->fd_lastfile = fd;
if (fd == fdp->fd_freefile)
-   fdp->fd_freefile = fd_first_free(fdp, fd, fdp->fd_nfiles);
+   fdp->fd_freefile++;
 }
 
 /*
___
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: r341682 - head/sys/sys

2018-12-11 Thread Warner Losh 
On Mon, Dec 10, 2018 at 9:57 PM Scott Long  wrote:

>
>
> > On Dec 10, 2018, at 4:47 PM, Konstantin Belousov 
> wrote:
> >
> > On Mon, Dec 10, 2018 at 02:15:20PM -0800, John Baldwin wrote:
> >> On 12/8/18 7:43 PM, Warner Losh wrote:
> >>>
> >>>
> >>> On Sat, Dec 8, 2018, 8:36 PM Kevin Bowling   wrote:
> >>>
> >>>On Sat, Dec 8, 2018 at 12:09 AM Mateusz Guzik  > wrote:
> >>>
> 
>  Fully satisfying solution would be that all architectures get 64-bit
>  ops, even if in the worst case they end up taking a lock. Then
>  subsystems would not have to ifdef on anything. However, there
>  was some opposition to this proposal and I don't think this is
>  important enough to push.
> >>>
> >>>Mateusz,
> >>>
> >>>Who is opposing this particular polyfill solution?  Scott Long
> brought
> >>>up a situation in driver development where this would be useful as
> >>>well.  The polyfills lower the cognitive load and #ifdef soup which
> >>>are the right call here regardless of performance on toy ports.
> >>>
> >>>
> >>> I don't recall seeing the opposition either. It would have to be a
> global lock for all 64bit atomics but I think it would only be 2
> atomics on those architectures.
> >>
> >> It would have to be a spin lock, so in the case of unrl you would be
> trading
> >> an operation on one of N regular mutexes for a single spin lock that was
> >> also contested by other things.  This would be pretty crappy.  For
> drivers
> >> that aren't actually used on platforms without 32-bit atomics we can
> simply
> >> not build them in sys/modules/Makefile or not put them in GENERIC.  For
> >> something in the core kernel like unrl I think we will have to do what
> >> Mateusz has done here.
> >
> > It is worse. All atomics that acess the same location must use the same
> > lock. Otherwise, you could observe torn writes and out of thin air
> > values. Since you cannot know in advance which locations are acceses
> > by the locked variant, all freebsd atomics ops have to be switched to
> > locked variant on the architecture.
>
> 64bit atomics on I486 already suffer the risk of torn reads; the
> implementation
> merely does a CLI to protect against local preemption (though you could
> still
> get unlucky with an NMI).  I suppose you could argue that SMP isn’t really
> viable on I486 and therefore this fact is irrelevant, but it does
> illustrate
> precedence for having API completeness in a platform.
>

We haven't ever supported SMP on i486, to my knowledge. Certainly by the
5.x time frame with SMPng it wasn't there. The 64-bit ops that are there
are mostly to smoothly support some of the (now older) embedded boards. I
haven't looked at the SMP work smp did for 4.x, but IIRC, it wasn't even
supported there.


> Really, this isn’t that hard.  Part of the existing contract of using
> atomics is
> that you carefully evaluate all uses of the variable and decide when to use
> an atomic instruction.  Arguing that we can’t make this process automatic
> and foolproof for 64bit quantities, especially for a subset of subset of
> platforms/architectures, and therefore we should be even more of a
> difficult
> landmine, is not…. I don’t know what to say… sensical?
>

I think it's fine to say that 64-bit atomics need to be efficient on the
supported platforms (more on that below).


> 64bit operations are a reality for MI code in a modern OS, and I’m tired of
> having to tip-toe around them due to incomplete MD implementations.  The
> instructions have been available on Intel CPUs for 25 years!  My
> very strong preference is to have a complete and functional implementation
> of atomic.h for any architecture that is hooked up to the build.  We can
> then
> tackle the details of optimization and edge case refinement, just like we
> do
> with every other API and service that we work on.  It doesn’t have to be
> perfect to be useful, and at this point we’re providing neither perfection
> nor
> utility, just “buts” and “what ifs”.
>

I think you miss the point of discussion, at least on my part. I'm looking
at the MIPS side and asking the question whatever 32-bit SMP support we may
have had in the past should die. We only ever supported it on one
not-so-common board that's aged out of relevance (JZ4780 is the only one I
found that needs 32-bit MIPS SMP, and it's a 4 year old embedded board
that's not that relevant today and there's no successor products in the
market or as far as I can tell planned). We also have kernels that run in
32-bit mode on 64-bit hardware, but those provide little value and w
already transitioned our largest 64-bit mips platform away from that
support, so we can deorbit as well, I think. They give little value to the
project. some house keeping here is likely in order.

If that just leaves an odd PPC thing, then I think it's perfectly fine to
start conversations there as well about trimming that support with the

svn commit: r341815 - in stable/12/sys: conf dev/netmap modules/netmap net

2018-12-11 Thread Vincenzo Maffione 
Author: vmaffione
Date: Tue Dec 11 11:31:13 2018
New Revision: 341815
URL: https://svnweb.freebsd.org/changeset/base/341815

Log:
  MFC r341516, r341589
  
  netmap: align codebase to the current upstream (760279cfb2730a585)
  
  Changelist:
- Replace netmap passthrough host support with a more general
  mechanism to call TXSYNC/RXSYNC from an in-kernel event-loop.
  No kernel threads are used to use this feature: the application
  is required to spawn a thread (or a process) and issue a
  SYNC_KLOOP_START (NIOCCTRL) command in the thread body. The
  kernel loop is executed by the ioctl implementation, which returns
  to userspace only when a different thread calls SYNC_KLOOP_STOP
  or the netmap file descriptor is closed.
- Update the if_ptnet driver to cope with the new data structures,
  and prune all the obsolete ptnetmap code.
- Add support for "null" netmap ports, useful to allocate netmap_if,
  netmap_ring and netmap buffers to be used by specialized applications
  (e.g. hypervisors). TXSYNC/RXSYNC on these ports have no effect.
- Various fixes and code refactoring.
  
  Sponsored by: Sunny Valley Networks
  Differential Revision:https://reviews.freebsd.org/D18015

Added:
  stable/12/sys/dev/netmap/netmap_kloop.c
 - copied unchanged from r341516, head/sys/dev/netmap/netmap_kloop.c
  stable/12/sys/dev/netmap/netmap_null.c
 - copied unchanged from r341516, head/sys/dev/netmap/netmap_null.c
Modified:
  stable/12/sys/conf/files
  stable/12/sys/dev/netmap/if_ixl_netmap.h
  stable/12/sys/dev/netmap/if_ptnet.c
  stable/12/sys/dev/netmap/if_vtnet_netmap.h
  stable/12/sys/dev/netmap/netmap.c
  stable/12/sys/dev/netmap/netmap_bdg.c
  stable/12/sys/dev/netmap/netmap_bdg.h
  stable/12/sys/dev/netmap/netmap_freebsd.c
  stable/12/sys/dev/netmap/netmap_generic.c
  stable/12/sys/dev/netmap/netmap_kern.h
  stable/12/sys/dev/netmap/netmap_legacy.c
  stable/12/sys/dev/netmap/netmap_mem2.c
  stable/12/sys/dev/netmap/netmap_mem2.h
  stable/12/sys/dev/netmap/netmap_pipe.c
  stable/12/sys/dev/netmap/netmap_vale.c
  stable/12/sys/modules/netmap/Makefile
  stable/12/sys/net/netmap.h
  stable/12/sys/net/netmap_user.h
  stable/12/sys/net/netmap_virt.h
Directory Properties:
  stable/12/   (props changed)

Modified: stable/12/sys/conf/files
==
--- stable/12/sys/conf/filesTue Dec 11 11:13:11 2018(r341814)
+++ stable/12/sys/conf/filesTue Dec 11 11:31:13 2018(r341815)
@@ -2534,17 +2534,19 @@ dev/ncv/ncr53c500.c optional ncv
 dev/ncv/ncr53c500_pccard.c optional ncv pccard
 dev/netmap/if_ptnet.c  optional netmap inet
 dev/netmap/netmap.coptional netmap
+dev/netmap/netmap_bdg.coptional netmap
 dev/netmap/netmap_freebsd.coptional netmap
 dev/netmap/netmap_generic.coptional netmap
+dev/netmap/netmap_kloop.c  optional netmap
+dev/netmap/netmap_legacy.c optional netmap
 dev/netmap/netmap_mbq.coptional netmap
 dev/netmap/netmap_mem2.c   optional netmap
 dev/netmap/netmap_monitor.coptional netmap
+dev/netmap/netmap_null.c   optional netmap
 dev/netmap/netmap_offloadings.coptional netmap
 dev/netmap/netmap_pipe.c   optional netmap
 dev/netmap/netmap_pt.c optional netmap
 dev/netmap/netmap_vale.c   optional netmap
-dev/netmap/netmap_legacy.c optional netmap
-dev/netmap/netmap_bdg.coptional netmap
 # compile-with "${NORMAL_C} -Wconversion -Wextra"
 dev/nfsmb/nfsmb.c  optional nfsmb pci
 dev/nge/if_nge.c   optional nge

Modified: stable/12/sys/dev/netmap/if_ixl_netmap.h
==
--- stable/12/sys/dev/netmap/if_ixl_netmap.hTue Dec 11 11:13:11 2018
(r341814)
+++ stable/12/sys/dev/netmap/if_ixl_netmap.hTue Dec 11 11:31:13 2018
(r341815)
@@ -129,7 +129,7 @@ ixl_netmap_attach(struct ixl_vsi *vsi)
na.ifp = vsi->ifp;
na.na_flags = NAF_BDG_MAYSLEEP;
// XXX check that queues is set.
-   nm_prinf("queues is %p\n", vsi->queues);
+   nm_prinf("queues is %p", vsi->queues);
if (vsi->queues) {
na.num_tx_desc = vsi->queues[0].num_desc;
na.num_rx_desc = vsi->queues[0].num_desc;

Modified: stable/12/sys/dev/netmap/if_ptnet.c
==
--- stable/12/sys/dev/netmap/if_ptnet.c Tue Dec 11 11:13:11 2018
(r341814)
+++ stable/12/sys/dev/netmap/if_ptnet.c Tue Dec 11 11:31:13 2018
(r341815)
@@ -128,8 +128,8 @@ struct ptnet_queue {
struct  resource *irq;
void*cookie;
int kring_id;
-   struct ptnet_csb_gh *ptgh;
-   struct ptnet_csb_hg *pthg;
+   struct

svn commit: r341814 - head/sys/arm64/acpica

2018-12-11 Thread Andrew Turner 
Author: andrew
Date: Tue Dec 11 11:13:11 2018
New Revision: 341814
URL: https://svnweb.freebsd.org/changeset/base/341814

Log:
  Only read the ACPI proximity tabled on arm64 when we are booting from
  ACPI.
  
  Sponsored by: DARPA, AFRL

Modified:
  head/sys/arm64/acpica/acpi_machdep.c

Modified: head/sys/arm64/acpica/acpi_machdep.c
==
--- head/sys/arm64/acpica/acpi_machdep.cTue Dec 11 06:47:04 2018
(r341813)
+++ head/sys/arm64/acpica/acpi_machdep.cTue Dec 11 11:13:11 2018
(r341814)
@@ -38,6 +38,8 @@ __FBSDID("$FreeBSD$");
 #include 
 #include 
 
+#include 
+
 #include 
 #include 
 #include 
@@ -238,6 +240,10 @@ acpi_map_addr(struct acpi_generic_address *addr, bus_s
 static void
 parse_pxm_tables(void *dummy)
 {
+
+   /* Only parse ACPI tables when booting via ACPI */
+   if (arm64_bus_method != ARM64_BUS_ACPI)
+   return;
 
acpi_pxm_init(MAXCPU, (vm_paddr_t)1 << 40);
acpi_pxm_parse_tables();
___
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"