svn commit: r345206 - in head/sys: geom kern sys

[Conrad Meyer]

Author: cem
Date: Fri Mar 15 22:39:55 2019
New Revision: 345206
URL: https://svnweb.freebsd.org/changeset/base/345206

Log:
  stack(9): Drop unused API mode and comment that referenced it
  
  Reviewed by:  markj
  Differential Revision:https://reviews.freebsd.org/D19601

Modified:
  head/sys/geom/geom_io.c
  head/sys/kern/subr_stack.c
  head/sys/sys/_stack.h
  head/sys/sys/stack.h

Modified: head/sys/geom/geom_io.c
==
--- head/sys/geom/geom_io.c Fri Mar 15 21:49:19 2019(r345205)
+++ head/sys/geom/geom_io.c Fri Mar 15 22:39:55 2019(r345206)
@@ -155,7 +155,7 @@ g_new_bio(void)
 
CTR1(KTR_GEOM, "g_new_bio(): %p", bp);
stack_save();
-   CTRSTACK(KTR_GEOM, , 3, 0);
+   CTRSTACK(KTR_GEOM, , 3);
}
 #endif
return (bp);
@@ -173,7 +173,7 @@ g_alloc_bio(void)
 
CTR1(KTR_GEOM, "g_alloc_bio(): %p", bp);
stack_save();
-   CTRSTACK(KTR_GEOM, , 3, 0);
+   CTRSTACK(KTR_GEOM, , 3);
}
 #endif
return (bp);
@@ -188,7 +188,7 @@ g_destroy_bio(struct bio *bp)
 
CTR1(KTR_GEOM, "g_destroy_bio(): %p", bp);
stack_save();
-   CTRSTACK(KTR_GEOM, , 3, 0);
+   CTRSTACK(KTR_GEOM, , 3);
}
 #endif
uma_zfree(biozone, bp);
@@ -236,7 +236,7 @@ g_clone_bio(struct bio *bp)
 
CTR2(KTR_GEOM, "g_clone_bio(%p): %p", bp, bp2);
stack_save();
-   CTRSTACK(KTR_GEOM, , 3, 0);
+   CTRSTACK(KTR_GEOM, , 3);
}
 #endif
return(bp2);
@@ -265,7 +265,7 @@ g_duplicate_bio(struct bio *bp)
 
CTR2(KTR_GEOM, "g_duplicate_bio(%p): %p", bp, bp2);
stack_save();
-   CTRSTACK(KTR_GEOM, , 3, 0);
+   CTRSTACK(KTR_GEOM, , 3);
}
 #endif
return(bp2);

Modified: head/sys/kern/subr_stack.c
==
--- head/sys/kern/subr_stack.c  Fri Mar 15 21:49:19 2019(r345205)
+++ head/sys/kern/subr_stack.c  Fri Mar 15 22:39:55 2019(r345206)
@@ -215,7 +215,7 @@ stack_sbuf_print_ddb(struct sbuf *sb, const struct sta
 #ifdef KTR
 void
 stack_ktr(u_int mask, const char *file, int line, const struct stack *st,
-u_int depth, int cheap)
+u_int depth)
 {
 #ifdef DDB
const char *name;
@@ -224,31 +224,15 @@ stack_ktr(u_int mask, const char *file, int line, cons
 #endif
 
KASSERT(st->depth <= STACK_MAX, ("bogus stack"));
-   if (cheap) {
-   ktr_tracepoint(mask, file, line, "#0 %p %p %p %p %p %p",
-   st->pcs[0], st->pcs[1], st->pcs[2], st->pcs[3],
-   st->pcs[4], st->pcs[5]);
-   if (st->depth <= 6)
-   return;
-   ktr_tracepoint(mask, file, line, "#1 %p %p %p %p %p %p",
-   st->pcs[6], st->pcs[7], st->pcs[8], st->pcs[9],
-   st->pcs[10], st->pcs[11]);
-   if (st->depth <= 12)
-   return;
-   ktr_tracepoint(mask, file, line, "#2 %p %p %p %p %p %p",
-   st->pcs[12], st->pcs[13], st->pcs[14], st->pcs[15],
-   st->pcs[16], st->pcs[17]);
 #ifdef DDB
-   } else {
-   if (depth == 0 || st->depth < depth)
-   depth = st->depth;
-   for (i = 0; i < depth; i++) {
-   (void)stack_symbol_ddb(st->pcs[i], , );
-   ktr_tracepoint(mask, file, line, "#%d %p at %s+%#lx",
-   i, st->pcs[i], (u_long)name, offset, 0, 0);
-   }
-#endif
+   if (depth == 0 || st->depth < depth)
+   depth = st->depth;
+   for (i = 0; i < depth; i++) {
+   (void)stack_symbol_ddb(st->pcs[i], , );
+   ktr_tracepoint(mask, file, line, "#%d %p at %s+%#lx",
+   i, st->pcs[i], (u_long)name, offset, 0, 0);
}
+#endif
 }
 #endif
 

Modified: head/sys/sys/_stack.h
==
--- head/sys/sys/_stack.h   Fri Mar 15 21:49:19 2019(r345205)
+++ head/sys/sys/_stack.h   Fri Mar 15 22:39:55 2019(r345206)
@@ -31,7 +31,7 @@
 #ifndef _SYS__STACK_H_
 #define_SYS__STACK_H_
 
-#defineSTACK_MAX   18  /* Don't change, stack_ktr relies on 
this. */
+#defineSTACK_MAX   18
 
 struct stack {
int depth;

Modified: head/sys/sys/stack.h
==
--- head/sys/sys/stack.hFri Mar 15 21:49:19 2019(r345205)
+++ head/sys/sys/stack.hFri Mar 15 22:39:55 2019(r345206)
@@ -51,13 +51,13 @@ int  stack_sbuf_print_flags(struct sbuf *, const 
stru
 int);
 #ifdef KTR
 

Re: svn commit: r345171 - head/usr.sbin/bhyve

[John Baldwin]

On 3/15/19 2:36 PM, Chuck Tuffli wrote:
> I was contacted by a bhyve user who mentioned that Windows didn't seem
> to like bhyve's NVMe emulation. This change doesn't fix that, but this
> is one of a handful of changes inspired by qemu. While trying to
> reverse engineer why Windows is grumpy, I've run across several
> comments in the qemu code which make claims about what Windows needs
> to see before starting a device. This was one of those, and (at the
> time) seemed innocuous enough to commit.

Ok.  It seems like a bit of an odd requirement, but perhaps Windows PCI-e error
handling stuff assumes it is present?  It might be worth expanding the comment
to note that as the reason?

-- 
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: r345205 - in head/cddl/usr.sbin/zfsd: . tests

[Enji Cooper]

Author: ngie
Date: Fri Mar 15 21:49:19 2019
New Revision: 345205
URL: https://svnweb.freebsd.org/changeset/base/345205

Log:
  Integrate cddl/usr.sbin/zfds/tests into the FreeBSD test suite
  
  This change integrates the unit tests for zfsd into the test suite using the
  integration method described in r345203.
  
  This change removes the `LOCALBASE` includes added for the port version of
  googlemock/googletest, as well as unnecessary `LIBADD`/`DPADD` and `CXXFLAGS`
  defines, which are included in the `GTEST_CXXFLAGS` variable, as part of
  r345203.
  
  Reviewed by:  asomers
  Approved by:  emaste (mentor)
  MFC after:2 months
  MFC with: r345203
  Differential Revision: https://reviews.freebsd.org/D19552

Modified:
  head/cddl/usr.sbin/zfsd/Makefile
  head/cddl/usr.sbin/zfsd/Makefile.common
  head/cddl/usr.sbin/zfsd/tests/Makefile

Modified: head/cddl/usr.sbin/zfsd/Makefile
==
--- head/cddl/usr.sbin/zfsd/MakefileFri Mar 15 21:46:54 2019
(r345204)
+++ head/cddl/usr.sbin/zfsd/MakefileFri Mar 15 21:49:19 2019
(r345205)
@@ -1,12 +1,13 @@
 # $FreeBSD$
 
+.include 
+
 .include "Makefile.common"
 
 PROG_CXX=  zfsd
 MAN=   zfsd.8
 
-.include 
+HAS_TESTS=
+SUBDIR.${MK_GOOGLETEST}+= tests
 
-# The unittests require devel/googletest and devel/googlemock from ports.
-# Don't automatically build them.
-SUBDIR=
+.include 

Modified: head/cddl/usr.sbin/zfsd/Makefile.common
==
--- head/cddl/usr.sbin/zfsd/Makefile.common Fri Mar 15 21:46:54 2019
(r345204)
+++ head/cddl/usr.sbin/zfsd/Makefile.common Fri Mar 15 21:49:19 2019
(r345205)
@@ -28,12 +28,11 @@ INCFLAGS+= -I${SRCTOP}/cddl/contrib/opensolaris/lib/li
 INCFLAGS+= -I${SRCTOP}/sys/cddl/contrib/opensolaris/common/zfs
 INCFLAGS+= -I${SRCTOP}/sys/cddl/contrib/opensolaris/uts/common
 INCFLAGS+= -I${SRCTOP}/sys/cddl/contrib/opensolaris/uts/common/fs/zfs
+INCFLAGS+= -I${SRCTOP}/cddl/usr.sbin
 
 CFLAGS= -g -DNEED_SOLARIS_BOOLEAN ${INCFLAGS}
 
-DPADD=  ${LIBDEVDCTL} ${LIBZFS} ${LIBZFS_CORE} ${LIBUTIL} ${LIBGEOM} \
-   ${LIBBSDXML} ${LIBSBUF} ${LIBNVPAIR} ${LIBUUTIL}
-LIBADD=  devdctl zfs zfs_core util geom bsdxml sbuf nvpair uutil
+LIBADD+=   devdctl zfs zfs_core util geom bsdxml sbuf nvpair uutil
 
 cscope:
find ${.CURDIR} -type f -a \( -name "*.[ch]" -o -name "*.cc" \) \

Modified: head/cddl/usr.sbin/zfsd/tests/Makefile
==
--- head/cddl/usr.sbin/zfsd/tests/Makefile  Fri Mar 15 21:46:54 2019
(r345204)
+++ head/cddl/usr.sbin/zfsd/tests/Makefile  Fri Mar 15 21:49:19 2019
(r345205)
@@ -3,30 +3,12 @@
 .include "${.CURDIR}/../Makefile.common"
 .PATH: ${.CURDIR:H}
 
-PLAIN_TESTS_CXX=   zfsd_unittest
-SRCS.zfsd_unittest:=   ${SRCS:Nzfsd_main.cc}
-SRCS.zfsd_unittest+=   libmocks.c zfsd_unittest.cc
-SRCS=
+GTESTS=zfsd_unittest
 
-# Use #include  in test programs.
-INCFLAGS+= -I${.CURDIR:H:H}
+SRCS.zfsd_unittest:=   ${SRCS:Nzfsd_main.cc}
+SRCS.zfsd_unittest+=   libmocks.c zfsd_unittest.cc
+.undef SRCS
 
-.if defined(DESTDIR) || defined(SYSROOT)
-INCFLAGS+= -I${SYSROOT:U${DESTDIR}}/usr/include
-LDFLAGS.zfsd_unittest+=-L${SYSROOT:U${DESTDIR}}/lib \
-   -L${SYSROOT:U${DESTDIR}}/usr/lib
-.endif
-
-# Googletest options
-INCFLAGS+= -I${LOCALBASE}/include -D_THREAD_SAFE -pthread
-LDFLAGS.zfsd_unittest+=-L${LOCALBASE}/lib -D_THREAD_SAFE -pthread
-LDADD.zfsd_unittest+=  ${LOCALBASE}/lib/libgtest.a
-
-# GoogleMock options
-LDADD.zfsd_unittest+= ${LOCALBASE}/lib/libgmock.a 
${LOCALBASE}/lib/libgmock_main.a
-
-# Googlemock fails if we don't have this line
-# 
https://groups.google.com/forum/#!msg/googletestframework/h8ixEPCFm0o/amwfu4xGJb0J
-CFLAGS.zfsd_unittest+= -DGTEST_HAS_PTHREAD
+LIBADD.zfsd_unittest+= gmock_main
 
 .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"

svn commit: r345204 - head/share/man/man5

[Enji Cooper]

Author: ngie
Date: Fri Mar 15 21:46:54 2019
New Revision: 345204
URL: https://svnweb.freebsd.org/changeset/base/345204

Log:
  Regenerate src.conf(5) after r345203 (MK_GOOGLETEST addition)
  
  MFC after:2 months
  MFC with: r345203
  Approved by:  emaste (mentor; implicit: https://reviews.freebsd.org/D19551)

Modified:
  head/share/man/man5/src.conf.5

Modified: head/share/man/man5/src.conf.5
==
--- head/share/man/man5/src.conf.5  Fri Mar 15 21:43:52 2019
(r345203)
+++ head/share/man/man5/src.conf.5  Fri Mar 15 21:46:54 2019
(r345204)
@@ -1,6 +1,6 @@
 .\" DO NOT EDIT-- this file is @generated by tools/build/options/makeman.
 .\" $FreeBSD$
-.Dd March 6, 2019
+.Dd March 15, 2019
 .Dt SRC.CONF 5
 .Os
 .Sh NAME
@@ -828,6 +828,11 @@ Set to not build GNU
 Set this option to include GNU extensions in
 .Xr bsdgrep 1
 by linking against libgnuregex.
+.It Va WITHOUT_GOOGLETEST
+Set to neither build nor install
+.Lb libgmock ,
+.Lb libgtest ,
+and dependent tests.
 .It Va WITHOUT_GPIO
 Set to not build
 .Xr gpioctl 8
@@ -1826,6 +1831,10 @@ When set, it enforces these options:
 When set, these options are also in effect:
 .Pp
 .Bl -inset -compact
+.It Va WITHOUT_GOOGLETEST
+(unless
+.Va WITH_GOOGLETEST
+is set explicitly)
 .It Va WITHOUT_TESTS_SUPPORT
 (unless
 .Va WITH_TESTS_SUPPORT
@@ -1833,6 +1842,12 @@ is set explicitly)
 .El
 .It Va WITHOUT_TESTS_SUPPORT
 Set to disables the build of all test-related dependencies, including ATF.
+When set, it enforces these options:
+.Pp
+.Bl -item -compact
+.It
+.Va WITHOUT_GOOGLETEST
+.El
 .It Va WITHOUT_TEXTPROC
 Set to not build
 programs used for text processing.
___
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: r345203 - in head: contrib/googletest contrib/mandoc etc/mtree lib lib/googletest share/examples/tests/tests share/examples/tests/tests/googletest share/mk tools/build/mk tools/build/op...

[Enji Cooper]

Author: ngie
Date: Fri Mar 15 21:43:52 2019
New Revision: 345203
URL: https://svnweb.freebsd.org/changeset/base/345203

Log:
  Initial googlemock/googletest integration into the build/FreeBSD test suite
  
  This initial integration takes googlemock/googletest release 1.8.1, integrates
  the library, tests, and sample unit tests into the build.
  
  googlemock/googletest's inclusion is optionally available via `MK_GOOGLETEST`.
  `MK_GOOGLETEST` is dependent on `MK_TESTS` and is enabled by default when
  built with a C++11 capable toolchain.
  
  Google tests can be specified via the `GTESTS` variable, which, in comparison
  with the other test drivers, is more simplified/streamlined, as Googletest 
only
  supports C++ tests; not raw C or shell tests (C tests can be written in C++
  using the standard embedding methods).
  
  No dependent libraries are assumed for the tests. One must specify `gmock`,
  `gmock_main`, `gtest`, or `gtest_main`, via `LIBADD` for the program.
  
  More information about googlemock and googletest can be found on the
  Googletest [project page](https://github.com/google/googletest), and the
  
[GoogleMock](https://github.com/google/googletest/blob/v1.8.x/googlemock/docs/Documentation.md)
  and
  [GoogleTest](https://github.com/google/googletest/tree/v1.8.x/googletest/docs)
  docs.
  
  These tests are originally integrated into the build as plain driver tests, 
but
  will be natively integrated into Kyua in a later version.
  
  Known issues/Errata:
  * [WhenDynamicCastToTest.AmbiguousCast fails on 
FreeBSD](https://github.com/google/googletest/issues/2172)
  
  Reviewed by:  asomers
  Approved by:  emaste (mentor)
  MFC after:2 months
  Differential Revision: https://reviews.freebsd.org/D19551

Added:
  head/contrib/googletest/
 - copied from r345031, projects/import-googletest-1.8.1/contrib/googletest/
  head/lib/googletest/
 - copied from r345031, projects/import-googletest-1.8.1/lib/googletest/
  head/share/examples/tests/tests/googletest/
 - copied from r345031, 
projects/import-googletest-1.8.1/share/examples/tests/tests/googletest/
  head/share/mk/googletest.test.inc.mk
 - copied, changed from r345031, 
projects/import-googletest-1.8.1/share/mk/googletest.test.inc.mk
  head/share/mk/googletest.test.mk
 - copied unchanged from r345031, 
projects/import-googletest-1.8.1/share/mk/googletest.test.mk
  head/tools/build/options/WITHOUT_GOOGLETEST
 - copied, changed from r345031, 
projects/import-googletest-1.8.1/tools/build/options/WITHOUT_GOOGLETEST
Modified:
  head/contrib/mandoc/lib.in
  head/etc/mtree/BSD.tests.dist
  head/etc/mtree/BSD.usr.dist
  head/lib/Makefile
  head/share/examples/tests/tests/Makefile
  head/share/examples/tests/tests/googletest/Makefile
  head/share/mk/Makefile
  head/share/mk/bsd.README
  head/share/mk/bsd.test.mk
  head/share/mk/src.libnames.mk
  head/share/mk/src.opts.mk
  head/tools/build/mk/OptionalObsoleteFiles.inc

Modified: head/contrib/mandoc/lib.in
==
--- head/contrib/mandoc/lib.in  Fri Mar 15 21:11:47 2019(r345202)
+++ head/contrib/mandoc/lib.in  Fri Mar 15 21:43:52 2019(r345203)
@@ -62,7 +62,9 @@ LINE("libfsid",   "Filesystem Identification 
Library (l
 LINE("libftpio",   "FTP Connection Management Library (libftpio, 
\\-lftpio)")
 LINE("libform","Curses Form Library (libform, \\-lform)")
 LINE("libgeom","Userland API Library for Kernel GEOM subsystem 
(libgeom, \\-lgeom)")
+LINE("libgmock",   "GoogleMock library (libgmock, \\-lgmock)")
 LINE("libgpio","General-Purpose Input Output (GPIO) library 
(libgpio, \\-lgpio)")
+LINE("libgtest",   "GoogleTest library (libgtest, \\-lgtest)")
 LINE("libhammer",  "HAMMER Filesystem Userland Library (libhammer, 
\\-lhammer)")
 LINE("libi386","i386 Architecture Library (libi386, \\-li386)")
 LINE("libintl","Internationalized Message Handling Library 
(libintl, \\-lintl)")

Modified: head/etc/mtree/BSD.tests.dist
==
--- head/etc/mtree/BSD.tests.dist   Fri Mar 15 21:11:47 2019
(r345202)
+++ head/etc/mtree/BSD.tests.dist   Fri Mar 15 21:43:52 2019
(r345203)
@@ -278,6 +278,16 @@
 static
 ..
 ..
+googletest
+gmock
+..
+gmock_main
+..
+gtest
+..
+gtest_main
+..
+..
 libarchive
 ..
 libc
@@ -429,6 +439,8 @@
 examples
 tests
 atf
+..
+googletest
 ..
 plain
 ..

Modified: head/etc/mtree/BSD.usr.dist
==
--- head/etc/mtree/BSD.usr.dist Fri 

Re: svn commit: r345171 - head/usr.sbin/bhyve

[Chuck Tuffli]

Apologies all the way around. I was ignorant about the maintainer for
this code and goofed. See inline for other comments.

On Fri, Mar 15, 2019 at 9:28 AM John Baldwin  wrote:
>
> On 3/14/19 10:24 PM, Conrad Meyer wrote:
> > On Thu, Mar 14, 2019 at 8:06 PM Andrew Thompson  wrote:
> >>
> >> On Fri, 15 Mar 2019 at 15:11, Chuck Tuffli  wrote:
> >>> bzero(, sizeof(pciecap));
> > ...
> >>> +   pciecap.dev_capabilities = PCIEM_CAP_ROLE_ERR_RPT;
> >>
> >> If the message you say 'set the bit' but you are overwriting the whole 
> >> variable, is this intended?
> >
> > Looks like it was zero before.  So yeah, it sets the bit.
>
> It would probably be cleaner for future changes to make it a |=, but that's a
> tiny nit.  style(9) wants a blank line before the comment as well.

Happy to make those changes

> I hadn't approved it yet only because I hadn't gone and dug through my PCIe
> books / specs to see what this bit is and confirm it is required.
>
> OTOH, it's not clear to me that bhyve PCI-e devices don't want to just be 1.0a
> devices as a lowest common denominator to be as accommodating to as wide 
> variety
> of OS's as possible.
>
> One thing I didn't see in a review was a reason for why to make this change?
> Does some OS reject devices without this bit set or is it just based on 
> reading
> the spec?  bhyve doesn't assert any PCI-e errors for virtual devices, so
> this bit is pretty meaningless.

I was contacted by a bhyve user who mentioned that Windows didn't seem
to like bhyve's NVMe emulation. This change doesn't fix that, but this
is one of a handful of changes inspired by qemu. While trying to
reverse engineer why Windows is grumpy, I've run across several
comments in the qemu code which make claims about what Windows needs
to see before starting a device. This was one of those, and (at the
time) seemed innocuous enough to commit.

--chuck
___
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: r345202 - head/share/man/man9

[Alan Somers]

Author: asomers
Date: Fri Mar 15 21:11:47 2019
New Revision: 345202
URL: https://svnweb.freebsd.org/changeset/base/345202

Log:
  VOP_INACTIVE(9): clarify wording
  
  Reviewed by:  kib, 0mp
  MFC after:2 weeks
  Sponsored by: The FreeBSD Foundation
  Differential Revision:https://reviews.freebsd.org/D19596

Modified:
  head/share/man/man9/VOP_INACTIVE.9

Modified: head/share/man/man9/VOP_INACTIVE.9
==
--- head/share/man/man9/VOP_INACTIVE.9  Fri Mar 15 20:16:35 2019
(r345201)
+++ head/share/man/man9/VOP_INACTIVE.9  Fri Mar 15 21:11:47 2019
(r345202)
@@ -28,7 +28,7 @@
 .\"
 .\" $FreeBSD$
 .\"
-.Dd July 27, 2014
+.Dd March 15, 2019
 .Dt VOP_INACTIVE 9
 .Os
 .Sh NAME
@@ -50,13 +50,16 @@ The vnode being reclaimed.
 .El
 .Pp
 .Fn VOP_INACTIVE
-is called when the kernel is no longer using the vnode.
+is usually called when the kernel is no longer using the vnode.
+However, there is no guarantee that it will be called at all, for example if
+the last reference was dropped while the vnode lock could not be upgraded
+to exclusive without sleeping.
 This may be
 because the reference count reaches zero or it may be that the
 file system is being forcibly unmounted while there are open files.
-It can be used to reclaim space for
+It can be used to reclaim space on the last close of an 
 .Sq open but deleted
-files.
+file.
 .Pp
 .Fn VOP_RECLAIM
 is called when a vnode is being reused for a different file system.
___
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: r345200 - in head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs: . sys

[Alexander Motin]

Author: mav
Date: Fri Mar 15 18:59:04 2019
New Revision: 345200
URL: https://svnweb.freebsd.org/changeset/base/345200

Log:
  MFV r336930: 9284 arc_reclaim_thread has 2 jobs
  
  `arc_reclaim_thread()` calls `arc_adjust()` after calling
  `arc_kmem_reap_now()`; `arc_adjust()` signals `arc_get_data_buf()` to
  indicate that we may no longer be `arc_is_overflowing()`.
  
  The problem is, `arc_kmem_reap_now()` can take several seconds to
  complete, has no impact on `arc_is_overflowing()`, but due to how the
  code is structured, can impact how long the ARC will remain in the
  `arc_is_overflowing()` state.
  
  The fix is to use seperate threads to:
  
  1. keep `arc_size` under `arc_c`, by calling `arc_adjust()`, which
  improves `arc_is_overflowing()`
  
  2. keep enough free memory in the system, by calling
   `arc_kmem_reap_now()` plus `arc_shrink()`, which improves
   `arc_available_memory()`.
  
  illumos/illumos-gate@de753e34f9c399037936e8bc547d823bba9d4b0d
  
  Reviewed by: Matt Ahrens 
  Reviewed by: Serapheim Dimitropoulos 
  Reviewed by: Pavel Zakharov 
  Reviewed by: Dan Kimmel 
  Reviewed by: Paul Dagnelie 
  Reviewed by: Dan McDonald 
  Reviewed by: Tim Kordas 
  Approved by: Garrett D'Amore 
  Author: Brad Lewis 

Modified:
  head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c
  head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/sys/zthr.h
  head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zthr.c
Directory Properties:
  head/sys/cddl/contrib/opensolaris/   (props changed)

Modified: head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c
==
--- head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c   Fri Mar 15 
18:53:36 2019(r345199)
+++ head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c   Fri Mar 15 
18:59:04 2019(r345200)
@@ -281,6 +281,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -296,11 +297,23 @@ int arc_procfd;
 #endif
 #endif /* illumos */
 
-static kmutex_tarc_reclaim_lock;
-static kcondvar_t  arc_reclaim_thread_cv;
-static boolean_t   arc_reclaim_thread_exit;
-static kcondvar_t  arc_reclaim_waiters_cv;
+/*
+ * This thread's job is to keep enough free memory in the system, by
+ * calling arc_kmem_reap_now() plus arc_shrink(), which improves
+ * arc_available_memory().
+ */
+static zthr_t  *arc_reap_zthr;
 
+/*
+ * This thread's job is to keep arc_size under arc_c, by calling
+ * arc_adjust(), which improves arc_is_overflowing().
+ */
+static zthr_t  *arc_adjust_zthr;
+
+static kmutex_tarc_adjust_lock;
+static kcondvar_t  arc_adjust_waiters_cv;
+static boolean_t   arc_adjust_needed = B_FALSE;
+
 static kmutex_tarc_dnlc_evicts_lock;
 static kcondvar_t  arc_dnlc_evicts_cv;
 static boolean_t   arc_dnlc_evicts_thread_exit;
@@ -317,19 +330,23 @@ uint_t arc_reduce_dnlc_percent = 3;
 int zfs_arc_evict_batch_limit = 10;
 
 /* number of seconds before growing cache again */
-static int arc_grow_retry = 60;
+int arc_grow_retry = 60;
 
-/* number of milliseconds before attempting a kmem-cache-reap */
-static int arc_kmem_cache_reap_retry_ms = 0;
+/*
+ * Minimum time between calls to arc_kmem_reap_soon().  Note that this will
+ * be converted to ticks, so with the default hz=100, a setting of 15 ms
+ * will actually wait 2 ticks, or 20ms.
+ */
+int arc_kmem_cache_reap_retry_ms = 1000;
 
 /* shift of arc_c for calculating overflow limit in arc_get_data_impl */
-intzfs_arc_overflow_shift = 8;
+int zfs_arc_overflow_shift = 8;
 
 /* shift of arc_c for calculating both min and max arc_p */
-static int arc_p_min_shift = 4;
+int arc_p_min_shift = 4;
 
 /* log2(fraction of arc to reclaim) */
-static int arc_shrink_shift = 7;
+int arc_shrink_shift = 7;
 
 /*
  * log2(fraction of ARC which must be free to allow growing).
@@ -355,7 +372,7 @@ static int  zfs_arc_min_prescient_prefetch_ms = 6;
  */
 int arc_lotsfree_percent = 10;
 
-static int arc_dead;
+static boolean_t arc_initialized;
 extern boolean_t zfs_prefetch_disable;
 
 /*
@@ -1052,6 +1069,7 @@ static kmutex_t arc_prune_mtx;
 static taskq_t *arc_prune_taskq;
 
 static int arc_no_grow;/* Don't try to grow cache size */
+static hrtime_tarc_growtime;
 static uint64_tarc_tempreserve;
 static uint64_tarc_loaned_bytes;
 
@@ -1819,8 +1837,8 @@ hdr_recl(void *unused)
 * umem calls the reclaim func when we destroy the buf cache,
 * which is after we do arc_fini().
 */
-   if (!arc_dead)
-   cv_signal(_reclaim_thread_cv);
+   if (arc_initialized)
+   zthr_wakeup(arc_reap_zthr);
 }
 
 static void
@@ -3905,13 +3923,14 @@ arc_evict_state_impl(multilist_t *ml, int idx, arc_buf
 * function should proceed in 

svn commit: r345199 - in stable/11/sys/x86: include x86

[Konstantin Belousov]

Author: kib
Date: Fri Mar 15 18:53:36 2019
New Revision: 345199
URL: https://svnweb.freebsd.org/changeset/base/345199

Log:
  MFC r345075:
  Add register number, CPUID bits, and print identification for TSX
  force abort errata.

Modified:
  stable/11/sys/x86/include/specialreg.h
  stable/11/sys/x86/x86/identcpu.c
Directory Properties:
  stable/11/   (props changed)

Modified: stable/11/sys/x86/include/specialreg.h
==
--- stable/11/sys/x86/include/specialreg.h  Fri Mar 15 18:50:36 2019
(r345198)
+++ stable/11/sys/x86/include/specialreg.h  Fri Mar 15 18:53:36 2019
(r345199)
@@ -390,6 +390,7 @@
 /*
  * CPUID instruction 7 Structured Extended Features, leaf 0 edx info
  */
+#defineCPUID_STDEXT3_TSXFA 0x2000
 #defineCPUID_STDEXT3_IBPB  0x0400
 #defineCPUID_STDEXT3_STIBP 0x0800
 #defineCPUID_STDEXT3_L1D_FLUSH 0x1000
@@ -448,6 +449,7 @@
 #defineMSR_MTRRcap 0x0fe
 #defineMSR_IA32_ARCH_CAP   0x10a
 #defineMSR_IA32_FLUSH_CMD  0x10b
+#defineMSR_TSX_FORCE_ABORT 0x10f
 #defineMSR_BBL_CR_ADDR 0x116
 #defineMSR_BBL_CR_DECC 0x118
 #defineMSR_BBL_CR_CTL  0x119

Modified: stable/11/sys/x86/x86/identcpu.c
==
--- stable/11/sys/x86/x86/identcpu.cFri Mar 15 18:50:36 2019
(r345198)
+++ stable/11/sys/x86/x86/identcpu.cFri Mar 15 18:53:36 2019
(r345199)
@@ -991,6 +991,7 @@ printcpuinfo(void)
printf("\n  Structured Extended Features3=0x%b",
cpu_stdext_feature3,
   "\020"
+  "\016TSXFA"
   "\033IBPB"
   "\034STIBP"
   "\035L1DFL"
___
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: r345197 - stable/11/sys/dev/hwpmc

[Konstantin Belousov]

Author: kib
Date: Fri Mar 15 18:50:00 2019
New Revision: 345197
URL: https://svnweb.freebsd.org/changeset/base/345197

Log:
  MFC r345074:
  Remove useless version check.

Modified:
  stable/11/sys/dev/hwpmc/hwpmc_core.c
Directory Properties:
  stable/11/   (props changed)

Modified: stable/11/sys/dev/hwpmc/hwpmc_core.c
==
--- stable/11/sys/dev/hwpmc/hwpmc_core.cFri Mar 15 18:18:05 2019
(r345196)
+++ stable/11/sys/dev/hwpmc/hwpmc_core.cFri Mar 15 18:50:00 2019
(r345197)
@@ -38,11 +38,7 @@ __FBSDID("$FreeBSD$");
 #include 
 
 #include 
-#if (__FreeBSD_version >= 110)
 #include 
-#else
-#include 
-#endif
 #include 
 #include 
 #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: r345196 - head/sys/sys

[John Baldwin]

On 3/15/19 11:28 AM, John Baldwin wrote:
> On 3/15/19 11:18 AM, Gleb Smirnoff wrote:
>> Author: glebius
>> Date: Fri Mar 15 18:18:05 2019
>> New Revision: 345196
>> URL: https://svnweb.freebsd.org/changeset/base/345196
>>
>> Log:
>>   Deanonymize thread and proc state enums, so that a userland app can
>>   use them without redefining the value names. New clang no longer
>>   allows to redefine a enum value name to the same value.
>>   
>>   Bump __FreeBSD_version, since ports depend on that.
>>   
>>   Discussed with:jhb
> 
> Note that devel/mdb from before this commit will no longer work on
> kernels built with this commit (so you can't use mdb on a 12.x box
> to cross-debug a crash with this change anymore).  Similarly, once
> mdb is fixed to build with this change, a new mdb built with this
> won't work with older kernels.

For background, mdb makes "clever" use of CTF debug info.  You
declare a structure in the debugger (or one of the debugger modules)
that contains a subset of the fields of the type from the thing you
are debugging.  mdb then compares the CTF of the two structures
and figures out how to copy the needed fields from the target structure
into the smaller one in the debugger module handling endian-ness swaps,
integer size differences, etc.  However, it requires the types of
each field to be identical.  The simplest way to do this is to make
a copy of the field by literally copying the fields (in this case
from sys/proc.h).  This meant that mdb had structs like this:

typedef struct {
...
enum {
 TDS_INACTIVE = 0,
 ...
} td_state;
} mdb_thread_t;

clang 8, in its infinite wisdom decided that the existing enum values
in  conflicted with the ones in mdb_thread_t even though
the numerical value of the enumerators was identical.

Note that even with this change, the existing code can't be copied
verbatim to mdb as using 'enum td_states { TDS_INACTIVE' once again
triggers clang 8's hyper-sensitivity.  Thus, with clang 8 it is now
impossible to copy and paste enum fields from the target structure to
the debugger version of the structure if you ever include the original
header for some other reason.  I consider this to be a compiler bug that
it isn't able to understand that 0 == 0.

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

Re: svn commit: r345196 - head/sys/sys

[John Baldwin]

On 3/15/19 11:18 AM, Gleb Smirnoff wrote:
> Author: glebius
> Date: Fri Mar 15 18:18:05 2019
> New Revision: 345196
> URL: https://svnweb.freebsd.org/changeset/base/345196
> 
> Log:
>   Deanonymize thread and proc state enums, so that a userland app can
>   use them without redefining the value names. New clang no longer
>   allows to redefine a enum value name to the same value.
>   
>   Bump __FreeBSD_version, since ports depend on that.
>   
>   Discussed with: jhb

Note that devel/mdb from before this commit will no longer work on
kernels built with this commit (so you can't use mdb on a 12.x box
to cross-debug a crash with this change anymore).  Similarly, once
mdb is fixed to build with this change, a new mdb built with this
won't work with older kernels.

-- 
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: r345196 - head/sys/sys

[Gleb Smirnoff]

Author: glebius
Date: Fri Mar 15 18:18:05 2019
New Revision: 345196
URL: https://svnweb.freebsd.org/changeset/base/345196

Log:
  Deanonymize thread and proc state enums, so that a userland app can
  use them without redefining the value names. New clang no longer
  allows to redefine a enum value name to the same value.
  
  Bump __FreeBSD_version, since ports depend on that.
  
  Discussed with:   jhb

Modified:
  head/sys/sys/param.h
  head/sys/sys/proc.h

Modified: head/sys/sys/param.h
==
--- head/sys/sys/param.hFri Mar 15 18:06:51 2019(r345195)
+++ head/sys/sys/param.hFri Mar 15 18:18:05 2019(r345196)
@@ -60,7 +60,7 @@
  * in the range 5 to 9.
  */
 #undef __FreeBSD_version
-#define __FreeBSD_version 1300014  /* Master, propagated to newvers */
+#define __FreeBSD_version 1300015  /* Master, propagated to newvers */
 
 /*
  * __FreeBSD_kernel__ indicates that this system uses the kernel of FreeBSD,

Modified: head/sys/sys/proc.h
==
--- head/sys/sys/proc.h Fri Mar 15 18:06:51 2019(r345195)
+++ head/sys/sys/proc.h Fri Mar 15 18:18:05 2019(r345196)
@@ -326,7 +326,7 @@ struct thread {
  * or already have been set in the allocator, constructor, etc.
  */
struct pcb  *td_pcb;/* (k) Kernel VA of pcb and kstack. */
-   enum {
+   enum td_states {
TDS_INACTIVE = 0x0,
TDS_INHIBITED,
TDS_CAN_RUN,
@@ -573,7 +573,7 @@ struct proc {
 
int p_flag; /* (c) P_* flags. */
int p_flag2;/* (c) P2_* flags. */
-   enum {
+   enum p_states {
PRS_NEW = 0,/* In creation */
PRS_NORMAL, /* threads can be run. */
PRS_ZOMBIE
___
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: r345171 - head/usr.sbin/bhyve

[Warner Losh]

On Fri, Mar 15, 2019 at 11:27 AM Rodney W. Grimes 
wrote:

> > On Fri, Mar 15, 2019 at 9:56 AM Rodney W. Grimes <
> free...@gndrsh.dnsmgr.net>
> > wrote:
> >
> > > > On Thu, Mar 14, 2019 at 8:32 PM Rodney W. Grimes <
> > > free...@gndrsh.dnsmgr.net>
> > > > wrote:
> > > >
> > > > > > Author: chuck
> > > > > > Date: Fri Mar 15 02:11:28 2019
> > > > > > New Revision: 345171
> > > > > > URL: https://svnweb.freebsd.org/changeset/base/345171
> > > > > >
> > > > > > Log:
> > > > > >   Fix bhyve PCIe capability emulation
> > > > > >
> > > > > >   PCIe devices starting with version 1.1 must set the Role-Based
> > > Error
> > > > > >   Reporting bit.
> > > > > >
> > > > > >   And while we're in the neighborhood, generalize the code
> assigning
> > > the
> > > > > >   device type.
> > > > > >
> > > > > >   Reviewed by:imp, araujo, rgrimes
> > > > > >   Approved by:imp (mentor)
> > > > > >   MFC after:  1 week
> > > > > >   Differential Revision: https://reviews.freebsd.org/D19580
> > > > >
> > > > > This code requires maintainer approval before a commit,
> > > > > though this was well reviewed that doesnt exclude it
> > > > > from the MAINTAINERS entry.
> > > > >
> > > > > Leave it for now, I am sure jhb or thyco are fine with it,
> > > > > this is just a heads up FYI for future commits.
> > > > >
> > > > > Bhyve code has been and still is under a fairly tight
> > > > > MAINTAINER status.
> > > > >
> > > >
> > > > There is no such thing as a hard lock in FreeBSD. This sounds like
> you
> > > are
> > > > advocating for that, but that's not the case.
> > > >
> > > > Stop this stupid nitpicking for single line commits. We don't have
> that
> ^^
>
> Thank you for calling my actions stupid, in effect demoralizing me with
> the label that includes.  I may nit pick, but I never call people degrading
> names on a public list.


I said your actions (specifically the nitpicking) were stupid. I never
called you stupid, and don't think you are stupid.

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: r345171 - head/usr.sbin/bhyve

[Marcelo Araujo]

Em sáb, 16 de mar de 2019 às 01:27, Rodney W. Grimes <
free...@gndrsh.dnsmgr.net> escreveu:

> > On Fri, Mar 15, 2019 at 9:56 AM Rodney W. Grimes <
> free...@gndrsh.dnsmgr.net>
> > wrote:
> >
> > > > On Thu, Mar 14, 2019 at 8:32 PM Rodney W. Grimes <
> > > free...@gndrsh.dnsmgr.net>
> > > > wrote:
> > > >
> > > > > > Author: chuck
> > > > > > Date: Fri Mar 15 02:11:28 2019
> > > > > > New Revision: 345171
> > > > > > URL: https://svnweb.freebsd.org/changeset/base/345171
> > > > > >
> > > > > > Log:
> > > > > >   Fix bhyve PCIe capability emulation
> > > > > >
> > > > > >   PCIe devices starting with version 1.1 must set the Role-Based
> > > Error
> > > > > >   Reporting bit.
> > > > > >
> > > > > >   And while we're in the neighborhood, generalize the code
> assigning
> > > the
> > > > > >   device type.
> > > > > >
> > > > > >   Reviewed by:imp, araujo, rgrimes
> > > > > >   Approved by:imp (mentor)
> > > > > >   MFC after:  1 week
> > > > > >   Differential Revision: https://reviews.freebsd.org/D19580
> > > > >
> > > > > This code requires maintainer approval before a commit,
> > > > > though this was well reviewed that doesnt exclude it
> > > > > from the MAINTAINERS entry.
> > > > >
> > > > > Leave it for now, I am sure jhb or thyco are fine with it,
> > > > > this is just a heads up FYI for future commits.
> > > > >
> > > > > Bhyve code has been and still is under a fairly tight
> > > > > MAINTAINER status.
> > > > >
> > > >
> > > > There is no such thing as a hard lock in FreeBSD. This sounds like
> you
> > > are
> > > > advocating for that, but that's not the case.
> > > >
> > > > Stop this stupid nitpicking for single line commits. We don't have
> that
> ^^
>
> Thank you for calling my actions stupid, in effect demoralizing me with
> the label that includes.  I may nit pick, but I never call people degrading
> names on a public list.
>
> Also it only takes a single like to make a bug or problem,
> it would help to not consider single line changes any less or
> any more important or potentially damaging.
>
> > > > culture any more and it's really pissing a lot of people off.
> > > >
> > > > The MAINTAINERS file even says this:
> > > >
> > > > Please note that the content of this file is strictly advisory.
> > > >
> > > > And the entry for bhyve doesn't say things are mandatory, just
> requested.
> > > >
> > > > Jumping on people's case like this, for a review you yourself were
> on and
> > > > approved but made no mention of seeking further review / approval, is
> > > > demotivating and toxic. Please stop.
> > >
> > > I explicitly DID add jhb to the review.
> > > I also explicitly did not mark the bhyve# box that is added by
> > > the hearald rules.
> > >
> > > I did not jump on him, I informed him of the entry, and told him to
> leave
> > > it.
> > > You how ever have infact jumped on me, repeatedly, if you want to talk
> > > about
> > > discouraging tones of behavior I suggest you look at yourself as well.
> > >
> >
> > Weird that so many other people in the thread read it the same way that I
> > did, and not only this time. That suggests that you're not aware that
> your
> > behavior is annoying others, which I contend is a problem that needs
> > looking into.
>
> If you have a pre conceived notion or opinion about anything I say,
> and I contend that many do, you well always hear it in that tone.  This is
> the rose colored glasses problem.  I can not fix that what you hear is
> not what I said.
>
> I speak frankly and without political or other polish to my words,
> which at times do make them sound harsh or overly direct.  I think
> we both actually do that, and, imho, that is better than trying to
> sugar coat stuff and be all polite and indirect about things.
>
> > As always, I'm open to constructive, actionable feedback about my
> actions.
>
> I have tried above.
>
> > Warner
> > > > Warner
> > > > >   head/usr.sbin/bhyve/pci_emul.c
> > > > > >
> > > > > > Modified: head/usr.sbin/bhyve/pci_emul.c
> > > > > >
> > > > >
> > >
> ==
> > > > > > --- head/usr.sbin/bhyve/pci_emul.cFri Mar 15 02:11:27 2019
> > > > > (r345170)
> > > > > > +++ head/usr.sbin/bhyve/pci_emul.cFri Mar 15 02:11:28 2019
> > > > > (r345171)
> > > > > > @@ -953,7 +953,10 @@ pci_emul_add_pciecap(struct pci_devinst
> *pi, int
> > > > > type)
> > > > > >   bzero(, sizeof(pciecap));
> > > > > >
> > > > > >   pciecap.capid = PCIY_EXPRESS;
> > > > > > - pciecap.pcie_capabilities = PCIECAP_VERSION |
> > > PCIEM_TYPE_ROOT_PORT;
> > > > > > + pciecap.pcie_capabilities = PCIECAP_VERSION | type;
> > > > > > + /* Devices starting with version 1.1 must set the RBER bit
> */
> > > > > > + if (PCIECAP_VERSION >= 1)
> > > > > > + pciecap.dev_capabilities = PCIEM_CAP_ROLE_ERR_RPT;
> > > > > >   pciecap.link_capabilities = 0x411;  /* gen1, x1 */
> > > > > >   

Re: svn commit: r345151 - head/sys/net

[Rodney W. Grimes]

> On Fri, Mar 15, 2019 at 12:04 PM Rodney W. Grimes
>  wrote:
> >
> > > On 14 Mar 2019, at 19:48, Kyle Evans wrote:
> > >
> > > > Author: kevans
> > > > Date: Thu Mar 14 19:48:43 2019
> > > > New Revision: 345151
> > > > URL: https://svnweb.freebsd.org/changeset/base/345151
> > > >
> > > > Log:
> > > >   ether_fakeaddr: Use 'b' 's' 'd' for the prefix
> > > >
> > > >   This has the advantage of being obvious to sniff out the designated
> > > > prefix
> > > >   by eye and it has all the right bits set. Comment stolen from ffec.
> > > >
> > > >   I've removed bryanv@'s pending question of using the FreeBSD OUI
> > > > range --
> > > >   no one has followed up on this with a definitive action, and there's
> > > > no
> > > >   particular reason to shoot for it and the administrative overhead
> > > > that comes
> > > >   with deciding exactly how to use it.
> > >
> > > Yay.  iflib_gen_mac() has already thought kind-of similar and just took
> > > the entire(?) FreeBSD space for doing the same.  That code should be
> > > merged as well.
> > >
> > > Bhyve is using a good chunk from the FreeBSD allocation; see
> > > sys/net/ieee_oui.h also for allocation guidelines (if I don?t
> > > misremember).
> > >
> > > The fact that it might need figuring out should not prevent us from
> > > doing it right .. the third time .. maybe .. this time?
> > >
> > > epair(4) is yet another one of the cloned interfaces which does magic
> > > for the ethernet addresses, not sure what else.
> >
> > Yes yes yes please!  Can we get the OUI assigning code collapsed to
> > one place, though it well need to come in dependent on a complex set
> > of options, or perhaps just INET and/or INET6 should drag it in.
> >
> 
> For you and anyone else that wants to participate, I opened up
> https://reviews.freebsd.org/D19587 for this effort last night-ish to
> hash out the details.
> 

Thank you Kyle, I have subscribed and read all the comments so far,
keep moving the state of art forward.  This may take some time on
this one, but it shoud be possible to come to a generally usable
OUI management code.

> Thanks,
> Kyle Evans
-- 
Rod Grimes rgri...@freebsd.org
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r345171 - head/usr.sbin/bhyve

[Rodney W. Grimes]

> On Fri, Mar 15, 2019 at 9:56 AM Rodney W. Grimes 
> wrote:
> 
> > > On Thu, Mar 14, 2019 at 8:32 PM Rodney W. Grimes <
> > free...@gndrsh.dnsmgr.net>
> > > wrote:
> > >
> > > > > Author: chuck
> > > > > Date: Fri Mar 15 02:11:28 2019
> > > > > New Revision: 345171
> > > > > URL: https://svnweb.freebsd.org/changeset/base/345171
> > > > >
> > > > > Log:
> > > > >   Fix bhyve PCIe capability emulation
> > > > >
> > > > >   PCIe devices starting with version 1.1 must set the Role-Based
> > Error
> > > > >   Reporting bit.
> > > > >
> > > > >   And while we're in the neighborhood, generalize the code assigning
> > the
> > > > >   device type.
> > > > >
> > > > >   Reviewed by:imp, araujo, rgrimes
> > > > >   Approved by:imp (mentor)
> > > > >   MFC after:  1 week
> > > > >   Differential Revision: https://reviews.freebsd.org/D19580
> > > >
> > > > This code requires maintainer approval before a commit,
> > > > though this was well reviewed that doesnt exclude it
> > > > from the MAINTAINERS entry.
> > > >
> > > > Leave it for now, I am sure jhb or thyco are fine with it,
> > > > this is just a heads up FYI for future commits.
> > > >
> > > > Bhyve code has been and still is under a fairly tight
> > > > MAINTAINER status.
> > > >
> > >
> > > There is no such thing as a hard lock in FreeBSD. This sounds like you
> > are
> > > advocating for that, but that's not the case.
> > >
> > > Stop this stupid nitpicking for single line commits. We don't have that
^^

Thank you for calling my actions stupid, in effect demoralizing me with
the label that includes.  I may nit pick, but I never call people degrading
names on a public list.

Also it only takes a single like to make a bug or problem,
it would help to not consider single line changes any less or
any more important or potentially damaging.

> > > culture any more and it's really pissing a lot of people off.
> > >
> > > The MAINTAINERS file even says this:
> > >
> > > Please note that the content of this file is strictly advisory.
> > >
> > > And the entry for bhyve doesn't say things are mandatory, just requested.
> > >
> > > Jumping on people's case like this, for a review you yourself were on and
> > > approved but made no mention of seeking further review / approval, is
> > > demotivating and toxic. Please stop.
> >
> > I explicitly DID add jhb to the review.
> > I also explicitly did not mark the bhyve# box that is added by
> > the hearald rules.
> >
> > I did not jump on him, I informed him of the entry, and told him to leave
> > it.
> > You how ever have infact jumped on me, repeatedly, if you want to talk
> > about
> > discouraging tones of behavior I suggest you look at yourself as well.
> >
> 
> Weird that so many other people in the thread read it the same way that I
> did, and not only this time. That suggests that you're not aware that your
> behavior is annoying others, which I contend is a problem that needs
> looking into.

If you have a pre conceived notion or opinion about anything I say,
and I contend that many do, you well always hear it in that tone.  This is
the rose colored glasses problem.  I can not fix that what you hear is
not what I said.

I speak frankly and without political or other polish to my words,
which at times do make them sound harsh or overly direct.  I think
we both actually do that, and, imho, that is better than trying to
sugar coat stuff and be all polite and indirect about things.

> As always, I'm open to constructive, actionable feedback about my actions.

I have tried above.  

> Warner
> > > Warner
> > > >   head/usr.sbin/bhyve/pci_emul.c
> > > > >
> > > > > Modified: head/usr.sbin/bhyve/pci_emul.c
> > > > >
> > > >
> > ==
> > > > > --- head/usr.sbin/bhyve/pci_emul.cFri Mar 15 02:11:27 2019
> > > > (r345170)
> > > > > +++ head/usr.sbin/bhyve/pci_emul.cFri Mar 15 02:11:28 2019
> > > > (r345171)
> > > > > @@ -953,7 +953,10 @@ pci_emul_add_pciecap(struct pci_devinst *pi, int
> > > > type)
> > > > >   bzero(, sizeof(pciecap));
> > > > >
> > > > >   pciecap.capid = PCIY_EXPRESS;
> > > > > - pciecap.pcie_capabilities = PCIECAP_VERSION |
> > PCIEM_TYPE_ROOT_PORT;
> > > > > + pciecap.pcie_capabilities = PCIECAP_VERSION | type;
> > > > > + /* Devices starting with version 1.1 must set the RBER bit */
> > > > > + if (PCIECAP_VERSION >= 1)
> > > > > + pciecap.dev_capabilities = PCIEM_CAP_ROLE_ERR_RPT;
> > > > >   pciecap.link_capabilities = 0x411;  /* gen1, x1 */
> > > > >   pciecap.link_status = 0x11; /* gen1, x1 */
> > > > >
> > > > >
> > > > >
> > > >
> > > > --
> > > > Rod Grimes
> > > > rgri...@freebsd.org
> > > >
> > > >
> >
> > --
> > Rod Grimes
> > rgri...@freebsd.org
> >

-- 
Rod Grimes rgri...@freebsd.org
___
svn-src-all@freebsd.org mailing list

svn commit: r345194 - head/sys/net

[Kyle Evans]

Author: kevans
Date: Fri Mar 15 17:19:36 2019
New Revision: 345194
URL: https://svnweb.freebsd.org/changeset/base/345194

Log:
  if_bridge(4): Drop pointless rtflush
  
  At this point, all routes should've already been dropped by removing all
  members from the bridge. This condition is in-fact KASSERT'd in the line
  immediately above where this nop flush was added.

Modified:
  head/sys/net/if_bridge.c

Modified: head/sys/net/if_bridge.c
==
--- head/sys/net/if_bridge.cFri Mar 15 17:18:19 2019(r345193)
+++ head/sys/net/if_bridge.cFri Mar 15 17:19:36 2019(r345194)
@@ -2890,7 +2890,6 @@ bridge_rtable_fini(struct bridge_softc *sc)
 
KASSERT(sc->sc_brtcnt == 0,
("%s: %d bridge routes referenced", __func__, sc->sc_brtcnt));
-   bridge_rtflush(sc, 1);
free(sc->sc_rthash, M_DEVBUF);
 }
 
___
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: r345193 - head/sys/net

[Kyle Evans]

Author: kevans
Date: Fri Mar 15 17:18:19 2019
New Revision: 345193
URL: https://svnweb.freebsd.org/changeset/base/345193

Log:
  Revert r345192: Too many trees in play for bridge(4) bits
  
  An accidental appendage was committed that has not undergone review yet.

Modified:
  head/sys/net/if_bridge.c

Modified: head/sys/net/if_bridge.c
==
--- head/sys/net/if_bridge.cFri Mar 15 17:13:05 2019(r345192)
+++ head/sys/net/if_bridge.cFri Mar 15 17:18:19 2019(r345193)
@@ -2449,22 +2449,6 @@ bridge_input(struct ifnet *ifp, struct mbuf *m)
}   \
m->m_pkthdr.rcvif = iface;  \
BRIDGE_UNLOCK(sc);  \
-   /*  \
-* These mbufs will not have another chance to get sent \
-* to bpf elsewhere in the stack as being received  \
-* by this interface, because they are coming in over   \
-* the bridge.  They likely have been accounted for \
-* when received by the interface that they came from,  \
-* but this is not enough for other consumers,  \
-* e.g. dhclient, to be satisfied.  \
-*  \
-* rcvif needs to be set on the mbuf here, lest we risk \
-* losing the mbuf as a "duplicate" because it's\
-* considered outgoing by bpf.  \
-*/ \
-   if ((iface)->if_type != IFT_BRIDGE &&   \
-   (iface)->if_bpf != NULL && (iface) != (ifp)) \
-   ETHER_BPF_MTAP(iface, m);   \
return (m); \
}   \
\
@@ -2906,6 +2890,7 @@ bridge_rtable_fini(struct bridge_softc *sc)
 
KASSERT(sc->sc_brtcnt == 0,
("%s: %d bridge routes referenced", __func__, sc->sc_brtcnt));
+   bridge_rtflush(sc, 1);
free(sc->sc_rthash, M_DEVBUF);
 }
 
___
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: r345192 - head/sys/net

[Kyle Evans]

On Fri, Mar 15, 2019 at 12:14 PM Kristof Provost  wrote:
>
> On 2019-03-15 17:13:05 (+), Kyle Evans  wrote:
> > Author: kevans
> > Date: Fri Mar 15 17:13:05 2019
> > New Revision: 345192
> > URL: https://svnweb.freebsd.org/changeset/base/345192
> >
> > Log:
> >   if_bridge(4): Drop pointless rtflush
> >
> >   At this point, all routes should've already been dropped by removing all
> >   members from the bridge. This condition is in-fact KASSERT'd in the line
> >   immediately above where this nop flush was added.
> >
> > Modified:
> >   head/sys/net/if_bridge.c
> >
> > Modified: head/sys/net/if_bridge.c
> > ==
> > --- head/sys/net/if_bridge.c  Fri Mar 15 17:04:33 2019(r345191)
> > +++ head/sys/net/if_bridge.c  Fri Mar 15 17:13:05 2019(r345192)
> > @@ -2449,6 +2449,22 @@ bridge_input(struct ifnet *ifp, struct mbuf *m)
> >   }   \
> >   m->m_pkthdr.rcvif = iface;  \
> >   BRIDGE_UNLOCK(sc);  \
> > + /*  \
> > +  * These mbufs will not have another chance to get sent \
> > +  * to bpf elsewhere in the stack as being received  \
> > +  * by this interface, because they are coming in over   \
> > +  * the bridge.  They likely have been accounted for \
> > +  * when received by the interface that they came from,  \
> > +  * but this is not enough for other consumers,  \
> > +  * e.g. dhclient, to be satisfied.  \
> > +  *  \
> > +  * rcvif needs to be set on the mbuf here, lest we risk \
> > +  * losing the mbuf as a "duplicate" because it's\
> > +  * considered outgoing by bpf.  \
> > +  */ \
> > + if ((iface)->if_type != IFT_BRIDGE &&   \
> > + (iface)->if_bpf != NULL && (iface) != (ifp)) \
> > + ETHER_BPF_MTAP(iface, m);   \
>
> I think you didn't intend to commit this yet.
>

*sigh* wrong tree. =(
___
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: r345192 - head/sys/net

[Kristof Provost]

On 2019-03-15 17:13:05 (+), Kyle Evans  wrote:
> Author: kevans
> Date: Fri Mar 15 17:13:05 2019
> New Revision: 345192
> URL: https://svnweb.freebsd.org/changeset/base/345192
> 
> Log:
>   if_bridge(4): Drop pointless rtflush
>   
>   At this point, all routes should've already been dropped by removing all
>   members from the bridge. This condition is in-fact KASSERT'd in the line
>   immediately above where this nop flush was added.
> 
> Modified:
>   head/sys/net/if_bridge.c
> 
> Modified: head/sys/net/if_bridge.c
> ==
> --- head/sys/net/if_bridge.c  Fri Mar 15 17:04:33 2019(r345191)
> +++ head/sys/net/if_bridge.c  Fri Mar 15 17:13:05 2019(r345192)
> @@ -2449,6 +2449,22 @@ bridge_input(struct ifnet *ifp, struct mbuf *m)
>   }   \
>   m->m_pkthdr.rcvif = iface;  \
>   BRIDGE_UNLOCK(sc);  \
> + /*  \
> +  * These mbufs will not have another chance to get sent \
> +  * to bpf elsewhere in the stack as being received  \
> +  * by this interface, because they are coming in over   \
> +  * the bridge.  They likely have been accounted for \
> +  * when received by the interface that they came from,  \
> +  * but this is not enough for other consumers,  \
> +  * e.g. dhclient, to be satisfied.  \
> +  *  \
> +  * rcvif needs to be set on the mbuf here, lest we risk \
> +  * losing the mbuf as a "duplicate" because it's\
> +  * considered outgoing by bpf.  \
> +  */ \
> + if ((iface)->if_type != IFT_BRIDGE &&   \
> + (iface)->if_bpf != NULL && (iface) != (ifp)) \
> + ETHER_BPF_MTAP(iface, m);   \

I think you didn't intend to commit this yet.

Regards,
Kristof
___
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: r345192 - head/sys/net

[Kyle Evans]

Author: kevans
Date: Fri Mar 15 17:13:05 2019
New Revision: 345192
URL: https://svnweb.freebsd.org/changeset/base/345192

Log:
  if_bridge(4): Drop pointless rtflush
  
  At this point, all routes should've already been dropped by removing all
  members from the bridge. This condition is in-fact KASSERT'd in the line
  immediately above where this nop flush was added.

Modified:
  head/sys/net/if_bridge.c

Modified: head/sys/net/if_bridge.c
==
--- head/sys/net/if_bridge.cFri Mar 15 17:04:33 2019(r345191)
+++ head/sys/net/if_bridge.cFri Mar 15 17:13:05 2019(r345192)
@@ -2449,6 +2449,22 @@ bridge_input(struct ifnet *ifp, struct mbuf *m)
}   \
m->m_pkthdr.rcvif = iface;  \
BRIDGE_UNLOCK(sc);  \
+   /*  \
+* These mbufs will not have another chance to get sent \
+* to bpf elsewhere in the stack as being received  \
+* by this interface, because they are coming in over   \
+* the bridge.  They likely have been accounted for \
+* when received by the interface that they came from,  \
+* but this is not enough for other consumers,  \
+* e.g. dhclient, to be satisfied.  \
+*  \
+* rcvif needs to be set on the mbuf here, lest we risk \
+* losing the mbuf as a "duplicate" because it's\
+* considered outgoing by bpf.  \
+*/ \
+   if ((iface)->if_type != IFT_BRIDGE &&   \
+   (iface)->if_bpf != NULL && (iface) != (ifp)) \
+   ETHER_BPF_MTAP(iface, m);   \
return (m); \
}   \
\
@@ -2890,7 +2906,6 @@ bridge_rtable_fini(struct bridge_softc *sc)
 
KASSERT(sc->sc_brtcnt == 0,
("%s: %d bridge routes referenced", __func__, sc->sc_brtcnt));
-   bridge_rtflush(sc, 1);
free(sc->sc_rthash, M_DEVBUF);
 }
 
___
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: r345151 - head/sys/net

[Kyle Evans]

On Fri, Mar 15, 2019 at 12:04 PM Rodney W. Grimes
 wrote:
>
> > On 14 Mar 2019, at 19:48, Kyle Evans wrote:
> >
> > > Author: kevans
> > > Date: Thu Mar 14 19:48:43 2019
> > > New Revision: 345151
> > > URL: https://svnweb.freebsd.org/changeset/base/345151
> > >
> > > Log:
> > >   ether_fakeaddr: Use 'b' 's' 'd' for the prefix
> > >
> > >   This has the advantage of being obvious to sniff out the designated
> > > prefix
> > >   by eye and it has all the right bits set. Comment stolen from ffec.
> > >
> > >   I've removed bryanv@'s pending question of using the FreeBSD OUI
> > > range --
> > >   no one has followed up on this with a definitive action, and there's
> > > no
> > >   particular reason to shoot for it and the administrative overhead
> > > that comes
> > >   with deciding exactly how to use it.
> >
> > Yay.  iflib_gen_mac() has already thought kind-of similar and just took
> > the entire(?) FreeBSD space for doing the same.  That code should be
> > merged as well.
> >
> > Bhyve is using a good chunk from the FreeBSD allocation; see
> > sys/net/ieee_oui.h also for allocation guidelines (if I don?t
> > misremember).
> >
> > The fact that it might need figuring out should not prevent us from
> > doing it right .. the third time .. maybe .. this time?
> >
> > epair(4) is yet another one of the cloned interfaces which does magic
> > for the ethernet addresses, not sure what else.
>
> Yes yes yes please!  Can we get the OUI assigning code collapsed to
> one place, though it well need to come in dependent on a complex set
> of options, or perhaps just INET and/or INET6 should drag it in.
>

For you and anyone else that wants to participate, I opened up
https://reviews.freebsd.org/D19587 for this effort last night-ish to
hash out the details.

Thanks,

Kyle Evans
___
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: r345171 - head/usr.sbin/bhyve

[Warner Losh]

On Fri, Mar 15, 2019 at 9:56 AM Rodney W. Grimes 
wrote:

> > On Thu, Mar 14, 2019 at 8:32 PM Rodney W. Grimes <
> free...@gndrsh.dnsmgr.net>
> > wrote:
> >
> > > > Author: chuck
> > > > Date: Fri Mar 15 02:11:28 2019
> > > > New Revision: 345171
> > > > URL: https://svnweb.freebsd.org/changeset/base/345171
> > > >
> > > > Log:
> > > >   Fix bhyve PCIe capability emulation
> > > >
> > > >   PCIe devices starting with version 1.1 must set the Role-Based
> Error
> > > >   Reporting bit.
> > > >
> > > >   And while we're in the neighborhood, generalize the code assigning
> the
> > > >   device type.
> > > >
> > > >   Reviewed by:imp, araujo, rgrimes
> > > >   Approved by:imp (mentor)
> > > >   MFC after:  1 week
> > > >   Differential Revision: https://reviews.freebsd.org/D19580
> > >
> > > This code requires maintainer approval before a commit,
> > > though this was well reviewed that doesnt exclude it
> > > from the MAINTAINERS entry.
> > >
> > > Leave it for now, I am sure jhb or thyco are fine with it,
> > > this is just a heads up FYI for future commits.
> > >
> > > Bhyve code has been and still is under a fairly tight
> > > MAINTAINER status.
> > >
> >
> > There is no such thing as a hard lock in FreeBSD. This sounds like you
> are
> > advocating for that, but that's not the case.
> >
> > Stop this stupid nitpicking for single line commits. We don't have that
> > culture any more and it's really pissing a lot of people off.
> >
> > The MAINTAINERS file even says this:
> >
> > Please note that the content of this file is strictly advisory.
> >
> > And the entry for bhyve doesn't say things are mandatory, just requested.
> >
> > Jumping on people's case like this, for a review you yourself were on and
> > approved but made no mention of seeking further review / approval, is
> > demotivating and toxic. Please stop.
>
> I explicitly DID add jhb to the review.
> I also explicitly did not mark the bhyve# box that is added by
> the hearald rules.
>
> I did not jump on him, I informed him of the entry, and told him to leave
> it.
> You how ever have infact jumped on me, repeatedly, if you want to talk
> about
> discouraging tones of behavior I suggest you look at yourself as well.
>

Weird that so many other people in the thread read it the same way that I
did, and not only this time. That suggests that you're not aware that your
behavior is annoying others, which I contend is a problem that needs
looking into.

As always, I'm open to constructive, actionable feedback about my actions.

Warner


> > Warner
> >
> > >   head/usr.sbin/bhyve/pci_emul.c
> > > >
> > > > Modified: head/usr.sbin/bhyve/pci_emul.c
> > > >
> > >
> ==
> > > > --- head/usr.sbin/bhyve/pci_emul.cFri Mar 15 02:11:27 2019
> > > (r345170)
> > > > +++ head/usr.sbin/bhyve/pci_emul.cFri Mar 15 02:11:28 2019
> > > (r345171)
> > > > @@ -953,7 +953,10 @@ pci_emul_add_pciecap(struct pci_devinst *pi, int
> > > type)
> > > >   bzero(, sizeof(pciecap));
> > > >
> > > >   pciecap.capid = PCIY_EXPRESS;
> > > > - pciecap.pcie_capabilities = PCIECAP_VERSION |
> PCIEM_TYPE_ROOT_PORT;
> > > > + pciecap.pcie_capabilities = PCIECAP_VERSION | type;
> > > > + /* Devices starting with version 1.1 must set the RBER bit */
> > > > + if (PCIECAP_VERSION >= 1)
> > > > + pciecap.dev_capabilities = PCIEM_CAP_ROLE_ERR_RPT;
> > > >   pciecap.link_capabilities = 0x411;  /* gen1, x1 */
> > > >   pciecap.link_status = 0x11; /* gen1, x1 */
> > > >
> > > >
> > > >
> > >
> > > --
> > > Rod Grimes
> > > rgri...@freebsd.org
> > >
> > >
>
> --
> Rod Grimes
> rgri...@freebsd.org
>
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r345151 - head/sys/net

[Rodney W. Grimes]

> On 14 Mar 2019, at 19:48, Kyle Evans wrote:
> 
> > Author: kevans
> > Date: Thu Mar 14 19:48:43 2019
> > New Revision: 345151
> > URL: https://svnweb.freebsd.org/changeset/base/345151
> >
> > Log:
> >   ether_fakeaddr: Use 'b' 's' 'd' for the prefix
> >
> >   This has the advantage of being obvious to sniff out the designated 
> > prefix
> >   by eye and it has all the right bits set. Comment stolen from ffec.
> >
> >   I've removed bryanv@'s pending question of using the FreeBSD OUI 
> > range --
> >   no one has followed up on this with a definitive action, and there's 
> > no
> >   particular reason to shoot for it and the administrative overhead 
> > that comes
> >   with deciding exactly how to use it.
> 
> Yay.  iflib_gen_mac() has already thought kind-of similar and just took 
> the entire(?) FreeBSD space for doing the same.  That code should be 
> merged as well.
> 
> Bhyve is using a good chunk from the FreeBSD allocation; see 
> sys/net/ieee_oui.h also for allocation guidelines (if I don?t 
> misremember).
> 
> The fact that it might need figuring out should not prevent us from 
> doing it right .. the third time .. maybe .. this time?
> 
> epair(4) is yet another one of the cloned interfaces which does magic 
> for the ethernet addresses, not sure what else.

Yes yes yes please!  Can we get the OUI assigning code collapsed to
one place, though it well need to come in dependent on a complex set
of options, or perhaps just INET and/or INET6 should drag it in.

Thanks to anyone that does this work!
> /bz
-- 
Rod Grimes rgri...@freebsd.org
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r345138 - head/share/man/man9

[Rodney W. Grimes]

> 
> In message <201903150152.x2f1q34w027...@gndrsh.dnsmgr.net>, "Rodney W. 
> Grimes" 
> writes:
> 
> >> The first versions of CTM used diff -e and ed(1) to transmit changes,
> >> and that choked up on binary files.  We didn't have patch in the
> >> tree back then.
> 
> >patch has always been in the tree.
> >https://github.com/sergev/4.4BSD-Lite2/tree/master/usr/src/usr.bin/patch
> 
> Yes, in *that* tree, but it was not always in *our* tree, particularly
> not in the strange time between 1.1.5.1 and 2.0.

I would have to go find the 4.4BSD-Lite2_import.sh script, but I
would of either imported the one from 4.4, or I would of imported
the gnu one into gnu/.

> Trust me: if it had been, I would not have used diff-e+ed(1)

It would of been pretty impossible to live without patch
at that time so I doubt very much that the respository
had it missing for more than a day or three, there was
the time period from the import of 4.4 to the completion
of the 2.0 ncvs repository, though that was only days, the
there was the lag while we waited for Greenman/Dyson to
fix the missing bits and to get make world running again,
but after that we would of had the same patch we had in
1.x as that is external code and uneffected by the lawsuit.

> Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
> p...@freebsd.org | TCP/IP since RFC 956
-- 
Rod Grimes rgri...@freebsd.org
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

svn commit: r345190 - in head/sys: amd64/amd64 i386/i386

[Konstantin Belousov]

Author: kib
Date: Fri Mar 15 16:43:28 2019
New Revision: 345190
URL: https://svnweb.freebsd.org/changeset/base/345190

Log:
  Provide deterministic (and somewhat useful) value for RDPID result,
  and for %ecx after RDTSCP.
  
  Initialize TSC_AUX MSR with CPUID.  It allows for userspace to cheaply
  identify CPU it was executed on some time ago, which is sometimes useful.
  
  Note: The values returned might be changed in future.
  
  Sponsored by: The FreeBSD Foundation
  MFC after:1 week

Modified:
  head/sys/amd64/amd64/initcpu.c
  head/sys/i386/i386/initcpu.c

Modified: head/sys/amd64/amd64/initcpu.c
==
--- head/sys/amd64/amd64/initcpu.c  Fri Mar 15 16:39:05 2019
(r345189)
+++ head/sys/amd64/amd64/initcpu.c  Fri Mar 15 16:43:28 2019
(r345190)
@@ -265,6 +265,10 @@ initializecpu(void)
init_via();
break;
}
+
+   if ((amd_feature & AMDID_RDTSCP) != 0 ||
+   (cpu_stdext_feature2 & CPUID_STDEXT2_RDPID) != 0)
+   wrmsr(MSR_TSC_AUX, PCPU_GET(cpuid));
 }
 
 void

Modified: head/sys/i386/i386/initcpu.c
==
--- head/sys/i386/i386/initcpu.cFri Mar 15 16:39:05 2019
(r345189)
+++ head/sys/i386/i386/initcpu.cFri Mar 15 16:43:28 2019
(r345190)
@@ -749,6 +749,9 @@ initializecpu(void)
msr = rdmsr(MSR_EFER) | EFER_NXE;
wrmsr(MSR_EFER, msr);
}
+   if ((amd_feature & AMDID_RDTSCP) != 0 ||
+   (cpu_stdext_feature2 & CPUID_STDEXT2_RDPID) != 0)
+   wrmsr(MSR_TSC_AUX, PCPU_GET(cpuid));
 }
 
 void
___
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: r345171 - head/usr.sbin/bhyve

[Rodney W. Grimes]

> Em s?b, 16 de mar de 2019 ?s 00:03, Rodney W. Grimes <
> free...@gndrsh.dnsmgr.net> escreveu:
> 
> > > Em sex, 15 de mar de 2019 ?s 22:12, Ian Lepore 
> > escreveu:
> > >
> > > > On Thu, 2019-03-14 at 19:31 -0700, Rodney W. Grimes wrote:
> > > > > > Author: chuck
> > > > > > Date: Fri Mar 15 02:11:28 2019
> > > > > > New Revision: 345171
> > > > > > URL: https://svnweb.freebsd.org/changeset/base/345171
> > > > > >
> > > > > > Log:
> > > > > >   Fix bhyve PCIe capability emulation
> > > > > >
> > > > > >   PCIe devices starting with version 1.1 must set the Role-Based
> > > > > > Error
> > > > > >   Reporting bit.
> > > > > >
> > > > > >   And while we're in the neighborhood, generalize the code
> > > > > > assigning the
> > > > > >   device type.
> > > > > >
> > > > > >   Reviewed by:  imp, araujo, rgrimes
> > > > > >   Approved by:  imp (mentor)
> > > > > >   MFC after:1 week
> > > > > >   Differential Revision: https://reviews.freebsd.org/D19580
> > > > >
> > > > > This code requires maintainer approval before a commit,
> > > > > though this was well reviewed that doesnt exclude it
> > > > > from the MAINTAINERS entry.
> > > > >
> > > >
> > > > Where exactly does it say that in MAINTAINERS?  As another victim of
> > > > this sort of drive-by lynching after making a trivial bhyve change I
> > > > pretty seriously object to a vague and meaningless entry in MAINTAINERS
> > > > being used to pounce on anyone who dares to touch the precious bhyve
> > > > code.
> > > >
> > >
> > > There is a new entry on MAINTAINERS:
> > > https://svnweb.freebsd.org/base?view=revision=344631
> > >
> > >
> > > >
> > > > There is no mention of bhyve in MAINTAINERS, for usr.sbin or elsewhere.
> > > > There is an entry for vmm(4), which to me does not say anything about
> > > > bhyve, yet somehow everybody is supposed to know what it means and
> > > > what-all territory it covers?
> > > >
> > > > IMO, this sort of hyper-proprietary pouncing on everyone who dares
> > > > change a single line of code is not productive.  It is HIGHLY de-
> > > > motivating.  Large sweeping design changes are one thing, but pouncing
> > > > on every tiny minor commit is just not helpful.
> > > >
> > >
> > > +1
> > >
> > > I got so frustrated with it recently that I have decided to don't
> > > contribute with bhyve anymore, perhaps even with FreeBSD.
> > > I still have some people under mentorship that I intend to finish and
> > then
> > > probably I will phase out.
> >
> > Your failure to get reviews, and infact even abandon one that had
> > negative advice as to the validity of your suggested change and
> > committing it anyway is more likely the cause here.
> >
> > You also committed code with no review at all that had to be reverted
> > after the bugs it caused were found by an external down stream consumers
> > of the bhyve code.
> >
> > You had code reverted by core due to a external attribution request,
> > which had you been attending the bi monthly bhyve calls you would of
> > known was an issue.
> >
> > I would suggest these are the reasons your feeling angry, and that
> > I infact tried to reach out to jhb to discuss some of these earlier
> > but that reach out was never returned.  I under stand your frustration,
> > you are just wanting to do with best thing you can for the project
> > and bhyve, can we try to find a better resolution to this situation
> > than your exit?
> >
> 
> 
> 
> 
> >
> > > > -- Ian
> > > >
> > > > > Leave it for now, I am sure jhb or thyco are fine with it,
> > > > > this is just a heads up FYI for future commits.
> > > > >
> > > > > Bhyve code has been and still is under a fairly tight
> > > > > MAINTAINER status.
> > > > >
> > > > > > Modified:
> > > > > >   head/usr.sbin/bhyve/pci_emul.c
> > > > > >
> > > > > > Modified: head/usr.sbin/bhyve/pci_emul.c
> > > > > > ===
> > > > > > ===
> > > > > > --- head/usr.sbin/bhyve/pci_emul.c  Fri Mar 15 02:11:27 2019
> >   (r3
> > > > > > 45170)
> > > > > > +++ head/usr.sbin/bhyve/pci_emul.c  Fri Mar 15 02:11:28 2019
> >   (r3
> > > > > > 45171)
> > > > > > @@ -953,7 +953,10 @@ pci_emul_add_pciecap(struct pci_devinst *pi,
> > > > > > int type)
> > > > > > bzero(, sizeof(pciecap));
> > > > > >
> > > > > > pciecap.capid = PCIY_EXPRESS;
> > > > > > -   pciecap.pcie_capabilities = PCIECAP_VERSION |
> > > > > > PCIEM_TYPE_ROOT_PORT;
> > > > > > +   pciecap.pcie_capabilities = PCIECAP_VERSION | type;
> > > > > > +   /* Devices starting with version 1.1 must set the RBER bit */
> > > > > > +   if (PCIECAP_VERSION >= 1)
> > > > > > +   pciecap.dev_capabilities = PCIEM_CAP_ROLE_ERR_RPT;
> > > > > > pciecap.link_capabilities = 0x411;  /* gen1, x1 */
> > > > > > pciecap.link_status = 0x11; /* gen1, x1 */
> > > > > >
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > >
> > > >
> > > >
> > >
> > > --
> > >
> > > --
> > > Marcelo Araujo

svn commit: r345189 - head/sys/x86/include

[Konstantin Belousov]

Author: kib
Date: Fri Mar 15 16:39:05 2019
New Revision: 345189
URL: https://svnweb.freebsd.org/changeset/base/345189

Log:
  Add symbolic name for TSC_AUX MSR address.
  
  Sponsored by: The FreeBSD Foundation
  MFC after:3 days

Modified:
  head/sys/x86/include/specialreg.h

Modified: head/sys/x86/include/specialreg.h
==
--- head/sys/x86/include/specialreg.h   Fri Mar 15 16:16:50 2019
(r345188)
+++ head/sys/x86/include/specialreg.h   Fri Mar 15 16:39:05 2019
(r345189)
@@ -1044,6 +1044,7 @@
 #defineMSR_FSBASE  0xc100  /* base address of the %fs 
"segment" */
 #defineMSR_GSBASE  0xc101  /* base address of the %gs 
"segment" */
 #defineMSR_KGSBASE 0xc102  /* base address of the kernel 
%gs */
+#defineMSR_TSC_AUX 0xc103
 #defineMSR_PERFEVSEL0  0xc001
 #defineMSR_PERFEVSEL1  0xc0010001
 #defineMSR_PERFEVSEL2  0xc0010002
___
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: r345171 - head/usr.sbin/bhyve

[John Baldwin]

On 3/15/19 9:27 AM, John Baldwin wrote:
> On 3/14/19 10:24 PM, Conrad Meyer wrote:
>> On Thu, Mar 14, 2019 at 8:06 PM Andrew Thompson  wrote:
>>>
>>> On Fri, 15 Mar 2019 at 15:11, Chuck Tuffli  wrote:
 bzero(, sizeof(pciecap));
>> ...
 +   pciecap.dev_capabilities = PCIEM_CAP_ROLE_ERR_RPT;
>>>
>>> If the message you say 'set the bit' but you are overwriting the whole 
>>> variable, is this intended?
>>
>> Looks like it was zero before.  So yeah, it sets the bit.
> 
> It would probably be cleaner for future changes to make it a |=, but that's a
> tiny nit.  style(9) wants a blank line before the comment as well.
> 
> I hadn't approved it yet only because I hadn't gone and dug through my PCIe
> books / specs to see what this bit is and confirm it is required.
> 
> OTOH, it's not clear to me that bhyve PCI-e devices don't want to just be 1.0a
> devices as a lowest common denominator to be as accommodating to as wide 
> variety
> of OS's as possible.
> 
> One thing I didn't see in a review was a reason for why to make this change?
> Does some OS reject devices without this bit set or is it just based on 
> reading
> the spec?  bhyve doesn't assert any PCI-e errors for virtual devices, so
> this bit is pretty meaningless.

On the topic of a hard lock, the intention of "Review requested" is not to
enforce a hard lock, but to request a heads up so that work can be coordinated.
I think committing this was ok given other people ok'd the change, though I
think I still I want some answers as to the "why" this is needed to think about
if we actually want the change or not.

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

Re: svn commit: r345171 - head/usr.sbin/bhyve

[John Baldwin]

On 3/14/19 10:24 PM, Conrad Meyer wrote:
> On Thu, Mar 14, 2019 at 8:06 PM Andrew Thompson  wrote:
>>
>> On Fri, 15 Mar 2019 at 15:11, Chuck Tuffli  wrote:
>>> bzero(, sizeof(pciecap));
> ...
>>> +   pciecap.dev_capabilities = PCIEM_CAP_ROLE_ERR_RPT;
>>
>> If the message you say 'set the bit' but you are overwriting the whole 
>> variable, is this intended?
> 
> Looks like it was zero before.  So yeah, it sets the bit.

It would probably be cleaner for future changes to make it a |=, but that's a
tiny nit.  style(9) wants a blank line before the comment as well.

I hadn't approved it yet only because I hadn't gone and dug through my PCIe
books / specs to see what this bit is and confirm it is required.

OTOH, it's not clear to me that bhyve PCI-e devices don't want to just be 1.0a
devices as a lowest common denominator to be as accommodating to as wide variety
of OS's as possible.

One thing I didn't see in a review was a reason for why to make this change?
Does some OS reject devices without this bit set or is it just based on reading
the spec?  bhyve doesn't assert any PCI-e errors for virtual devices, so
this bit is pretty meaningless.

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

Re: svn commit: r345171 - head/usr.sbin/bhyve

[Marcelo Araujo]

Em sáb, 16 de mar de 2019 às 00:03, Rodney W. Grimes <
free...@gndrsh.dnsmgr.net> escreveu:

> > Em sex, 15 de mar de 2019 ?s 22:12, Ian Lepore 
> escreveu:
> >
> > > On Thu, 2019-03-14 at 19:31 -0700, Rodney W. Grimes wrote:
> > > > > Author: chuck
> > > > > Date: Fri Mar 15 02:11:28 2019
> > > > > New Revision: 345171
> > > > > URL: https://svnweb.freebsd.org/changeset/base/345171
> > > > >
> > > > > Log:
> > > > >   Fix bhyve PCIe capability emulation
> > > > >
> > > > >   PCIe devices starting with version 1.1 must set the Role-Based
> > > > > Error
> > > > >   Reporting bit.
> > > > >
> > > > >   And while we're in the neighborhood, generalize the code
> > > > > assigning the
> > > > >   device type.
> > > > >
> > > > >   Reviewed by:  imp, araujo, rgrimes
> > > > >   Approved by:  imp (mentor)
> > > > >   MFC after:1 week
> > > > >   Differential Revision: https://reviews.freebsd.org/D19580
> > > >
> > > > This code requires maintainer approval before a commit,
> > > > though this was well reviewed that doesnt exclude it
> > > > from the MAINTAINERS entry.
> > > >
> > >
> > > Where exactly does it say that in MAINTAINERS?  As another victim of
> > > this sort of drive-by lynching after making a trivial bhyve change I
> > > pretty seriously object to a vague and meaningless entry in MAINTAINERS
> > > being used to pounce on anyone who dares to touch the precious bhyve
> > > code.
> > >
> >
> > There is a new entry on MAINTAINERS:
> > https://svnweb.freebsd.org/base?view=revision=344631
> >
> >
> > >
> > > There is no mention of bhyve in MAINTAINERS, for usr.sbin or elsewhere.
> > > There is an entry for vmm(4), which to me does not say anything about
> > > bhyve, yet somehow everybody is supposed to know what it means and
> > > what-all territory it covers?
> > >
> > > IMO, this sort of hyper-proprietary pouncing on everyone who dares
> > > change a single line of code is not productive.  It is HIGHLY de-
> > > motivating.  Large sweeping design changes are one thing, but pouncing
> > > on every tiny minor commit is just not helpful.
> > >
> >
> > +1
> >
> > I got so frustrated with it recently that I have decided to don't
> > contribute with bhyve anymore, perhaps even with FreeBSD.
> > I still have some people under mentorship that I intend to finish and
> then
> > probably I will phase out.
>
> Your failure to get reviews, and infact even abandon one that had
> negative advice as to the validity of your suggested change and
> committing it anyway is more likely the cause here.
>
> You also committed code with no review at all that had to be reverted
> after the bugs it caused were found by an external down stream consumers
> of the bhyve code.
>
> You had code reverted by core due to a external attribution request,
> which had you been attending the bi monthly bhyve calls you would of
> known was an issue.
>
> I would suggest these are the reasons your feeling angry, and that
> I infact tried to reach out to jhb to discuss some of these earlier
> but that reach out was never returned.  I under stand your frustration,
> you are just wanting to do with best thing you can for the project
> and bhyve, can we try to find a better resolution to this situation
> than your exit?
>




>
> > > -- Ian
> > >
> > > > Leave it for now, I am sure jhb or thyco are fine with it,
> > > > this is just a heads up FYI for future commits.
> > > >
> > > > Bhyve code has been and still is under a fairly tight
> > > > MAINTAINER status.
> > > >
> > > > > Modified:
> > > > >   head/usr.sbin/bhyve/pci_emul.c
> > > > >
> > > > > Modified: head/usr.sbin/bhyve/pci_emul.c
> > > > > ===
> > > > > ===
> > > > > --- head/usr.sbin/bhyve/pci_emul.c  Fri Mar 15 02:11:27 2019
>   (r3
> > > > > 45170)
> > > > > +++ head/usr.sbin/bhyve/pci_emul.c  Fri Mar 15 02:11:28 2019
>   (r3
> > > > > 45171)
> > > > > @@ -953,7 +953,10 @@ pci_emul_add_pciecap(struct pci_devinst *pi,
> > > > > int type)
> > > > > bzero(, sizeof(pciecap));
> > > > >
> > > > > pciecap.capid = PCIY_EXPRESS;
> > > > > -   pciecap.pcie_capabilities = PCIECAP_VERSION |
> > > > > PCIEM_TYPE_ROOT_PORT;
> > > > > +   pciecap.pcie_capabilities = PCIECAP_VERSION | type;
> > > > > +   /* Devices starting with version 1.1 must set the RBER bit */
> > > > > +   if (PCIECAP_VERSION >= 1)
> > > > > +   pciecap.dev_capabilities = PCIEM_CAP_ROLE_ERR_RPT;
> > > > > pciecap.link_capabilities = 0x411;  /* gen1, x1 */
> > > > > pciecap.link_status = 0x11; /* gen1, x1 */
> > > > >
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> > >
> >
> > --
> >
> > --
> > Marcelo Araujo(__)ara...@freebsd.org
> > \\\'',)http://www.FreeBSD.org    \/  \ ^
> > Power To Server. .\. /_)
>
> --
> Rod Grimes
> rgri...@freebsd.org
>

Sorry Rod, I don't want to be rude, but even though I'm not a native
English speaker, it hurts my eyes 

Re: svn commit: r345171 - head/usr.sbin/bhyve

[Pedro Giffuni]

On 15/03/2019 11:03, Rodney W. Grimes wrote:

Em sex, 15 de mar de 2019 ?s 22:12, Ian Lepore  escreveu:


On Thu, 2019-03-14 at 19:31 -0700, Rodney W. Grimes wrote:

Author: chuck
Date: Fri Mar 15 02:11:28 2019
New Revision: 345171
URL: https://svnweb.freebsd.org/changeset/base/345171

Log:
   Fix bhyve PCIe capability emulation

   PCIe devices starting with version 1.1 must set the Role-Based
Error
   Reporting bit.

   And while we're in the neighborhood, generalize the code
assigning the
   device type.

   Reviewed by:  imp, araujo, rgrimes
   Approved by:  imp (mentor)
   MFC after:1 week
   Differential Revision: https://reviews.freebsd.org/D19580

This code requires maintainer approval before a commit,
though this was well reviewed that doesnt exclude it
from the MAINTAINERS entry.


Where exactly does it say that in MAINTAINERS?  As another victim of
this sort of drive-by lynching after making a trivial bhyve change I
pretty seriously object to a vague and meaningless entry in MAINTAINERS
being used to pounce on anyone who dares to touch the precious bhyve
code.


There is a new entry on MAINTAINERS:
https://svnweb.freebsd.org/base?view=revision=344631



There is no mention of bhyve in MAINTAINERS, for usr.sbin or elsewhere.
There is an entry for vmm(4), which to me does not say anything about
bhyve, yet somehow everybody is supposed to know what it means and
what-all territory it covers?

IMO, this sort of hyper-proprietary pouncing on everyone who dares
change a single line of code is not productive.  It is HIGHLY de-
motivating.  Large sweeping design changes are one thing, but pouncing
on every tiny minor commit is just not helpful.


+1

I got so frustrated with it recently that I have decided to don't
contribute with bhyve anymore, perhaps even with FreeBSD.
I still have some people under mentorship that I intend to finish and then
probably I will phase out.

Your failure to get reviews, and infact even abandon one that had
negative advice as to the validity of your suggested change and
committing it anyway is more likely the cause here.


I will have to add  to the choir here: getting reviews is not mandatory 
and I hope they will never be.


Reviewed code is likely to have less errors but sometimes we just need 
to get things done.


Look, for example, the case of the automounting daemon amd(8), which we 
have been planning to remove for some years: your unfortunate 
intervention stopped it from getting removed from the system for how 
many months(?) stopping progress there altogether.


Pedro.





You also committed code with no review at all that had to be reverted
after the bugs it caused were found by an external down stream consumers
of the bhyve code.

You had code reverted by core due to a external attribution request,
which had you been attending the bi monthly bhyve calls you would of
known was an issue.

I would suggest these are the reasons your feeling angry, and that
I infact tried to reach out to jhb to discuss some of these earlier
but that reach out was never returned.  I under stand your frustration,
you are just wanting to do with best thing you can for the project
and bhyve, can we try to find a better resolution to this situation
than your exit?
  

-- Ian


Leave it for now, I am sure jhb or thyco are fine with it,
this is just a heads up FYI for future commits.

Bhyve code has been and still is under a fairly tight
MAINTAINER status.


Modified:
   head/usr.sbin/bhyve/pci_emul.c

Modified: head/usr.sbin/bhyve/pci_emul.c
===
===
--- head/usr.sbin/bhyve/pci_emul.c  Fri Mar 15 02:11:27 2019(r3
45170)
+++ head/usr.sbin/bhyve/pci_emul.c  Fri Mar 15 02:11:28 2019(r3
45171)
@@ -953,7 +953,10 @@ pci_emul_add_pciecap(struct pci_devinst *pi,
int type)
 bzero(, sizeof(pciecap));

 pciecap.capid = PCIY_EXPRESS;
-   pciecap.pcie_capabilities = PCIECAP_VERSION |
PCIEM_TYPE_ROOT_PORT;
+   pciecap.pcie_capabilities = PCIECAP_VERSION | type;
+   /* Devices starting with version 1.1 must set the RBER bit */
+   if (PCIECAP_VERSION >= 1)
+   pciecap.dev_capabilities = PCIEM_CAP_ROLE_ERR_RPT;
 pciecap.link_capabilities = 0x411;  /* gen1, x1 */
 pciecap.link_status = 0x11; /* gen1, x1 */









--

--
Marcelo Araujo(__)ara...@freebsd.org
\\\'',)http://www.FreeBSD.org    \/  \ ^
Power To Server. .\. /_)

___
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: r345171 - head/usr.sbin/bhyve

[Rodney W. Grimes]

> Em sex, 15 de mar de 2019 ?s 22:12, Ian Lepore  escreveu:
> 
> > On Thu, 2019-03-14 at 19:31 -0700, Rodney W. Grimes wrote:
> > > > Author: chuck
> > > > Date: Fri Mar 15 02:11:28 2019
> > > > New Revision: 345171
> > > > URL: https://svnweb.freebsd.org/changeset/base/345171
> > > >
> > > > Log:
> > > >   Fix bhyve PCIe capability emulation
> > > >
> > > >   PCIe devices starting with version 1.1 must set the Role-Based
> > > > Error
> > > >   Reporting bit.
> > > >
> > > >   And while we're in the neighborhood, generalize the code
> > > > assigning the
> > > >   device type.
> > > >
> > > >   Reviewed by:  imp, araujo, rgrimes
> > > >   Approved by:  imp (mentor)
> > > >   MFC after:1 week
> > > >   Differential Revision: https://reviews.freebsd.org/D19580
> > >
> > > This code requires maintainer approval before a commit,
> > > though this was well reviewed that doesnt exclude it
> > > from the MAINTAINERS entry.
> > >
> >
> > Where exactly does it say that in MAINTAINERS?  As another victim of
> > this sort of drive-by lynching after making a trivial bhyve change I
> > pretty seriously object to a vague and meaningless entry in MAINTAINERS
> > being used to pounce on anyone who dares to touch the precious bhyve
> > code.
> >
> 
> There is a new entry on MAINTAINERS:
> https://svnweb.freebsd.org/base?view=revision=344631
> 
> 
> >
> > There is no mention of bhyve in MAINTAINERS, for usr.sbin or elsewhere.
> > There is an entry for vmm(4), which to me does not say anything about
> > bhyve, yet somehow everybody is supposed to know what it means and
> > what-all territory it covers?
> >
> > IMO, this sort of hyper-proprietary pouncing on everyone who dares
> > change a single line of code is not productive.  It is HIGHLY de-
> > motivating.  Large sweeping design changes are one thing, but pouncing
> > on every tiny minor commit is just not helpful.
> >
> 
> +1
> 
> I got so frustrated with it recently that I have decided to don't
> contribute with bhyve anymore, perhaps even with FreeBSD.
> I still have some people under mentorship that I intend to finish and then
> probably I will phase out.

Your failure to get reviews, and infact even abandon one that had
negative advice as to the validity of your suggested change and
committing it anyway is more likely the cause here.

You also committed code with no review at all that had to be reverted
after the bugs it caused were found by an external down stream consumers
of the bhyve code.

You had code reverted by core due to a external attribution request,
which had you been attending the bi monthly bhyve calls you would of
known was an issue.

I would suggest these are the reasons your feeling angry, and that
I infact tried to reach out to jhb to discuss some of these earlier
but that reach out was never returned.  I under stand your frustration,
you are just wanting to do with best thing you can for the project
and bhyve, can we try to find a better resolution to this situation
than your exit?
 
> > -- Ian
> >
> > > Leave it for now, I am sure jhb or thyco are fine with it,
> > > this is just a heads up FYI for future commits.
> > >
> > > Bhyve code has been and still is under a fairly tight
> > > MAINTAINER status.
> > >
> > > > Modified:
> > > >   head/usr.sbin/bhyve/pci_emul.c
> > > >
> > > > Modified: head/usr.sbin/bhyve/pci_emul.c
> > > > ===
> > > > ===
> > > > --- head/usr.sbin/bhyve/pci_emul.c  Fri Mar 15 02:11:27 2019(r3
> > > > 45170)
> > > > +++ head/usr.sbin/bhyve/pci_emul.c  Fri Mar 15 02:11:28 2019(r3
> > > > 45171)
> > > > @@ -953,7 +953,10 @@ pci_emul_add_pciecap(struct pci_devinst *pi,
> > > > int type)
> > > > bzero(, sizeof(pciecap));
> > > >
> > > > pciecap.capid = PCIY_EXPRESS;
> > > > -   pciecap.pcie_capabilities = PCIECAP_VERSION |
> > > > PCIEM_TYPE_ROOT_PORT;
> > > > +   pciecap.pcie_capabilities = PCIECAP_VERSION | type;
> > > > +   /* Devices starting with version 1.1 must set the RBER bit */
> > > > +   if (PCIECAP_VERSION >= 1)
> > > > +   pciecap.dev_capabilities = PCIEM_CAP_ROLE_ERR_RPT;
> > > > pciecap.link_capabilities = 0x411;  /* gen1, x1 */
> > > > pciecap.link_status = 0x11; /* gen1, x1 */
> > > >
> > > >
> > > >
> > >
> > >
> >
> >
> >
> 
> -- 
> 
> -- 
> Marcelo Araujo(__)ara...@freebsd.org
> \\\'',)http://www.FreeBSD.org    \/  \ ^
> Power To Server. .\. /_)

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

Re: svn commit: r345171 - head/usr.sbin/bhyve

[Rodney W. Grimes]

> On Thu, Mar 14, 2019 at 8:32 PM Rodney W. Grimes 
> wrote:
> 
> > > Author: chuck
> > > Date: Fri Mar 15 02:11:28 2019
> > > New Revision: 345171
> > > URL: https://svnweb.freebsd.org/changeset/base/345171
> > >
> > > Log:
> > >   Fix bhyve PCIe capability emulation
> > >
> > >   PCIe devices starting with version 1.1 must set the Role-Based Error
> > >   Reporting bit.
> > >
> > >   And while we're in the neighborhood, generalize the code assigning the
> > >   device type.
> > >
> > >   Reviewed by:imp, araujo, rgrimes
> > >   Approved by:imp (mentor)
> > >   MFC after:  1 week
> > >   Differential Revision: https://reviews.freebsd.org/D19580
> >
> > This code requires maintainer approval before a commit,
> > though this was well reviewed that doesnt exclude it
> > from the MAINTAINERS entry.
> >
> > Leave it for now, I am sure jhb or thyco are fine with it,
> > this is just a heads up FYI for future commits.
> >
> > Bhyve code has been and still is under a fairly tight
> > MAINTAINER status.
> >
> 
> There is no such thing as a hard lock in FreeBSD. This sounds like you are
> advocating for that, but that's not the case.
> 
> Stop this stupid nitpicking for single line commits. We don't have that
> culture any more and it's really pissing a lot of people off.
> 
> The MAINTAINERS file even says this:
> 
> Please note that the content of this file is strictly advisory.
> 
> And the entry for bhyve doesn't say things are mandatory, just requested.
> 
> Jumping on people's case like this, for a review you yourself were on and
> approved but made no mention of seeking further review / approval, is
> demotivating and toxic. Please stop.

I explicitly DID add jhb to the review.
I also explicitly did not mark the bhyve# box that is added by
the hearald rules.

I did not jump on him, I informed him of the entry, and told him to leave it.
You how ever have infact jumped on me, repeatedly, if you want to talk about
discouraging tones of behavior I suggest you look at yourself as well.

> Warner
> 
> >   head/usr.sbin/bhyve/pci_emul.c
> > >
> > > Modified: head/usr.sbin/bhyve/pci_emul.c
> > >
> > ==
> > > --- head/usr.sbin/bhyve/pci_emul.cFri Mar 15 02:11:27 2019
> > (r345170)
> > > +++ head/usr.sbin/bhyve/pci_emul.cFri Mar 15 02:11:28 2019
> > (r345171)
> > > @@ -953,7 +953,10 @@ pci_emul_add_pciecap(struct pci_devinst *pi, int
> > type)
> > >   bzero(, sizeof(pciecap));
> > >
> > >   pciecap.capid = PCIY_EXPRESS;
> > > - pciecap.pcie_capabilities = PCIECAP_VERSION | PCIEM_TYPE_ROOT_PORT;
> > > + pciecap.pcie_capabilities = PCIECAP_VERSION | type;
> > > + /* Devices starting with version 1.1 must set the RBER bit */
> > > + if (PCIECAP_VERSION >= 1)
> > > + pciecap.dev_capabilities = PCIEM_CAP_ROLE_ERR_RPT;
> > >   pciecap.link_capabilities = 0x411;  /* gen1, x1 */
> > >   pciecap.link_status = 0x11; /* gen1, x1 */
> > >
> > >
> > >
> >
> > --
> > Rod Grimes
> > rgri...@freebsd.org
> >
> >

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

svn commit: r345187 - head/sys/net

[Kristof Provost]

Author: kp
Date: Fri Mar 15 15:52:36 2019
New Revision: 345187
URL: https://svnweb.freebsd.org/changeset/base/345187

Log:
  bridge: Fix STP-related panic
  
  After r345180 we need to have the appropriate vnet context set to delete an
  rtnode in bridge_rtnode_destroy().
  That's usually the case, but not when it's called by the STP code (through
  bstp_notify_rtage()).
  
  We have to set the vnet context in bridge_rtable_expire() just as we do in the
  other STP callback bridge_state_change().
  
  Reviewed by:  kevans

Modified:
  head/sys/net/if_bridge.c

Modified: head/sys/net/if_bridge.c
==
--- head/sys/net/if_bridge.cFri Mar 15 15:16:31 2019(r345186)
+++ head/sys/net/if_bridge.cFri Mar 15 15:52:36 2019(r345187)
@@ -3047,6 +3047,7 @@ bridge_rtable_expire(struct ifnet *ifp, int age)
struct bridge_softc *sc = ifp->if_bridge;
struct bridge_rtnode *brt;
 
+   CURVNET_SET(ifp->if_vnet);
BRIDGE_LOCK(sc);
 
/*
@@ -3065,6 +3066,7 @@ bridge_rtable_expire(struct ifnet *ifp, int age)
}
}
BRIDGE_UNLOCK(sc);
+   CURVNET_RESTORE();
 }
 
 /*
___
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: r345186 - in stable/11/sys: conf dev/fxp modules/fxp

[Mark Johnston]

Author: markj
Date: Fri Mar 15 15:16:31 2019
New Revision: 345186
URL: https://svnweb.freebsd.org/changeset/base/345186

Log:
  MFC r342214:
  Remove a use of a negative array index from fxp(4).

Modified:
  stable/11/sys/conf/files
  stable/11/sys/conf/kern.mk
  stable/11/sys/dev/fxp/if_fxp.c
  stable/11/sys/dev/fxp/if_fxpreg.h
  stable/11/sys/modules/fxp/Makefile
Directory Properties:
  stable/11/   (props changed)

Modified: stable/11/sys/conf/files
==
--- stable/11/sys/conf/filesFri Mar 15 14:49:27 2019(r345185)
+++ stable/11/sys/conf/filesFri Mar 15 15:16:31 2019(r345186)
@@ -1733,8 +1733,7 @@ dev/firewire/sbp.coptional sbp
 dev/firewire/sbp_targ.coptional sbp_targ
 dev/flash/at45d.c  optional at45d
 dev/flash/mx25l.c  optional mx25l
-dev/fxp/if_fxp.c   optional fxp \
-   compile-with "${NORMAL_C} ${NO_WARRAY_BOUNDS}"
+dev/fxp/if_fxp.c   optional fxp
 dev/fxp/inphy.coptional fxp
 dev/gem/if_gem.c   optional gem
 dev/gem/if_gem_pci.c   optional gem pci

Modified: stable/11/sys/conf/kern.mk
==
--- stable/11/sys/conf/kern.mk  Fri Mar 15 14:49:27 2019(r345185)
+++ stable/11/sys/conf/kern.mk  Fri Mar 15 15:16:31 2019(r345186)
@@ -24,7 +24,6 @@ NO_WSELF_ASSIGN=  -Wno-self-assign
 NO_WUNNEEDED_INTERNAL_DECL=-Wno-unneeded-internal-declaration
 NO_WSOMETIMES_UNINITIALIZED=   -Wno-error-sometimes-uninitialized
 NO_WCAST_QUAL= -Wno-cast-qual
-NO_WARRAY_BOUNDS=  -Wno-error-array-bounds
 # Several other warnings which might be useful in some cases, but not severe
 # enough to error out the whole kernel build.  Display them anyway, so there is
 # some incentive to fix them eventually.

Modified: stable/11/sys/dev/fxp/if_fxp.c
==
--- stable/11/sys/dev/fxp/if_fxp.c  Fri Mar 15 14:49:27 2019
(r345185)
+++ stable/11/sys/dev/fxp/if_fxp.c  Fri Mar 15 15:16:31 2019
(r345186)
@@ -1623,7 +1623,7 @@ fxp_encap(struct fxp_softc *sc, struct mbuf **m_head)
cbp->tbd_number = nseg;
/* Configure TSO. */
if (m->m_pkthdr.csum_flags & CSUM_TSO) {
-   cbp->tbd[-1].tb_size = htole32(m->m_pkthdr.tso_segsz << 16);
+   cbp->tbdtso.tb_size = htole32(m->m_pkthdr.tso_segsz << 16);
cbp->tbd[1].tb_size |= htole32(tcp_payload << 16);
cbp->ipcb_ip_schedule |= FXP_IPCB_LARGESEND_ENABLE |
FXP_IPCB_IP_CHECKSUM_ENABLE |

Modified: stable/11/sys/dev/fxp/if_fxpreg.h
==
--- stable/11/sys/dev/fxp/if_fxpreg.h   Fri Mar 15 14:49:27 2019
(r345185)
+++ stable/11/sys/dev/fxp/if_fxpreg.h   Fri Mar 15 15:16:31 2019
(r345186)
@@ -279,10 +279,15 @@ struct fxp_cb_tx {
uint16_t cb_status;
uint16_t cb_command;
uint32_t link_addr;
-   uint32_t tbd_array_addr;
-   uint16_t byte_count;
-   uint8_t tx_threshold;
-   uint8_t tbd_number;
+   union {
+   struct {
+   uint32_t tbd_array_addr;
+   uint16_t byte_count;
+   uint8_t tx_threshold;
+   uint8_t tbd_number;
+   };
+   struct fxp_tbd tbdtso;
+   };
 
/*
 * The following structure isn't actually part of the TxCB,

Modified: stable/11/sys/modules/fxp/Makefile
==
--- stable/11/sys/modules/fxp/Makefile  Fri Mar 15 14:49:27 2019
(r345185)
+++ stable/11/sys/modules/fxp/Makefile  Fri Mar 15 15:16:31 2019
(r345186)
@@ -6,5 +6,3 @@ KMOD=   if_fxp
 SRCS=  device_if.h bus_if.h if_fxp.c inphy.c miibus_if.h miidevs.h pci_if.h
 
 .include 
-
-CWARNFLAGS+=   ${NO_WARRAY_BOUNDS}
___
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: r345180 - head/sys/net

[Kyle Evans]

On Fri, Mar 15, 2019 at 8:20 AM Kyle Evans  wrote:
>
> Author: kevans
> Date: Fri Mar 15 13:19:52 2019
> New Revision: 345180
> URL: https://svnweb.freebsd.org/changeset/base/345180
>
> Log:
>   if_bridge(4): Fix module teardown
>
>   bridge_rtnode_zone still has outstanding allocations at the time of
>   destruction in the current model because all of the interface teardown
>   happens in a VNET_SYSUNINIT, -after- the MOD_UNLOAD has already been
>   processed.  The SYSUNINIT triggers destruction of the interfaces, which then
>   attempts to free the memory from the zone that's already been destroyed, and
>   we hit a panic.
>
>   Solve this by virtualizing the uma_zone we allocate the rtnodes from to fix
>   the ordering. bridge_rtable_fini should also take care to flush any
>   remaining routes that weren't taken care of when dynamic routes were flushed
>   in bridge_stop.
>
>   Reviewed by:  kp
>   Differential Revision:https://reviews.freebsd.org/D19578
>
> Modified:
>   head/sys/net/if_bridge.c
>
> [... snip ...]
> @@ -2886,6 +2890,7 @@ bridge_rtable_fini(struct bridge_softc *sc)
>
> KASSERT(sc->sc_brtcnt == 0,
> ("%s: %d bridge routes referenced", __func__, sc->sc_brtcnt));
> +   bridge_rtflush(sc, 1);
> free(sc->sc_rthash, M_DEVBUF);
>  }
>

Now that I read through all of this again, this is wrong. Routes are
destroyed as the member interfaces are removed up in
bridge_clone_destroy, and that this needs to have been done already is
KASSERT'd on the line right above. I will remove this, because that
flush will accomplish nothing.
___
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: r345171 - head/usr.sbin/bhyve

[Warner Losh]

On Thu, Mar 14, 2019 at 8:32 PM Rodney W. Grimes 
wrote:

> > Author: chuck
> > Date: Fri Mar 15 02:11:28 2019
> > New Revision: 345171
> > URL: https://svnweb.freebsd.org/changeset/base/345171
> >
> > Log:
> >   Fix bhyve PCIe capability emulation
> >
> >   PCIe devices starting with version 1.1 must set the Role-Based Error
> >   Reporting bit.
> >
> >   And while we're in the neighborhood, generalize the code assigning the
> >   device type.
> >
> >   Reviewed by:imp, araujo, rgrimes
> >   Approved by:imp (mentor)
> >   MFC after:  1 week
> >   Differential Revision: https://reviews.freebsd.org/D19580
>
> This code requires maintainer approval before a commit,
> though this was well reviewed that doesnt exclude it
> from the MAINTAINERS entry.
>
> Leave it for now, I am sure jhb or thyco are fine with it,
> this is just a heads up FYI for future commits.
>
> Bhyve code has been and still is under a fairly tight
> MAINTAINER status.
>

There is no such thing as a hard lock in FreeBSD. This sounds like you are
advocating for that, but that's not the case.

Stop this stupid nitpicking for single line commits. We don't have that
culture any more and it's really pissing a lot of people off.

The MAINTAINERS file even says this:

Please note that the content of this file is strictly advisory.

And the entry for bhyve doesn't say things are mandatory, just requested.

Jumping on people's case like this, for a review you yourself were on and
approved but made no mention of seeking further review / approval, is
demotivating and toxic. Please stop.

Warner

>   head/usr.sbin/bhyve/pci_emul.c
> >
> > Modified: head/usr.sbin/bhyve/pci_emul.c
> >
> ==
> > --- head/usr.sbin/bhyve/pci_emul.cFri Mar 15 02:11:27 2019
> (r345170)
> > +++ head/usr.sbin/bhyve/pci_emul.cFri Mar 15 02:11:28 2019
> (r345171)
> > @@ -953,7 +953,10 @@ pci_emul_add_pciecap(struct pci_devinst *pi, int
> type)
> >   bzero(, sizeof(pciecap));
> >
> >   pciecap.capid = PCIY_EXPRESS;
> > - pciecap.pcie_capabilities = PCIECAP_VERSION | PCIEM_TYPE_ROOT_PORT;
> > + pciecap.pcie_capabilities = PCIECAP_VERSION | type;
> > + /* Devices starting with version 1.1 must set the RBER bit */
> > + if (PCIECAP_VERSION >= 1)
> > + pciecap.dev_capabilities = PCIEM_CAP_ROLE_ERR_RPT;
> >   pciecap.link_capabilities = 0x411;  /* gen1, x1 */
> >   pciecap.link_status = 0x11; /* gen1, x1 */
> >
> >
> >
>
> --
> Rod Grimes
> rgri...@freebsd.org
>
>
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r345171 - head/usr.sbin/bhyve

[Marcelo Araujo]

Em sex, 15 de mar de 2019 às 22:12, Ian Lepore  escreveu:

> On Thu, 2019-03-14 at 19:31 -0700, Rodney W. Grimes wrote:
> > > Author: chuck
> > > Date: Fri Mar 15 02:11:28 2019
> > > New Revision: 345171
> > > URL: https://svnweb.freebsd.org/changeset/base/345171
> > >
> > > Log:
> > >   Fix bhyve PCIe capability emulation
> > >
> > >   PCIe devices starting with version 1.1 must set the Role-Based
> > > Error
> > >   Reporting bit.
> > >
> > >   And while we're in the neighborhood, generalize the code
> > > assigning the
> > >   device type.
> > >
> > >   Reviewed by:  imp, araujo, rgrimes
> > >   Approved by:  imp (mentor)
> > >   MFC after:1 week
> > >   Differential Revision: https://reviews.freebsd.org/D19580
> >
> > This code requires maintainer approval before a commit,
> > though this was well reviewed that doesnt exclude it
> > from the MAINTAINERS entry.
> >
>
> Where exactly does it say that in MAINTAINERS?  As another victim of
> this sort of drive-by lynching after making a trivial bhyve change I
> pretty seriously object to a vague and meaningless entry in MAINTAINERS
> being used to pounce on anyone who dares to touch the precious bhyve
> code.
>

There is a new entry on MAINTAINERS:
https://svnweb.freebsd.org/base?view=revision=344631


>
> There is no mention of bhyve in MAINTAINERS, for usr.sbin or elsewhere.
> There is an entry for vmm(4), which to me does not say anything about
> bhyve, yet somehow everybody is supposed to know what it means and
> what-all territory it covers?
>
> IMO, this sort of hyper-proprietary pouncing on everyone who dares
> change a single line of code is not productive.  It is HIGHLY de-
> motivating.  Large sweeping design changes are one thing, but pouncing
> on every tiny minor commit is just not helpful.
>

+1

I got so frustrated with it recently that I have decided to don't
contribute with bhyve anymore, perhaps even with FreeBSD.
I still have some people under mentorship that I intend to finish and then
probably I will phase out.


>
> -- Ian
>
> > Leave it for now, I am sure jhb or thyco are fine with it,
> > this is just a heads up FYI for future commits.
> >
> > Bhyve code has been and still is under a fairly tight
> > MAINTAINER status.
> >
> > > Modified:
> > >   head/usr.sbin/bhyve/pci_emul.c
> > >
> > > Modified: head/usr.sbin/bhyve/pci_emul.c
> > > ===
> > > ===
> > > --- head/usr.sbin/bhyve/pci_emul.c  Fri Mar 15 02:11:27 2019(r3
> > > 45170)
> > > +++ head/usr.sbin/bhyve/pci_emul.c  Fri Mar 15 02:11:28 2019(r3
> > > 45171)
> > > @@ -953,7 +953,10 @@ pci_emul_add_pciecap(struct pci_devinst *pi,
> > > int type)
> > > bzero(, sizeof(pciecap));
> > >
> > > pciecap.capid = PCIY_EXPRESS;
> > > -   pciecap.pcie_capabilities = PCIECAP_VERSION |
> > > PCIEM_TYPE_ROOT_PORT;
> > > +   pciecap.pcie_capabilities = PCIECAP_VERSION | type;
> > > +   /* Devices starting with version 1.1 must set the RBER bit */
> > > +   if (PCIECAP_VERSION >= 1)
> > > +   pciecap.dev_capabilities = PCIEM_CAP_ROLE_ERR_RPT;
> > > pciecap.link_capabilities = 0x411;  /* gen1, x1 */
> > > pciecap.link_status = 0x11; /* gen1, x1 */
> > >
> > >
> > >
> >
> >
>
>
>

-- 

-- 
Marcelo Araujo(__)ara...@freebsd.org
\\\'',)http://www.FreeBSD.org    \/  \ ^
Power To Server. .\. /_)
___
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: r345184 - head/usr.sbin/trim

[Eugene Grosbein]

Author: eugen
Date: Fri Mar 15 14:42:23 2019
New Revision: 345184
URL: https://svnweb.freebsd.org/changeset/base/345184

Log:
  trim(8): emit more user-friendly error message in verbose mode.
  
  If underlying driver provides no TRIM/UNMAP support and operation fails
  due to this reason, state it clearly in verbose mode (default)
  instead of writing standard message that may be too cryptic for a user:
  
trim: ioctl(DIOCGDELETE) failed: nda0: Operation not supported
  
  Now it would write:
  
trim: nda0: TRIM/UNMAP not supported by driver
  
  But still use previous format including errno value for quiet mode.
  
  Small candelete() function borrowed from diskinfo(8) code.
  This function was committed by Alan Somers ,
  so give him some credit.
  
  Reported by:  chuck

Modified:
  head/usr.sbin/trim/trim.c

Modified: head/usr.sbin/trim/trim.c
==
--- head/usr.sbin/trim/trim.c   Fri Mar 15 14:19:45 2019(r345183)
+++ head/usr.sbin/trim/trim.c   Fri Mar 15 14:42:23 2019(r345184)
@@ -2,7 +2,7 @@
  * SPDX-License-Identifier: BSD-2-Clause-FreeBSD
  *
  * Copyright (c) 2019 Eugene Grosbein .
- * All rights reserved.
+ * Contains code written by Alan Somers .
  *
  * Redistribution and use in source and binary forms, with or without
  * modification, are permitted provided that the following conditions
@@ -47,6 +47,7 @@
 #include 
 __FBSDID("$FreeBSD$");
 
+static boolcandelete(int fd);
 static off_t   getsize(const char *path);
 static int opendev(const char *path, int flags);
 static int trim(const char *path, off_t offset, off_t length, bool dryrun, 
bool verbose);
@@ -135,6 +136,19 @@ main(int argc, char **argv)
return (error ? EXIT_FAILURE : EXIT_SUCCESS);
 }
 
+static bool
+candelete(int fd)
+{
+   struct diocgattr_arg arg;
+
+   strlcpy(arg.name, "GEOM::candelete", sizeof(arg.name));
+   arg.len = sizeof(arg.value.i);
+   if (ioctl(fd, DIOCGATTR, ) == 0)
+   return (arg.value.i != 0);
+   else
+   return (false);
+}
+
 static int
 opendev(const char *path, int flags)
 {
@@ -211,9 +225,12 @@ trim(const char *path, off_t offset, off_t length, boo
arg[1] = length;
 
error = ioctl(fd, DIOCGDELETE, arg);
-   if (error < 0)
-   warn("ioctl(DIOCGDELETE) failed: %s", path);
-
+   if (error < 0) {
+   if (errno == EOPNOTSUPP && verbose && !candelete(fd))
+   warnx("%s: TRIM/UNMAP not supported by driver", path);
+   else
+   warn("ioctl(DIOCGDELETE) failed: %s", path);
+   }
close(fd);
return (error);
 }
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

svn commit: r345183 - in stable/12/sys/x86: include x86

[Konstantin Belousov]

Author: kib
Date: Fri Mar 15 14:19:45 2019
New Revision: 345183
URL: https://svnweb.freebsd.org/changeset/base/345183

Log:
  MFC r345075:
  Add register number, CPUID bits, and print identification for TSX
  force abort errata.

Modified:
  stable/12/sys/x86/include/specialreg.h
  stable/12/sys/x86/x86/identcpu.c
Directory Properties:
  stable/12/   (props changed)

Modified: stable/12/sys/x86/include/specialreg.h
==
--- stable/12/sys/x86/include/specialreg.h  Fri Mar 15 14:18:19 2019
(r345182)
+++ stable/12/sys/x86/include/specialreg.h  Fri Mar 15 14:19:45 2019
(r345183)
@@ -431,6 +431,7 @@
 /*
  * CPUID instruction 7 Structured Extended Features, leaf 0 edx info
  */
+#defineCPUID_STDEXT3_TSXFA 0x2000
 #defineCPUID_STDEXT3_IBPB  0x0400
 #defineCPUID_STDEXT3_STIBP 0x0800
 #defineCPUID_STDEXT3_L1D_FLUSH 0x1000
@@ -489,6 +490,7 @@
 #defineMSR_MTRRcap 0x0fe
 #defineMSR_IA32_ARCH_CAP   0x10a
 #defineMSR_IA32_FLUSH_CMD  0x10b
+#defineMSR_TSX_FORCE_ABORT 0x10f
 #defineMSR_BBL_CR_ADDR 0x116
 #defineMSR_BBL_CR_DECC 0x118
 #defineMSR_BBL_CR_CTL  0x119

Modified: stable/12/sys/x86/x86/identcpu.c
==
--- stable/12/sys/x86/x86/identcpu.cFri Mar 15 14:18:19 2019
(r345182)
+++ stable/12/sys/x86/x86/identcpu.cFri Mar 15 14:19:45 2019
(r345183)
@@ -992,6 +992,7 @@ printcpuinfo(void)
printf("\n  Structured Extended Features3=0x%b",
cpu_stdext_feature3,
   "\020"
+  "\016TSXFA"
   "\033IBPB"
   "\034STIBP"
   "\035L1DFL"
___
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: r345182 - stable/12/sys/dev/hwpmc

[Konstantin Belousov]

Author: kib
Date: Fri Mar 15 14:18:19 2019
New Revision: 345182
URL: https://svnweb.freebsd.org/changeset/base/345182

Log:
  MFC r345074:
  Remove useless version check.

Modified:
  stable/12/sys/dev/hwpmc/hwpmc_core.c
Directory Properties:
  stable/12/   (props changed)

Modified: stable/12/sys/dev/hwpmc/hwpmc_core.c
==
--- stable/12/sys/dev/hwpmc/hwpmc_core.cFri Mar 15 14:16:16 2019
(r345181)
+++ stable/12/sys/dev/hwpmc/hwpmc_core.cFri Mar 15 14:18:19 2019
(r345182)
@@ -40,11 +40,7 @@ __FBSDID("$FreeBSD$");
 #include 
 
 #include 
-#if (__FreeBSD_version >= 110)
 #include 
-#else
-#include 
-#endif
 #include 
 #include 
 #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"

svn commit: r345181 - in stable/12: lib/libc/sys sys/compat/freebsd32 sys/kern sys/sys

[Konstantin Belousov]

Author: kib
Date: Fri Mar 15 14:16:16 2019
New Revision: 345181
URL: https://svnweb.freebsd.org/changeset/base/345181

Log:
  MFC r341689, r341711, r341712, r341809:
  Add getfhat(2), fhlink(2), fhlinkat(2), fhreadlink(2) file handle system 
calls.
  
  To easier potential MFC of the AT_BENEATH feature, some vestiges of it were
  left in the merged product but commented out.
  
  Due to a lot of conflicts, it was impossible to split the merge and
  regeneration of the syscall tables, because I needed to test the result.
  It is fine for stable branch to commit the whole change with the
  generated diff.

Added:
  stable/12/lib/libc/sys/fhlink.2
 - copied unchanged from r341689, head/lib/libc/sys/fhlink.2
  stable/12/lib/libc/sys/fhreadlink.2
 - copied unchanged from r341689, head/lib/libc/sys/fhreadlink.2
Modified:
  stable/12/lib/libc/sys/Makefile.inc
  stable/12/lib/libc/sys/Symbol.map
  stable/12/lib/libc/sys/getfh.2
  stable/12/sys/compat/freebsd32/freebsd32_syscall.h
  stable/12/sys/compat/freebsd32/freebsd32_syscalls.c
  stable/12/sys/compat/freebsd32/freebsd32_sysent.c
  stable/12/sys/compat/freebsd32/freebsd32_systrace_args.c
  stable/12/sys/compat/freebsd32/syscalls.master
  stable/12/sys/kern/init_sysent.c
  stable/12/sys/kern/syscalls.c
  stable/12/sys/kern/syscalls.master
  stable/12/sys/kern/systrace_args.c
  stable/12/sys/kern/vfs_syscalls.c
  stable/12/sys/sys/mount.h
  stable/12/sys/sys/syscall.h
  stable/12/sys/sys/syscall.mk
  stable/12/sys/sys/sysproto.h
Directory Properties:
  stable/12/   (props changed)

Modified: stable/12/lib/libc/sys/Makefile.inc
==
--- stable/12/lib/libc/sys/Makefile.inc Fri Mar 15 13:19:52 2019
(r345180)
+++ stable/12/lib/libc/sys/Makefile.inc Fri Mar 15 14:16:16 2019
(r345181)
@@ -184,7 +184,9 @@ MAN+=   abort2.2 \
extattr_get_file.2 \
fcntl.2 \
ffclock.2 \
+   fhlink.2 \
fhopen.2 \
+   fhreadlink.2 \
flock.2 \
fork.2 \
fsync.2 \
@@ -395,7 +397,8 @@ MLINKS+=ffclock.2 ffclock_getcounter.2 \
 MLINKS+=fhopen.2 fhstat.2 fhopen.2 fhstatfs.2
 MLINKS+=fsync.2 fdatasync.2
 MLINKS+=getdirentries.2 getdents.2
-MLINKS+=getfh.2 lgetfh.2
+MLINKS+=getfh.2 lgetfh.2 \
+   getfh.2 getfhat.2
 MLINKS+=getgid.2 getegid.2
 MLINKS+=getitimer.2 setitimer.2
 MLINKS+=getlogin.2 getlogin_r.3

Modified: stable/12/lib/libc/sys/Symbol.map
==
--- stable/12/lib/libc/sys/Symbol.map   Fri Mar 15 13:19:52 2019
(r345180)
+++ stable/12/lib/libc/sys/Symbol.map   Fri Mar 15 14:16:16 2019
(r345181)
@@ -401,6 +401,13 @@ FBSD_1.5 {
cpuset_setdomain;
 };
 
+FBSD_1.6 {
+   fhlink;
+   fhlinkat;
+   fhreadlink;
+   getfhat;
+};
+
 FBSDprivate_1.0 {
___acl_aclcheck_fd;
__sys___acl_aclcheck_fd;

Copied: stable/12/lib/libc/sys/fhlink.2 (from r341689, 
head/lib/libc/sys/fhlink.2)
==
--- /dev/null   00:00:00 1970   (empty, because file is newly added)
+++ stable/12/lib/libc/sys/fhlink.2 Fri Mar 15 14:16:16 2019
(r345181, copy of r341689, head/lib/libc/sys/fhlink.2)
@@ -0,0 +1,268 @@
+.\" SPDX-License-Identifier: BSD-2-Clause
+.\"
+.\" Copyright (c) 2018 Gandi
+.\"
+.\" Redistribution and use in source and binary forms, with or without
+.\" modification, are permitted provided that the following conditions
+.\" are met:
+.\" 1. Redistributions of source code must retain the above copyright
+.\"notice, this list of conditions and the following disclaimer.
+.\" 2. Redistributions in binary form must reproduce the above copyright
+.\"notice, this list of conditions and the following disclaimer in the
+.\"documentation and/or other materials provided with the distribution.
+.\"
+.\" THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
+.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+.\" ARE DISCLAIMED.  IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
+.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
+.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
+.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
+.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
+.\" SUCH DAMAGE.
+.\"
+.\" $FreeBSD$
+.\"
+.Dd November 29, 2018
+.Dt FHLINK 2
+.Os
+.Sh NAME
+.Nm fhlink ,
+.Nm fhlinkat
+.Nd make a hard file link
+.Sh LIBRARY
+.Lb libc
+.Sh SYNOPSIS
+.In unistd.h
+.Ft int
+.Fn fhlink "fhandle_t *fhp" "const char *to"
+.Ft int
+.Fn fhlinkat 

Re: svn commit: r345171 - head/usr.sbin/bhyve

[Ian Lepore]

On Thu, 2019-03-14 at 19:31 -0700, Rodney W. Grimes wrote:
> > Author: chuck
> > Date: Fri Mar 15 02:11:28 2019
> > New Revision: 345171
> > URL: https://svnweb.freebsd.org/changeset/base/345171
> > 
> > Log:
> >   Fix bhyve PCIe capability emulation
> >   
> >   PCIe devices starting with version 1.1 must set the Role-Based
> > Error
> >   Reporting bit.
> >   
> >   And while we're in the neighborhood, generalize the code
> > assigning the
> >   device type.
> >   
> >   Reviewed by:  imp, araujo, rgrimes
> >   Approved by:  imp (mentor)
> >   MFC after:1 week
> >   Differential Revision: https://reviews.freebsd.org/D19580
> 
> This code requires maintainer approval before a commit,
> though this was well reviewed that doesnt exclude it
> from the MAINTAINERS entry.
> 

Where exactly does it say that in MAINTAINERS?  As another victim of
this sort of drive-by lynching after making a trivial bhyve change I
pretty seriously object to a vague and meaningless entry in MAINTAINERS
being used to pounce on anyone who dares to touch the precious bhyve
code.

There is no mention of bhyve in MAINTAINERS, for usr.sbin or elsewhere.
There is an entry for vmm(4), which to me does not say anything about
bhyve, yet somehow everybody is supposed to know what it means and
what-all territory it covers?

IMO, this sort of hyper-proprietary pouncing on everyone who dares
change a single line of code is not productive.  It is HIGHLY de-
motivating.  Large sweeping design changes are one thing, but pouncing
on every tiny minor commit is just not helpful.

-- Ian

> Leave it for now, I am sure jhb or thyco are fine with it,
> this is just a heads up FYI for future commits.
> 
> Bhyve code has been and still is under a fairly tight
> MAINTAINER status.
> 
> > Modified:
> >   head/usr.sbin/bhyve/pci_emul.c
> > 
> > Modified: head/usr.sbin/bhyve/pci_emul.c
> > ===
> > ===
> > --- head/usr.sbin/bhyve/pci_emul.c  Fri Mar 15 02:11:27 2019(r3
> > 45170)
> > +++ head/usr.sbin/bhyve/pci_emul.c  Fri Mar 15 02:11:28 2019(r3
> > 45171)
> > @@ -953,7 +953,10 @@ pci_emul_add_pciecap(struct pci_devinst *pi,
> > int type)
> > bzero(, sizeof(pciecap));
> >  
> > pciecap.capid = PCIY_EXPRESS;
> > -   pciecap.pcie_capabilities = PCIECAP_VERSION |
> > PCIEM_TYPE_ROOT_PORT;
> > +   pciecap.pcie_capabilities = PCIECAP_VERSION | type;
> > +   /* Devices starting with version 1.1 must set the RBER bit */
> > +   if (PCIECAP_VERSION >= 1)
> > +   pciecap.dev_capabilities = PCIEM_CAP_ROLE_ERR_RPT;
> > pciecap.link_capabilities = 0x411;  /* gen1, x1 */
> > pciecap.link_status = 0x11; /* gen1, x1 */
> >  
> > 
> > 
> 
> 

___
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: r345138 - head/share/man/man9

[Poul-Henning Kamp]

In message , Andrew Gallatin 
writes:
>On 3/14/19 11:36 PM, Rodney W. Grimes wrote:
>> [ Charset UTF-8 unsupported, converting... ]
>>> On Thu, 14 Mar 2019 at 22:39, Rodney W. Grimes
>>>  wrote:

 4. There is no easy way to show
 "changed byte at offset 0x432 from 0xef to 0xfe"
>> 
>> How do we represent Copyright and License in such objects?
>> This is an issue that is totally left out of even .uu version.

I am pretty sure that some of the .uu files had copyrights in them
at various points, but yes, good point.

-- 
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: r345180 - head/sys/net

[Kyle Evans]

Author: kevans
Date: Fri Mar 15 13:19:52 2019
New Revision: 345180
URL: https://svnweb.freebsd.org/changeset/base/345180

Log:
  if_bridge(4): Fix module teardown
  
  bridge_rtnode_zone still has outstanding allocations at the time of
  destruction in the current model because all of the interface teardown
  happens in a VNET_SYSUNINIT, -after- the MOD_UNLOAD has already been
  processed.  The SYSUNINIT triggers destruction of the interfaces, which then
  attempts to free the memory from the zone that's already been destroyed, and
  we hit a panic.
  
  Solve this by virtualizing the uma_zone we allocate the rtnodes from to fix
  the ordering. bridge_rtable_fini should also take care to flush any
  remaining routes that weren't taken care of when dynamic routes were flushed
  in bridge_stop.
  
  Reviewed by:  kp
  Differential Revision:https://reviews.freebsd.org/D19578

Modified:
  head/sys/net/if_bridge.c

Modified: head/sys/net/if_bridge.c
==
--- head/sys/net/if_bridge.cFri Mar 15 11:49:46 2019(r345179)
+++ head/sys/net/if_bridge.cFri Mar 15 13:19:52 2019(r345180)
@@ -235,7 +235,8 @@ static eventhandler_tag bridge_detach_cookie;
 
 intbridge_rtable_prune_period = BRIDGE_RTABLE_PRUNE_PERIOD;
 
-uma_zone_t bridge_rtnode_zone;
+VNET_DEFINE_STATIC(uma_zone_t, bridge_rtnode_zone);
+#defineV_bridge_rtnode_zoneVNET(bridge_rtnode_zone)
 
 static int bridge_clone_create(struct if_clone *, int, caddr_t);
 static voidbridge_clone_destroy(struct ifnet *);
@@ -527,6 +528,9 @@ static void
 vnet_bridge_init(const void *unused __unused)
 {
 
+   V_bridge_rtnode_zone = uma_zcreate("bridge_rtnode",
+   sizeof(struct bridge_rtnode), NULL, NULL, NULL, NULL,
+   UMA_ALIGN_PTR, 0);
BRIDGE_LIST_LOCK_INIT();
LIST_INIT(_bridge_list);
V_bridge_cloner = if_clone_simple(bridge_name,
@@ -542,6 +546,7 @@ vnet_bridge_uninit(const void *unused __unused)
if_clone_detach(V_bridge_cloner);
V_bridge_cloner = NULL;
BRIDGE_LIST_LOCK_DESTROY();
+   uma_zdestroy(V_bridge_rtnode_zone);
 }
 VNET_SYSUNINIT(vnet_bridge_uninit, SI_SUB_PSEUDO, SI_ORDER_ANY,
 vnet_bridge_uninit, NULL);
@@ -552,9 +557,6 @@ bridge_modevent(module_t mod, int type, void *data)
 
switch (type) {
case MOD_LOAD:
-   bridge_rtnode_zone = uma_zcreate("bridge_rtnode",
-   sizeof(struct bridge_rtnode), NULL, NULL, NULL, NULL,
-   UMA_ALIGN_PTR, 0);
bridge_dn_p = bridge_dummynet;
bridge_detach_cookie = EVENTHANDLER_REGISTER(
ifnet_departure_event, bridge_ifdetach, NULL,
@@ -563,7 +565,6 @@ bridge_modevent(module_t mod, int type, void *data)
case MOD_UNLOAD:
EVENTHANDLER_DEREGISTER(ifnet_departure_event,
bridge_detach_cookie);
-   uma_zdestroy(bridge_rtnode_zone);
bridge_dn_p = NULL;
break;
default:
@@ -730,6 +731,9 @@ bridge_clone_destroy(struct ifnet *ifp)
bridge_delete_span(sc, bif);
}
 
+   /* Tear down the routing table. */
+   bridge_rtable_fini(sc);
+
BRIDGE_UNLOCK(sc);
 
callout_drain(>sc_brcallout);
@@ -742,9 +746,6 @@ bridge_clone_destroy(struct ifnet *ifp)
ether_ifdetach(ifp);
if_free(ifp);
 
-   /* Tear down the routing table. */
-   bridge_rtable_fini(sc);
-
BRIDGE_LOCK_DESTROY(sc);
free(sc, M_DEVBUF);
 }
@@ -2669,7 +2670,7 @@ bridge_rtupdate(struct bridge_softc *sc, const uint8_t
 * initialize the expiration time and Ethernet
 * address.
 */
-   brt = uma_zalloc(bridge_rtnode_zone, M_NOWAIT | M_ZERO);
+   brt = uma_zalloc(V_bridge_rtnode_zone, M_NOWAIT | M_ZERO);
if (brt == NULL)
return (ENOMEM);
 
@@ -2682,7 +2683,7 @@ bridge_rtupdate(struct bridge_softc *sc, const uint8_t
brt->brt_vlan = vlan;
 
if ((error = bridge_rtnode_insert(sc, brt)) != 0) {
-   uma_zfree(bridge_rtnode_zone, brt);
+   uma_zfree(V_bridge_rtnode_zone, brt);
return (error);
}
brt->brt_dst = bif;
@@ -2766,11 +2767,14 @@ bridge_timer(void *arg)
 
BRIDGE_LOCK_ASSERT(sc);
 
+   /* Destruction of rtnodes requires a proper vnet context */
+   CURVNET_SET(sc->sc_ifp->if_vnet);
bridge_rtage(sc);
 
if (sc->sc_ifp->if_drv_flags & IFF_DRV_RUNNING)
callout_reset(>sc_brcallout,
bridge_rtable_prune_period * hz, bridge_timer, sc);
+   CURVNET_RESTORE();
 }
 
 /*
@@ -2886,6 +2890,7 @@ bridge_rtable_fini(struct bridge_softc *sc)
 
KASSERT(sc->sc_brtcnt == 0,
("%s: %d bridge routes 

Re: svn commit: r345138 - head/share/man/man9

[Andrew Gallatin]

On 3/14/19 11:36 PM, Rodney W. Grimes wrote:

[ Charset UTF-8 unsupported, converting... ]

On Thu, 14 Mar 2019 at 22:39, Rodney W. Grimes
 wrote:


4. There is no easy way to show
"changed byte at offset 0x432 from 0xef to 0xfe"


How do we represent Copyright and License in such objects?
This is an issue that is totally left out of even .uu version.



This is an excellent point.  What I used to do for mxge
firmware when I worked at Myricom was to have a shell
script that created a source file with the uuencoded bits
as a static array.  That way, it had copyright info in
the file itself.

Drew
___
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: r345138 - head/share/man/man9

[Bruce Evans]

On Fri, 15 Mar 2019, Poul-Henning Kamp wrote:



In message <201903150152.x2f1q34w027...@gndrsh.dnsmgr.net>, "Rodney W. Grimes"
writes:


The first versions of CTM used diff -e and ed(1) to transmit changes,
and that choked up on binary files.  We didn't have patch in the
tree back then.



patch has always been in the tree.
https://github.com/sergev/4.4BSD-Lite2/tree/master/usr/src/usr.bin/patch


Yes, in *that* tree, but it was not always in *our* tree, particularly
not in the strange time between 1.1.5.1 and 2.0.

Trust me: if it had been, I would not have used diff-e+ed(1)


patch has been in the tree since FreeBSD.1.1.  It was gnu patch, so it
had an unbroken history through the transition to 2.0.  From a FreeBSD-5.2
repository:

XX RCS file: /home/ncvs/src/gnu/usr.bin/patch/patch.c,v
XX Working file: patch.c
XX head: 1.21
XX branch:
XX locks: strict
XX access list:
XX symbolic names:
XX  RELENG_4_10_0_RELEASE: 1.16.2.4
XX  RELENG_4_10: 1.16.2.4.0.6
XX  RELENG_4_10_BP: 1.16.2.4
XX  RELENG_5_2_1_RELEASE: 1.21
XX  RELENG_5_2_0_RELEASE: 1.21
XX  RELENG_5_2: 1.21.0.6
XX  RELENG_5_2_BP: 1.21
XX  RELENG_4_9_0_RELEASE: 1.16.2.4
XX  RELENG_4_9: 1.16.2.4.0.4
XX  RELENG_4_9_BP: 1.16.2.4
XX  RELENG_5_1_0_RELEASE: 1.21
XX  RELENG_5_1: 1.21.0.4
XX  RELENG_5_1_BP: 1.21
XX  RELENG_4_8_0_RELEASE: 1.16.2.4
XX  RELENG_4_8: 1.16.2.4.0.2
XX  RELENG_4_8_BP: 1.16.2.4
XX  RELENG_5_0_0_RELEASE: 1.21
XX  RELENG_5_0: 1.21.0.2
XX  RELENG_5_0_BP: 1.21
XX  RELENG_4_7_0_RELEASE: 1.16.2.3
XX  RELENG_4_7: 1.16.2.3.0.4
XX  RELENG_4_7_BP: 1.16.2.3
XX  RELENG_4_6_2_RELEASE: 1.16.2.3
XX  RELENG_4_6_1_RELEASE: 1.16.2.3
XX  RELENG_4_6_0_RELEASE: 1.16.2.3
XX  RELENG_4_6: 1.16.2.3.0.2
XX  RELENG_4_6_BP: 1.16.2.3
XX  RELENG_4_5_0_RELEASE: 1.16.2.1
XX  RELENG_4_5: 1.16.2.1.0.6
XX  RELENG_4_5_BP: 1.16.2.1
XX  RELENG_4_4_0_RELEASE: 1.16.2.1
XX  RELENG_4_4: 1.16.2.1.0.4
XX  RELENG_4_4_BP: 1.16.2.1
XX  RELENG_4_3_0_RELEASE: 1.16.2.1
XX  RELENG_4_3: 1.16.2.1.0.2
XX  RELENG_4_3_BP: 1.16.2.1
XX  RELENG_4_2_0_RELEASE: 1.16.2.1
XX  RELENG_4_1_1_RELEASE: 1.16.2.1
XX  PRE_SMPNG: 1.18
XX  RELENG_4_1_0_RELEASE: 1.16
XX  RELENG_3_5_0_RELEASE: 1.14.2.1
XX  RELENG_4_0_0_RELEASE: 1.16
XX  RELENG_4: 1.16.0.2
XX  RELENG_4_BP: 1.16
XX  RELENG_3_4_0_RELEASE: 1.14.2.1
XX  RELENG_3_3_0_RELEASE: 1.14.2.1
XX  RELENG_3_2_PAO: 1.14.0.4
XX  RELENG_3_2_PAO_BP: 1.14
XX  RELENG_3_2_0_RELEASE: 1.14
XX  RELENG_3_1_0_RELEASE: 1.14
XX  RELENG_3: 1.14.0.2
XX  RELENG_3_BP: 1.14
XX  RELENG_2_2_8_RELEASE: 1.6.6.3
XX  RELENG_3_0_0_RELEASE: 1.14
XX  RELENG_2_2_7_RELEASE: 1.6.6.3
XX  RELENG_2_2_6_RELEASE: 1.6.6.3
XX  RELENG_2_2_5_RELEASE: 1.6.6.1
XX  RELENG_2_2_2_RELEASE: 1.6.6.1
XX  RELENG_2_2_1_RELEASE: 1.6.6.1
XX  RELENG_2_2_0_RELEASE: 1.6
XX  RELENG_2_1_7_RELEASE: 1.6.4.1
XX  RELENG_2_1_6_1_RELEASE: 1.6.4.1
XX  RELENG_2_1_6_RELEASE: 1.6.4.1
XX  RELENG_2_2: 1.6.0.6
XX  RELENG_2_2_BP: 1.6
XX  RELENG_2_1_5_RELEASE: 1.6.4.1
XX  RELENG_2_1_0_RELEASE: 1.6
XX  RELENG_2_1_0: 1.6.0.4
XX  RELENG_2_1_0_BP: 1.6
XX  RELENG_2_0_5_RELEASE: 1.6
XX  RELENG_2_0_5: 1.6.0.2
XX  RELENG_2_0_5_BP: 1.6
XX  RELENG_2_0_5_ALPHA: 1.5
XX  RELEASE_2_0: 1.4
XX  BETA_2_0: 1.4
XX  ALPHA_2_0: 1.4.0.2
XX  MOVED_NEWCVS: 1.4
XX  FINAL_1_1_5: 1.4
XX  ALPHA_1_1_5: 1.4
XX  FINAL_1_1: 1.3
XX  GAMMA_1_1: 1.3
XX  BETA_1_1: 1.3.0.2
XX  BP_BETA_1_1: 1.3
XX  FINAL_1_0: 1.1.1.1
XX  EPSILON_1_0: 1.1.1.1
XX  GAMMA_1_0: 1.1.1.1
XX  BETA_1_0: 1.1.1.1
XX  ALPHA_1_0: 1.1.1.1
XX  V2_10: 1.1.1.1
XX keyword substitution: kv
XX total revisions: 33; selected revisions: 33
XX description:
XX 
XX revision 1.21
XX date: 2002/10/13 01:18:33;  author: kris;  state: Exp;  lines: +7 -6
XX Prevent stack-smashing buffer overflows in -D and -r options by using
XX buffer-safe string functions.  The rest of the code is still probably
XX unsafe.
XX 
XX MFC after:	1 week

XX ...
XX 
XX revision 1.2
XX date: 1994/02/17 22:16:03;  author: jkh;  state: Exp;  lines: +21 -7
XX From Poul-Henning Kamp -  Implement a -C option to verify the integrity of
XX a patch before actually applying it.
XX 
XX revision 1.1
XX date: 1993/06/19 14:21:51;  author: paul;  state: Exp;
XX branches:  1.1.1;
XX Initial revision
XX 
XX revision 1.1.1.1
XX date: 1993/06/19 14:21:52;  author: paul;  state: Exp;  lines: +0 -0
XX b-maked patch-2.10
XX 

I don't know how to find the old history using svn.  svn log doesn't show
removed files.  It is hard to find where the files were unless you already
know the history.  svn log on stable/5/gnu/usr.bin/patch/patch.c only shows
history on 

svn commit: r345179 - head/sys/fs/ext2fs

[Fedor Uporov]

Author: fsu
Date: Fri Mar 15 11:49:46 2019
New Revision: 345179
URL: https://svnweb.freebsd.org/changeset/base/345179

Log:
  Remove unneeded mount point unlock function calls.
  
  The ext2_nodealloccg() function unlocks the mount point
  in case of successful node allocation.
  The additional unlocks are not required and should be removed.
  
  PR:   236452
  Reported by:  pho
  MFC after:3 days

Modified:
  head/sys/fs/ext2fs/ext2_alloc.c

Modified: head/sys/fs/ext2fs/ext2_alloc.c
==
--- head/sys/fs/ext2fs/ext2_alloc.c Fri Mar 15 11:21:20 2019
(r345178)
+++ head/sys/fs/ext2fs/ext2_alloc.c Fri Mar 15 11:49:46 2019
(r345179)
@@ -412,23 +412,21 @@ ext2_valloc(struct vnode *pvp, int mode, struct ucred 
td = curthread;
error = vfs_hash_get(ump->um_mountp, ino, LK_EXCLUSIVE, td, vpp, NULL, 
NULL);
if (error || *vpp != NULL) {
-   EXT2_UNLOCK(ump);
return (error);
}
 
ip = malloc(sizeof(struct inode), M_EXT2NODE, M_WAITOK | M_ZERO);
if (ip == NULL) {
-   EXT2_UNLOCK(ump);
return (ENOMEM);
}
 
/* Allocate a new vnode/inode. */
if ((error = getnewvnode("ext2fs", ump->um_mountp, _vnodeops, 
)) != 0) {
free(ip, M_EXT2NODE);
-   EXT2_UNLOCK(ump);
return (error);
}
 
+   lockmgr(vp->v_vnlock, LK_EXCLUSIVE, NULL);
vp->v_data = ip;
ip->i_vnode = vp;
ip->i_e2fs = fs = ump->um_e2fs;
@@ -438,11 +436,9 @@ ext2_valloc(struct vnode *pvp, int mode, struct ucred 
ip->i_next_alloc_block = 0;
ip->i_next_alloc_goal = 0;
 
-   lockmgr(vp->v_vnlock, LK_EXCLUSIVE, NULL);
error = insmntque(vp, ump->um_mountp);
if (error) {
free(ip, M_EXT2NODE);
-   EXT2_UNLOCK(ump);
return (error);
}
 
@@ -450,7 +446,6 @@ ext2_valloc(struct vnode *pvp, int mode, struct ucred 
if (error || *vpp != NULL) {
*vpp = NULL;
free(ip, M_EXT2NODE);
-   EXT2_UNLOCK(ump);
return (error);
}
 
@@ -458,7 +453,6 @@ ext2_valloc(struct vnode *pvp, int mode, struct ucred 
vput(vp);
*vpp = NULL;
free(ip, M_EXT2NODE);
-   EXT2_UNLOCK(ump);
return (error);
}
 
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

svn commit: r345178 - head/sys/net

[Kristof Provost]

Author: kp
Date: Fri Mar 15 11:21:20 2019
New Revision: 345178
URL: https://svnweb.freebsd.org/changeset/base/345178

Log:
  bridge: Fix panic if the STP root is removed
  
  If the spanning tree root interface is removed from the bridge we panic
  on the next 'ifconfig'.
  While the STP code is notified whenever a bridge member interface is
  removed from the bridge it does not clear the bs_root_port. This means
  bs_root_port can still point at an bridge_iflist which has been free()d.
  The next access to it will panic.
  
  Explicitly check if the interface we're removing in bstp_destroy() is
  the root, and if so re-assign the roles, which clears bs_root_port.
  
  Reviewed by:  philip
  MFC after:2 weeks

Modified:
  head/sys/net/bridgestp.c

Modified: head/sys/net/bridgestp.c
==
--- head/sys/net/bridgestp.cFri Mar 15 11:08:44 2019(r345177)
+++ head/sys/net/bridgestp.cFri Mar 15 11:21:20 2019(r345178)
@@ -2274,4 +2274,7 @@ bstp_destroy(struct bstp_port *bp)
taskqueue_drain(taskqueue_swi, >bp_statetask);
taskqueue_drain(taskqueue_swi, >bp_rtagetask);
taskqueue_drain(taskqueue_swi, >bp_mediatask);
+
+   if (bp->bp_bs->bs_root_port == bp)
+   bstp_assign_roles(bp->bp_bs);
 }
___
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: r345177 - in head/sys: net netpfil/pf

[Kristof Provost]

Author: kp
Date: Fri Mar 15 11:08:44 2019
New Revision: 345177
URL: https://svnweb.freebsd.org/changeset/base/345177

Log:
  pf :Use counter(9) in pf tables.
  
  The counters of pf tables are updated outside the rule lock. That means state
  updates might overwrite each other. Furthermore allocation and
  freeing of counters happens outside the lock as well.
  
  Use counter(9) for the counters, and always allocate the counter table
  element, so that the race condition cannot happen any more.
  
  PR:   230619
  Submitted by: Kajetan Staszkiewicz 
  Reviewed by:  glebius
  MFC after:2 weeks
  Differential Revision:https://reviews.freebsd.org/D19558

Modified:
  head/sys/net/pfvar.h
  head/sys/netpfil/pf/pf_table.c

Modified: head/sys/net/pfvar.h
==
--- head/sys/net/pfvar.hFri Mar 15 11:01:52 2019(r345176)
+++ head/sys/net/pfvar.hFri Mar 15 11:08:44 2019(r345177)
@@ -1021,6 +1021,17 @@ struct pfr_tstats {
int  pfrts_cnt;
int  pfrts_refcnt[PFR_REFCNT_MAX];
 };
+
+struct pfr_ktstats {
+   struct pfr_table pfrts_t;
+   counter_u64_tpfrkts_packets[PFR_DIR_MAX][PFR_OP_TABLE_MAX];
+   counter_u64_tpfrkts_bytes[PFR_DIR_MAX][PFR_OP_TABLE_MAX];
+   counter_u64_tpfrkts_match;
+   counter_u64_tpfrkts_nomatch;
+   long pfrkts_tzero;
+   int  pfrkts_cnt;
+   int  pfrkts_refcnt[PFR_REFCNT_MAX];
+};
 #definepfrts_name  pfrts_t.pfrt_name
 #define pfrts_flagspfrts_t.pfrt_flags
 
@@ -1034,8 +1045,9 @@ union sockaddr_union {
 #endif /* _SOCKADDR_UNION_DEFINED */
 
 struct pfr_kcounters {
-   u_int64_tpfrkc_packets[PFR_DIR_MAX][PFR_OP_ADDR_MAX];
-   u_int64_tpfrkc_bytes[PFR_DIR_MAX][PFR_OP_ADDR_MAX];
+   counter_u64_tpfrkc_packets[PFR_DIR_MAX][PFR_OP_ADDR_MAX];
+   counter_u64_tpfrkc_bytes[PFR_DIR_MAX][PFR_OP_ADDR_MAX];
+   long pfrkc_tzero;
 };
 
 SLIST_HEAD(pfr_kentryworkq, pfr_kentry);
@@ -1043,8 +1055,7 @@ struct pfr_kentry {
struct radix_nodepfrke_node[2];
union sockaddr_union pfrke_sa;
SLIST_ENTRY(pfr_kentry)  pfrke_workq;
-   struct pfr_kcounters*pfrke_counters;
-   long pfrke_tzero;
+   struct pfr_kcounters pfrke_counters;
u_int8_t pfrke_af;
u_int8_t pfrke_net;
u_int8_t pfrke_not;
@@ -1054,7 +1065,7 @@ struct pfr_kentry {
 SLIST_HEAD(pfr_ktableworkq, pfr_ktable);
 RB_HEAD(pfr_ktablehead, pfr_ktable);
 struct pfr_ktable {
-   struct pfr_tstatspfrkt_ts;
+   struct pfr_ktstats   pfrkt_kts;
RB_ENTRY(pfr_ktable) pfrkt_tree;
SLIST_ENTRY(pfr_ktable)  pfrkt_workq;
struct radix_node_head  *pfrkt_ip4;
@@ -1065,18 +1076,18 @@ struct pfr_ktable {
long pfrkt_larg;
int  pfrkt_nflags;
 };
-#define pfrkt_tpfrkt_ts.pfrts_t
+#define pfrkt_tpfrkt_kts.pfrts_t
 #define pfrkt_name pfrkt_t.pfrt_name
 #define pfrkt_anchor   pfrkt_t.pfrt_anchor
 #define pfrkt_ruleset  pfrkt_t.pfrt_ruleset
 #define pfrkt_flagspfrkt_t.pfrt_flags
-#define pfrkt_cnt  pfrkt_ts.pfrts_cnt
-#define pfrkt_refcnt   pfrkt_ts.pfrts_refcnt
-#define pfrkt_packets  pfrkt_ts.pfrts_packets
-#define pfrkt_bytespfrkt_ts.pfrts_bytes
-#define pfrkt_matchpfrkt_ts.pfrts_match
-#define pfrkt_nomatch  pfrkt_ts.pfrts_nomatch
-#define pfrkt_tzeropfrkt_ts.pfrts_tzero
+#define pfrkt_cnt  pfrkt_kts.pfrkts_cnt
+#define pfrkt_refcnt   pfrkt_kts.pfrkts_refcnt
+#define pfrkt_packets  pfrkt_kts.pfrkts_packets
+#define pfrkt_bytespfrkt_kts.pfrkts_bytes
+#define pfrkt_matchpfrkt_kts.pfrkts_match
+#define pfrkt_nomatch  pfrkt_kts.pfrkts_nomatch
+#define pfrkt_tzeropfrkt_kts.pfrkts_tzero
 
 /* keep synced with pfi_kif, used in RB_FIND */
 struct pfi_kif_cmp {

Modified: head/sys/netpfil/pf/pf_table.c
==
--- head/sys/netpfil/pf/pf_table.c  Fri Mar 15 11:01:52 2019
(r345176)
+++ head/sys/netpfil/pf/pf_table.c  Fri Mar 15 11:08:44 2019
(r345177)
@@ -113,6 +113,7 @@ struct pfr_walktree {
struct pfi_dynaddr  *pfrw1_dyn;
}pfrw_1;
int  pfrw_free;
+   int  pfrw_flags;
 };
 #definepfrw_addr   pfrw_1.pfrw1_addr
 #definepfrw_astats pfrw_1.pfrw1_astats
@@ -126,15 +127,16 @@ struct pfr_walktree {
 static MALLOC_DEFINE(M_PFTABLE, "pf_table", "pf(4) tables structures");
 VNET_DEFINE_STATIC(uma_zone_t, pfr_kentry_z);
 #defineV_pfr_kentry_z  VNET(pfr_kentry_z)
-VNET_DEFINE_STATIC(uma_zone_t, pfr_kcounters_z);
-#defineV_pfr_kcounters_z

svn commit: r345176 - stable/11/sys/netpfil/pf

[Kristof Provost]

Author: kp
Date: Fri Mar 15 11:01:52 2019
New Revision: 345176
URL: https://svnweb.freebsd.org/changeset/base/345176

Log:
  MFC r344921:
  
  pf: Fix DIOCGETSRCNODES
  
  r343295 broke DIOCGETSRCNODES by failing to reset 'nr' after counting the
  number of source tracking nodes.
  This meant that we never copied the information to userspace, leading to '? ->
  ?' output from pfctl.
  
  PR:   236368

Modified:
  stable/11/sys/netpfil/pf/pf_ioctl.c
Directory Properties:
  stable/11/   (props changed)

Modified: stable/11/sys/netpfil/pf/pf_ioctl.c
==
--- stable/11/sys/netpfil/pf/pf_ioctl.c Fri Mar 15 11:01:49 2019
(r345175)
+++ stable/11/sys/netpfil/pf/pf_ioctl.c Fri Mar 15 11:01:52 2019
(r345176)
@@ -3326,6 +3326,8 @@ DIOCCHANGEADDR_error:
break;
}
 
+   nr = 0;
+
p = pstore = malloc(psn->psn_len, M_TEMP, M_WAITOK);
for (i = 0, sh = V_pf_srchash; i <= pf_srchashmask;
i++, sh++) {
___
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: r345175 - stable/12/sys/netpfil/pf

[Kristof Provost]

Author: kp
Date: Fri Mar 15 11:01:49 2019
New Revision: 345175
URL: https://svnweb.freebsd.org/changeset/base/345175

Log:
  MFC r344921:
  
  pf: Fix DIOCGETSRCNODES
  
  r343295 broke DIOCGETSRCNODES by failing to reset 'nr' after counting the
  number of source tracking nodes.
  This meant that we never copied the information to userspace, leading to '? ->
  ?' output from pfctl.
  
  PR:   236368

Modified:
  stable/12/sys/netpfil/pf/pf_ioctl.c
Directory Properties:
  stable/12/   (props changed)

Modified: stable/12/sys/netpfil/pf/pf_ioctl.c
==
--- stable/12/sys/netpfil/pf/pf_ioctl.c Fri Mar 15 08:21:11 2019
(r345174)
+++ stable/12/sys/netpfil/pf/pf_ioctl.c Fri Mar 15 11:01:49 2019
(r345175)
@@ -3754,6 +3754,8 @@ DIOCCHANGEADDR_error:
break;
}
 
+   nr = 0;
+
p = pstore = malloc(psn->psn_len, M_TEMP, M_WAITOK);
for (i = 0, sh = V_pf_srchash; i <= pf_srchashmask;
i++, sh++) {
___
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: r345174 - stable/10/sbin/ifconfig

[Andriy Voskoboinyk]

Author: avos
Date: Fri Mar 15 08:21:11 2019
New Revision: 345174
URL: https://svnweb.freebsd.org/changeset/base/345174

Log:
  MFC r344748:
  Allow to build ifconfig(8) without wireless support
  
  The change removes SIOC[GS]IEEE80211 handling from ifconfig(8)
  if WITHOUT_WIRELESS_SUPPORT=yes is set in src.conf(5).
  
  Reviewed by:  bz
  Differential Revision:https://reviews.freebsd.org/D19289

Modified:
  stable/10/sbin/ifconfig/Makefile
Directory Properties:
  stable/10/   (props changed)

Modified: stable/10/sbin/ifconfig/Makefile
==
--- stable/10/sbin/ifconfig/MakefileFri Mar 15 08:18:02 2019
(r345173)
+++ stable/10/sbin/ifconfig/MakefileFri Mar 15 08:21:11 2019
(r345174)
@@ -39,9 +39,11 @@ SRCS+=   sfp.c   # SFP/SFP+ information
 DPADD+=${LIBM}
 LDADD+=-lm
 
+.if ${MK_WIRELESS_SUPPORT} != "no"
 SRCS+= ifieee80211.c regdomain.c # SIOC[GS]IEEE80211 support
 DPADD+=${LIBBSDXML} ${LIBSBUF}
 LDADD+=-lbsdxml -lsbuf
+.endif
 
 SRCS+= carp.c  # SIOC[GS]VH support
 SRCS+= ifgroup.c   # ...
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

svn commit: r345173 - in stable: 11/sbin/ifconfig 12/sbin/ifconfig

[Andriy Voskoboinyk]

Author: avos
Date: Fri Mar 15 08:18:02 2019
New Revision: 345173
URL: https://svnweb.freebsd.org/changeset/base/345173

Log:
  MFC r344748:
  Allow to build ifconfig(8) without wireless support
  
  The change removes SIOC[GS]IEEE80211 handling from ifconfig(8)
  if WITHOUT_WIRELESS_SUPPORT=yes is set in src.conf(5).
  
  Reviewed by:  bz
  Differential Revision:https://reviews.freebsd.org/D19289

Modified:
  stable/12/sbin/ifconfig/Makefile
Directory Properties:
  stable/12/   (props changed)

Changes in other areas also in this revision:
Modified:
  stable/11/sbin/ifconfig/Makefile
Directory Properties:
  stable/11/   (props changed)

Modified: stable/12/sbin/ifconfig/Makefile
==
--- stable/12/sbin/ifconfig/MakefileFri Mar 15 07:34:06 2019
(r345172)
+++ stable/12/sbin/ifconfig/MakefileFri Mar 15 08:18:02 2019
(r345173)
@@ -39,8 +39,10 @@ SRCS+=   ifipsec.c   # IPsec VTI
 SRCS+= sfp.c   # SFP/SFP+ information
 LIBADD+=   m
 
+.if ${MK_WIRELESS_SUPPORT} != "no"
 SRCS+= ifieee80211.c   # SIOC[GS]IEEE80211 support
 LIBADD+=   80211
+.endif
 
 SRCS+= carp.c  # SIOC[GS]VH support
 SRCS+= ifgroup.c   # ...
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

svn commit: r345173 - in stable: 11/sbin/ifconfig 12/sbin/ifconfig

[Andriy Voskoboinyk]

Author: avos
Date: Fri Mar 15 08:18:02 2019
New Revision: 345173
URL: https://svnweb.freebsd.org/changeset/base/345173

Log:
  MFC r344748:
  Allow to build ifconfig(8) without wireless support
  
  The change removes SIOC[GS]IEEE80211 handling from ifconfig(8)
  if WITHOUT_WIRELESS_SUPPORT=yes is set in src.conf(5).
  
  Reviewed by:  bz
  Differential Revision:https://reviews.freebsd.org/D19289

Modified:
  stable/11/sbin/ifconfig/Makefile
Directory Properties:
  stable/11/   (props changed)

Changes in other areas also in this revision:
Modified:
  stable/12/sbin/ifconfig/Makefile
Directory Properties:
  stable/12/   (props changed)

Modified: stable/11/sbin/ifconfig/Makefile
==
--- stable/11/sbin/ifconfig/MakefileFri Mar 15 07:34:06 2019
(r345172)
+++ stable/11/sbin/ifconfig/MakefileFri Mar 15 08:18:02 2019
(r345173)
@@ -39,8 +39,10 @@ SRCS+=   ifipsec.c   # IPsec VTI
 SRCS+= sfp.c   # SFP/SFP+ information
 LIBADD+=   m
 
+.if ${MK_WIRELESS_SUPPORT} != "no"
 SRCS+= ifieee80211.c   # SIOC[GS]IEEE80211 support
 LIBADD+=   80211
+.endif
 
 SRCS+= carp.c  # SIOC[GS]VH support
 SRCS+= ifgroup.c   # ...
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

svn commit: r345172 - stable/12/sys/dev/iwm

[Andriy Voskoboinyk]

Author: avos
Date: Fri Mar 15 07:34:06 2019
New Revision: 345172
URL: https://svnweb.freebsd.org/changeset/base/345172

Log:
  MFC r345002:
  iwm(4): use correct channel list source for Intel 3168
  
  Intel 3168 uses another EEPROM section to store channel flags;
  port missing bits from iwlwifi to make it work.
  
  PR:   230750, 236235
  Tested by:Bert JW Regeer 

Modified:
  stable/12/sys/dev/iwm/if_iwm.c
  stable/12/sys/dev/iwm/if_iwm_7000.c
  stable/12/sys/dev/iwm/if_iwm_config.h
  stable/12/sys/dev/iwm/if_iwmreg.h
Directory Properties:
  stable/12/   (props changed)

Modified: stable/12/sys/dev/iwm/if_iwm.c
==
--- stable/12/sys/dev/iwm/if_iwm.c  Fri Mar 15 02:11:28 2019
(r345171)
+++ stable/12/sys/dev/iwm/if_iwm.c  Fri Mar 15 07:34:06 2019
(r345172)
@@ -2237,7 +2237,8 @@ iwm_parse_nvm_data(struct iwm_softc *sc,
}
 
if (sc->cfg->device_family == IWM_DEVICE_FAMILY_7000) {
-   memcpy(data->nvm_ch_flags, _sw[IWM_NVM_CHANNELS],
+   memcpy(data->nvm_ch_flags, sc->cfg->nvm_type == IWM_NVM_SDP ?
+   [0] : _sw[IWM_NVM_CHANNELS],
IWM_NUM_CHANNELS * sizeof(uint16_t));
} else {
memcpy(data->nvm_ch_flags, [IWM_NVM_CHANNELS_8000],
@@ -2297,8 +2298,9 @@ iwm_parse_nvm_sections(struct iwm_softc *sc, struct iw
sw = (const uint16_t *)sections[IWM_NVM_SECTION_TYPE_SW].data;
calib = (const uint16_t *)
sections[IWM_NVM_SECTION_TYPE_CALIBRATION].data;
-   regulatory = (const uint16_t *)
-   sections[IWM_NVM_SECTION_TYPE_REGULATORY].data;
+   regulatory = sc->cfg->nvm_type == IWM_NVM_SDP ?
+   (const uint16_t 
*)sections[IWM_NVM_SECTION_TYPE_REGULATORY_SDP].data :
+   (const uint16_t *)sections[IWM_NVM_SECTION_TYPE_REGULATORY].data;
mac_override = (const uint16_t *)
sections[IWM_NVM_SECTION_TYPE_MAC_OVERRIDE].data;
phy_sku = (const uint16_t *)sections[IWM_NVM_SECTION_TYPE_PHY_SKU].data;

Modified: stable/12/sys/dev/iwm/if_iwm_7000.c
==
--- stable/12/sys/dev/iwm/if_iwm_7000.c Fri Mar 15 02:11:28 2019
(r345171)
+++ stable/12/sys/dev/iwm/if_iwm_7000.c Fri Mar 15 07:34:06 2019
(r345172)
@@ -119,6 +119,7 @@ const struct iwm_cfg iwm3168_cfg = {
.fw_name = IWM3168_FW,
IWM_DEVICE_7000_COMMON,
.host_interrupt_operation_mode = 0,
+   .nvm_type = IWM_NVM_SDP,
 };
 
 const struct iwm_cfg iwm7265_cfg = {

Modified: stable/12/sys/dev/iwm/if_iwm_config.h
==
--- stable/12/sys/dev/iwm/if_iwm_config.h   Fri Mar 15 02:11:28 2019
(r345171)
+++ stable/12/sys/dev/iwm/if_iwm_config.h   Fri Mar 15 07:34:06 2019
(r345172)
@@ -102,7 +102,20 @@ static inline uint8_t num_of_ant(uint8_t mask)
 #define IWM_OTP_LOW_IMAGE_SIZE_FAMILY_8000 (32 * 512 * sizeof(uint16_t)) 
/* 32 KB */
 #define IWM_OTP_LOW_IMAGE_SIZE_FAMILY_9000 
IWM_OTP_LOW_IMAGE_SIZE_FAMILY_8000
 
+
 /**
+ * enum iwl_nvm_type - nvm formats
+ * @IWM_NVM: the regular format
+ * @IWM_NVM_EXT: extended NVM format
+ * @IWM_NVM_SDP: NVM format used by 3168 series
+ */
+enum iwm_nvm_type {
+   IWM_NVM,
+   IWM_NVM_EXT,
+   IWM_NVM_SDP,
+};
+
+/**
  * struct iwm_cfg
  * @name: Official name of the device
  * @fw_name: Firmware filename.
@@ -111,6 +124,7 @@ static inline uint8_t num_of_ant(uint8_t mask)
  * @nvm_hw_section_num: the ID of the HW NVM section
  * @apmg_wake_up_wa: should the MAC access REQ be asserted when a command
  *  is in flight. This is due to a HW bug in 7260, 3160 and 7265.
+ * @nvm_type: see  iwl_nvm_type
  */
 struct iwm_cfg {
const char *name;
@@ -120,6 +134,7 @@ struct iwm_cfg {
 int host_interrupt_operation_mode;
 uint8_t nvm_hw_section_num;
 int apmg_wake_up_wa;
+enum iwm_nvm_type nvm_type;
 };
 
 /*

Modified: stable/12/sys/dev/iwm/if_iwmreg.h
==
--- stable/12/sys/dev/iwm/if_iwmreg.h   Fri Mar 15 02:11:28 2019
(r345171)
+++ stable/12/sys/dev/iwm/if_iwmreg.h   Fri Mar 15 07:34:06 2019
(r345172)
@@ -1992,6 +1992,7 @@ enum {
IWM_NVM_SECTION_TYPE_REGULATORY = 3,
IWM_NVM_SECTION_TYPE_CALIBRATION = 4,
IWM_NVM_SECTION_TYPE_PRODUCTION = 5,
+   IWM_NVM_SECTION_TYPE_REGULATORY_SDP = 8,
IWM_NVM_SECTION_TYPE_MAC_OVERRIDE = 11,
IWM_NVM_SECTION_TYPE_PHY_SKU = 12,
IWM_NVM_MAX_NUM_SECTIONS = 13,
___
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: r345151 - head/sys/net

[Marko Zec]

On Thu, 14 Mar 2019 20:14:14 +
"Bjoern A. Zeeb"  wrote:

> On 14 Mar 2019, at 19:48, Kyle Evans wrote:
> 
> > Author: kevans
> > Date: Thu Mar 14 19:48:43 2019
> > New Revision: 345151
> > URL: https://svnweb.freebsd.org/changeset/base/345151
> >
> > Log:
> >   ether_fakeaddr: Use 'b' 's' 'd' for the prefix
...
> epair(4) is yet another one of the cloned interfaces which does magic 
> for the ethernet addresses, not sure what else.

ng_eiface(4) currently does not autogenerate a fake MAC address
(defaults to all zeros), but it could be useful if it would, in a
way consistent to the rest of the clonable fake ethernet ifcs...

Marko
___
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: r345138 - head/share/man/man9

[Poul-Henning Kamp]

In message <201903150152.x2f1q34w027...@gndrsh.dnsmgr.net>, "Rodney W. Grimes" 
writes:

>> The first versions of CTM used diff -e and ed(1) to transmit changes,
>> and that choked up on binary files.  We didn't have patch in the
>> tree back then.

>patch has always been in the tree.
>https://github.com/sergev/4.4BSD-Lite2/tree/master/usr/src/usr.bin/patch

Yes, in *that* tree, but it was not always in *our* tree, particularly
not in the strange time between 1.1.5.1 and 2.0.

Trust me: if it had been, I would not have used diff-e+ed(1)


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