svn commit: r343569 - head/sys/dev/cxgbe/iw_cxgbe

[Navdeep Parhar]

Author: np
Date: Wed Jan 30 05:39:47 2019
New Revision: 343569
URL: https://svnweb.freebsd.org/changeset/base/343569

Log:
  cxgbe/iw_cxgbe: Fix an address calculation in the memory registration code 
that
  was added in r342266.
  
  Submitted by: Krishnamraju Eraparaju @ Chelsio
  Sponsored by: Chelsio Communications

Modified:
  head/sys/dev/cxgbe/iw_cxgbe/mem.c

Modified: head/sys/dev/cxgbe/iw_cxgbe/mem.c
==
--- head/sys/dev/cxgbe/iw_cxgbe/mem.c   Wed Jan 30 02:39:08 2019
(r343568)
+++ head/sys/dev/cxgbe/iw_cxgbe/mem.c   Wed Jan 30 05:39:47 2019
(r343569)
@@ -207,7 +207,7 @@ _c4iw_write_mem_dma(struct c4iw_rdev *rdev, u32 addr, 
if (ret)
goto out;
addr += dmalen >> 5;
-   data = (u64 *)data + dmalen;
+   data = (u8 *)data + dmalen;
daddr = daddr + dmalen;
}
if (remain)
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r343566 - in head/lib/libthr: . thread

[Alexey Dokuchaev]

On Tue, Jan 29, 2019 at 10:46:45PM +, Konstantin Belousov wrote:
> New Revision: 343566
> URL: https://svnweb.freebsd.org/changeset/base/343566
> 
> Log:
>   Untangle jemalloc and mutexes initialization.
>   
>   The need to use libc malloc(3) from some places in libthr always
>   caused issues.  For instance, per-thread key allocation was switched to
>   use plain mmap(2) to get storage, because some third party mallocs
>   used keys for implementation of calloc(3).
>   
>   Even more important, libthr calls calloc(3) during initialization of
>   pthread mutexes, and jemalloc uses pthread mutexes.  Jemalloc provides
>   some way to both postpone the initialization, and to make
>   initialization to use specialized allocator, but this is very fragile
>   and often breaks.  See the referenced PR for another example.

Could this also fix https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=220767
I wonder...  Going through the "make world" now to test some Quake II. :-)

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

svn commit: r343567 - in head: lib/libkvm sys/conf sys/dev/dcons sys/dev/fb sys/dev/syscons sys/i386/acpica sys/i386/i386 sys/i386/include sys/i386/pci sys/x86/acpica sys/x86/include sys/x86/x86

[Konstantin Belousov]

Author: kib
Date: Wed Jan 30 02:07:13 2019
New Revision: 343567
URL: https://svnweb.freebsd.org/changeset/base/343567

Log:
  i386: Merge PAE and non-PAE pmaps into same kernel.
  
  Effectively all i386 kernels now have two pmaps compiled in: one
  managing PAE pagetables, and another non-PAE. The implementation is
  selected at cold time depending on the CPU features. The vm_paddr_t is
  always 64bit now. As result, nx bit can be used on all capable CPUs.
  
  Option PAE only affects the bus_addr_t: it is still 32bit for non-PAE
  configs, for drivers compatibility. Kernel layout, esp. max kernel
  address, low memory PDEs and max user address (same as trampoline
  start) are now same for PAE and for non-PAE regardless of the type of
  page tables used.
  
  Non-PAE kernel (when using PAE pagetables) can handle physical memory
  up to 24G now, larger memory requires re-tuning the KVA consumers and
  instead the code caps the maximum at 24G. Unfortunately, a lot of
  drivers do not use busdma(9) properly so by default even 4G barrier is
  not easy. There are two tunables added: hw.above4g_allow and
  hw.above24g_allow, the first one is kept enabled for now to evaluate
  the status on HEAD, second is only for dev use.
  
  i386 now creates three freelists if there is any memory above 4G, to
  allow proper bounce pages allocation. Also, VM_KMEM_SIZE_SCALE changed
  from 3 to 1.
  
  The PAE_TABLES kernel config option is retired.
  
  In collaboarion with: pho
  Discussed with:   emaste
  Reviewed by:  markj
  MFC after:2 weeks
  Sponsored by: The FreeBSD Foundation
  Differential revision:https://reviews.freebsd.org/D18894

Added:
  head/sys/i386/i386/minidump_machdep_base.c
 - copied, changed from r343566, head/sys/i386/i386/minidump_machdep.c
  head/sys/i386/i386/minidump_machdep_nopae.c
 - copied, changed from r343566, head/sys/i386/i386/minidump_machdep.c
  head/sys/i386/i386/minidump_machdep_pae.c
 - copied, changed from r343566, head/sys/i386/i386/minidump_machdep.c
  head/sys/i386/i386/pmap_base.c   (contents, props changed)
  head/sys/i386/i386/pmap_nopae.c   (contents, props changed)
  head/sys/i386/i386/pmap_pae.c   (contents, props changed)
  head/sys/i386/include/pmap_base.h   (contents, props changed)
  head/sys/i386/include/pmap_nopae.h   (contents, props changed)
  head/sys/i386/include/pmap_pae.h   (contents, props changed)
Modified:
  head/lib/libkvm/kvm_i386.h
  head/sys/conf/files.i386
  head/sys/conf/options.i386
  head/sys/dev/dcons/dcons_os.c
  head/sys/dev/fb/fb.c
  head/sys/dev/fb/fbreg.h
  head/sys/dev/fb/vga.c
  head/sys/dev/fb/vgareg.h
  head/sys/dev/syscons/syscons.c
  head/sys/i386/acpica/acpi_machdep.c
  head/sys/i386/i386/bios.c
  head/sys/i386/i386/copyout.c
  head/sys/i386/i386/genassym.c
  head/sys/i386/i386/initcpu.c
  head/sys/i386/i386/locore.s
  head/sys/i386/i386/machdep.c
  head/sys/i386/i386/mem.c
  head/sys/i386/i386/minidump_machdep.c
  head/sys/i386/i386/mp_machdep.c
  head/sys/i386/i386/mpboot.s
  head/sys/i386/i386/pmap.c
  head/sys/i386/i386/trap.c
  head/sys/i386/i386/vm86.c
  head/sys/i386/i386/vm86bios.s
  head/sys/i386/i386/vm_machdep.c
  head/sys/i386/include/md_var.h
  head/sys/i386/include/param.h
  head/sys/i386/include/pmap.h
  head/sys/i386/include/vm86.h
  head/sys/i386/include/vmparam.h
  head/sys/i386/pci/pci_cfgreg.c
  head/sys/x86/acpica/acpi_wakeup.c
  head/sys/x86/include/_types.h
  head/sys/x86/include/x86_var.h
  head/sys/x86/x86/identcpu.c

Modified: head/lib/libkvm/kvm_i386.h
==
--- head/lib/libkvm/kvm_i386.h  Tue Jan 29 22:46:44 2019(r343566)
+++ head/lib/libkvm/kvm_i386.h  Wed Jan 30 02:07:13 2019(r343567)
@@ -67,14 +67,16 @@ typedef uint64_ti386_pde_pae_t;
 _Static_assert(PAGE_SHIFT == I386_PAGE_SHIFT, "PAGE_SHIFT mismatch");
 _Static_assert(PAGE_SIZE == I386_PAGE_SIZE, "PAGE_SIZE mismatch");
 _Static_assert(PAGE_MASK == I386_PAGE_MASK, "PAGE_MASK mismatch");
+#if 0
 _Static_assert(NPTEPG == I386_NPTEPG, "NPTEPG mismatch");
-_Static_assert(PDRSHIFT == I386_PDRSHIFT, "PDRSHIFT mismatch");
 _Static_assert(NBPDR == I386_NBPDR, "NBPDR mismatch");
+#endif
+_Static_assert(PDRSHIFT_NOPAE == I386_PDRSHIFT, "PDRSHIFT mismatch");
 
 _Static_assert(PG_V == I386_PG_V, "PG_V mismatch");
 _Static_assert(PG_PS == I386_PG_PS, "PG_PS mismatch");
-_Static_assert((u_int)PG_FRAME == I386_PG_FRAME, "PG_FRAME mismatch");
-_Static_assert(PG_PS_FRAME == I386_PG_PS_FRAME, "PG_PS_FRAME mismatch");
+_Static_assert((u_int)PG_FRAME_NOPAE == I386_PG_FRAME, "PG_FRAME mismatch");
+_Static_assert(PG_PS_FRAME_NOPAE == I386_PG_PS_FRAME, "PG_PS_FRAME mismatch");
 #endif
 
 int_i386_native(kvm_t *);

Modified: head/sys/conf/files.i386
==
--- head/sys/conf/files.i386Tue Jan 29 22:46:44 2019(r343566)
+++ head/sys/conf/files.i386Wed Jan 30 02:07:13 

svn commit: r343566 - in head/lib/libthr: . thread

[Konstantin Belousov]

Author: kib
Date: Tue Jan 29 22:46:44 2019
New Revision: 343566
URL: https://svnweb.freebsd.org/changeset/base/343566

Log:
  Untangle jemalloc and mutexes initialization.
  
  The need to use libc malloc(3) from some places in libthr always
  caused issues.  For instance, per-thread key allocation was switched to
  use plain mmap(2) to get storage, because some third party mallocs
  used keys for implementation of calloc(3).
  
  Even more important, libthr calls calloc(3) during initialization of
  pthread mutexes, and jemalloc uses pthread mutexes.  Jemalloc provides
  some way to both postpone the initialization, and to make
  initialization to use specialized allocator, but this is very fragile
  and often breaks.  See the referenced PR for another example.
  
  Add the small malloc implementation used by rtld, to libthr. Use it in
  thr_spec.c and for mutexes initialization. This avoids the issues with
  mutual dependencies between malloc and libthr in principle.  The
  drawback is that some more allocations are not interceptable for
  alternate malloc implementations.  There should be not too much memory
  use from this allocator, and the alternative, direct use of mmap(2) is
  obviously worse.
  
  PR:   235211
  MFC after:2 weeks
  Sponsored by: The FreeBSD Foundation
  Differential revision:https://reviews.freebsd.org/D18988

Added:
  head/lib/libthr/thread/thr_malloc.c   (contents, props changed)
Modified:
  head/lib/libthr/Makefile
  head/lib/libthr/thread/Makefile.inc
  head/lib/libthr/thread/thr_fork.c
  head/lib/libthr/thread/thr_init.c
  head/lib/libthr/thread/thr_mutex.c
  head/lib/libthr/thread/thr_private.h
  head/lib/libthr/thread/thr_spec.c

Modified: head/lib/libthr/Makefile
==
--- head/lib/libthr/MakefileTue Jan 29 22:45:24 2019(r343565)
+++ head/lib/libthr/MakefileTue Jan 29 22:46:44 2019(r343566)
@@ -27,6 +27,7 @@ CFLAGS+=-I${SRCTOP}/lib/libthread_db
 CFLAGS+=-Winline
 
 CFLAGS.thr_stack.c+=   -Wno-cast-align
+CFLAGS.malloc.c+=  -Wno-cast-align
 .include 
 .if !(${COMPILER_TYPE} == "gcc" && ${COMPILER_VERSION} < 40300)
 CFLAGS.thr_symbols.c+= -Wno-missing-variable-declarations
@@ -50,12 +51,14 @@ CFLAGS+=-D_PTHREADS_INVARIANTS
 PRECIOUSLIB=
 
 .PATH: ${.CURDIR}/arch/${MACHINE_CPUARCH}/${MACHINE_CPUARCH}
+.PATH: ${SRCTOP}/libexec/rtld-elf
 
 .if exists(${.CURDIR}/arch/${MACHINE_CPUARCH}/Makefile.inc)
 .include "${.CURDIR}/arch/${MACHINE_CPUARCH}/Makefile.inc"
 .endif
 .include "${.CURDIR}/sys/Makefile.inc"
 .include "${.CURDIR}/thread/Makefile.inc"
+SRCS+= malloc.c
 
 .if ${MK_INSTALLLIB} != "no"
 SYMLINKS+=lib${LIB}.a ${LIBDIR}/libpthread.a

Modified: head/lib/libthr/thread/Makefile.inc
==
--- head/lib/libthr/thread/Makefile.inc Tue Jan 29 22:45:24 2019
(r343565)
+++ head/lib/libthr/thread/Makefile.inc Tue Jan 29 22:46:44 2019
(r343566)
@@ -31,6 +31,7 @@ SRCS+= \
thr_kern.c \
thr_kill.c \
thr_main_np.c \
+   thr_malloc.c \
thr_multi_np.c \
thr_mutex.c \
thr_mutexattr.c \

Modified: head/lib/libthr/thread/thr_fork.c
==
--- head/lib/libthr/thread/thr_fork.c   Tue Jan 29 22:45:24 2019
(r343565)
+++ head/lib/libthr/thread/thr_fork.c   Tue Jan 29 22:46:44 2019
(r343566)
@@ -170,6 +170,7 @@ __thr_fork(void)
 */
if (_thr_isthreaded() != 0) {
was_threaded = 1;
+   __thr_malloc_prefork(curthread);
_malloc_prefork();
__thr_pshared_atfork_pre();
_rtld_atfork_pre(rtld_locks);
@@ -197,6 +198,10 @@ __thr_fork(void)
 */
curthread->tlflags &= ~TLFLAGS_IN_TDLIST;
 
+   /* before thr_self() */
+   if (was_threaded)
+   __thr_malloc_postfork(curthread);
+
/* child is a new kernel thread. */
thr_self(>tid);
 
@@ -241,6 +246,7 @@ __thr_fork(void)
_thr_signal_postfork();
 
if (was_threaded) {
+   __thr_malloc_postfork(curthread);
_rtld_atfork_post(rtld_locks);
__thr_pshared_atfork_post();
_malloc_postfork();

Modified: head/lib/libthr/thread/thr_init.c
==
--- head/lib/libthr/thread/thr_init.c   Tue Jan 29 22:45:24 2019
(r343565)
+++ head/lib/libthr/thread/thr_init.c   Tue Jan 29 22:46:44 2019
(r343566)
@@ -461,6 +461,7 @@ init_private(void)
 */
if (init_once == 0) {
__thr_pshared_init();
+   __thr_malloc_init();
/* Find the stack top */
mib[0] = CTL_KERN;

svn commit: r343565 - head/libexec/rtld-elf

[Konstantin Belousov]

Author: kib
Date: Tue Jan 29 22:45:24 2019
New Revision: 343565
URL: https://svnweb.freebsd.org/changeset/base/343565

Log:
  Add header file missed in r343564.
  
  MFC after:2 weeks
  Sponsored by: The FreeBSD Foundation
  Differential revision:https://reviews.freebsd.org/D18988

Added:
  head/libexec/rtld-elf/rtld_malloc.h   (contents, props changed)

Added: head/libexec/rtld-elf/rtld_malloc.h
==
--- /dev/null   00:00:00 1970   (empty, because file is newly added)
+++ head/libexec/rtld-elf/rtld_malloc.h Tue Jan 29 22:45:24 2019
(r343565)
@@ -0,0 +1,45 @@
+/*-
+ * SPDX-License-Identifier: BSD-2-Clause-FreeBSD
+ *
+ * Copyright (c) 2019 The FreeBSD Foundation
+ * All rights reserved.
+ *
+ * This software was developed by Konstantin Belousov 
+ * under sponsorship from the FreeBSD Foundation.
+ *
+ * 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$
+ */
+
+#ifndef RTLD_MALLOC_H
+#defineRTLD_MALLOC_H
+
+void *__crt_calloc(size_t num, size_t size);
+void __crt_free(void *cp);
+void *__crt_malloc(size_t nbytes);
+void *__crt_realloc(void *cp, size_t nbytes);
+
+extern int npagesizes;
+extern size_t *pagesizes;
+
+#endif
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

svn commit: r343564 - head/libexec/rtld-elf

[Konstantin Belousov]

Author: kib
Date: Tue Jan 29 22:40:42 2019
New Revision: 343564
URL: https://svnweb.freebsd.org/changeset/base/343564

Log:
  Adjust posix symbols from rtld-elf/malloc.c with the __crt_ prefix.
  
  This allows to reuse the allocator in other environments that get
  malloc(3) and related functions from libc or interposer.
  
  MFC after:2 weeks
  Sponsored by: The FreeBSD Foundation
  Differential revision:https://reviews.freebsd.org/D18988

Modified:
  head/libexec/rtld-elf/malloc.c
  head/libexec/rtld-elf/rtld.c
  head/libexec/rtld-elf/rtld.h
  head/libexec/rtld-elf/xmalloc.c

Modified: head/libexec/rtld-elf/malloc.c
==
--- head/libexec/rtld-elf/malloc.c  Tue Jan 29 20:50:29 2019
(r343563)
+++ head/libexec/rtld-elf/malloc.c  Tue Jan 29 22:40:42 2019
(r343564)
@@ -153,7 +153,7 @@ botch(s)
  */
 
 void *
-malloc(size_t nbytes)
+__crt_malloc(size_t nbytes)
 {
union overhead *op;
int bucket;
@@ -236,7 +236,7 @@ malloc(size_t nbytes)
 }
 
 void *
-calloc(size_t num, size_t size)
+__crt_calloc(size_t num, size_t size)
 {
void *ret;
 
@@ -245,7 +245,7 @@ calloc(size_t num, size_t size)
return (NULL);
}
 
-   if ((ret = malloc(num * size)) != NULL)
+   if ((ret = __crt_malloc(num * size)) != NULL)
memset(ret, 0, num * size);
 
return (ret);
@@ -298,7 +298,7 @@ morecore(int bucket)
 }
 
 void
-free(void * cp)
+__crt_free(void *cp)
 {
int size;
union overhead *op;
@@ -339,7 +339,7 @@ free(void * cp)
 static int realloc_srchlen = 4;/* 4 should be plenty, -1 =>'s whole 
list */
 
 void *
-realloc(void *cp, size_t nbytes)
+__crt_realloc(void *cp, size_t nbytes)
 {
u_int onb;
int i;
@@ -348,7 +348,7 @@ realloc(void *cp, size_t nbytes)
int was_alloced = 0;
 
if (cp == NULL)
-   return (malloc(nbytes));
+   return (__crt_malloc(nbytes));
op = (union overhead *)((caddr_t)cp - sizeof (union overhead));
if (op->ov_magic == MAGIC) {
was_alloced++;
@@ -393,10 +393,10 @@ realloc(void *cp, size_t nbytes)
 #endif
return(cp);
} else
-   free(cp);
+   __crt_free(cp);
}
-   if ((res = malloc(nbytes)) == NULL)
-   return (NULL);
+   if ((res = __crt_malloc(nbytes)) == NULL)
+   return (NULL);
if (cp != res)  /* common optimization if "compacting" */
bcopy(cp, res, (nbytes < onb) ? nbytes : onb);
return (res);
@@ -467,9 +467,11 @@ morepages(int n)
caddr_t addr = (caddr_t)
(((long)pagepool_start + pagesz - 1) & ~(pagesz - 1));
if (munmap(addr, pagepool_end - addr) != 0) {
+#ifdef IN_RTLD
rtld_fdprintf(STDERR_FILENO, _BASENAME_RTLD ": "
"morepages: cannot munmap %p: %s\n",
addr, rtld_strerror(errno));
+#endif
}
}
 
@@ -478,9 +480,11 @@ morepages(int n)
if ((pagepool_start = mmap(0, n * pagesz,
PROT_READ|PROT_WRITE,
MAP_ANON|MAP_PRIVATE, fd, 0)) == (caddr_t)-1) {
+#ifdef IN_RTLD
rtld_fdprintf(STDERR_FILENO, _BASENAME_RTLD ": morepages: "
"cannot mmap anonymous memory: %s\n",
rtld_strerror(errno));
+#endif
return 0;
}
pagepool_end = pagepool_start + n * pagesz;

Modified: head/libexec/rtld-elf/rtld.c
==
--- head/libexec/rtld-elf/rtld.cTue Jan 29 20:50:29 2019
(r343563)
+++ head/libexec/rtld-elf/rtld.cTue Jan 29 22:40:42 2019
(r343564)
@@ -66,6 +66,7 @@ __FBSDID("$FreeBSD$");
 #include "paths.h"
 #include "rtld_tls.h"
 #include "rtld_printf.h"
+#include "rtld_malloc.h"
 #include "rtld_utrace.h"
 #include "notes.h"
 
@@ -5636,4 +5637,33 @@ bzero(void *dest, size_t len)
 
for (i = 0; i < len; i++)
((char *)dest)[i] = 0;
+}
+
+/* malloc */
+void *
+malloc(size_t nbytes)
+{
+
+   return (__crt_malloc(nbytes));
+}
+
+void *
+calloc(size_t num, size_t size)
+{
+
+   return (__crt_calloc(num, size));
+}
+
+void
+free(void *cp)
+{
+
+   __crt_free(cp);
+}
+
+void *
+realloc(void *cp, size_t nbytes)
+{
+
+   return (__crt_realloc(cp, nbytes));
 }

Modified: head/libexec/rtld-elf/rtld.h
==
--- head/libexec/rtld-elf/rtld.hTue Jan 29 20:50:29 2019
(r343563)
+++ head/libexec/rtld-elf/rtld.hTue Jan 29 22:40:42 2019
(r343564)
@@ -409,4 +409,9 @@ void pre_init(void);
 void init_pltgot(Obj_Entry *);
 void allocate_initial_tls(Obj_Entry *);
 
+void 

Re: svn commit: r343561 - in head/sys: arm64/include riscv/include

[Konstantin Belousov]

On Tue, Jan 29, 2019 at 08:10:27PM +, David E. O'Brien wrote:
> Author: obrien
> Date: Tue Jan 29 20:10:27 2019
> New Revision: 343561
> URL: https://svnweb.freebsd.org/changeset/base/343561
> 
> Log:
>   Follow arm[32] and sparc64 KAPI and provide the FreeBSD standard spelling
>   across all architectures for this header.
>   
>   Reviewed by:stevek
>   Obtained from:  Juniper Networks
> 
> Added:
>   head/sys/arm64/include/sigframe.h
>  - copied unchanged from r343560, head/sys/arm/include/sigframe.h
>   head/sys/riscv/include/sigframe.h
>  - copied unchanged from r343560, head/sys/arm/include/sigframe.h
> 
> Copied: head/sys/arm64/include/sigframe.h (from r343560, 
> head/sys/arm/include/sigframe.h)
> ==
> --- /dev/null 00:00:00 1970   (empty, because file is newly added)
> +++ head/sys/arm64/include/sigframe.h Tue Jan 29 20:10:27 2019
> (r343561, copy of r343560, head/sys/arm/include/sigframe.h)
> @@ -0,0 +1,2 @@
> +/* $FreeBSD$ */
> +#include 
> 
> Copied: head/sys/riscv/include/sigframe.h (from r343560, 
> head/sys/arm/include/sigframe.h)
> ==
> --- /dev/null 00:00:00 1970   (empty, because file is newly added)
> +++ head/sys/riscv/include/sigframe.h Tue Jan 29 20:10:27 2019
> (r343561, copy of r343560, head/sys/arm/include/sigframe.h)
> @@ -0,0 +1,2 @@
> +/* $FreeBSD$ */
> +#include 

All other architectures are careful to only provide sigframe definition
in machine/sigframe.h.  For instance trapframes are not exposed.

This is the main reason why frame.h and sigframe.h both exist.
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

svn commit: r343563 - head/sys/dev/nvd

[Alexander Motin]

Author: mav
Date: Tue Jan 29 20:50:29 2019
New Revision: 343563
URL: https://svnweb.freebsd.org/changeset/base/343563

Log:
  Fix GCC build, failed due to false integer overflow in r343562.
  
  MFC after:2 weeks

Modified:
  head/sys/dev/nvd/nvd.c

Modified: head/sys/dev/nvd/nvd.c
==
--- head/sys/dev/nvd/nvd.c  Tue Jan 29 20:35:09 2019(r343562)
+++ head/sys/dev/nvd/nvd.c  Tue Jan 29 20:50:29 2019(r343563)
@@ -82,7 +82,7 @@ struct nvd_disk {
struct nvme_namespace   *ns;
 
uint32_tcur_depth;
-#defineNVD_ODEPTH  (1 << 31)
+#defineNVD_ODEPTH  (1 << 30)
uint32_tordered_in_flight;
u_int   unit;
 
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

svn commit: r343562 - head/sys/dev/nvd

[Alexander Motin]

Author: mav
Date: Tue Jan 29 20:35:09 2019
New Revision: 343562
URL: https://svnweb.freebsd.org/changeset/base/343562

Log:
  Reimplement BIO_ORDERED handling in nvd(4).
  
  This fixes BIO_ORDERED semantics while also improving performance by:
   - sleeping also before BIO_ORDERED bio, as defined, not only after;
   - not queueing BIO_ORDERED bio to taskqueue if no other bios running;
   - waking up sleeping taskqueue explicitly rather then rely on polling.
  
  On Samsung SSD 970 PRO this shows sync write latency, measured with
  `diskinfo -wS`, reduction from ~2ms to ~1.1ms by not sleeping without
  reason till next HZ tick.
  
  On the same device ZFS pool with 8 ZVOLs synchronously writing 4KB blocks
  shows ~950 IOPS instead of ~750 IOPS before.  I suspect ZFS does not need
  BIO_ORDERED on BIO_FLUSH at all, but that will be next question.
  
  MFC after:2 weeks
  Sponsored by: iXsystems, Inc.

Modified:
  head/sys/dev/nvd/nvd.c

Modified: head/sys/dev/nvd/nvd.c
==
--- head/sys/dev/nvd/nvd.c  Tue Jan 29 20:10:27 2019(r343561)
+++ head/sys/dev/nvd/nvd.c  Tue Jan 29 20:35:09 2019(r343562)
@@ -82,6 +82,7 @@ struct nvd_disk {
struct nvme_namespace   *ns;
 
uint32_tcur_depth;
+#defineNVD_ODEPTH  (1 << 31)
uint32_tordered_in_flight;
u_int   unit;
 
@@ -181,39 +182,50 @@ nvd_unload()
mtx_destroy(_lock);
 }
 
-static int
+static void
 nvd_bio_submit(struct nvd_disk *ndisk, struct bio *bp)
 {
int err;
 
bp->bio_driver1 = NULL;
-   atomic_add_int(>cur_depth, 1);
+   if (__predict_false(bp->bio_flags & BIO_ORDERED))
+   atomic_add_int(>cur_depth, NVD_ODEPTH);
+   else
+   atomic_add_int(>cur_depth, 1);
err = nvme_ns_bio_process(ndisk->ns, bp, nvd_done);
if (err) {
-   atomic_add_int(>cur_depth, -1);
-   if (__predict_false(bp->bio_flags & BIO_ORDERED))
+   if (__predict_false(bp->bio_flags & BIO_ORDERED)) {
+   atomic_add_int(>cur_depth, -NVD_ODEPTH);
atomic_add_int(>ordered_in_flight, -1);
+   wakeup(>cur_depth);
+   } else {
+   if (atomic_fetchadd_int(>cur_depth, -1) == 1 &&
+   __predict_false(ndisk->ordered_in_flight != 0))
+   wakeup(>cur_depth);
+   }
bp->bio_error = err;
bp->bio_flags |= BIO_ERROR;
bp->bio_resid = bp->bio_bcount;
biodone(bp);
-   return (-1);
}
-
-   return (0);
 }
 
 static void
 nvd_strategy(struct bio *bp)
 {
-   struct nvd_disk *ndisk;
+   struct nvd_disk *ndisk = (struct nvd_disk *)bp->bio_disk->d_drv1;
 
-   ndisk = (struct nvd_disk *)bp->bio_disk->d_drv1;
-
-   if (__predict_false(bp->bio_flags & BIO_ORDERED))
-   atomic_add_int(>ordered_in_flight, 1);
-
-   if (__predict_true(ndisk->ordered_in_flight == 0)) {
+   /*
+* bio with BIO_ORDERED flag must be executed after all previous
+* bios in the queue, and before any successive bios.
+*/
+   if (__predict_false(bp->bio_flags & BIO_ORDERED)) {
+   if (atomic_fetchadd_int(>ordered_in_flight, 1) == 0 &&
+   ndisk->cur_depth == 0 && bioq_first(>bioq) == NULL) {
+   nvd_bio_submit(ndisk, bp);
+   return;
+   }
+   } else if (__predict_true(ndisk->ordered_in_flight == 0)) {
nvd_bio_submit(ndisk, bp);
return;
}
@@ -281,28 +293,27 @@ nvd_ioctl(struct disk *ndisk, u_long cmd, void *data, 
 static int
 nvd_dump(void *arg, void *virt, vm_offset_t phys, off_t offset, size_t len)
 {
-   struct nvd_disk *ndisk;
-   struct disk *dp;
+   struct disk *dp = arg;
+   struct nvd_disk *ndisk = dp->d_drv1;
 
-   dp = arg;
-   ndisk = dp->d_drv1;
-
return (nvme_ns_dump(ndisk->ns, virt, offset, len));
 }
 
 static void
 nvd_done(void *arg, const struct nvme_completion *cpl)
 {
-   struct bio *bp;
-   struct nvd_disk *ndisk;
+   struct bio *bp = (struct bio *)arg;
+   struct nvd_disk *ndisk = bp->bio_disk->d_drv1;
 
-   bp = (struct bio *)arg;
-
-   ndisk = bp->bio_disk->d_drv1;
-
-   atomic_add_int(>cur_depth, -1);
-   if (__predict_false(bp->bio_flags & BIO_ORDERED))
+   if (__predict_false(bp->bio_flags & BIO_ORDERED)) {
+   atomic_add_int(>cur_depth, -NVD_ODEPTH);
atomic_add_int(>ordered_in_flight, -1);
+   wakeup(>cur_depth);
+   } else {
+   if (atomic_fetchadd_int(>cur_depth, -1) == 1 &&
+   __predict_false(ndisk->ordered_in_flight != 0))
+   

svn commit: r343561 - in head/sys: arm64/include riscv/include

[David E. O'Brien]

Author: obrien
Date: Tue Jan 29 20:10:27 2019
New Revision: 343561
URL: https://svnweb.freebsd.org/changeset/base/343561

Log:
  Follow arm[32] and sparc64 KAPI and provide the FreeBSD standard spelling
  across all architectures for this header.
  
  Reviewed by:  stevek
  Obtained from:Juniper Networks

Added:
  head/sys/arm64/include/sigframe.h
 - copied unchanged from r343560, head/sys/arm/include/sigframe.h
  head/sys/riscv/include/sigframe.h
 - copied unchanged from r343560, head/sys/arm/include/sigframe.h

Copied: head/sys/arm64/include/sigframe.h (from r343560, 
head/sys/arm/include/sigframe.h)
==
--- /dev/null   00:00:00 1970   (empty, because file is newly added)
+++ head/sys/arm64/include/sigframe.h   Tue Jan 29 20:10:27 2019
(r343561, copy of r343560, head/sys/arm/include/sigframe.h)
@@ -0,0 +1,2 @@
+/* $FreeBSD$ */
+#include 

Copied: head/sys/riscv/include/sigframe.h (from r343560, 
head/sys/arm/include/sigframe.h)
==
--- /dev/null   00:00:00 1970   (empty, because file is newly added)
+++ head/sys/riscv/include/sigframe.h   Tue Jan 29 20:10:27 2019
(r343561, copy of r343560, head/sys/arm/include/sigframe.h)
@@ -0,0 +1,2 @@
+/* $FreeBSD$ */
+#include 
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

svn commit: r343560 - head/usr.bin/calendar/calendars/de_AT.ISO_8859-15

[Oleksandr Tymoshenko]

Author: gonzo
Date: Tue Jan 29 19:54:37 2019
New Revision: 343560
URL: https://svnweb.freebsd.org/changeset/base/343560

Log:
  calendar(1): Fix Aschermittwoch date for Austrian calendar
  
  PR:   165516
  Submitted by: j...@berklix.com
  MFC after:1 week

Modified:
  head/usr.bin/calendar/calendars/de_AT.ISO_8859-15/calendar.feiertag

Modified: head/usr.bin/calendar/calendars/de_AT.ISO_8859-15/calendar.feiertag
==
--- head/usr.bin/calendar/calendars/de_AT.ISO_8859-15/calendar.feiertag Tue Jan 
29 18:18:55 2019(r343559)
+++ head/usr.bin/calendar/calendars/de_AT.ISO_8859-15/calendar.feiertag Tue Jan 
29 19:54:37 2019(r343560)
@@ -37,7 +37,7 @@ Easter+60 Fronleichnam
 
 /*  Gedenktage - nicht arbeitsfreie Feiertage */
 02/14  Valentinstag
-02/WednesdayLast   Aschermittwoch
+Easter-46  Aschermittwoch
 Easter-7   Palmsonntag
 Nov Sun+3  Totensonntag
 Nov Sun+4  1. Advent
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r343543 - head/sbin/bectl/tests

[Enji Cooper]

> On Jan 29, 2019, at 9:21 AM, Enji Cooper  wrote:

…

>> Right- this is the part that makes sense to me. =) The 'default2' BE
>> is clearly a leftover from a previous test, but it should've been
>> unmounted in the process and the zpool cleaned up.
>> 
>> What's not clear is how the cleanup routine is failing; the `zpool get
>> health` shouldn't have any reason to fail (though I can't test it
>> here, apparently =() and `zpool destroy -f` should've unmounted this
>> BE even if that hadn't happened throughout the course of the test, but
>> the failure remains (even if probably incorrectly fixed) following the
>> above commit.
>> 
>> Setting the zpool name globally with a suffix unique to this test
>> would likely be a great idea -- I think there's something else going
>> on as well, though.
> 
> My comment about the zpool name being defined locally to tests as opposed is 
> globally is probably what’s tripping you up. The cleanup function is not run 
> in the same shell context as the test.

I submitted a proposed fix here: https://reviews.freebsd.org/D19024 
 .

After doing some more thinking, it dawned on me that these tests might not be 
running in parallel, which (because they weren’t using unique names) could be 
clashing with parallel executing tests.

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

Re: svn commit: r343543 - head/sbin/bectl/tests

[Rodney W. Grimes]

[ Charset UTF-8 unsupported, converting... ]
> On 1/29/19 9:04 AM, Rodney W. Grimes wrote:
> >>> On Jan 29, 2019, at 08:39, Kyle Evans  wrote:
> >> It?s probably and issue with timing and the bhyve implementation for amd64 
> >> vs i386, or something else.
> > 
> > There is not a i386 mode of bhyve, ie all guests run in the same 64 bit
> > virtualization and no part of the hyperviser knows if the guest is
> > executing 32 bit or 64 bit code.
> 
> While I doubt the i386 vs amd64 bits matter, it's not true that the hypervisor
> doesn't know.  The code to handle instruction emulation has to know since it
> has to walk the page tables to map guest virtual addresses to guest
> physical addresses.  As a result, that part of bhyve knows about no paging
> vs 32-bit paging vs PAE paging vs 64-bit paging.  (Thankfully it doesn't
> have to reason about real vs protected mode as we get the faulting virtual
> address which is after the hardware has handled segmentation.)

I forgot about that, but it is not as if there is
some great difference between running i386 or amd64 code
inside bhyve.  Other than some very small places like the
instruction emulation, they are treated the same, and most
of what is going on is purely done in the hardware of the CPU
with respect to i386 vs amd64.

Does a drop in and out of real mode even take a VMexit?
You can also run real, 32bit or 64bit code all in the
same bhyve instance and bhyve, other than the emulation
really cares little about what your doingm, correct?

Some people get the idea that because in VirtualBox,
or Vmware you specify the guest as some 32 bit flavor
or some 64 bit flavor of some OS that there are mass
differences.

You can tell ESXi that you have a 64 bit FreeBSD guest
and load the 32 bit version in there and it runs just
fine.  IIRC you can even tell it you have a 32 bit guest,
set the nested bit in your .vmx file and go run FreeBSD
64 bit with bhyuve guests inside it. 

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

Re: svn commit: r343543 - head/sbin/bectl/tests

[John Baldwin]

On 1/29/19 9:04 AM, Rodney W. Grimes wrote:
>>> On Jan 29, 2019, at 08:39, Kyle Evans  wrote:
>> It?s probably and issue with timing and the bhyve implementation for amd64 
>> vs i386, or something else.
> 
> There is not a i386 mode of bhyve, ie all guests run in the same 64 bit
> virtualization and no part of the hyperviser knows if the guest is
> executing 32 bit or 64 bit code.

While I doubt the i386 vs amd64 bits matter, it's not true that the hypervisor
doesn't know.  The code to handle instruction emulation has to know since it
has to walk the page tables to map guest virtual addresses to guest
physical addresses.  As a result, that part of bhyve knows about no paging
vs 32-bit paging vs PAE paging vs 64-bit paging.  (Thankfully it doesn't
have to reason about real vs protected mode as we get the faulting virtual
address which is after the hardware has handled segmentation.)

-- 
John Baldwin


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

Re: svn commit: r343543 - head/sbin/bectl/tests

[Enji Cooper]

> On Jan 29, 2019, at 09:06, Rodney W. Grimes  
> wrote:
> 
> [ Charset UTF-8 unsupported, converting... ]
>> On Jan 28, 2019, at 20:31, Rodney W. Grimes  
>> wrote:
>> 
> On Mon, Jan 28, 2019 at 10:09 PM Kyle Evans  wrote:
> 
> Author: kevans
> Date: Tue Jan 29 04:08:49 2019
> New Revision: 343543
> URL: https://svnweb.freebsd.org/changeset/base/343543
> 
> Log:
> bectl(8) test: Force destroy the zpool in cleanup
> 
> This is a wild guess as to why bectl tests failed once upon a time in CI,
> given no apparent way to see a transcript of cleanup routines with Kyua. 
> The
> bectl tests construct a new, clean zpool for every test. The failure
> indicated was because of a mount that was leftover from a previous test, 
> but
> the previous test had succeeded so it's not clear how the mount remained
> leftover unless the `zpool get health ${pool}` had somehow failed.
> 
 
 I left out: the tests are supposed to be constructed to clean up any
 mounts that were left over in the course of the test, hence the
 assumption that the failure lies in the cleanup.
>> 
>> Hi Rod,
>> 
>>> From my experience as a hardware test engineer the test
>>> setup was required to make sure any of those assumptions
>>> are valid.  Meaning that the test would have to validate
>>> that no left over cruft was going to interfere with the
>>> test about to be run.
>>> 
>>> Ie, you should probably do a force destroy of the pool
>>> *before* the test too.
>> 
>> While this approach makes sense and is valid, it would leave open/orphaned 
>> resources after each test run (in this case a single zpool). It?s best to 
>> fix the underlying issue with how the test formulates, sets up, and tears 
>> down the zpool.
> 
> I did not advocate in any way that the post run cleanup
> should be removed.  Infact you should have both a pre-test
> assurance that the environment is correct and a post-test
> cleanup trying to removall all artifacts.
> 
> You can fix the current issue, but eventually if you get
> enough testing going on your going to start to find that
> things fail in ways that do not clean up (machine crash
> is one instance) and not doing a pretest cleanup is eventually
> going to run aground of this pitfall.

I understand what you mean, but we don’t have to worry about this. Our CI runs 
don’t persist today as the bhyve instance is setup at start and torn down at 
exit (it was a problem in the first few iterations). Furthermore, resources 
like zpools that the bectl tests construct are should transient in nature at 
import (don’t affect the zpool.cache file), meaning that it should not be 
reconnected on the next boot.

Assuming $TMPDIR is set to /tmp (or unset for that matter) and a standard 
rc.conf configuration (or better yet, a tmpfs/md-backed filesystem), all 
leftover remnants on disk will be cleaned up at next boot on test hosts that 
are more persistent.

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

Re: svn commit: r343543 - head/sbin/bectl/tests

[Enji Cooper]

> On Jan 29, 2019, at 09:10, Kyle Evans  wrote:
> 
>> On Tue, Jan 29, 2019 at 10:55 AM Enji Cooper  wrote:
>> 
>> 
 On Jan 29, 2019, at 08:39, Kyle Evans  wrote:
 
 On Tue, Jan 29, 2019 at 10:32 AM Enji Cooper  wrote:
 
 
>> On Jan 28, 2019, at 20:10, Kyle Evans  wrote:
>> 
>> On Mon, Jan 28, 2019 at 10:09 PM Kyle Evans  wrote:
>> 
>> Author: kevans
>> Date: Tue Jan 29 04:08:49 2019
>> New Revision: 343543
>> URL: https://svnweb.freebsd.org/changeset/base/343543
>> 
>> Log:
>> bectl(8) test: Force destroy the zpool in cleanup
>> 
>> This is a wild guess as to why bectl tests failed once upon a time in CI,
>> given no apparent way to see a transcript of cleanup routines with Kyua. 
>> The
>> bectl tests construct a new, clean zpool for every test. The failure
>> indicated was because of a mount that was leftover from a previous test, 
>> but
>> the previous test had succeeded so it's not clear how the mount remained
>> leftover unless the `zpool get health ${pool}` had somehow failed.
>> 
> 
> I left out: the tests are supposed to be constructed to clean up any
> mounts that were left over in the course of the test, hence the
> assumption that the failure lies in the cleanup.
 
 Hi Kyle,
 
 The tests use a deterministic zpool name defined locally (not globally), 
 and will only destroy the zpool if “zpool get health” succeeds.
 
 The tests will work the first time (when the zpool doesn’t exist), but I 
 believe they’re actually introducing nondeterminism by accident. I will 
 propose a fix for this.
 
 There’s a way to decipher why things failed from /var/log/messages and 
 kyua output. It’s just nontrivial to those who don’t know what to look 
 for. Can you please provide a failing ci run?
 
>>> 
>>> Hi,
>>> 
>>> Thanks! Any help is appreciated -- my inquiry to -testing@ in response
>>> to the weekly report where the failing test [1] was mentioned has been
>>> met with silence. The failure is consistent in the i386-test job, but
>>> amd64-test sees nothing of the sort (and neither does my local
>>> testing).
>> 
>> Thanks for the reminder to rejoin that list.
>> 
>>> [1] 
>>> https://ci.freebsd.org/job/FreeBSD-stable-12-i386-test/426/testReport/sbin.bectl/bectl_test/bectl_mount/
>> 
>> It’s pretty obvious from the above run what’s going on from the output. A 
>> similarly named zpool (same prefix; suffixed with a 2) is being matched by 
>> grep, even though the test sets up one with a suffix in the preceding steps.
>> 
> 
> Right- this is the part that makes sense to me. =) The 'default2' BE
> is clearly a leftover from a previous test, but it should've been
> unmounted in the process and the zpool cleaned up.
> 
> What's not clear is how the cleanup routine is failing; the `zpool get
> health` shouldn't have any reason to fail (though I can't test it
> here, apparently =() and `zpool destroy -f` should've unmounted this
> BE even if that hadn't happened throughout the course of the test, but
> the failure remains (even if probably incorrectly fixed) following the
> above commit.
> 
> Setting the zpool name globally with a suffix unique to this test
> would likely be a great idea -- I think there's something else going
> on as well, though.

My comment about the zpool name being defined locally to tests as opposed is 
globally is probably what’s tripping you up. The cleanup function is not run in 
the same shell context as the test.

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

Re: svn commit: r343543 - head/sbin/bectl/tests

[Kyle Evans]

On Tue, Jan 29, 2019 at 10:55 AM Enji Cooper  wrote:
>
>
> > On Jan 29, 2019, at 08:39, Kyle Evans  wrote:
> >
> >> On Tue, Jan 29, 2019 at 10:32 AM Enji Cooper  wrote:
> >>
> >>
>  On Jan 28, 2019, at 20:10, Kyle Evans  wrote:
> 
>  On Mon, Jan 28, 2019 at 10:09 PM Kyle Evans  wrote:
> 
>  Author: kevans
>  Date: Tue Jan 29 04:08:49 2019
>  New Revision: 343543
>  URL: https://svnweb.freebsd.org/changeset/base/343543
> 
>  Log:
>  bectl(8) test: Force destroy the zpool in cleanup
> 
>  This is a wild guess as to why bectl tests failed once upon a time in CI,
>  given no apparent way to see a transcript of cleanup routines with Kyua. 
>  The
>  bectl tests construct a new, clean zpool for every test. The failure
>  indicated was because of a mount that was leftover from a previous test, 
>  but
>  the previous test had succeeded so it's not clear how the mount remained
>  leftover unless the `zpool get health ${pool}` had somehow failed.
> 
> >>>
> >>> I left out: the tests are supposed to be constructed to clean up any
> >>> mounts that were left over in the course of the test, hence the
> >>> assumption that the failure lies in the cleanup.
> >>
> >> Hi Kyle,
> >>
> >> The tests use a deterministic zpool name defined locally (not globally), 
> >> and will only destroy the zpool if “zpool get health” succeeds.
> >>
> >> The tests will work the first time (when the zpool doesn’t exist), but I 
> >> believe they’re actually introducing nondeterminism by accident. I will 
> >> propose a fix for this.
> >>
> >> There’s a way to decipher why things failed from /var/log/messages and 
> >> kyua output. It’s just nontrivial to those who don’t know what to look 
> >> for. Can you please provide a failing ci run?
> >>
> >
> > Hi,
> >
> > Thanks! Any help is appreciated -- my inquiry to -testing@ in response
> > to the weekly report where the failing test [1] was mentioned has been
> > met with silence. The failure is consistent in the i386-test job, but
> > amd64-test sees nothing of the sort (and neither does my local
> > testing).
>
> Thanks for the reminder to rejoin that list.
>
> > [1] 
> > https://ci.freebsd.org/job/FreeBSD-stable-12-i386-test/426/testReport/sbin.bectl/bectl_test/bectl_mount/
>
> It’s pretty obvious from the above run what’s going on from the output. A 
> similarly named zpool (same prefix; suffixed with a 2) is being matched by 
> grep, even though the test sets up one with a suffix in the preceding steps.
>

Right- this is the part that makes sense to me. =) The 'default2' BE
is clearly a leftover from a previous test, but it should've been
unmounted in the process and the zpool cleaned up.

What's not clear is how the cleanup routine is failing; the `zpool get
health` shouldn't have any reason to fail (though I can't test it
here, apparently =() and `zpool destroy -f` should've unmounted this
BE even if that hadn't happened throughout the course of the test, but
the failure remains (even if probably incorrectly fixed) following the
above commit.

Setting the zpool name globally with a suffix unique to this test
would likely be a great idea -- I think there's something else going
on as well, though.

Thanks,

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

Re: svn commit: r343543 - head/sbin/bectl/tests

[Rodney W. Grimes]

[ Charset UTF-8 unsupported, converting... ]
> On Jan 28, 2019, at 20:31, Rodney W. Grimes  
> wrote:
> 
> >>> On Mon, Jan 28, 2019 at 10:09 PM Kyle Evans  wrote:
> >>> 
> >>> Author: kevans
> >>> Date: Tue Jan 29 04:08:49 2019
> >>> New Revision: 343543
> >>> URL: https://svnweb.freebsd.org/changeset/base/343543
> >>> 
> >>> Log:
> >>>  bectl(8) test: Force destroy the zpool in cleanup
> >>> 
> >>>  This is a wild guess as to why bectl tests failed once upon a time in CI,
> >>>  given no apparent way to see a transcript of cleanup routines with Kyua. 
> >>> The
> >>>  bectl tests construct a new, clean zpool for every test. The failure
> >>>  indicated was because of a mount that was leftover from a previous test, 
> >>> but
> >>>  the previous test had succeeded so it's not clear how the mount remained
> >>>  leftover unless the `zpool get health ${pool}` had somehow failed.
> >>> 
> >> 
> >> I left out: the tests are supposed to be constructed to clean up any
> >> mounts that were left over in the course of the test, hence the
> >> assumption that the failure lies in the cleanup.
> 
> Hi Rod,
> 
> > From my experience as a hardware test engineer the test
> > setup was required to make sure any of those assumptions
> > are valid.  Meaning that the test would have to validate
> > that no left over cruft was going to interfere with the
> > test about to be run.
> > 
> > Ie, you should probably do a force destroy of the pool
> > *before* the test too.
> 
> While this approach makes sense and is valid, it would leave open/orphaned 
> resources after each test run (in this case a single zpool). It?s best to fix 
> the underlying issue with how the test formulates, sets up, and tears down 
> the zpool.

I did not advocate in any way that the post run cleanup
should be removed.  Infact you should have both a pre-test
assurance that the environment is correct and a post-test
cleanup trying to removall all artifacts.

You can fix the current issue, but eventually if you get
enough testing going on your going to start to find that
things fail in ways that do not clean up (machine crash
is one instance) and not doing a pretest cleanup is eventually
going to run aground of this pitfall.

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

Re: svn commit: r343543 - head/sbin/bectl/tests

[Rodney W. Grimes]

> > On Jan 29, 2019, at 08:39, Kyle Evans  wrote:
> > 
> >> On Tue, Jan 29, 2019 at 10:32 AM Enji Cooper  wrote:
> >> 
> >> 
>  On Jan 28, 2019, at 20:10, Kyle Evans  wrote:
>  
>  On Mon, Jan 28, 2019 at 10:09 PM Kyle Evans  wrote:
>  
>  Author: kevans
>  Date: Tue Jan 29 04:08:49 2019
>  New Revision: 343543
>  URL: https://svnweb.freebsd.org/changeset/base/343543
>  
>  Log:
>  bectl(8) test: Force destroy the zpool in cleanup
>  
>  This is a wild guess as to why bectl tests failed once upon a time in CI,
>  given no apparent way to see a transcript of cleanup routines with Kyua. 
>  The
>  bectl tests construct a new, clean zpool for every test. The failure
>  indicated was because of a mount that was leftover from a previous test, 
>  but
>  the previous test had succeeded so it's not clear how the mount remained
>  leftover unless the `zpool get health ${pool}` had somehow failed.
>  
> >>> 
> >>> I left out: the tests are supposed to be constructed to clean up any
> >>> mounts that were left over in the course of the test, hence the
> >>> assumption that the failure lies in the cleanup.
> >> 
> >> Hi Kyle,
> >> 
> >> The tests use a deterministic zpool name defined locally (not globally), 
> >> and will only destroy the zpool if ?zpool get health? succeeds.
> >> 
> >> The tests will work the first time (when the zpool doesn?t exist), but I 
> >> believe they?re actually introducing nondeterminism by accident. I will 
> >> propose a fix for this.
> >> 
> >> There?s a way to decipher why things failed from /var/log/messages and 
> >> kyua output. It?s just nontrivial to those who don?t know what to look 
> >> for. Can you please provide a failing ci run?
> >> 
> > 
> > Hi,
> > 
> > Thanks! Any help is appreciated -- my inquiry to -testing@ in response
> > to the weekly report where the failing test [1] was mentioned has been
> > met with silence. The failure is consistent in the i386-test job, but
> > amd64-test sees nothing of the sort (and neither does my local
> > testing).
> 
> Thanks for the reminder to rejoin that list.
> 
> > [1] 
> > https://ci.freebsd.org/job/FreeBSD-stable-12-i386-test/426/testReport/sbin.bectl/bectl_test/bectl_mount/
> 
> It?s pretty obvious from the above run what?s going on from the output. A 
> similarly named zpool (same prefix; suffixed with a 2) is being matched by 
> grep, even though the test sets up one with a suffix in the preceding steps.
> 
> It?s probably and issue with timing and the bhyve implementation for amd64 vs 
> i386, or something else.

There is not a i386 mode of bhyve, ie all guests run in the same 64 bit
virtualization and no part of the hyperviser knows if the guest is
executing 32 bit or 64 bit code.

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

Re: svn commit: r343543 - head/sbin/bectl/tests

[Enji Cooper]

> On Jan 29, 2019, at 08:55, Enji Cooper  wrote:
> 
> 
>>> On Jan 29, 2019, at 08:39, Kyle Evans  wrote:
>>> 
>>> On Tue, Jan 29, 2019 at 10:32 AM Enji Cooper  wrote:
>>> 
>>> 
> On Jan 28, 2019, at 20:10, Kyle Evans  wrote:
> 
> On Mon, Jan 28, 2019 at 10:09 PM Kyle Evans  wrote:
> 
> Author: kevans
> Date: Tue Jan 29 04:08:49 2019
> New Revision: 343543
> URL: https://svnweb.freebsd.org/changeset/base/343543
> 
> Log:
> bectl(8) test: Force destroy the zpool in cleanup
> 
> This is a wild guess as to why bectl tests failed once upon a time in CI,
> given no apparent way to see a transcript of cleanup routines with Kyua. 
> The
> bectl tests construct a new, clean zpool for every test. The failure
> indicated was because of a mount that was leftover from a previous test, 
> but
> the previous test had succeeded so it's not clear how the mount remained
> leftover unless the `zpool get health ${pool}` had somehow failed.
> 
 
 I left out: the tests are supposed to be constructed to clean up any
 mounts that were left over in the course of the test, hence the
 assumption that the failure lies in the cleanup.
>>> 
>>> Hi Kyle,
>>> 
>>> The tests use a deterministic zpool name defined locally (not globally), 
>>> and will only destroy the zpool if “zpool get health” succeeds.
>>> 
>>> The tests will work the first time (when the zpool doesn’t exist), but I 
>>> believe they’re actually introducing nondeterminism by accident. I will 
>>> propose a fix for this.
>>> 
>>> There’s a way to decipher why things failed from /var/log/messages and kyua 
>>> output. It’s just nontrivial to those who don’t know what to look for. Can 
>>> you please provide a failing ci run?
>>> 
>> 
>> Hi,
>> 
>> Thanks! Any help is appreciated -- my inquiry to -testing@ in response
>> to the weekly report where the failing test [1] was mentioned has been
>> met with silence. The failure is consistent in the i386-test job, but
>> amd64-test sees nothing of the sort (and neither does my local
>> testing).
> 
> Thanks for the reminder to rejoin that list.
> 
>> [1] 
>> https://ci.freebsd.org/job/FreeBSD-stable-12-i386-test/426/testReport/sbin.bectl/bectl_test/bectl_mount/
> 
> It’s pretty obvious from the above run what’s going on from the output. A 
> similarly named zpool (same prefix; suffixed with a 2) is being matched by 
> grep, even though the test sets up one with a suffix in the preceding steps.

*without a suffix. My bad.
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r343543 - head/sbin/bectl/tests

[Enji Cooper]

> On Jan 29, 2019, at 08:39, Kyle Evans  wrote:
> 
>> On Tue, Jan 29, 2019 at 10:32 AM Enji Cooper  wrote:
>> 
>> 
 On Jan 28, 2019, at 20:10, Kyle Evans  wrote:
 
 On Mon, Jan 28, 2019 at 10:09 PM Kyle Evans  wrote:
 
 Author: kevans
 Date: Tue Jan 29 04:08:49 2019
 New Revision: 343543
 URL: https://svnweb.freebsd.org/changeset/base/343543
 
 Log:
 bectl(8) test: Force destroy the zpool in cleanup
 
 This is a wild guess as to why bectl tests failed once upon a time in CI,
 given no apparent way to see a transcript of cleanup routines with Kyua. 
 The
 bectl tests construct a new, clean zpool for every test. The failure
 indicated was because of a mount that was leftover from a previous test, 
 but
 the previous test had succeeded so it's not clear how the mount remained
 leftover unless the `zpool get health ${pool}` had somehow failed.
 
>>> 
>>> I left out: the tests are supposed to be constructed to clean up any
>>> mounts that were left over in the course of the test, hence the
>>> assumption that the failure lies in the cleanup.
>> 
>> Hi Kyle,
>> 
>> The tests use a deterministic zpool name defined locally (not globally), and 
>> will only destroy the zpool if “zpool get health” succeeds.
>> 
>> The tests will work the first time (when the zpool doesn’t exist), but I 
>> believe they’re actually introducing nondeterminism by accident. I will 
>> propose a fix for this.
>> 
>> There’s a way to decipher why things failed from /var/log/messages and kyua 
>> output. It’s just nontrivial to those who don’t know what to look for. Can 
>> you please provide a failing ci run?
>> 
> 
> Hi,
> 
> Thanks! Any help is appreciated -- my inquiry to -testing@ in response
> to the weekly report where the failing test [1] was mentioned has been
> met with silence. The failure is consistent in the i386-test job, but
> amd64-test sees nothing of the sort (and neither does my local
> testing).

Thanks for the reminder to rejoin that list.

> [1] 
> https://ci.freebsd.org/job/FreeBSD-stable-12-i386-test/426/testReport/sbin.bectl/bectl_test/bectl_mount/

It’s pretty obvious from the above run what’s going on from the output. A 
similarly named zpool (same prefix; suffixed with a 2) is being matched by 
grep, even though the test sets up one with a suffix in the preceding steps.

It’s probably and issue with timing and the bhyve implementation for amd64 vs 
i386, or something else.

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

Re: svn commit: r343543 - head/sbin/bectl/tests

[Kyle Evans]

On Tue, Jan 29, 2019 at 10:32 AM Enji Cooper  wrote:
>
>
> > On Jan 28, 2019, at 20:10, Kyle Evans  wrote:
> >
> >> On Mon, Jan 28, 2019 at 10:09 PM Kyle Evans  wrote:
> >>
> >> Author: kevans
> >> Date: Tue Jan 29 04:08:49 2019
> >> New Revision: 343543
> >> URL: https://svnweb.freebsd.org/changeset/base/343543
> >>
> >> Log:
> >>  bectl(8) test: Force destroy the zpool in cleanup
> >>
> >>  This is a wild guess as to why bectl tests failed once upon a time in CI,
> >>  given no apparent way to see a transcript of cleanup routines with Kyua. 
> >> The
> >>  bectl tests construct a new, clean zpool for every test. The failure
> >>  indicated was because of a mount that was leftover from a previous test, 
> >> but
> >>  the previous test had succeeded so it's not clear how the mount remained
> >>  leftover unless the `zpool get health ${pool}` had somehow failed.
> >>
> >
> > I left out: the tests are supposed to be constructed to clean up any
> > mounts that were left over in the course of the test, hence the
> > assumption that the failure lies in the cleanup.
>
> Hi Kyle,
>
> The tests use a deterministic zpool name defined locally (not globally), and 
> will only destroy the zpool if “zpool get health” succeeds.
>
> The tests will work the first time (when the zpool doesn’t exist), but I 
> believe they’re actually introducing nondeterminism by accident. I will 
> propose a fix for this.
>
> There’s a way to decipher why things failed from /var/log/messages and kyua 
> output. It’s just nontrivial to those who don’t know what to look for. Can 
> you please provide a failing ci run?
>

Hi,

Thanks! Any help is appreciated -- my inquiry to -testing@ in response
to the weekly report where the failing test [1] was mentioned has been
met with silence. The failure is consistent in the i386-test job, but
amd64-test sees nothing of the sort (and neither does my local
testing).

[1] 
https://ci.freebsd.org/job/FreeBSD-stable-12-i386-test/426/testReport/sbin.bectl/bectl_test/bectl_mount/
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r343543 - head/sbin/bectl/tests

[Enji Cooper]

On Jan 28, 2019, at 20:31, Rodney W. Grimes  
wrote:

>>> On Mon, Jan 28, 2019 at 10:09 PM Kyle Evans  wrote:
>>> 
>>> Author: kevans
>>> Date: Tue Jan 29 04:08:49 2019
>>> New Revision: 343543
>>> URL: https://svnweb.freebsd.org/changeset/base/343543
>>> 
>>> Log:
>>>  bectl(8) test: Force destroy the zpool in cleanup
>>> 
>>>  This is a wild guess as to why bectl tests failed once upon a time in CI,
>>>  given no apparent way to see a transcript of cleanup routines with Kyua. 
>>> The
>>>  bectl tests construct a new, clean zpool for every test. The failure
>>>  indicated was because of a mount that was leftover from a previous test, 
>>> but
>>>  the previous test had succeeded so it's not clear how the mount remained
>>>  leftover unless the `zpool get health ${pool}` had somehow failed.
>>> 
>> 
>> I left out: the tests are supposed to be constructed to clean up any
>> mounts that were left over in the course of the test, hence the
>> assumption that the failure lies in the cleanup.

Hi Rod,

> From my experience as a hardware test engineer the test
> setup was required to make sure any of those assumptions
> are valid.  Meaning that the test would have to validate
> that no left over cruft was going to interfere with the
> test about to be run.
> 
> Ie, you should probably do a force destroy of the pool
> *before* the test too.

While this approach makes sense and is valid, it would leave open/orphaned 
resources after each test run (in this case a single zpool). It’s best to fix 
the underlying issue with how the test formulates, sets up, and tears down the 
zpool.

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

Re: svn commit: r343543 - head/sbin/bectl/tests

[Enji Cooper]

> On Jan 28, 2019, at 20:10, Kyle Evans  wrote:
> 
>> On Mon, Jan 28, 2019 at 10:09 PM Kyle Evans  wrote:
>> 
>> Author: kevans
>> Date: Tue Jan 29 04:08:49 2019
>> New Revision: 343543
>> URL: https://svnweb.freebsd.org/changeset/base/343543
>> 
>> Log:
>>  bectl(8) test: Force destroy the zpool in cleanup
>> 
>>  This is a wild guess as to why bectl tests failed once upon a time in CI,
>>  given no apparent way to see a transcript of cleanup routines with Kyua. The
>>  bectl tests construct a new, clean zpool for every test. The failure
>>  indicated was because of a mount that was leftover from a previous test, but
>>  the previous test had succeeded so it's not clear how the mount remained
>>  leftover unless the `zpool get health ${pool}` had somehow failed.
>> 
> 
> I left out: the tests are supposed to be constructed to clean up any
> mounts that were left over in the course of the test, hence the
> assumption that the failure lies in the cleanup.

Hi Kyle,

The tests use a deterministic zpool name defined locally (not globally), and 
will only destroy the zpool if “zpool get health” succeeds.

The tests will work the first time (when the zpool doesn’t exist), but I 
believe they’re actually introducing nondeterminism by accident. I will propose 
a fix for this.

There’s a way to decipher why things failed from /var/log/messages and kyua 
output. It’s just nontrivial to those who don’t know what to look for. Can you 
please provide a failing ci run?

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

svn commit: r343552 - head/sys/dev/virtio/network

[Vincenzo Maffione]

Author: vmaffione
Date: Tue Jan 29 14:31:41 2019
New Revision: 343552
URL: https://svnweb.freebsd.org/changeset/base/343552

Log:
  vtnet: fix typo in vtnet_free_taskqueues
  
  Because of a typo, the code was mistakenly resetting the
  vtnrx_vq pointer rather than vtntx_tq.
  
  Reviewed by:  bryanv
  MFC after:3 days
  Differential Revision:https://reviews.freebsd.org/D19015

Modified:
  head/sys/dev/virtio/network/if_vtnet.c

Modified: head/sys/dev/virtio/network/if_vtnet.c
==
--- head/sys/dev/virtio/network/if_vtnet.c  Tue Jan 29 11:18:41 2019
(r343551)
+++ head/sys/dev/virtio/network/if_vtnet.c  Tue Jan 29 14:31:41 2019
(r343552)
@@ -2748,7 +2748,7 @@ vtnet_free_taskqueues(struct vtnet_softc *sc)
rxq = >vtnet_rxqs[i];
if (rxq->vtnrx_tq != NULL) {
taskqueue_free(rxq->vtnrx_tq);
-   rxq->vtnrx_vq = NULL;
+   rxq->vtnrx_tq = NULL;
}
 
txq = >vtnet_txqs[i];
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

svn commit: r343551 - head/sys/netpfil/ipfw

[Andrey V. Elsukov]

Author: ae
Date: Tue Jan 29 11:18:41 2019
New Revision: 343551
URL: https://svnweb.freebsd.org/changeset/base/343551

Log:
  Fix the bug introduced in r342908, that causes problems with dynamic
  handling for protocols without ports numbers.
  
  Since port numbers were uninitialized for protocols like ICMP/ICMPv6,
  ipfw_chk() used some non-zero values to create dynamic states, and due
  this it failed to match replies with created states.
  
  Reported by:  Oliver Hartmann, Boris Lytochkin
  Obtained from:Yandex LLC
  X-MFC after:  r342908

Modified:
  head/sys/netpfil/ipfw/ip_fw2.c

Modified: head/sys/netpfil/ipfw/ip_fw2.c
==
--- head/sys/netpfil/ipfw/ip_fw2.c  Tue Jan 29 11:04:17 2019
(r343550)
+++ head/sys/netpfil/ipfw/ip_fw2.c  Tue Jan 29 11:18:41 2019
(r343551)
@@ -1410,6 +1410,7 @@ ipfw_chk(struct ip_fw_args *args)
 
dst_ip.s_addr = 0;  /* make sure it is initialized */
src_ip.s_addr = 0;  /* make sure it is initialized */
+   src_port = dst_port = 0;
pktlen = m->m_pkthdr.len;
 
DYN_INFO_INIT(_info);
@@ -1688,7 +1689,6 @@ do {  
\
args->f_id.dst_ip = ntohl(dst_ip.s_addr);
} else {
proto = 0;
-   src_port = dst_port = 0;
dst_ip.s_addr = src_ip.s_addr = 0;
 
args->f_id.addr_type = 1; /* XXX */
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

svn commit: r343550 - in head/sys: amd64/conf arm64/conf conf kern sys

[Andrew Turner]

Author: andrew
Date: Tue Jan 29 11:04:17 2019
New Revision: 343550
URL: https://svnweb.freebsd.org/changeset/base/343550

Log:
  Extract the coverage sanitizer KPI to a new file.
  
  This will allow multiple consumers of the coverage data to be compiled
  into the kernel together. The only requirement is only one can be
  registered at a given point in time, however it is expected they will
  only register when the coverage data is needed.
  
  A new kernel conflig option COVERAGE is added. This will allow kcov to
  become a module that can be loaded as needed, or compiled into the
  kernel.
  
  While here clean up the #include style a little.
  
  Reviewed by:  kib
  Sponsored by: DARPA, AFRL
  Differential Revision:https://reviews.freebsd.org/D18955

Added:
  head/sys/kern/subr_coverage.c
 - copied, changed from r343547, head/sys/kern/kern_kcov.c
  head/sys/sys/coverage.h
 - copied, changed from r343547, head/sys/sys/kcov.h
Modified:
  head/sys/amd64/conf/GENERIC
  head/sys/amd64/conf/GENERIC-NODEBUG
  head/sys/arm64/conf/GENERIC
  head/sys/arm64/conf/GENERIC-NODEBUG
  head/sys/conf/files
  head/sys/conf/kern.pre.mk
  head/sys/conf/options
  head/sys/kern/kern_kcov.c
  head/sys/sys/kcov.h

Modified: head/sys/amd64/conf/GENERIC
==
--- head/sys/amd64/conf/GENERIC Tue Jan 29 10:28:50 2019(r343549)
+++ head/sys/amd64/conf/GENERIC Tue Jan 29 11:04:17 2019(r343550)
@@ -100,9 +100,12 @@ optionsWITNESS # Enable checks to 
detect deadlocks
 optionsWITNESS_SKIPSPIN# Don't run witness on spinlocks for 
speed
 optionsMALLOC_DEBUG_MAXZONES=8 # Separate malloc(9) zones
 optionsVERBOSE_SYSINIT=0   # Support debug.verbose_sysinit, off by 
default
+
+# Kernel Sanitizers
+#options   COVERAGE# Generic kernel coverage. Used by KCOV
+#options   KCOV# Kernel Coverage Sanitizer
 # Warning: KUBSAN can result in a kernel too large for loader to load
 #options   KUBSAN  # Kernel Undefined Behavior Sanitizer
-#options   KCOV# Kernel Coverage Sanitizer
 
 # Kernel dump features.
 optionsEKCD# Support for encrypted kernel dumps

Modified: head/sys/amd64/conf/GENERIC-NODEBUG
==
--- head/sys/amd64/conf/GENERIC-NODEBUG Tue Jan 29 10:28:50 2019
(r343549)
+++ head/sys/amd64/conf/GENERIC-NODEBUG Tue Jan 29 11:04:17 2019
(r343550)
@@ -37,4 +37,5 @@ nooptions   WITNESS_SKIPSPIN
 nooptions   BUF_TRACKING
 nooptions   DEADLKRES
 nooptions   FULL_BUF_TRACKING
-
+nooptions  COVERAGE
+nooptions  KCOV

Modified: head/sys/arm64/conf/GENERIC
==
--- head/sys/arm64/conf/GENERIC Tue Jan 29 10:28:50 2019(r343549)
+++ head/sys/arm64/conf/GENERIC Tue Jan 29 11:04:17 2019(r343550)
@@ -92,9 +92,12 @@ options  MALLOC_DEBUG_MAXZONES=8 # Separate malloc(9) 
 optionsALT_BREAK_TO_DEBUGGER   # Enter debugger on keyboard escape 
sequence
 optionsUSB_DEBUG   # enable debug msgs
 optionsVERBOSE_SYSINIT=0   # Support debug.verbose_sysinit, off by 
default
+
+# Kernel Sanitizers
+#options   COVERAGE# Generic kernel coverage. Used by KCOV
+#options   KCOV# Kernel Coverage Sanitizer
 # Warning: KUBSAN can result in a kernel too large for loader to load
 #options   KUBSAN  # Kernel Undefined Behavior Sanitizer
-#options   KCOV# Kernel Coverage Sanitizer
 
 # Kernel dump features.
 optionsEKCD# Support for encrypted kernel dumps

Modified: head/sys/arm64/conf/GENERIC-NODEBUG
==
--- head/sys/arm64/conf/GENERIC-NODEBUG Tue Jan 29 10:28:50 2019
(r343549)
+++ head/sys/arm64/conf/GENERIC-NODEBUG Tue Jan 29 11:04:17 2019
(r343550)
@@ -36,3 +36,5 @@ nooptions   WITNESS
 nooptions   WITNESS_SKIPSPIN
 nooptions   DEADLKRES
 nooptions   USB_DEBUG
+nooptions  COVERAGE
+nooptions  KCOV

Modified: head/sys/conf/files
==
--- head/sys/conf/files Tue Jan 29 10:28:50 2019(r343549)
+++ head/sys/conf/files Tue Jan 29 11:04:17 2019(r343550)
@@ -3883,6 +3883,8 @@ kern/subr_capability.cstandard
 kern/subr_clock.c  standard
 kern/subr_compressor.c standard \
compile-with "${NORMAL_C} -I$S/contrib/zstd/lib/freebsd"
+kern/subr_coverage.c   optional coverage \
+   compile-with"${NORMAL_C} -fno-sanitize=all"
 kern/subr_counter.cstandard
 kern/subr_devstat.cstandard
 

svn commit: r343549 - head/sys/dev/netmap

[Vincenzo Maffione]

Author: vmaffione
Date: Tue Jan 29 10:28:50 2019
New Revision: 343549
URL: https://svnweb.freebsd.org/changeset/base/343549

Log:
  netmap: add notifications on kloop stop
  
  On sync-kloop stop, send a wake-up signal to the kloop, so that
  waiting for the timeout is not needed.
  Also, improve logging in netmap_freebsd.c.
  
  MFC after:3 days

Modified:
  head/sys/dev/netmap/netmap_bdg.c
  head/sys/dev/netmap/netmap_freebsd.c
  head/sys/dev/netmap/netmap_kloop.c

Modified: head/sys/dev/netmap/netmap_bdg.c
==
--- head/sys/dev/netmap/netmap_bdg.cTue Jan 29 10:21:41 2019
(r343548)
+++ head/sys/dev/netmap/netmap_bdg.cTue Jan 29 10:28:50 2019
(r343549)
@@ -1141,8 +1141,8 @@ netmap_bwrap_intr_notify(struct netmap_kring *kring, i
goto put_out;
if (kring->nr_hwcur == kring->nr_hwtail) {
if (netmap_verbose)
-   nm_prerr("how strange, interrupt with no packets on %s",
-   na->name);
+   nm_prlim(1, "interrupt with no packets on %s",
+   kring->name);
goto put_out;
}
 

Modified: head/sys/dev/netmap/netmap_freebsd.c
==
--- head/sys/dev/netmap/netmap_freebsd.cTue Jan 29 10:21:41 2019
(r343548)
+++ head/sys/dev/netmap/netmap_freebsd.cTue Jan 29 10:28:50 2019
(r343549)
@@ -240,7 +240,7 @@ nm_os_csum_tcpudp_ipv4(struct nm_iphdr *iph, void *dat
static int notsupported = 0;
if (!notsupported) {
notsupported = 1;
-   D("inet4 segmentation not supported");
+   nm_prerr("inet4 segmentation not supported");
}
 #endif
 }
@@ -256,7 +256,7 @@ nm_os_csum_tcpudp_ipv6(struct nm_ipv6hdr *ip6h, void *
static int notsupported = 0;
if (!notsupported) {
notsupported = 1;
-   D("inet6 segmentation not supported");
+   nm_prerr("inet6 segmentation not supported");
}
 #endif
 }
@@ -288,8 +288,9 @@ freebsd_generic_rx_handler(struct ifnet *ifp, struct m
 {
int stolen;
 
-   if (!NM_NA_VALID(ifp)) {
-   RD(1, "Warning: got RX packet for invalid emulated adapter");
+   if (unlikely(!NM_NA_VALID(ifp))) {
+   nm_prlim(1, "Warning: RX packet intercepted, but no"
+   " emulated adapter");
return;
}
 
@@ -315,15 +316,16 @@ nm_os_catch_rx(struct netmap_generic_adapter *gna, int
nm_os_ifnet_lock();
if (intercept) {
if (gna->save_if_input) {
-   D("cannot intercept again");
-   ret = EINVAL; /* already set */
+   nm_prerr("RX on %s already intercepted", na->name);
+   ret = EBUSY; /* already set */
goto out;
}
gna->save_if_input = ifp->if_input;
ifp->if_input = freebsd_generic_rx_handler;
} else {
-   if (!gna->save_if_input){
-   D("cannot restore");
+   if (!gna->save_if_input) {
+   nm_prerr("Failed to undo RX intercept on %s",
+   na->name);
ret = EINVAL;  /* not saved */
goto out;
}
@@ -392,11 +394,11 @@ nm_os_generic_xmit_frame(struct nm_os_gen_arg *a)
 * we need to copy from the cluster to the netmap buffer.
 */
if (MBUF_REFCNT(m) != 1) {
-   D("invalid refcnt %d for %p", MBUF_REFCNT(m), m);
+   nm_prerr("invalid refcnt %d for %p", MBUF_REFCNT(m), m);
panic("in generic_xmit_frame");
}
if (m->m_ext.ext_size < len) {
-   RD(5, "size %d < len %d", m->m_ext.ext_size, len);
+   nm_prlim(2, "size %d < len %d", m->m_ext.ext_size, len);
len = m->m_ext.ext_size;
}
bcopy(a->addr, m->m_data, len);
@@ -459,7 +461,6 @@ nm_os_generic_set_features(struct netmap_generic_adapt
 void
 nm_os_mitigation_init(struct nm_generic_mit *mit, int idx, struct 
netmap_adapter *na)
 {
-   ND("called");
mit->mit_pending = 0;
mit->mit_ring_idx = idx;
mit->mit_na = na;
@@ -469,21 +470,19 @@ nm_os_mitigation_init(struct nm_generic_mit *mit, int 
 void
 nm_os_mitigation_start(struct nm_generic_mit *mit)
 {
-   ND("called");
 }
 
 
 void
 nm_os_mitigation_restart(struct nm_generic_mit *mit)
 {
-   ND("called");
 }
 
 
 int
 nm_os_mitigation_active(struct nm_generic_mit *mit)
 {
-   ND("called");
+
return 0;
 }
 
@@ -491,12 +490,12 @@ nm_os_mitigation_active(struct nm_generic_mit *mit)
 void
 nm_os_mitigation_cleanup(struct nm_generic_mit *mit)
 {
-   ND("called");
 }
 
 

svn commit: r343548 - in head/sbin: newfs tunefs

[Dmitry Morozovsky]

Author: marck (doc committer)
Date: Tue Jan 29 10:21:41 2019
New Revision: 343548
URL: https://svnweb.freebsd.org/changeset/base/343548

Log:
  Allow dashes as a valid character in UFS labels.
  
  Reviewed by:  mckusick, imp, 0mp
  MFC after:2 weeks
  Differential Revision:D18991

Modified:
  head/sbin/newfs/newfs.8
  head/sbin/newfs/newfs.c
  head/sbin/tunefs/tunefs.8
  head/sbin/tunefs/tunefs.c

Modified: head/sbin/newfs/newfs.8
==
--- head/sbin/newfs/newfs.8 Tue Jan 29 09:22:20 2019(r343547)
+++ head/sbin/newfs/newfs.8 Tue Jan 29 10:21:41 2019(r343548)
@@ -28,7 +28,7 @@
 .\" @(#)newfs.88.6 (Berkeley) 5/3/95
 .\" $FreeBSD$
 .\"
-.Dd July 7, 2017
+.Dd January 29, 2019
 .Dt NEWFS 8
 .Os
 .Sh NAME
@@ -89,7 +89,7 @@ See
 for details.
 .It Fl L Ar volname
 Add a volume label to the new file system.
-Legal characters are alphanumerics and underscores.
+Legal characters are alphanumerics, dashes, and underscores.
 .It Fl N
 Cause the file system parameters to be printed out
 without really creating the file system.

Modified: head/sbin/newfs/newfs.c
==
--- head/sbin/newfs/newfs.c Tue Jan 29 09:22:20 2019(r343547)
+++ head/sbin/newfs/newfs.c Tue Jan 29 10:21:41 2019(r343548)
@@ -153,10 +153,10 @@ main(int argc, char *argv[])
volumelabel = optarg;
i = -1;
while (isalnum(volumelabel[++i]) ||
-   volumelabel[i] == '_');
+   volumelabel[i] == '_' || volumelabel[i] == '-');
if (volumelabel[i] != '\0') {
errx(1, "bad volume label. Valid characters "
-   "are alphanumerics and underscores.");
+   "are alphanumerics, dashes, and 
underscores.");
}
if (strlen(volumelabel) >= MAXVOLLEN) {
errx(1, "bad volume label. Length is longer 
than %d.",

Modified: head/sbin/tunefs/tunefs.8
==
--- head/sbin/tunefs/tunefs.8   Tue Jan 29 09:22:20 2019(r343547)
+++ head/sbin/tunefs/tunefs.8   Tue Jan 29 10:21:41 2019(r343548)
@@ -28,7 +28,7 @@
 .\" @(#)tunefs.8   8.2 (Berkeley) 12/11/93
 .\" $FreeBSD$
 .\"
-.Dd April 19, 2016
+.Dd January 29, 2019
 .Dt TUNEFS 8
 .Os
 .Sh NAME
@@ -112,7 +112,7 @@ By default
 sets it to half of the space reserved to minfree.
 .It Fl L Ar volname
 Add/modify an optional file system volume label.
-Legal characters are alphanumerics and underscores.
+Legal characters are alphanumerics, dashes, and underscores.
 .It Fl l Cm enable | disable
 Turn on/off MAC multilabel flag.
 .It Fl m Ar minfree

Modified: head/sbin/tunefs/tunefs.c
==
--- head/sbin/tunefs/tunefs.c   Tue Jan 29 09:22:20 2019(r343547)
+++ head/sbin/tunefs/tunefs.c   Tue Jan 29 10:21:41 2019(r343548)
@@ -189,10 +189,13 @@ main(int argc, char *argv[])
name = "volume label";
Lvalue = optarg;
i = -1;
-   while (isalnum(Lvalue[++i]) || Lvalue[i] == '_');
+   while (isalnum(Lvalue[++i]) || Lvalue[i] == '_' ||
+   Lvalue[i] == '-')
+   ;
if (Lvalue[i] != '\0') {
errx(10, "bad %s. Valid characters are "
-   "alphanumerics and underscores.", name);
+   "alphanumerics, dashes, and underscores.",
+   name);
}
if (strlen(Lvalue) >= MAXVOLLEN) {
errx(10, "bad %s. Length is longer than %d.",
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

svn commit: r343546 - head/share/misc

[Baptiste Daroussin]

Author: bapt
Date: Tue Jan 29 08:07:14 2019
New Revision: 343546
URL: https://svnweb.freebsd.org/changeset/base/343546

Log:
  Update pci_vendors to 2019.01.29
  
  MFC after:2 days

Modified:
  head/share/misc/pci_vendors

Modified: head/share/misc/pci_vendors
==
--- head/share/misc/pci_vendors Tue Jan 29 07:48:49 2019(r343545)
+++ head/share/misc/pci_vendors Tue Jan 29 08:07:14 2019(r343546)
@@ -2,11 +2,11 @@
 
 #  List of PCI ID's
 #
-#  Version: 2018.08.12
-#  Date:2018-08-12 03:15:01
+#  Version: 2019.01.29
+#  Date:2019-01-29 03:15:01
 #
 #  Maintained by Albert Pool, Martin Mares, and other volunteers from
-#  the PCI ID Project at http://pci-ids.ucw.cz/.
+#  the PCI ID Project at https://pci-ids.ucw.cz/.
 #
 #  New data are always welcome, especially if they are accurate. If you 
have
 #  anything to contribute, please follow the instructions at the web site.
@@ -58,8 +58,7 @@
0680  Ultra ATA/133 IDE RAID CONTROLLER CARD
 # Wrong ID used in subsystem ID of the TELES.S0/PCI 2.x ISDN adapter
 00a7  Teles AG (Wrong ID)
-# nee nCipher
-0100  Thales e-Security
+0100  nCipher Security
 0123  General Dynamics
 0128  Dell (wrong ID)
 # 018a is not LevelOne but there is a board misprogrammed
@@ -275,6 +274,7 @@
8086 9460  RAID Controller RSP3TD160F
8086 9480  RAID Controller RSP3MD088F
0015  MegaRAID Tri-Mode SAS3416
+   1d49 0503  ThinkSystem RAID 530-16i PCIe 12Gb Adapter
0016  MegaRAID Tri-Mode SAS3508
1028 1fc9  PERC H840 Adapter
1028 1fcb  PERC H740P Adapter
@@ -282,7 +282,6 @@
1028 1fcf  PERC H740P Mini
1d49 0601  ThinkSystem RAID 930-8i 2GB Flash PCIe 12Gb Adapter
1d49 0603  ThinkSystem RAID 930-24i 4GB Flash PCIe 12Gb Adapter
-   1d49 0604  ThinkSystem RAID 930-8e 4GB Flash PCIe 12Gb Adapter
8086 352e  Integrated RAID Module RMSP3CD080F
8086 352f  Integrated RAID Module RMSP3HD080E
8086 9461  RAID Controller RSP3DD080F
@@ -413,6 +412,7 @@
005c  SAS1064A PCI-X Fusion-MPT SAS
005d  MegaRAID SAS-3 3108 [Invader]
1000 9361  MegaRAID SAS 9361-8i
+   1000 9363  MegaRAID SAS 9361-4i
1000 9364  MegaRAID SAS 9364-8i
1000 936a  MegaRAID SAS 9364-8i
1028 1f41  PERC H830 Adapter
@@ -445,6 +445,7 @@
1028 1f4d  PERC H330 Embedded (for monolithic)
1054 306a  SAS 3004 iMR ROMB
1d49 04db  ServeRAID M1210 SAS/SATA Controller
+   1d49 0504  ThinkSystem RAID 520-8i PCIe 12Gb Adapter
0060  MegaRAID SAS 1078
1000 1006  MegaRAID SAS ELP
1000 100a  MegaRAID SAS 8708ELP
@@ -483,15 +484,17 @@
0065  SAS2116 PCI-Express Fusion-MPT SAS-2 [Meteor]
006e  SAS2308 PCI-Express Fusion-MPT SAS-2
0070  SAS2004 PCI-Express Fusion-MPT SAS-2 [Spitfire]
+   1000 3010  SAS9211-4i
0071  MR SAS HBA 2004
0072  SAS2008 PCI-Express Fusion-MPT SAS-2 [Falcon]
+   1000 3040  9210-8i
1000 30b0  9200-8e [LSI SAS 6Gb/s SAS/SATA PCIe x8 External HBA]
1028 1f1c  6Gbps SAS HBA Adapter
1028 1f1d  PERC H200 Adapter
1028 1f1e  PERC H200 Integrated
1028 1f1f  PERC H200 Modular
1028 1f20  PERC H200 Embedded
-   1028 1f22  Internal Tape Adapter
+   1028 1f22  PERC H200 Internal Tape Adapter
8086 350f  RMS2LL040 RAID Controller
8086 3700  SSD 910 Series
0073  MegaRAID SAS 2008 [Falcon]
@@ -506,6 +509,7 @@
1028 1f52  PERC H310 Embedded1
1028 1f53  PERC H310 Embedded2
1028 1f54  PERC H310 Reserved
+   1028 1f78  PERC H310
1054 3035  LSI MegaRAID SAS 9240-8i
1137 0072  2004 iMR ROMB
1137 0073  2008 ROMB
@@ -586,10 +590,13 @@
0084  SAS2208 PCI-Express Fusion-MPT SAS-2
0085  SAS2208 PCI-Express Fusion-MPT SAS-2
0086  SAS2308 PCI-Express Fusion-MPT SAS-2
+   15d9 0690  Onboard MegaRAID SAS2208 [Thunderbolt]
+   15d9 0691  Onboard SAS2308 PCI-Express Fusion-MPT SAS-2
0087  SAS2308 PCI-Express Fusion-MPT SAS-2
1000 3020  9207-8i SAS2.1 HBA
1000 3040  9207-8e SAS2.1 HBA
1000 3050  SAS9217-8i
+   1014 0472  N2125 External Host Bus Adapter
1590 0044  H220i
8086 3000  RS25GB008 RAID Controller
8086 3060  RS25FB044 RAID Controller
@@ -627,6 +634,7 @@
8086 3020  RAID Controller RSP3GD016J
00ae  SAS3508 Fusion-MPT Tri-Mode RAID