svn commit: r327689 - head/lib/libcasper/services/cap_dns
Author: oshogbo
Date: Mon Jan 8 09:20:08 2018
New Revision: 327689
URL: https://svnweb.freebsd.org/changeset/base/327689
Log:
Document the DNS Casper service.
Reviewed by: brueffer@, bcr@
Differential Revision:https://reviews.freebsd.org/D13762
Added:
head/lib/libcasper/services/cap_dns/cap_dns.3 (contents, props changed)
Modified:
head/lib/libcasper/services/cap_dns/Makefile
Modified: head/lib/libcasper/services/cap_dns/Makefile
==
--- head/lib/libcasper/services/cap_dns/MakefileMon Jan 8 08:37:31
2018(r327688)
+++ head/lib/libcasper/services/cap_dns/MakefileMon Jan 8 09:20:08
2018(r327689)
@@ -24,4 +24,14 @@ CFLAGS+=-I${.CURDIR}
HAS_TESTS=
SUBDIR.${MK_TESTS}+= tests
+MAN+= cap_dns.3
+
+MLINKS+=cap_dns.3 libcap_dns.3
+MLINKS+=cap_dns.3 cap_gethostbyname.3
+MLINKS+=cap_dns.3 cap_gethostbyname2.3
+MLINKS+=cap_dns.3 cap_gethostbyaddr.3
+MLINKS+=cap_dns.3 cap_getnameinfo.3
+MLINKS+=cap_dns.3 cap_dns_type_limit.3
+MLINKS+=cap_dns.3 cap_dns_family_limit.3
+
.include
Added: head/lib/libcasper/services/cap_dns/cap_dns.3
==
--- /dev/null 00:00:00 1970 (empty, because file is newly added)
+++ head/lib/libcasper/services/cap_dns/cap_dns.3 Mon Jan 8 09:20:08
2018(r327689)
@@ -0,0 +1,205 @@
+.\" Copyright (c) 2018 Mariusz Zaborski
+.\" All rights reserved.
+.\"
+.\" Redistribution and use in source and binary forms, with or without
+.\" modification, are permitted provided that the following conditions
+.\" are met:
+.\" 1. Redistributions of source code must retain the above copyright
+.\"notice, this list of conditions and the following disclaimer.
+.\" 2. Redistributions in binary form must reproduce the above copyright
+.\"notice, this list of conditions and the following disclaimer in the
+.\"documentation and/or other materials provided with the distribution.
+.\"
+.\" THIS SOFTWARE IS PROVIDED BY THE AUTHORS 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 AUTHORS 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 January 8, 2018
+.Dt CAP_DNS 3
+.Os
+.Sh NAME
+.Nm cap_gethostbyname ,
+.Nm cap_gethostbyname2 ,
+.Nm cap_gethostbyaddr ,
+.Nm cap_getnameinfo ,
+.Nm cap_dns_type_limit ,
+.Nm cap_dns_family_limit
+.Nd "library for getting network host entry in capability mode"
+.Sh LIBRARY
+.Lb libcap_dns
+.Sh SYNOPSIS
+.In sys/nv.h
+.In libcasper.h
+.In casper/cap_dns.h
+.Ft "struct hostent *"
+.Fn cap_gethostbyname "const cap_channel_t *chan" "const char *name"
+.Ft "struct hostent *"
+.Fn cap_gethostbyname2 "const cap_channel_t *chan" "const char *name" "int af"
+.Ft "struct hostent *"
+.Fn cap_gethostbyaddr "const cap_channel_t *chan" "const void *addr"
"socklen_t len" "int af"
+.Ft "int"
+.Fn cap_getnameinfo "const cap_channel_t *chan" "const void *name" "int
namelen"
+.Ft "int"
+.Fn cap_dns_type_limit "cap_channel_t *chan" "const char * const *types"
"size_t ntypes"
+.Ft "int"
+.Fn cap_dns_family_limit "const cap_channel_t *chan" "const int *families"
"size_t nfamilies"
+.Sh DESCRIPTION
+The functions
+.Fn cap_gethostbyname ,
+.Fn cap_gethostbyname2 ,
+.Fn cep_gethostbyaddr
+and
+.Xr cap_getnameinfo
+are respectively equivalent to
+.Xr gethostbyname 2 ,
+.Xr gethostbyname2 2 ,
+.Xr gethostbyaddr 2
+and
+.Xr getnameinfo 2
+except that the connection to the
+.Nm system.dns
+service needs to be provided.
+.Pp
+The
+.Fn cap_dns_type_limit
+function limits the functions allowed in the service.
+The
+.Fa types
+variable can be set to
+.Dv ADDR
+or
+.Dv NAME .
+See the
+.Sx LIMITS
+section for more details.
+The
+.Fa ntpyes
+variable contains the number of
+.Fa types
+provided.
+.Pp
+The
+.Fn cap_dns_family_limit
+functions allows to limit address families.
+For details see
+.Sx LIMITS .
+The
+.Fa nfamilies
+variable contains the number of
+.Fa families
+provided.
+.Sh LIMITS
+The preferred way of setting limits is to use the
+.Fn cap_dns_type_limit
+and
+.Fn cap_dns_family_limit
+functions, but the limits of service can be set also using
+.Xr cap_limit_set 3 .
+The nvlist for that function can contain the following values and types:
+.Bl -ohang -offset indent
+.It type ( NV_TYPE_STRING )
+The
+.Va type
svn commit: r327690 - in head/sys/arm64: arm64 include
Author: andrew
Date: Mon Jan 8 10:23:31 2018
New Revision: 327690
URL: https://svnweb.freebsd.org/changeset/base/327690
Log:
Move some of the common thread switching code into C. This will help with
future optimisations, e.g. using Address Space IDs (asid).
MFC after:1 week
Sponsored by: DARPA, AFRL
Modified:
head/sys/arm64/arm64/pmap.c
head/sys/arm64/arm64/swtch.S
head/sys/arm64/include/pmap.h
Modified: head/sys/arm64/arm64/pmap.c
==
--- head/sys/arm64/arm64/pmap.c Mon Jan 8 09:20:08 2018(r327689)
+++ head/sys/arm64/arm64/pmap.c Mon Jan 8 10:23:31 2018(r327690)
@@ -4660,6 +4660,38 @@ pmap_activate(struct thread *td)
critical_exit();
}
+struct pcb *
+pmap_switch(struct thread *old, struct thread *new)
+{
+ struct pcb *pcb;
+
+ /* Store the new curthread */
+ PCPU_SET(curthread, new);
+
+ /* And the new pcb */
+ pcb = new->td_pcb;
+ PCPU_SET(curpcb, pcb);
+
+ /*
+* TODO: We may need to flush the cache here if switching
+* to a user process.
+*/
+
+ __asm __volatile(
+ /* Switch to the new pmap */
+ "msrttbr0_el1, %0 \n"
+ "isb\n"
+
+ /* Invalidate the TLB */
+ "dsbishst \n"
+ "tlbi vmalle1is \n"
+ "dsbish \n"
+ "isb\n"
+ : : "r"(new->td_proc->p_md.md_l0addr));
+
+ return (pcb);
+}
+
void
pmap_sync_icache(pmap_t pmap, vm_offset_t va, vm_size_t sz)
{
Modified: head/sys/arm64/arm64/swtch.S
==
--- head/sys/arm64/arm64/swtch.SMon Jan 8 09:20:08 2018
(r327689)
+++ head/sys/arm64/arm64/swtch.SMon Jan 8 10:23:31 2018
(r327690)
@@ -70,33 +70,16 @@ ENTRY(cpu_throw)
#ifdef VFP
/* Backup the new thread pointer around a call to C code */
- mov x19, x1
+ mov x19, x0
+ mov x20, x1
bl vfp_discard
- mov x1, x19
+ mov x1, x20
+ mov x0, x19
#endif
- /* Store the new curthread */
- str x1, [x18, #PC_CURTHREAD]
- /* And the new pcb */
- ldr x4, [x1, #TD_PCB]
- str x4, [x18, #PC_CURPCB]
+ bl pmap_switch
+ mov x4, x0
- /*
-* TODO: We may need to flush the cache here.
-*/
-
- /* Switch to the new pmap */
- ldr x28, [x1, #TD_PROC]
- ldr x5, [x28, #(P_MD + MD_L0ADDR)]
- msr ttbr0_el1, x5
- isb
-
- /* Invalidate the TLB */
- dsb ishst
- tlbivmalle1
- dsb ish
- isb
-
/* If we are single stepping, enable it */
ldr w5, [x4, #PCB_FLAGS]
set_step_flag w5, x6
@@ -161,45 +144,25 @@ ENTRY(cpu_switch)
ldr w5, [x4, #PCB_FLAGS]
clear_step_flag w5, x6
-#ifdef VFP
mov x19, x0
mov x20, x1
mov x21, x2
+
+#ifdef VFP
/* Load the pcb address */
mov x1, x4
bl vfp_save_state
- mov x2, x21
mov x1, x20
mov x0, x19
#endif
- /* Store the new curthread */
- str x1, [x18, #PC_CURTHREAD]
+ bl pmap_switch
+ /* Move the new pcb out of the way */
+ mov x4, x0
- /*
-* Restore the saved context and set it as curpcb.
-*/
- ldr x4, [x1, #TD_PCB]
- str x4, [x18, #PC_CURPCB]
-
- /*
-* TODO: We may need to flush the cache here if switching
-* to a user process.
-*/
-
- /* Load the new proc address */
- ldr x28, [x1, #TD_PROC]
-
- /* Switch to the new pmap */
- ldr x5, [x28, #(P_MD + MD_L0ADDR)]
- msr ttbr0_el1, x5
- isb
-
- /* Invalidate the TLB */
- dsb ishst
- tlbivmalle1
- dsb ish
- isb
+ mov x2, x21
+ mov x1, x20
+ mov x0, x19
/*
* Release the old thread. This doesn't need to be a store-release
Modified: head/sys/arm64/include/pmap.h
==
--- head/sys/arm64/include/pmap.h Mon Jan 8 09:20:08 2018
(r327689)
+++ head/sys/arm64/include/pmap.h Mon Jan 8 10:23:31 2018
(r327690)
@@ -106,6 +106,8 @@ struct pv_chunk {
typedef struct pmap *pmap_t;
+struct thread;
+
#ifdef _KERNEL
extern struct pmap kernel_pmap_store;
#definekernel_pmap (&kernel_pmap_store)
@@ -155,6 +157,8 @@ boolpmap_get_tables(pmap_t, vm_offset_t, pd_entry_t
*
pd_entry_t **, pt_entry_t **);
intpmap_fault(pmap_t, uint64_t, uint64_t);
+
+struct pcb *pmap_switch(struct thread *, struct thread *);
svn commit: r327691 - head/sys/arm64/arm64
Author: andrew
Date: Mon Jan 8 11:08:45 2018
New Revision: 327691
URL: https://svnweb.freebsd.org/changeset/base/327691
Log:
Only install the new pagetable pointer into ttbr0_el1 when it differs from
the existing value.
MFC after:1 week
Sponsored by: DARPA, AFRL
Modified:
head/sys/arm64/arm64/pmap.c
Modified: head/sys/arm64/arm64/pmap.c
==
--- head/sys/arm64/arm64/pmap.c Mon Jan 8 10:23:31 2018(r327690)
+++ head/sys/arm64/arm64/pmap.c Mon Jan 8 11:08:45 2018(r327691)
@@ -4677,17 +4677,20 @@ pmap_switch(struct thread *old, struct thread *new)
* to a user process.
*/
- __asm __volatile(
- /* Switch to the new pmap */
- "msrttbr0_el1, %0 \n"
- "isb\n"
+ if (old == NULL ||
+ old->td_proc->p_md.md_l0addr != new->td_proc->p_md.md_l0addr) {
+ __asm __volatile(
+ /* Switch to the new pmap */
+ "msrttbr0_el1, %0 \n"
+ "isb\n"
- /* Invalidate the TLB */
- "dsbishst \n"
- "tlbi vmalle1is \n"
- "dsbish \n"
- "isb\n"
- : : "r"(new->td_proc->p_md.md_l0addr));
+ /* Invalidate the TLB */
+ "dsbishst \n"
+ "tlbi vmalle1is \n"
+ "dsbish \n"
+ "isb\n"
+ : : "r"(new->td_proc->p_md.md_l0addr));
+ }
return (pcb);
}
___
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: r327696 - head/sys/opencrypto
Author: fabient
Date: Mon Jan 8 13:43:12 2018
New Revision: 327696
URL: https://svnweb.freebsd.org/changeset/base/327696
Log:
Fix uninitialized crp_retw_id when using asynchronous crypto drivers
with defered callbacks.
Submitted by: emeric.pou...@stormshield.eu
Reported by: mav@
Reviewed by: fabient@
Modified:
head/sys/opencrypto/crypto.c
Modified: head/sys/opencrypto/crypto.c
==
--- head/sys/opencrypto/crypto.cMon Jan 8 13:19:15 2018
(r327695)
+++ head/sys/opencrypto/crypto.cMon Jan 8 13:43:12 2018
(r327696)
@@ -896,11 +896,12 @@ crypto_dispatch(struct cryptop *crp)
binuptime(&crp->crp_tstamp);
#endif
+ crp->crp_retw_id = crp->crp_sid % crypto_workers_num;
+
if (CRYPTOP_ASYNC(crp)) {
if (crp->crp_flags & CRYPTO_F_ASYNC_KEEPORDER) {
struct crypto_ret_worker *ret_worker;
- crp->crp_retw_id = crp->crp_sid % crypto_workers_num;
ret_worker = CRYPTO_RETW(crp->crp_retw_id);
CRYPTO_RETW_LOCK(ret_worker);
___
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: r327684 - in head/sys/compat: cloudabi32 cloudabi64
Hi Andrew, 2018-01-08 8:37 GMT+01:00 Andrew Turner : > Won’t this lead to a NULL pointer dereference on overflow? mallocarray can > return NULL even with M_WAITOK. Yes, it will, but an overflow shouldn't happen in the first place. ri_data_len is compared with UIO_MAXIOV a few lines above. Even if an overflow would happen, this would cause a kernel panic due to a NULL pointer dereference later on, which is likely easier to debug than some piece of code that overruns a buffer. In this case, mallocarray() is preferred, because it makes it more obvious that we're allocating a buffer that is accessed as an array, as opposed to single structure. -- Ed Schouten Nuxi, 's-Hertogenbosch, the Netherlands ___ 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: r327684 - in head/sys/compat: cloudabi32 cloudabi64
Hi; On 08/01/2018 02:37, Andrew Turner wrote: On 7 Jan 2018, at 22:38, Ed Schouten wrote: Author: ed Date: Sun Jan 7 22:38:45 2018 New Revision: 327684 URL: https://svnweb.freebsd.org/changeset/base/327684 Log: Use mallocarray(9) in CloudABI kernel code where possible. Submitted by: pfg@ Modified: head/sys/compat/cloudabi32/cloudabi32_sock.c head/sys/compat/cloudabi64/cloudabi64_sock.c Modified: head/sys/compat/cloudabi32/cloudabi32_sock.c == --- head/sys/compat/cloudabi32/cloudabi32_sock.cSun Jan 7 22:21:07 2018(r327683) +++ head/sys/compat/cloudabi32/cloudabi32_sock.cSun Jan 7 22:38:45 2018(r327684) @@ -60,7 +60,7 @@ cloudabi32_sys_sock_recv(struct thread *td, /* Convert iovecs to native format. */ if (ri.ri_data_len > UIO_MAXIOV) return (EINVAL); - iov = malloc(ri.ri_data_len * sizeof(struct iovec), + iov = mallocarray(ri.ri_data_len, sizeof(struct iovec), M_SOCKET, M_WAITOK); Won’t this lead to a NULL pointer dereference on overflow? mallocarray can return NULL even with M_WAITOK. I think you are right: for the M_WAITOK case we should do the check outside the malloc. Compilers and static checkers should be giving out a warning since mallocarray() has the __result_use_check attribute (is that working!?). In the case of malloc(9) we should remove the attribute since we can by using M_WAITOK. And yes, this patch should be reverted. Pedro. ___ 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: r327684 - in head/sys/compat: cloudabi32 cloudabi64
On 01/08/18 10:13, Ed Schouten wrote: Hi Andrew, 2018-01-08 8:37 GMT+01:00 Andrew Turner : Won’t this lead to a NULL pointer dereference on overflow? mallocarray can return NULL even with M_WAITOK. Yes, it will, but an overflow shouldn't happen in the first place. ri_data_len is compared with UIO_MAXIOV a few lines above. Even if an overflow would happen, this would cause a kernel panic due to a NULL pointer dereference later on, which is likely easier to debug than some piece of code that overruns a buffer. In this case, mallocarray() is preferred, because it makes it more obvious that we're allocating a buffer that is accessed as an array, as opposed to single structure. OK... The behavior of mallocarray() somewhat inconsistent with malloc(9), realloc(9) and reallocf(9) but this is clearly documented., so we just assume the developer knows what he/she is doing :). Pedro. ___ 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: r327697 - head/sys/sys
Author: pfg Date: Mon Jan 8 15:41:48 2018 New Revision: 327697 URL: https://svnweb.freebsd.org/changeset/base/327697 Log: malloc(9): drop the __result_use_check attribute for the kernel allocator. The __result_use_check attribute was brought to the kernel malloc in r281203 for consistency with the userland malloc. For the case of the M_WAITOK flag, the kernel malloc(), realloc(), and reallocf() cannot return NULL so in that case the __result_use_check attribute makes no sense. We don't have any way of conditionalizing such attributes so just drop it. MFC after:3 days Modified: head/sys/sys/malloc.h Modified: head/sys/sys/malloc.h == --- head/sys/sys/malloc.h Mon Jan 8 13:43:12 2018(r327696) +++ head/sys/sys/malloc.h Mon Jan 8 15:41:48 2018(r327697) @@ -176,7 +176,7 @@ void*contigmalloc(unsigned long size, struct malloc_t __alloc_size(1) __alloc_align(6); void free(void *addr, struct malloc_type *type); void *malloc(unsigned long size, struct malloc_type *type, int flags) - __malloc_like __result_use_check __alloc_size(1); + __malloc_like __alloc_size(1); void *mallocarray(size_t nmemb, size_t size, struct malloc_type *type, int flags) __malloc_like __result_use_check __alloc_size(1) __alloc_size(2); @@ -187,7 +187,7 @@ voidmalloc_type_freed(struct malloc_type *type, unsig void malloc_type_list(malloc_type_list_func_t *, void *); void malloc_uninit(void *); void *realloc(void *addr, unsigned long size, struct malloc_type *type, - int flags) __result_use_check __alloc_size(2); + int flags) __alloc_size(2); void *reallocf(void *addr, unsigned long size, struct malloc_type *type, int flags) __alloc_size(2); ___ 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: r327698 - head/sys/geom/mirror
Author: markj
Date: Mon Jan 8 15:41:49 2018
New Revision: 327698
URL: https://svnweb.freebsd.org/changeset/base/327698
Log:
Release the queue lock before restarting the worker loop.
Reported and tested by: pho
MFC after:3 days
Sponsored by: Dell EMC Isilon
Modified:
head/sys/geom/mirror/g_mirror.c
Modified: head/sys/geom/mirror/g_mirror.c
==
--- head/sys/geom/mirror/g_mirror.c Mon Jan 8 15:41:48 2018
(r327697)
+++ head/sys/geom/mirror/g_mirror.c Mon Jan 8 15:41:49 2018
(r327698)
@@ -1964,8 +1964,10 @@ g_mirror_worker(void *arg)
continue;
}
}
- if (g_mirror_event_first(sc) != NULL)
+ if (g_mirror_event_first(sc) != NULL) {
+ mtx_unlock(&sc->sc_queue_mtx);
continue;
+ }
sx_xunlock(&sc->sc_lock);
MSLEEP(sc, &sc->sc_queue_mtx, PRIBIO | PDROP, "m:w1",
timeout * hz);
___
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: r327699 - head/sys/sys
Author: pfg Date: Mon Jan 8 15:54:29 2018 New Revision: 327699 URL: https://svnweb.freebsd.org/changeset/base/327699 Log: Revert r327697: malloc(9): drop the __result_use_check attribute for the kernel allocator. My bad: __result_use_check just checks the for the general and we always want to make sure allocated memory is used, not only checked for nullness. Add it to reallocf since that was missing. Modified: head/sys/sys/malloc.h Modified: head/sys/sys/malloc.h == --- head/sys/sys/malloc.h Mon Jan 8 15:41:49 2018(r327698) +++ head/sys/sys/malloc.h Mon Jan 8 15:54:29 2018(r327699) @@ -176,7 +176,7 @@ void*contigmalloc(unsigned long size, struct malloc_t __alloc_size(1) __alloc_align(6); void free(void *addr, struct malloc_type *type); void *malloc(unsigned long size, struct malloc_type *type, int flags) - __malloc_like __alloc_size(1); + __malloc_like __result_use_check __alloc_size(1); void *mallocarray(size_t nmemb, size_t size, struct malloc_type *type, int flags) __malloc_like __result_use_check __alloc_size(1) __alloc_size(2); @@ -187,9 +187,9 @@ voidmalloc_type_freed(struct malloc_type *type, unsig void malloc_type_list(malloc_type_list_func_t *, void *); void malloc_uninit(void *); void *realloc(void *addr, unsigned long size, struct malloc_type *type, - int flags) __alloc_size(2); + int flags) __result_use_check __alloc_size(2); void *reallocf(void *addr, unsigned long size, struct malloc_type *type, - int flags) __alloc_size(2); + int flags) __result_use_check __alloc_size(2); struct malloc_type *malloc_desc2type(const char *desc); #endif /* _KERNEL */ ___ 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: r327700 - head/sys/geom/mirror
Author: markj
Date: Mon Jan 8 15:56:40 2018
New Revision: 327700
URL: https://svnweb.freebsd.org/changeset/base/327700
Log:
Sort and remove unneeded includes.
MFC after:1 week
Sponsored by: Dell EMC Isilon
Modified:
head/sys/geom/mirror/g_mirror.c
head/sys/geom/mirror/g_mirror_ctl.c
Modified: head/sys/geom/mirror/g_mirror.c
==
--- head/sys/geom/mirror/g_mirror.c Mon Jan 8 15:54:29 2018
(r327699)
+++ head/sys/geom/mirror/g_mirror.c Mon Jan 8 15:56:40 2018
(r327700)
@@ -31,22 +31,22 @@ __FBSDID("$FreeBSD$");
#include
#include
+#include
+#include
#include
#include
-#include
+#include
#include
#include
+#include
#include
-#include
+#include
#include
+#include
+#include
#include
-#include
-#include
-#include
+
#include
-#include
-#include
-#include
#include
FEATURE(geom_mirror, "GEOM mirroring support");
Modified: head/sys/geom/mirror/g_mirror_ctl.c
==
--- head/sys/geom/mirror/g_mirror_ctl.c Mon Jan 8 15:54:29 2018
(r327699)
+++ head/sys/geom/mirror/g_mirror_ctl.c Mon Jan 8 15:56:40 2018
(r327700)
@@ -31,24 +31,17 @@ __FBSDID("$FreeBSD$");
#include
#include
+#include
#include
-#include
#include
#include
-#include
-#include
-#include
-#include
#include
-#include
-#include
-#include
+#include
+#include
+
#include
#include
-#include
-#include
#include
-
static struct g_mirror_softc *
g_mirror_find_device(struct g_class *mp, const char *name)
___
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: r327697 - head/sys/sys
On 01/08/18 10:41, Pedro F. Giffuni wrote: Author: pfg Date: Mon Jan 8 15:41:48 2018 New Revision: 327697 URL: https://svnweb.freebsd.org/changeset/base/327697 Log: malloc(9): drop the __result_use_check attribute for the kernel allocator. The __result_use_check attribute was brought to the kernel malloc in r281203 for consistency with the userland malloc. For the case of the M_WAITOK flag, the kernel malloc(), realloc(), and reallocf() cannot return NULL so in that case the __result_use_check attribute makes no sense. Bah ... I misinterpreted the attribute (hate it when that happens) reverted in r327697, sorry for the code churn. Pedro. ___ 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: r327699 - head/sys/sys
> Author: pfg > Date: Mon Jan 8 15:54:29 2018 > New Revision: 327699 > URL: https://svnweb.freebsd.org/changeset/base/327699 > > Log: > Revert r327697: > malloc(9): drop the __result_use_check attribute for the kernel allocator. > > My bad: __result_use_check just checks the for the general and we always > want to make sure allocated memory is used, not only checked for nullness. > > Add it to reallocf since that was missing. Please try not to combine a revert with an add, it makes it messy to try and figure out things in the future when only the svn log is being used to analyze stuff as digging in mail archives becomes painful. Revert, then commit the add standalone, is the better sequence in this type of situation. > > Modified: > head/sys/sys/malloc.h > > Modified: head/sys/sys/malloc.h > == > --- head/sys/sys/malloc.h Mon Jan 8 15:41:49 2018(r327698) > +++ head/sys/sys/malloc.h Mon Jan 8 15:54:29 2018(r327699) > @@ -176,7 +176,7 @@ void *contigmalloc(unsigned long size, struct > malloc_t > __alloc_size(1) __alloc_align(6); > void free(void *addr, struct malloc_type *type); > void *malloc(unsigned long size, struct malloc_type *type, int flags) > - __malloc_like __alloc_size(1); > + __malloc_like __result_use_check __alloc_size(1); > void *mallocarray(size_t nmemb, size_t size, struct malloc_type *type, > int flags) __malloc_like __result_use_check > __alloc_size(1) __alloc_size(2); > @@ -187,9 +187,9 @@ void malloc_type_freed(struct malloc_type *type, > unsig > void malloc_type_list(malloc_type_list_func_t *, void *); > void malloc_uninit(void *); > void *realloc(void *addr, unsigned long size, struct malloc_type *type, > - int flags) __alloc_size(2); > + int flags) __result_use_check __alloc_size(2); > void *reallocf(void *addr, unsigned long size, struct malloc_type *type, > - int flags) __alloc_size(2); > + int flags) __result_use_check __alloc_size(2); > > struct malloc_type *malloc_desc2type(const char *desc); > #endif /* _KERNEL */ > > -- 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: r327684 - in head/sys/compat: cloudabi32 cloudabi64
On Jan 8, 2018 8:37 AM, "Pedro Giffuni" wrote: On 01/08/18 10:13, Ed Schouten wrote: > Hi Andrew, > > 2018-01-08 8:37 GMT+01:00 Andrew Turner : > >> Won’t this lead to a NULL pointer dereference on overflow? mallocarray >> can return NULL even with M_WAITOK. >> > Yes, it will, but an overflow shouldn't happen in the first place. > ri_data_len is compared with UIO_MAXIOV a few lines above. Even if an > overflow would happen, this would cause a kernel panic due to a NULL > pointer dereference later on, which is likely easier to debug than > some piece of code that overruns a buffer. > > In this case, mallocarray() is preferred, because it makes it more > obvious that we're allocating a buffer that is accessed as an array, > as opposed to single structure. > > OK... The behavior of mallocarray() somewhat inconsistent with malloc(9), realloc(9) and reallocf(9) but this is clearly documented., so we just assume the developer knows what he/she is doing :). This is one reason it didn't go in before... the error semantics suck... we re are a poor match for existing code. Warner ___ 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: r327684 - in head/sys/compat: cloudabi32 cloudabi64
On Mon, 2018-01-08 at 09:13 -0700, Warner Losh wrote: > On Jan 8, 2018 8:37 AM, "Pedro Giffuni" wrote: > > > On 01/08/18 10:13, Ed Schouten wrote: > > > > > Hi Andrew, > > > > 2018-01-08 8:37 GMT+01:00 Andrew Turner : > > > > > > > > Won’t this lead to a NULL pointer dereference on overflow? mallocarray > > > can return NULL even with M_WAITOK. > > > > > Yes, it will, but an overflow shouldn't happen in the first place. > > ri_data_len is compared with UIO_MAXIOV a few lines above. Even if an > > overflow would happen, this would cause a kernel panic due to a NULL > > pointer dereference later on, which is likely easier to debug than > > some piece of code that overruns a buffer. > > > > In this case, mallocarray() is preferred, because it makes it more > > obvious that we're allocating a buffer that is accessed as an array, > > as opposed to single structure. > > > > OK... > The behavior of mallocarray() somewhat inconsistent with malloc(9), > realloc(9) and reallocf(9) but this is clearly documented., so we just > assume the developer knows what he/she is doing :). > > > This is one reason it didn't go in before... the error semantics suck... we > re are a poor match for existing code. > > Warner Yeah, having a bunch of functions with malloc in the name, all taking the same M_WAITOK flag, but that flag has different implications for calling code in regards to just one of the malloc functions... that's just a recipe for creating bugs. It makes this whole function a bad idea. -- Ian ___ 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: r327684 - in head/sys/compat: cloudabi32 cloudabi64
On Mon, Jan 08, 2018 at 09:18:28AM -0700, Ian Lepore wrote: > On Mon, 2018-01-08 at 09:13 -0700, Warner Losh wrote: > > On Jan 8, 2018 8:37 AM, "Pedro Giffuni" wrote: > > On 01/08/18 10:13, Ed Schouten wrote: > > > > > > > > Hi Andrew, > > > > > > 2018-01-08 8:37 GMT+01:00 Andrew Turner : > > > > > > > > > > > Won’t this lead to a NULL pointer dereference on overflow? mallocarray > > > > can return NULL even with M_WAITOK. > > > > > > > Yes, it will, but an overflow shouldn't happen in the first place. > > > ri_data_len is compared with UIO_MAXIOV a few lines above. Even if an > > > overflow would happen, this would cause a kernel panic due to a NULL > > > pointer dereference later on, which is likely easier to debug than > > > some piece of code that overruns a buffer. > > > > > > In this case, mallocarray() is preferred, because it makes it more > > > obvious that we're allocating a buffer that is accessed as an array, > > > as opposed to single structure. > > > > > > OK... > > The behavior of mallocarray() somewhat inconsistent with malloc(9), > > realloc(9) and reallocf(9) but this is clearly documented., so we just > > assume the developer knows what he/she is doing :). > > > > > > This is one reason it didn't go in before... the error semantics suck... we > > re are a poor match for existing code. > > > > Warner > > Yeah, having a bunch of functions with malloc in the name, all taking > the same M_WAITOK flag, but that flag has different implications for > calling code in regards to just one of the malloc functions... contigmalloc(M_WAITOK) isn't guaranteed to succeed either. In that case, M_WAITOK just means "try harder to defragment physical memory in the request space before giving up." > that's just a recipe for creating bugs. It makes this whole function a bad > idea. A NULL return value from mallocarray() indicates a bug in the caller. I don't see why it isn't preferable to crash quickly and loudly in that case. ___ 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: r327684 - in head/sys/compat: cloudabi32 cloudabi64
On Mon, Jan 8, 2018 at 9:29 AM, Mark Johnston wrote: > On Mon, Jan 08, 2018 at 09:18:28AM -0700, Ian Lepore wrote: > > On Mon, 2018-01-08 at 09:13 -0700, Warner Losh wrote: > > > On Jan 8, 2018 8:37 AM, "Pedro Giffuni" wrote: > > > On 01/08/18 10:13, Ed Schouten wrote: > > > > > > > > > > > Hi Andrew, > > > > > > > > 2018-01-08 8:37 GMT+01:00 Andrew Turner : > > > > > > > > > > > > > > Won’t this lead to a NULL pointer dereference on overflow? > mallocarray > > > > > can return NULL even with M_WAITOK. > > > > > > > > > Yes, it will, but an overflow shouldn't happen in the first place. > > > > ri_data_len is compared with UIO_MAXIOV a few lines above. Even if an > > > > overflow would happen, this would cause a kernel panic due to a NULL > > > > pointer dereference later on, which is likely easier to debug than > > > > some piece of code that overruns a buffer. > > > > > > > > In this case, mallocarray() is preferred, because it makes it more > > > > obvious that we're allocating a buffer that is accessed as an array, > > > > as opposed to single structure. > > > > > > > > OK... > > > The behavior of mallocarray() somewhat inconsistent with malloc(9), > > > realloc(9) and reallocf(9) but this is clearly documented., so we just > > > assume the developer knows what he/she is doing :). > > > > > > > > > This is one reason it didn't go in before... the error semantics > suck... we > > > re are a poor match for existing code. > > > > > > Warner > > > > Yeah, having a bunch of functions with malloc in the name, all taking > > the same M_WAITOK flag, but that flag has different implications for > > calling code in regards to just one of the malloc functions... > > contigmalloc(M_WAITOK) isn't guaranteed to succeed either. In that case, > M_WAITOK just means "try harder to defragment physical memory in the > request space before giving up." > > > that's just a recipe for creating bugs. It makes this whole function a > bad > > idea. > > A NULL return value from mallocarray() indicates a bug in the caller. I > don't see why it isn't preferable to crash quickly and loudly in that > case. > When this came up before, people wanted a check_mallocarray(a, b) so they could centralize all the integer overflow knowledge in one place... Seems like we're creating ABIs that are more error prone than the problem we're trying to catch... Warner ___ 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: r327684 - in head/sys/compat: cloudabi32 cloudabi64
On Mon, Jan 08, 2018 at 04:13:42PM +0100, Ed Schouten wrote: > Hi Andrew, > > 2018-01-08 8:37 GMT+01:00 Andrew Turner : > > Won???t this lead to a NULL pointer dereference on overflow? mallocarray > > can return NULL even with M_WAITOK. > > Yes, it will, but an overflow shouldn't happen in the first place. > ri_data_len is compared with UIO_MAXIOV a few lines above. Even if an > overflow would happen, this would cause a kernel panic due to a NULL > pointer dereference later on, which is likely easier to debug than > some piece of code that overruns a buffer. Given that the overflow is due to a bug, there's an argument we should panic rather than returning NULL even in the M_NOWAIT case so we produce a useful message in exactly the right place. -- Brooks signature.asc Description: PGP signature
Re: svn commit: r327697 - head/sys/sys
Hi, Response inline. On Mon, Jan 8, 2018 at 7:41 AM, Pedro F. Giffuni wrote: > Author: pfg > Date: Mon Jan 8 15:41:48 2018 > New Revision: 327697 > URL: https://svnweb.freebsd.org/changeset/base/327697 > > Log: > malloc(9): drop the __result_use_check attribute for the kernel allocator. > > The __result_use_check attribute was brought to the kernel malloc in > r281203 for consistency with the userland malloc. > > For the case of the M_WAITOK flag, the kernel malloc(), realloc(), and > reallocf() cannot return NULL so in that case the __result_use_check > attribute makes no sense. > > We don't have any way of conditionalizing such attributes so just drop it. Could we conditionalize the attribute using two different names and a macro that inspected the (typically) constant flags argument? Something like this: #define malloc(s, t, f) \ (__builtin_constant_p(f) && (f & M_WAITOK) != 0) ? _malloc_waitok(s, t, f) : _malloc(s, t, f) void *_malloc(...) __malloc_like __alloc_size(1); void *_malloc_waitok(...) __malloc_like __result_use_check __alloc_size(1); The two names would just be aliases, or one could invoke the other as an inline function. Best, Conrad ___ 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: r327703 - head/stand/mips/beri/boot2
Author: jhb
Date: Mon Jan 8 18:44:36 2018
New Revision: 327703
URL: https://svnweb.freebsd.org/changeset/base/327703
Log:
Define __dmadat after #include'ing ufsread.c.
The __dmadat variable is a statically allocated I/O buffer. The type is
declared in the ufsread.c source file and clang warns if a variable is
defined before it's type is declared.
Sponsored by: DARPA / AFRL
Modified:
head/stand/mips/beri/boot2/boot2.c
Modified: head/stand/mips/beri/boot2/boot2.c
==
--- head/stand/mips/beri/boot2/boot2.c Mon Jan 8 18:42:40 2018
(r327702)
+++ head/stand/mips/beri/boot2/boot2.c Mon Jan 8 18:44:36 2018
(r327703)
@@ -118,8 +118,6 @@ static const unsigned char flags[NOPT] = {
static const char *const dev_nm[] = {"dram", "cfi", "sdcard"};
static const u_int dev_nm_count = nitems(dev_nm);
-static struct dmadat __dmadat;
-
static struct dsk {
unsigned type; /* BOOTINFO_DEV_TYPE_x object type. */
uintptr_t unitptr; /* Unit number or pointer to object. */
@@ -149,9 +147,10 @@ static int dskread(void *, unsigned, unsigned);
static int xputc(int);
static int xgetc(int);
-
#defineUFS_SMALL_CGBASE
#include "ufsread.c"
+
+static struct dmadat __dmadat;
static inline int
xfsread(ufs_ino_t inode, void *buf, size_t nbyte)
___
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: r327704 - head/stand/mips/beri/loader
Author: jhb
Date: Mon Jan 8 18:46:10 2018
New Revision: 327704
URL: https://svnweb.freebsd.org/changeset/base/327704
Log:
Fix printf missing format variables warnings.
Include the failing kernel file name for errors in beri_elf64_exec().
Sponsored by: DARPA / AFRL
Modified:
head/stand/mips/beri/loader/exec.c
Modified: head/stand/mips/beri/loader/exec.c
==
--- head/stand/mips/beri/loader/exec.c Mon Jan 8 18:44:36 2018
(r327703)
+++ head/stand/mips/beri/loader/exec.c Mon Jan 8 18:46:10 2018
(r327704)
@@ -80,14 +80,14 @@ beri_elf64_exec(struct preloaded_file *fp)
md = file_findmetadata(fp, MODINFOMD_ELFHDR);
if (md == NULL) {
- printf("%s: file_findmetadata failed\n");
+ printf("%s: file_findmetadata failed\n", fp->f_name);
return (EFTYPE);
}
ehdr = (Elf_Ehdr *)md->md_data;
error = md_load64(fp->f_args, &mdp);
if (error) {
- printf("%s: md_load64 failed\n");
+ printf("%s: md_load64 failed\n", fp->f_name);
return (error);
}
___
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: r327705 - head/stand/mips/beri/common
Author: jhb Date: Mon Jan 8 18:47:35 2018 New Revision: 327705 URL: https://svnweb.freebsd.org/changeset/base/327705 Log: Use instead of and in boot code. In the freestanding boot compile environment, standard headers are not available. Curiously, only building with clang exposed this as compiles with external GCC still succeeded. Sponsored by: DARPA / AFRL Modified: head/stand/mips/beri/common/sdcard.c Modified: head/stand/mips/beri/common/sdcard.c == --- head/stand/mips/beri/common/sdcard.cMon Jan 8 18:46:10 2018 (r327704) +++ head/stand/mips/beri/common/sdcard.cMon Jan 8 18:47:35 2018 (r327705) @@ -33,8 +33,7 @@ #include #include -#include -#include +#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"
Re: svn commit: r327705 - head/stand/mips/beri/common
This should have been a nop... libsa specifically creates 'safe' headers for all the standard ones. Ah, libsa creates a perfectly fine stdint.h, but not a inttypes.h... Warner On Mon, Jan 8, 2018 at 11:47 AM, John Baldwin wrote: > Author: jhb > Date: Mon Jan 8 18:47:35 2018 > New Revision: 327705 > URL: https://svnweb.freebsd.org/changeset/base/327705 > > Log: > Use instead of and in boot code. > > In the freestanding boot compile environment, standard headers are not > available. Curiously, only building with clang exposed this as compiles > with external GCC still succeeded. > > Sponsored by: DARPA / AFRL > > Modified: > head/stand/mips/beri/common/sdcard.c > > Modified: head/stand/mips/beri/common/sdcard.c > > == > --- head/stand/mips/beri/common/sdcard.cMon Jan 8 18:46:10 2018 > (r327704) > +++ head/stand/mips/beri/common/sdcard.cMon Jan 8 18:47:35 2018 > (r327705) > @@ -33,8 +33,7 @@ > #include > #include > > -#include > -#include > +#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"
Re: svn commit: r327697 - head/sys/sys
Hi; On 08/01/2018 13:08, Conrad Meyer wrote: Hi, Response inline. On Mon, Jan 8, 2018 at 7:41 AM, Pedro F. Giffuni wrote: Author: pfg Date: Mon Jan 8 15:41:48 2018 New Revision: 327697 URL: https://svnweb.freebsd.org/changeset/base/327697 Log: malloc(9): drop the __result_use_check attribute for the kernel allocator. The __result_use_check attribute was brought to the kernel malloc in r281203 for consistency with the userland malloc. For the case of the M_WAITOK flag, the kernel malloc(), realloc(), and reallocf() cannot return NULL so in that case the __result_use_check attribute makes no sense. We don't have any way of conditionalizing such attributes so just drop it. Could we conditionalize the attribute using two different names and a macro that inspected the (typically) constant flags argument? Something like this: #define malloc(s, t, f) \ (__builtin_constant_p(f) && (f & M_WAITOK) != 0) ? _malloc_waitok(s, t, f) : _malloc(s, t, f) void *_malloc(...) __malloc_like __alloc_size(1); void *_malloc_waitok(...) __malloc_like __result_use_check __alloc_size(1); The two names would just be aliases, or one could invoke the other as an inline function. That would work but I completely misunderstood the GCC attribute. Quoting the GCC documentation: warn_unused_result The warn_unused_result attribute causes a warning to be emitted if a caller of the function with this attribute does not use its return value. This is useful for functions where not checking the result is either a security problem or always a bug, such as realloc. Retrospectively, our attribute is badly named but it was very difficult to come up with a good name. Pedro. ___ 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: r327706 - in head/sys: conf contrib/zstd/lib/freebsd
Author: cem
Date: Mon Jan 8 20:14:16 2018
New Revision: 327706
URL: https://svnweb.freebsd.org/changeset/base/327706
Log:
Integrate zstd into the kernel
Mock userspace headers and include mocked headers first in compilation
command to inject kernel headers and override e.g., malloc(3) with
malloc(9).
Submitted by: allanjude
Reviewed by: imp (earlier version), bapt (earlier version)
Differential Revision:https://reviews.freebsd.org/D10407
Added:
head/sys/contrib/zstd/lib/freebsd/
head/sys/contrib/zstd/lib/freebsd/stddef.h (contents, props changed)
head/sys/contrib/zstd/lib/freebsd/stdint.h (contents, props changed)
head/sys/contrib/zstd/lib/freebsd/stdio.h (contents, props changed)
head/sys/contrib/zstd/lib/freebsd/stdlib.h (contents, props changed)
head/sys/contrib/zstd/lib/freebsd/string.h (contents, props changed)
head/sys/contrib/zstd/lib/freebsd/zstd_kfreebsd.h (contents, props changed)
head/sys/contrib/zstd/lib/freebsd/zstd_kmalloc.c (contents, props changed)
Modified:
head/sys/conf/files
head/sys/conf/kern.pre.mk
Modified: head/sys/conf/files
==
--- head/sys/conf/files Mon Jan 8 18:47:35 2018(r327705)
+++ head/sys/conf/files Mon Jan 8 20:14:16 2018(r327706)
@@ -626,6 +626,23 @@ contrib/ngatm/netnatm/sig/sig_unimsgcpy.c optional nga
compile-with "${NORMAL_C} -I$S/contrib/ngatm"
contrib/ngatm/netnatm/sig/sig_verify.c optional ngatm_uni \
compile-with "${NORMAL_C} -I$S/contrib/ngatm"
+# Zstd
+contrib/zstd/lib/freebsd/zstd_kmalloc.cstandard compile-with
${ZSTD_C}
+contrib/zstd/lib/common/zstd_common.c standard compile-with ${ZSTD_C}
+contrib/zstd/lib/common/fse_decompress.c standard compile-with ${ZSTD_C}
+contrib/zstd/lib/common/entropy_common.c standard compile-with ${ZSTD_C}
+contrib/zstd/lib/common/error_private.cstandard compile-with
${ZSTD_C}
+contrib/zstd/lib/common/xxhash.c standard compile-with ${ZSTD_C}
+contrib/zstd/lib/compress/zstd_compress.c standard compile-with ${ZSTD_C}
+contrib/zstd/lib/compress/fse_compress.c standard compile-with ${ZSTD_C}
+contrib/zstd/lib/compress/huf_compress.c standard compile-with ${ZSTD_C}
+contrib/zstd/lib/compress/zstd_double_fast.c standard compile-with ${ZSTD_C}
+contrib/zstd/lib/compress/zstd_fast.c standard compile-with ${ZSTD_C}
+contrib/zstd/lib/compress/zstd_lazy.c standard compile-with ${ZSTD_C}
+contrib/zstd/lib/compress/zstd_ldm.c standard compile-with ${ZSTD_C}
+contrib/zstd/lib/compress/zstd_opt.c standard compile-with ${ZSTD_C}
+contrib/zstd/lib/decompress/zstd_decompress.c standard compile-with ${ZSTD_C}
+contrib/zstd/lib/decompress/huf_decompress.c standard compile-with ${ZSTD_C}
crypto/blowfish/bf_ecb.c optional ipsec | ipsec_support
crypto/blowfish/bf_skey.c optional crypto | ipsec | ipsec_support
crypto/camellia/camellia.c optional crypto | ipsec | ipsec_support
Modified: head/sys/conf/kern.pre.mk
==
--- head/sys/conf/kern.pre.mk Mon Jan 8 18:47:35 2018(r327705)
+++ head/sys/conf/kern.pre.mk Mon Jan 8 20:14:16 2018(r327706)
@@ -132,6 +132,9 @@ NORMAL_FW= uudecode -o ${.TARGET} ${.ALLSRC}
NORMAL_FWO= ${LD} -b binary --no-warn-mismatch -d -warn-common -r \
-m ${LD_EMULATION} -o ${.TARGET} ${.ALLSRC:M*.fw}
+# for ZSTD in the kernel (include zstd/lib/freebsd before other CFLAGS)
+ZSTD_C= ${CC} -c -DZSTD_HEAPMODE=1 -I$S/contrib/zstd/lib/freebsd ${CFLAGS}
-I$S/contrib/zstd/lib -I$S/contrib/zstd/lib/common ${WERROR}
-Wno-missing-prototypes ${PROF} ${.IMPSRC}
+
# Common for dtrace / zfs
CDDL_CFLAGS= -DFREEBSD_NAMECACHE -nostdinc -I$S/cddl/compat/opensolaris
-I$S/cddl/contrib/opensolaris/uts/common -I$S
-I$S/cddl/contrib/opensolaris/common ${CFLAGS} -Wno-unknown-pragmas
-Wno-missing-prototypes -Wno-undef -Wno-strict-prototypes -Wno-cast-qual
-Wno-parentheses -Wno-redundant-decls -Wno-missing-braces -Wno-uninitialized
-Wno-unused -Wno-inline -Wno-switch -Wno-pointer-arith -Wno-unknown-pragmas
CDDL_CFLAGS+= -include $S/cddl/compat/opensolaris/sys/debug_compat.h
Added: head/sys/contrib/zstd/lib/freebsd/stddef.h
==
--- /dev/null 00:00:00 1970 (empty, because file is newly added)
+++ head/sys/contrib/zstd/lib/freebsd/stddef.h Mon Jan 8 20:14:16 2018
(r327706)
@@ -0,0 +1,3 @@
+/* This file is in the public domain */
+/* $FreeBSD$ */
+#include "zstd_kfreebsd.h"
Added: head/sys/contrib/zstd/lib/freebsd/stdint.h
==
--- /dev/null 00:00:00 1970 (empty, because file is newly added)
+++ head/sys/contrib/zstd/lib/freebsd/stdint.h Mon Jan 8 20:14:16 2018
Re: svn commit: r327699 - head/sys/sys
On 08/01/2018 11:09, Rodney W. Grimes wrote: Author: pfg Date: Mon Jan 8 15:54:29 2018 New Revision: 327699 URL: https://svnweb.freebsd.org/changeset/base/327699 Log: Revert r327697: malloc(9): drop the __result_use_check attribute for the kernel allocator. My bad: __result_use_check just checks the for the general and we always want to make sure allocated memory is used, not only checked for nullness. Add it to reallocf since that was missing. Please try not to combine a revert with an add, it makes it messy to try and figure out things in the future when only the svn log is being used to analyze stuff as digging in mail archives becomes painful. Revert, then commit the add standalone, is the better sequence in this type of situation. Not that any of this is defined in our committers guide but IMHO "svn revert" is just a tool, pretty much as "svn move" and "svn copy". The idea is to make a committers' life easier: making two commits for such a simple change is not "easier". In this case the change is rather consistent: I added __result_use_check to the three functions that needed it. The commit log is not only clear on why the revert happened but also explains the additional one line change. When I MFC it, I will merge both changes for repository consistency but the log will basically mention that I am adding __result_use_check to reallocf(). Pedro. Modified: head/sys/sys/malloc.h Modified: head/sys/sys/malloc.h == --- head/sys/sys/malloc.h Mon Jan 8 15:41:49 2018(r327698) +++ head/sys/sys/malloc.h Mon Jan 8 15:54:29 2018(r327699) @@ -176,7 +176,7 @@ void*contigmalloc(unsigned long size, struct malloc_t __alloc_size(1) __alloc_align(6); void free(void *addr, struct malloc_type *type); void *malloc(unsigned long size, struct malloc_type *type, int flags) - __malloc_like __alloc_size(1); + __malloc_like __result_use_check __alloc_size(1); void *mallocarray(size_t nmemb, size_t size, struct malloc_type *type, int flags) __malloc_like __result_use_check __alloc_size(1) __alloc_size(2); @@ -187,9 +187,9 @@ voidmalloc_type_freed(struct malloc_type *type, unsig void malloc_type_list(malloc_type_list_func_t *, void *); void malloc_uninit(void *); void *realloc(void *addr, unsigned long size, struct malloc_type *type, - int flags) __alloc_size(2); + int flags) __result_use_check __alloc_size(2); void *reallocf(void *addr, unsigned long size, struct malloc_type *type, - int flags) __alloc_size(2); + int flags) __result_use_check __alloc_size(2); struct malloc_type *malloc_desc2type(const char *desc); #endif /* _KERNEL */ Pedro. ___ 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: r327699 - head/sys/sys
I'm (again, atypically) with rgrimes here. Revert has a specific meaning and shouldn't be used like this. Making a commit with the subject "Revert rXXX" that does more than just "svn revert rXXX" makes life harder for developers looking at code history after you. Making two separate commits for two different changes (revert, then add the annotation) is not burdensome. Best, Conrad On Mon, Jan 8, 2018 at 12:18 PM, Pedro Giffuni wrote: > > On 08/01/2018 11:09, Rodney W. Grimes wrote: >>> >>> Author: pfg >>> Date: Mon Jan 8 15:54:29 2018 >>> New Revision: 327699 >>> URL: https://svnweb.freebsd.org/changeset/base/327699 >>> >>> Log: >>>Revert r327697: >>>malloc(9): drop the __result_use_check attribute for the kernel >>> allocator. >>> My bad: __result_use_check just checks the for the general and we >>> always >>>want to make sure allocated memory is used, not only checked for >>> nullness. >>> Add it to reallocf since that was missing. >> >> Please try not to combine a revert with an add, it makes it messy >> to try and figure out things in the future when only the svn log >> is being used to analyze stuff as digging in mail archives becomes >> painful. >> >> Revert, then commit the add standalone, is the better sequence in >> this type of situation. > > > Not that any of this is defined in our committers guide but IMHO "svn > revert" is just a tool, pretty much as "svn move" and "svn copy". The idea > is to make a committers' life easier: making two commits for such a simple > change is not "easier". > > In this case the change is rather consistent: I added __result_use_check to > the three functions that needed it. > The commit log is not only clear on why the revert happened but also > explains the additional one line change. > > When I MFC it, I will merge both changes for repository consistency but the > log will basically mention that I am adding __result_use_check to > reallocf(). > > > Pedro. > >>> Modified: >>>head/sys/sys/malloc.h >>> >>> Modified: head/sys/sys/malloc.h >>> >>> == >>> --- head/sys/sys/malloc.h Mon Jan 8 15:41:49 2018(r327698) >>> +++ head/sys/sys/malloc.h Mon Jan 8 15:54:29 2018(r327699) >>> @@ -176,7 +176,7 @@ void*contigmalloc(unsigned long size, struct >>> malloc_t >>> __alloc_size(1) __alloc_align(6); >>> void free(void *addr, struct malloc_type *type); >>> void *malloc(unsigned long size, struct malloc_type *type, int flags) >>> - __malloc_like __alloc_size(1); >>> + __malloc_like __result_use_check __alloc_size(1); >>> void *mallocarray(size_t nmemb, size_t size, struct malloc_type *type, >>> int flags) __malloc_like __result_use_check >>> __alloc_size(1) __alloc_size(2); >>> @@ -187,9 +187,9 @@ voidmalloc_type_freed(struct malloc_type >>> *type, unsig >>> void malloc_type_list(malloc_type_list_func_t *, void *); >>> void malloc_uninit(void *); >>> void *realloc(void *addr, unsigned long size, struct malloc_type >>> *type, >>> - int flags) __alloc_size(2); >>> + int flags) __result_use_check __alloc_size(2); >>> void *reallocf(void *addr, unsigned long size, struct malloc_type >>> *type, >>> - int flags) __alloc_size(2); >>> + int flags) __result_use_check __alloc_size(2); >>> struct malloc_type *malloc_desc2type(const char *desc); >>> #endif /* _KERNEL */ >>> >>> > > Pedro. > ___ 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: r327699 - head/sys/sys
Hello; On 08/01/2018 15:27, Conrad Meyer wrote: I'm (again, atypically) with rgrimes here. Revert has a specific meaning and shouldn't be used like this. Making a commit with the subject "Revert rXXX" that does more than just "svn revert rXXX" makes life harder for developers looking at code history after you. Making two separate commits for two different changes (revert, then add the annotation) is not burdensome. Best, Conrad Yeah, I understand where that comes from and I will take it into account for future commits, but I think it should be *documented* and not assume that everybody thinks that is the way version control is supposed to be used. Pedro. On Mon, Jan 8, 2018 at 12:18 PM, Pedro Giffuni wrote: On 08/01/2018 11:09, Rodney W. Grimes wrote: Author: pfg Date: Mon Jan 8 15:54:29 2018 New Revision: 327699 URL: https://svnweb.freebsd.org/changeset/base/327699 Log: Revert r327697: malloc(9): drop the __result_use_check attribute for the kernel allocator. My bad: __result_use_check just checks the for the general and we always want to make sure allocated memory is used, not only checked for nullness. Add it to reallocf since that was missing. Please try not to combine a revert with an add, it makes it messy to try and figure out things in the future when only the svn log is being used to analyze stuff as digging in mail archives becomes painful. Revert, then commit the add standalone, is the better sequence in this type of situation. Not that any of this is defined in our committers guide but IMHO "svn revert" is just a tool, pretty much as "svn move" and "svn copy". The idea is to make a committers' life easier: making two commits for such a simple change is not "easier". In this case the change is rather consistent: I added __result_use_check to the three functions that needed it. The commit log is not only clear on why the revert happened but also explains the additional one line change. When I MFC it, I will merge both changes for repository consistency but the log will basically mention that I am adding __result_use_check to reallocf(). Pedro. Modified: head/sys/sys/malloc.h Modified: head/sys/sys/malloc.h == --- head/sys/sys/malloc.h Mon Jan 8 15:41:49 2018(r327698) +++ head/sys/sys/malloc.h Mon Jan 8 15:54:29 2018(r327699) @@ -176,7 +176,7 @@ void*contigmalloc(unsigned long size, struct malloc_t __alloc_size(1) __alloc_align(6); void free(void *addr, struct malloc_type *type); void *malloc(unsigned long size, struct malloc_type *type, int flags) - __malloc_like __alloc_size(1); + __malloc_like __result_use_check __alloc_size(1); void *mallocarray(size_t nmemb, size_t size, struct malloc_type *type, int flags) __malloc_like __result_use_check __alloc_size(1) __alloc_size(2); @@ -187,9 +187,9 @@ voidmalloc_type_freed(struct malloc_type *type, unsig void malloc_type_list(malloc_type_list_func_t *, void *); void malloc_uninit(void *); void *realloc(void *addr, unsigned long size, struct malloc_type *type, - int flags) __alloc_size(2); + int flags) __result_use_check __alloc_size(2); void *reallocf(void *addr, unsigned long size, struct malloc_type *type, - int flags) __alloc_size(2); + int flags) __result_use_check __alloc_size(2); struct malloc_type *malloc_desc2type(const char *desc); #endif /* _KERNEL */ Pedro. ___ 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: r327699 - head/sys/sys
On Mon, Jan 8, 2018 at 12:54 PM, Pedro Giffuni wrote: > Yeah, I understand where that comes from and I will take it into account for > future commits, but I think it should be *documented* and not assume that > everybody thinks that is the way version control is supposed to be used. If you want to document it somewhere, I don't think anyone will stop you. In general, we do have a bunch of unwritten guidelines that are either inferred from reading SVN log / source or explicitly requested via review (pre- or post-commit). I don't think it would hurt to document. I don't know if this specific topic is really a FreeBSD guideline or not, but it's a good practice when using any version control system. (You could do the same thing with 'git revert' — make additions on top of the revert commit — and it would be equally a bad practice with that tool.) The only downsides I see are: 0. No one is interested in spending time writing this down and dealing with the inevitable bikeshedding, 1. Consensus may shift over time, and 2. People don't want to spend a ton of time reading rules Best, Conrad ___ 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: r327707 - in head: share/man/man5 sys/conf sys/ddb sys/kern sys/sys
Author: markj Date: Mon Jan 8 21:27:41 2018 New Revision: 327707 URL: https://svnweb.freebsd.org/changeset/base/327707 Log: Generalize the gzio API. We currently use a set of subroutines in kern_gzio.c to perform compression of user and kernel core dumps. In the interest of adding support for other compression algorithms (zstd) in this role without complicating the API consumers, add a simple compressor API which can be used to select an algorithm. Also change the (non-default) GZIO kernel option to not enable compressed user cores by default. It's not clear that such a default would be desirable with support for multiple algorithms implemented, and it's inconsistent in that it isn't applied to kernel dumps. Reviewed by: cem Differential Revision:https://reviews.freebsd.org/D13632 Added: head/sys/kern/subr_compressor.c - copied, changed from r327706, head/sys/kern/kern_gzio.c head/sys/sys/compressor.h - copied, changed from r327706, head/sys/sys/gzio.h Deleted: head/sys/kern/kern_gzio.c head/sys/sys/gzio.h Modified: head/share/man/man5/core.5 head/sys/conf/files head/sys/ddb/db_textdump.c head/sys/kern/imgact_elf.c head/sys/kern/kern_shutdown.c head/sys/kern/kern_sig.c head/sys/sys/conf.h head/sys/sys/imgact.h Modified: head/share/man/man5/core.5 == --- head/share/man/man5/core.5 Mon Jan 8 20:14:16 2018(r327706) +++ head/share/man/man5/core.5 Mon Jan 8 21:27:41 2018(r327707) @@ -28,7 +28,7 @@ .\" @(#)core.5 8.3 (Berkeley) 12/11/93 .\" $FreeBSD$ .\" -.Dd October 5, 2015 +.Dd January 8, 2018 .Dt CORE 5 .Os .Sh NAME @@ -67,8 +67,8 @@ generating it). .Pp The following format specifiers may be used in the .Va kern.corefile -sysctl to insert additional information into the resulting core file -name: +sysctl to insert additional information into the resulting core +filename: .Bl -tag -width "1234567890" -compact -offset "12345" .It Em \&%H Machine hostname. @@ -108,17 +108,17 @@ is included in the kernel configuration file: GZIO .El .Pp -When the GZIO option is included, the following sysctls control whether core -files will be compressed: -.Bl -tag -width "kern.compress_user_cores_gzlevel" -compact -offset "12345" -.It Em kern.compress_user_cores_gzlevel -Gzip compression level. -Defaults to 6. +The following sysctl control core file compression: +.Bl -tag -width "kern.compress_user_cores_level" -compact -offset "12345" .It Em kern.compress_user_cores -Actually compress user cores. -Compressed core files will have a suffix of +Enable compression of user cores. +A value of 1 configures gzip compression. +gzip-compressed core files will have a suffix of .Ql .gz -appended to them. +appended to their filenames. +.It Em kern.compress_user_cores_level +Compression level. +Defaults to 6. .El .Sh NOTES Corefiles are written with open file descriptor information as an ELF note. @@ -153,6 +153,7 @@ command can be used: .Dl sysctl kern.corefile=/var/coredumps/\&%U/\&%N.core .Sh SEE ALSO .Xr gdb 1 , +.Xr gzip 1 , .Xr kgdb 1 , .Xr setrlimit 2 , .Xr sigaction 2 , Modified: head/sys/conf/files == --- head/sys/conf/files Mon Jan 8 20:14:16 2018(r327706) +++ head/sys/conf/files Mon Jan 8 21:27:41 2018(r327707) @@ -3767,7 +3767,6 @@ kern/kern_exit.c standard kern/kern_fail.c standard kern/kern_ffclock.cstandard kern/kern_fork.c standard -kern/kern_gzio.c optional gzio kern/kern_hhook.c standard kern/kern_idle.c standard kern/kern_intr.c standard @@ -3843,6 +3842,7 @@ kern/subr_bus_dma.c standard kern/subr_bufring.cstandard kern/subr_capability.c standard kern/subr_clock.c standard +kern/subr_compressor.c standard kern/subr_counter.cstandard kern/subr_devstat.cstandard kern/subr_disk.c standard Modified: head/sys/ddb/db_textdump.c == --- head/sys/ddb/db_textdump.c Mon Jan 8 20:14:16 2018(r327706) +++ head/sys/ddb/db_textdump.c Mon Jan 8 21:27:41 2018(r327707) @@ -454,8 +454,8 @@ textdump_dumpsys(struct dumperinfo *di) /* * Disable EKCD because we don't provide encrypted textdumps. */ - kdc = di->kdc; - di->kdc = NULL; + kdc = di->kdcrypto; + di->kdcrypto = NULL; /* * Position the start of the dump so that we'll write the kernel dump @@ -512,7 +512,7 @@ textdump_dumpsys(struct dumperinfo *di) /* * Restore EKCD status. */ - di->kdc = kdc; + di->kdcrypto = kdc; } /*- Modified: head/sys/kern/imgact_elf.c =
svn commit: r327709 - head/sys/cam
Author: scottl
Date: Tue Jan 9 00:00:55 2018
New Revision: 327709
URL: https://svnweb.freebsd.org/changeset/base/327709
Log:
Protect against a possible NULL deference from an accessor
function.
Obtained from:Netflix
Modified:
head/sys/cam/cam_periph.h
Modified: head/sys/cam/cam_periph.h
==
--- head/sys/cam/cam_periph.h Mon Jan 8 22:59:36 2018(r327708)
+++ head/sys/cam/cam_periph.h Tue Jan 9 00:00:55 2018(r327709)
@@ -202,7 +202,10 @@ intcam_periph_error(union ccb *ccb,
cam_flags camfla
static __inline struct mtx *
cam_periph_mtx(struct cam_periph *periph)
{
- return (xpt_path_mtx(periph->path));
+ if (periph != NULL)
+ return (xpt_path_mtx(periph->path));
+ else
+ return (NULL);
}
#define cam_periph_owned(periph) \
___
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: r327710 - in head/sys/cam: . ata scsi
Author: scottl
Date: Tue Jan 9 00:10:59 2018
New Revision: 327710
URL: https://svnweb.freebsd.org/changeset/base/327710
Log:
Don't hold the periph lock when calling into cam_periph_runccb()
from the ada and da dump routines. This avoids difficult locking
problems from needing to be handled. While it might seem like this
would leave the periphs unprotected during dump, they were aleady
at risk of unexpected removal due to the dump functions not
keeping refcount state across the many calls that come in during
a dump. This is an exercise for future work.
Obtained from:Netflix
Modified:
head/sys/cam/ata/ata_da.c
head/sys/cam/cam_periph.c
head/sys/cam/scsi/scsi_da.c
Modified: head/sys/cam/ata/ata_da.c
==
--- head/sys/cam/ata/ata_da.c Tue Jan 9 00:00:55 2018(r327709)
+++ head/sys/cam/ata/ata_da.c Tue Jan 9 00:10:59 2018(r327710)
@@ -1062,15 +1062,12 @@ adadump(void *arg, void *virtual, vm_offset_t physical
dp = arg;
periph = dp->d_drv1;
softc = (struct ada_softc *)periph->softc;
- cam_periph_lock(periph);
secsize = softc->params.secsize;
lba = offset / secsize;
count = length / secsize;
- if ((periph->flags & CAM_PERIPH_INVALID) != 0) {
- cam_periph_unlock(periph);
+ if ((periph->flags & CAM_PERIPH_INVALID) != 0)
return (ENXIO);
- }
memset(&ataio, 0, sizeof(ataio));
if (length > 0) {
@@ -1098,7 +1095,6 @@ adadump(void *arg, void *virtual, vm_offset_t physical
if (error != 0)
printf("Aborting dump due to I/O error.\n");
- cam_periph_unlock(periph);
return (error);
}
@@ -1129,7 +1125,6 @@ adadump(void *arg, void *virtual, vm_offset_t physical
if (error != 0)
xpt_print(periph->path, "Synchronize cache failed\n");
}
- cam_periph_unlock(periph);
return (error);
}
Modified: head/sys/cam/cam_periph.c
==
--- head/sys/cam/cam_periph.c Tue Jan 9 00:00:55 2018(r327709)
+++ head/sys/cam/cam_periph.c Tue Jan 9 00:10:59 2018(r327710)
@@ -1160,8 +1160,6 @@ cam_periph_runccb(union ccb *ccb,
struct bintime ltime;
int error;
bool must_poll;
- struct mtx *periph_mtx;
- struct cam_periph *periph;
uint32_t timeout = 1;
starttime = NULL;
@@ -1188,20 +1186,20 @@ cam_periph_runccb(union ccb *ccb,
* stopped for dumping, except when we call doadump from ddb. While the
* scheduler is running in this case, we still need to poll the I/O to
* avoid sleeping waiting for the ccb to complete.
+*
+* XXX To avoid locking problems, dumping/polling callers must call
+* without a periph lock held.
*/
must_poll = dumping;
ccb->ccb_h.cbfcnp = cam_periph_done;
- periph = xpt_path_periph(ccb->ccb_h.path);
- periph_mtx = cam_periph_mtx(periph);
/*
* If we're polling, then we need to ensure that we have ample resources
-* in the periph. We also need to drop the periph lock while we're
polling.
+* in the periph.
* cam_periph_error can reschedule the ccb by calling xpt_action and
returning
* ERESTART, so we have to effect the polling in the do loop below.
*/
if (must_poll) {
- mtx_unlock(periph_mtx);
timeout = xpt_poll_setup(ccb);
}
@@ -1226,9 +1224,6 @@ cam_periph_runccb(union ccb *ccb,
error = 0;
} while (error == ERESTART);
}
-
- if (must_poll)
- mtx_lock(periph_mtx);
if ((ccb->ccb_h.status & CAM_DEV_QFRZN) != 0) {
cam_release_devq(ccb->ccb_h.path,
Modified: head/sys/cam/scsi/scsi_da.c
==
--- head/sys/cam/scsi/scsi_da.c Tue Jan 9 00:00:55 2018(r327709)
+++ head/sys/cam/scsi/scsi_da.c Tue Jan 9 00:10:59 2018(r327710)
@@ -1647,13 +1647,10 @@ dadump(void *arg, void *virtual, vm_offset_t physical,
dp = arg;
periph = dp->d_drv1;
softc = (struct da_softc *)periph->softc;
- cam_periph_lock(periph);
secsize = softc->params.secsize;
- if ((softc->flags & DA_FLAG_PACK_INVALID) != 0) {
- cam_periph_unlock(periph);
+ if ((softc->flags & DA_FLAG_PACK_INVALID) != 0)
return (ENXIO);
- }
memset(&csio, 0, sizeof(csio));
if (length > 0) {
@@ -1676,7 +1673,6 @@ dadump(void *arg, void *virtual, vm_offset_t physical,
0, SF_NO_RECOVERY | SF_NO_RETRY, NULL);
if (error != 0)
svn commit: r327711 - head/sys/cam/nvme
Author: scottl
Date: Tue Jan 9 00:17:15 2018
New Revision: 327711
URL: https://svnweb.freebsd.org/changeset/base/327711
Log:
Don't hold the periph locks during dump.
Obtained from:Netflix
Modified:
head/sys/cam/nvme/nvme_da.c
Modified: head/sys/cam/nvme/nvme_da.c
==
--- head/sys/cam/nvme/nvme_da.c Tue Jan 9 00:10:59 2018(r327710)
+++ head/sys/cam/nvme/nvme_da.c Tue Jan 9 00:17:15 2018(r327711)
@@ -388,15 +388,12 @@ ndadump(void *arg, void *virtual, vm_offset_t physical
dp = arg;
periph = dp->d_drv1;
softc = (struct nda_softc *)periph->softc;
- cam_periph_lock(periph);
secsize = softc->disk->d_sectorsize;
lba = offset / secsize;
count = length / secsize;
- if ((periph->flags & CAM_PERIPH_INVALID) != 0) {
- cam_periph_unlock(periph);
+ if ((periph->flags & CAM_PERIPH_INVALID) != 0)
return (ENXIO);
- }
/* xpt_get_ccb returns a zero'd allocation for the ccb, mimic that here
*/
memset(&nvmeio, 0, sizeof(nvmeio));
@@ -408,7 +405,6 @@ ndadump(void *arg, void *virtual, vm_offset_t physical
0, SF_NO_RECOVERY | SF_NO_RETRY, NULL);
if (error != 0)
printf("Aborting dump due to I/O error %d.\n", error);
- cam_periph_unlock(periph);
return (error);
}
@@ -422,7 +418,6 @@ ndadump(void *arg, void *virtual, vm_offset_t physical
0, SF_NO_RECOVERY | SF_NO_RETRY, NULL);
if (error != 0)
xpt_print(periph->path, "flush cmd failed\n");
- cam_periph_unlock(periph);
return (error);
}
___
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: r327699 - head/sys/sys
[ Charset UTF-8 unsupported, converting... ] > > On 08/01/2018 11:09, Rodney W. Grimes wrote: > >> Author: pfg > >> Date: Mon Jan 8 15:54:29 2018 > >> New Revision: 327699 > >> URL: https://svnweb.freebsd.org/changeset/base/327699 > >> > >> Log: > >>Revert r327697: > >>malloc(9): drop the __result_use_check attribute for the kernel > >> allocator. > >> > >>My bad: __result_use_check just checks the for the general and we always > >>want to make sure allocated memory is used, not only checked for > >> nullness. > >> > >>Add it to reallocf since that was missing. > > Please try not to combine a revert with an add, it makes it messy > > to try and figure out things in the future when only the svn log > > is being used to analyze stuff as digging in mail archives becomes > > painful. > > > > Revert, then commit the add standalone, is the better sequence in > > this type of situation. > > Not that any of this is defined in our committers guide but IMHO "svn > revert" is just a tool, pretty much as "svn move" and "svn copy". The > idea is to make a committers' life easier: making two commits for such a > simple change is not "easier". It is easier for other commiters to clearly see now, and in the future, exactly what was what. Please do not only think of yourself making the commit, think of all the others that try to read the diffs and understand exactly what is being done and why it is being done. By seperating the revert from the change one reading these can quickly go, yep that simple reverted what was done and move past it. And then when the commit for the new change comes in it is clear that yes, that does exactly what it says it does. Also your now forced to merge a bad commit, and a revert of that bad commit+delta to do a MFC. If this had been done with a pure revert only and then a commit of the correct fix you could of just merged the correct fix. > > In this case the change is rather consistent: I added __result_use_check > to the three functions that needed it. The change is mixed in with the noise of a revert. > The commit log is not only clear on why the revert happened but also > explains the additional one line change. I did not say the commit log was unclear, your correct, it is clear, I am saying that the operation mechanism here is general just a poor way to work in a vcs. > When I MFC it, I will merge both changes for repository consistency but > the log will basically mention that I am adding __result_use_check to > reallocf(). And what well the mergeinfo be? > > Pedro. > >> Modified: > >>head/sys/sys/malloc.h > >> > >> Modified: head/sys/sys/malloc.h > >> == > >> --- head/sys/sys/malloc.h Mon Jan 8 15:41:49 2018(r327698) > >> +++ head/sys/sys/malloc.h Mon Jan 8 15:54:29 2018(r327699) > >> @@ -176,7 +176,7 @@ void *contigmalloc(unsigned long size, struct > >> malloc_t > >>__alloc_size(1) __alloc_align(6); > >> void free(void *addr, struct malloc_type *type); > >> void *malloc(unsigned long size, struct malloc_type *type, int flags) > >> - __malloc_like __alloc_size(1); > >> + __malloc_like __result_use_check __alloc_size(1); > >> void *mallocarray(size_t nmemb, size_t size, struct malloc_type > >> *type, > >>int flags) __malloc_like __result_use_check > >>__alloc_size(1) __alloc_size(2); > >> @@ -187,9 +187,9 @@ void malloc_type_freed(struct malloc_type *type, > >> unsig > >> void malloc_type_list(malloc_type_list_func_t *, void *); > >> void malloc_uninit(void *); > >> void *realloc(void *addr, unsigned long size, struct malloc_type > >> *type, > >> - int flags) __alloc_size(2); > >> + int flags) __result_use_check __alloc_size(2); > >> void *reallocf(void *addr, unsigned long size, struct malloc_type > >> *type, > >> - int flags) __alloc_size(2); > >> + int flags) __result_use_check __alloc_size(2); > >> > >> struct malloc_type *malloc_desc2type(const char *desc); > >> #endif /* _KERNEL */ > >> > >> > > Pedro. > > -- 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: r327699 - head/sys/sys
[ Charset UTF-8 unsupported, converting... ] > Hello; > > On 08/01/2018 15:27, Conrad Meyer wrote: > > I'm (again, atypically) with rgrimes here. Revert has a specific > > meaning and shouldn't be used like this. Making a commit with the > > subject "Revert rXXX" that does more than just "svn revert rXXX" makes > > life harder for developers looking at code history after you. Making > > two separate commits for two different changes (revert, then add the > > annotation) is not burdensome. > > > > Best, > > Conrad > > Yeah, I understand where that comes from and I will take it into account > for future commits, but I think it should be *documented* and not assume > that everybody?s I agree, we should have a section in the commiters guide on doing reverts. We should also have one on how to merge code to other branches and how to format commit messages for merged code. Most of these things should be taught during mentorship, perhaps even a check list for mentor/mentee to make sure they have done most, if not all, of some specific set of things before they are releaesed. I would also like to see a standardize of the revert log format by adding a Revert: line to the template so that it is there in a very standard form that this reverts revision rXX > thinks that is the way version control is supposed to be > used. My background taught me that this is how document control should be used. Vcs is just an automated form of document control. We should also try to do more seperatation of style changes vs functional changes. It just makes things easier to both review and understand. Same with a function add done with a refactor of code, mixing the two in one commit, even in one differential review, makes it harder to understand what is just simply a refactor, and what is the new code. Nothing wrong with making 3 commits in a row to the same area, style, refactor, functional change. This makes it very easy to analyze the changes and IMHO could reduce the rate of breakage. I believe phabricator has the tooling to stack these as well? Dependent diffs or some such thing? > Pedro. > > > On Mon, Jan 8, 2018 at 12:18 PM, Pedro Giffuni wrote: > >> On 08/01/2018 11:09, Rodney W. Grimes wrote: > Author: pfg > Date: Mon Jan 8 15:54:29 2018 > New Revision: 327699 > URL: https://svnweb.freebsd.org/changeset/base/327699 > > Log: > Revert r327697: > malloc(9): drop the __result_use_check attribute for the kernel > allocator. > My bad: __result_use_check just checks the for the general and we > always > want to make sure allocated memory is used, not only checked for > nullness. > Add it to reallocf since that was missing. > >>> Please try not to combine a revert with an add, it makes it messy > >>> to try and figure out things in the future when only the svn log > >>> is being used to analyze stuff as digging in mail archives becomes > >>> painful. > >>> > >>> Revert, then commit the add standalone, is the better sequence in > >>> this type of situation. > >> > >> Not that any of this is defined in our committers guide but IMHO "svn > >> revert" is just a tool, pretty much as "svn move" and "svn copy". The idea > >> is to make a committers' life easier: making two commits for such a simple > >> change is not "easier". > >> > >> In this case the change is rather consistent: I added __result_use_check to > >> the three functions that needed it. > >> The commit log is not only clear on why the revert happened but also > >> explains the additional one line change. > >> > >> When I MFC it, I will merge both changes for repository consistency but the > >> log will basically mention that I am adding __result_use_check to > >> reallocf(). > >> > >> > >> Pedro. > >> > Modified: > head/sys/sys/malloc.h > > Modified: head/sys/sys/malloc.h > > == > --- head/sys/sys/malloc.h Mon Jan 8 15:41:49 2018(r327698) > +++ head/sys/sys/malloc.h Mon Jan 8 15:54:29 2018(r327699) > @@ -176,7 +176,7 @@ void*contigmalloc(unsigned long size, struct > malloc_t > __alloc_size(1) __alloc_align(6); > void free(void *addr, struct malloc_type *type); > void *malloc(unsigned long size, struct malloc_type *type, int flags) > - __malloc_like __alloc_size(1); > + __malloc_like __result_use_check __alloc_size(1); > void *mallocarray(size_t nmemb, size_t size, struct malloc_type > *type, > int flags) __malloc_like __result_use_check > __alloc_size(1) __alloc_size(2); > @@ -187,9 +187,9 @@ voidmalloc_type_freed(struct malloc_type > *type, unsig > void malloc_type_list(malloc_type_list_func_t *, void *); > void malloc_uninit(void *);
svn commit: r327715 - head/sys/conf
Author: cem
Date: Tue Jan 9 03:28:24 2018
New Revision: 327715
URL: https://svnweb.freebsd.org/changeset/base/327715
Log:
Fix Zstd kernel build with GCC 4.2
By disabling the -Winline warning. Fixes the powerpc and sparc64 build
after r327706.
Note: MIPS and RISCV builds still broken due to absense of __ctzdi2 (aka
__builtin_ctzll) in their libgcc or libcompiler-rt libraries.
Reported by: markj
Sponsored by: Dell EMC Isilon
Modified:
head/sys/conf/kern.pre.mk
Modified: head/sys/conf/kern.pre.mk
==
--- head/sys/conf/kern.pre.mk Tue Jan 9 01:41:55 2018(r327714)
+++ head/sys/conf/kern.pre.mk Tue Jan 9 03:28:24 2018(r327715)
@@ -133,7 +133,7 @@ NORMAL_FWO= ${LD} -b binary --no-warn-mismatch -d -war
-m ${LD_EMULATION} -o ${.TARGET} ${.ALLSRC:M*.fw}
# for ZSTD in the kernel (include zstd/lib/freebsd before other CFLAGS)
-ZSTD_C= ${CC} -c -DZSTD_HEAPMODE=1 -I$S/contrib/zstd/lib/freebsd ${CFLAGS}
-I$S/contrib/zstd/lib -I$S/contrib/zstd/lib/common ${WERROR}
-Wno-missing-prototypes ${PROF} ${.IMPSRC}
+ZSTD_C= ${CC} -c -DZSTD_HEAPMODE=1 -I$S/contrib/zstd/lib/freebsd ${CFLAGS}
-I$S/contrib/zstd/lib -I$S/contrib/zstd/lib/common ${WERROR} -Wno-inline
-Wno-missing-prototypes ${PROF} ${.IMPSRC}
# Common for dtrace / zfs
CDDL_CFLAGS= -DFREEBSD_NAMECACHE -nostdinc -I$S/cddl/compat/opensolaris
-I$S/cddl/contrib/opensolaris/uts/common -I$S
-I$S/cddl/contrib/opensolaris/common ${CFLAGS} -Wno-unknown-pragmas
-Wno-missing-prototypes -Wno-undef -Wno-strict-prototypes -Wno-cast-qual
-Wno-parentheses -Wno-redundant-decls -Wno-missing-braces -Wno-uninitialized
-Wno-unused -Wno-inline -Wno-switch -Wno-pointer-arith -Wno-unknown-pragmas
___
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: r327715 - head/sys/conf
Hi,
Could you please tell what is plan to back MIPS works?
Thanks!
On Tue, Jan 9, 2018 at 6:28 AM, Conrad Meyer wrote:
> Author: cem
> Date: Tue Jan 9 03:28:24 2018
> New Revision: 327715
> URL: https://svnweb.freebsd.org/changeset/base/327715
>
> Log:
> Fix Zstd kernel build with GCC 4.2
>
> By disabling the -Winline warning. Fixes the powerpc and sparc64 build
> after r327706.
>
> Note: MIPS and RISCV builds still broken due to absense of __ctzdi2 (aka
> __builtin_ctzll) in their libgcc or libcompiler-rt libraries.
>
> Reported by: markj
> Sponsored by: Dell EMC Isilon
>
> Modified:
> head/sys/conf/kern.pre.mk
>
> Modified: head/sys/conf/kern.pre.mk
>
> ==
> --- head/sys/conf/kern.pre.mk Tue Jan 9 01:41:55 2018(r327714)
> +++ head/sys/conf/kern.pre.mk Tue Jan 9 03:28:24 2018(r327715)
> @@ -133,7 +133,7 @@ NORMAL_FWO= ${LD} -b binary --no-warn-mismatch -d -war
> -m ${LD_EMULATION} -o ${.TARGET} ${.ALLSRC:M*.fw}
>
> # for ZSTD in the kernel (include zstd/lib/freebsd before other CFLAGS)
> -ZSTD_C= ${CC} -c -DZSTD_HEAPMODE=1 -I$S/contrib/zstd/lib/freebsd
> ${CFLAGS} -I$S/contrib/zstd/lib -I$S/contrib/zstd/lib/common ${WERROR}
> -Wno-missing-prototypes ${PROF} ${.IMPSRC}
> +ZSTD_C= ${CC} -c -DZSTD_HEAPMODE=1 -I$S/contrib/zstd/lib/freebsd
> ${CFLAGS} -I$S/contrib/zstd/lib -I$S/contrib/zstd/lib/common ${WERROR}
> -Wno-inline -Wno-missing-prototypes ${PROF} ${.IMPSRC}
>
> # Common for dtrace / zfs
> CDDL_CFLAGS= -DFREEBSD_NAMECACHE -nostdinc -I$S/cddl/compat/opensolaris
> -I$S/cddl/contrib/opensolaris/uts/common -I$S
> -I$S/cddl/contrib/opensolaris/common ${CFLAGS} -Wno-unknown-pragmas
> -Wno-missing-prototypes -Wno-undef -Wno-strict-prototypes -Wno-cast-qual
> -Wno-parentheses -Wno-redundant-decls -Wno-missing-braces
> -Wno-uninitialized -Wno-unused -Wno-inline -Wno-switch -Wno-pointer-arith
> -Wno-unknown-pragmas
>
>
___
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: r327718 - head/sys/contrib/ipfilter/netinet
Author: cy
Date: Tue Jan 9 06:43:58 2018
New Revision: 327718
URL: https://svnweb.freebsd.org/changeset/base/327718
Log:
When growing the state, also grow the seed array. Otherwise memory
that was not allocated will be accessed.
This necessitated refactoring state seed allocation from
ipf_state_soft_init() into a new common ipf_state_seed_alloc() function
as it is now also used by ipf_state_rehash() when changing the size of
the state hash table in addition to by ipf_state_soft_init() during
initialization.
According to Christos Zoulas :
The bug was encountered by a NetBSD vendor who's customer machines had
large ipfilter states. The bug was reliably triggered by resizing the
state variables using "ipf -T".
Submitted by: Christos Zoulas
Reviewed by: delphij, rgrimes
Obtained from:NetBSD ip_state.c CVS revs r1.9 and r1.10
MFC after:2 weeks
Differential Revision:https://reviews.freebsd.org/D13755
Modified:
head/sys/contrib/ipfilter/netinet/ip_state.c
Modified: head/sys/contrib/ipfilter/netinet/ip_state.c
==
--- head/sys/contrib/ipfilter/netinet/ip_state.cTue Jan 9 06:10:57
2018(r327717)
+++ head/sys/contrib/ipfilter/netinet/ip_state.cTue Jan 9 06:43:58
2018(r327718)
@@ -301,7 +301,33 @@ ipf_state_soft_destroy(softc, arg)
KFREE(softs);
}
+static void *
+ipf_state_seed_alloc(u_int state_size, u_int state_max)
+{
+ u_int i;
+ u_long *state_seed;
+ KMALLOCS(state_seed, u_long *, state_size * sizeof(*state_seed));
+ if (state_seed == NULL)
+ return NULL;
+ for (i = 0; i < state_size; i++) {
+ /*
+* XXX - ipf_state_seed[X] should be a random number of sorts.
+*/
+#if FREEBSD_GE_REV(40)
+ state_seed[i] = arc4random();
+#else
+ state_seed[i] = ((u_long)state_seed + i) * state_size;
+ state_seed[i] ^= 0xa5a55a5a;
+ state_seed[i] *= (u_long)state_seed;
+ state_seed[i] ^= 0x5a5aa5a5;
+ state_seed[i] *= state_max;
+#endif
+ }
+ return state_seed;
+}
+
+
/* */
/* Function:ipf_state_soft_init */
/* Returns: int - 0 == success, -1 == failure */
@@ -333,27 +359,11 @@ ipf_state_soft_init(softc, arg)
bzero((char *)softs->ipf_state_table,
softs->ipf_state_size * sizeof(ipstate_t *));
- KMALLOCS(softs->ipf_state_seed, u_long *,
-softs->ipf_state_size * sizeof(*softs->ipf_state_seed));
+ softs->ipf_state_seed = ipf_state_seed_alloc(softs->ipf_state_size,
+ softs->ipf_state_max);
if (softs->ipf_state_seed == NULL)
return -2;
- for (i = 0; i < softs->ipf_state_size; i++) {
- /*
-* XXX - ipf_state_seed[X] should be a random number of sorts.
-*/
-#if FREEBSD_GE_REV(40)
- softs->ipf_state_seed[i] = arc4random();
-#else
- softs->ipf_state_seed[i] = ((u_long)softs->ipf_state_seed + i) *
- softs->ipf_state_size;
- softs->ipf_state_seed[i] ^= 0xa5a55a5a;
- softs->ipf_state_seed[i] *= (u_long)softs->ipf_state_seed;
- softs->ipf_state_seed[i] ^= 0x5a5aa5a5;
- softs->ipf_state_seed[i] *= softs->ipf_state_max;
-#endif
- }
-
KMALLOCS(softs->ipf_state_stats.iss_bucketlen, u_int *,
softs->ipf_state_size * sizeof(u_int));
if (softs->ipf_state_stats.iss_bucketlen == NULL)
@@ -5259,6 +5269,7 @@ ipf_state_rehash(softc, t, p)
{
ipf_state_softc_t *softs = softc->ipf_state_soft;
ipstate_t **newtab, *is;
+ u_long *newseed;
u_int *bucketlens;
u_int maxbucket;
u_int newsize;
@@ -5285,6 +5296,14 @@ ipf_state_rehash(softc, t, p)
return ENOMEM;
}
+ newseed = ipf_state_seed_alloc(newsize, softs->ipf_state_max);
+ if (newseed == NULL) {
+ KFREES(bucketlens, newsize * sizeof(*bucketlens));
+ KFREES(newtab, newsize * sizeof(*newtab));
+ IPFERROR(100037);
+ return ENOMEM;
+ }
+
for (maxbucket = 0, i = newsize; i > 0; i >>= 1)
maxbucket++;
maxbucket *= 2;
@@ -5299,6 +5318,12 @@ ipf_state_rehash(softc, t, p)
softs->ipf_state_size * sizeof(*softs->ipf_state_table));
}
softs->ipf_state_table = newtab;
+
+ if (softs->ipf_state_seed != NULL) {
+ KFREES(softs->ipf_state_seed,
+ softs->ipf_state_size * sizeof(*softs->ipf_state_seed));
+ }
+ softs->ipf_state_seed = newseed;
svn commit: r327719 - head/sbin/ldconfig
Author: eadler Date: Tue Jan 9 06:51:41 2018 New Revision: 327719 URL: https://svnweb.freebsd.org/changeset/base/327719 Log: ldconfig(8): use .Nm instead of 'ldconfig' Modified: head/sbin/ldconfig/ldconfig.8 Modified: head/sbin/ldconfig/ldconfig.8 == --- head/sbin/ldconfig/ldconfig.8 Tue Jan 9 06:43:58 2018 (r327718) +++ head/sbin/ldconfig/ldconfig.8 Tue Jan 9 06:51:41 2018 (r327719) @@ -159,9 +159,10 @@ file. In particular, the .Ev LD_LIBRARY_PATH is not used to search for libraries. -Thus, the role of ldconfig is dual. -In -addition to building a set of hints for quick lookup, it also serves to +Thus, the role of +.Nm +is dual. +In addition to building a set of hints for quick lookup, it also serves to specify the trusted collection of directories from which shared objects can be safely loaded. .Sh FILES ___ 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"
