date:20180525

Re: svn commit: r333945 - head/usr.bin/top

2018-05-25 Thread Eitan Adler

On 20 May 2018 at 23:39, Alexey Dokuchaev  wrote:
> On Mon, May 21, 2018 at 10:32:30AM +1000, Bruce Evans wrote:
>> ...
>> > if (smpmode && namelength > SMPUNAMELEN)
>> > namelength = SMPUNAMELEN;
>> > else if (namelength > UPUNAMELEN)
>>
...

what about this?

commit 7d041879b4d0ad11818b5f5875b1198a722841d7
Author: Eitan Adler 
Date:   Sat May 26 04:30:48 2018 +

top(1): allow to configure the max username length

Some users prefer shorter names, and MAXLOGNAME is not a perfect method
of coming up with a default. Use 8, by request, and allow users to
configure it.

diff --git a/usr.bin/top/machine.c b/usr.bin/top/machine.c
index 0f31d87..d6a9b41 100644
--- a/usr.bin/top/machine.c
+++ b/usr.bin/top/machine.c
@@ -50,8 +50,9 @@
 #include "layout.h"

 #define GETSYSCTL(name, var) getsysctl(name, &(var), sizeof(var))
-#define SMPUNAMELEN 13
-#define UPUNAMELEN 15
+#ifndef MAXTOPNAMELEN
+#define MAXTOPNAMELEN 8
+#endif

 extern struct timeval timeout;
 static int smpmode;
@@ -329,11 +330,7 @@ machine_init(struct statics *statics)
 NULL, 0) == 0 && carc_en == 1)
  carc_enabled = 1;

- namelength = MAXLOGNAME;
- if (smpmode && namelength > SMPUNAMELEN)
- namelength = SMPUNAMELEN;
- else if (namelength > UPUNAMELEN)
- namelength = UPUNAMELEN;
+ namelength = MAXTOPNAMELEN;

  kd = kvm_open(NULL, _PATH_DEVNULL, NULL, O_RDONLY, "kvm_open");
  if (kd == NULL)




-- 
Eitan Adler
Source, Ports, Doc committer
Bugmeister, Ports Security teams
___
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: r334236 - head/sbin/kldstat

2018-05-25 Thread Eitan Adler

Author: eadler
Date: Sat May 26 05:15:07 2018
New Revision: 334236
URL: https://svnweb.freebsd.org/changeset/base/334236

Log:
  kldstat: align "Size" to the right
  
  This change also makes alignment and spacing an explicit number rather
  than a bunch of spaces.
  
  Reviewed by:  mmacy
  Requested by: Yuri Pankov 

Modified:
  head/sbin/kldstat/kldstat.c

Modified: head/sbin/kldstat/kldstat.c
==
--- head/sbin/kldstat/kldstat.c Sat May 26 04:33:19 2018(r334235)
+++ head/sbin/kldstat/kldstat.c Sat May 26 05:15:07 2018(r334236)
@@ -190,9 +190,9 @@ main(int argc, char** argv)
 }
 
 if (humanized)
-   printf("Id Refs Address%*c  Size Name\n", POINTER_WIDTH - 7, ' ');
+   printf("Id Refs Address%*c %5s Name\n", POINTER_WIDTH - 7, ' ', 
"Size");
 else
-   printf("Id Refs Address%*c Size Name\n", POINTER_WIDTH - 7, ' 
');
+   printf("Id Refs Address%*c %8s Name\n", POINTER_WIDTH - 7, ' ', 
"Size");
 if (fileid != 0)
printfile(fileid, verbose, humanized);
 else
___
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: r334235 - in head/sys/powerpc: aim include

2018-05-25 Thread Justin Hibbits

Author: jhibbits
Date: Sat May 26 04:33:19 2018
New Revision: 334235
URL: https://svnweb.freebsd.org/changeset/base/334235

Log:
  On POWER9 clear the HID0_RADIX before enabling the page tables
  
  POWER9 supports Radix page tables in addition to Hashed page tables.  When
  Radix page tables are in use, the TLB is cut in half, so that half of the
  TLB is used for the page walk cache.  This is the default behavior, however
  FreeBSD currently does not support Radix tables.  Clear this bit so that we
  can use the full TLB.  Do this in the MMU logic so that configuration can be
  localized to the specific translation format.  Once we do support Radix
  tables, the setup for that will be localized to the Radix MMU kobj.

Modified:
  head/sys/powerpc/aim/moea64_native.c
  head/sys/powerpc/include/hid.h

Modified: head/sys/powerpc/aim/moea64_native.c
==
--- head/sys/powerpc/aim/moea64_native.cSat May 26 04:24:25 2018
(r334234)
+++ head/sys/powerpc/aim/moea64_native.cSat May 26 04:33:19 2018
(r334235)
@@ -116,6 +116,7 @@ __FBSDID("$FreeBSD$");
 #include 
 
 #include 
+#include 
 #include 
 #include 
 
@@ -383,6 +384,12 @@ moea64_cpu_bootstrap_native(mmu_t mmup, int ap)
 */
 
mtmsr(mfmsr() & ~PSL_DR & ~PSL_IR);
+
+   switch (mfpvr() >> 16) {
+   case IBMPOWER9:
+   mtspr(SPR_HID0, mfspr(SPR_HID0) & ~HID0_RADIX);
+   break;
+   }
 
/*
 * Install kernel SLB entries

Modified: head/sys/powerpc/include/hid.h
==
--- head/sys/powerpc/include/hid.h  Sat May 26 04:24:25 2018
(r334234)
+++ head/sys/powerpc/include/hid.h  Sat May 26 04:33:19 2018
(r334235)
@@ -33,6 +33,7 @@
 #define _POWERPC_HID_H_
 
 /* Hardware Implementation Dependent registers for the PowerPC */
+#defineHID0_RADIX  0x0080  /* Enable Radix page 
tables (POWER9) */
 
 #define HID0_EMCP  0x8000  /* Enable machine check pin */
 #define HID0_DBP   0x4000  /* Disable 60x bus parity generation */
___
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: r334234 - head/sys/powerpc/powernv

2018-05-25 Thread Justin Hibbits

Author: jhibbits
Date: Sat May 26 04:24:25 2018
New Revision: 334234
URL: https://svnweb.freebsd.org/changeset/base/334234

Log:
  Fix a typo missed in r334232

Modified:
  head/sys/powerpc/powernv/opal_sensor.c

Modified: head/sys/powerpc/powernv/opal_sensor.c
==
--- head/sys/powerpc/powernv/opal_sensor.c  Sat May 26 02:59:34 2018
(r334233)
+++ head/sys/powerpc/powernv/opal_sensor.c  Sat May 26 04:24:25 2018
(r334234)
@@ -211,7 +211,7 @@ opal_sensor_attach(device_t dev)
sc->sc_handle = sensor_id;
SYSCTL_ADD_PROC(ctx, SYSCTL_CHILDREN(tree), OID_AUTO,
"sensor", CTLTYPE_INT | CTLFLAG_RD, sc, sensor_id,
-   opal_sensor_sysctl, (sc->sc_type == OPAL_MSG_TYPE_MAX) ? "IK" : "I",
+   opal_sensor_sysctl, (sc->sc_type == OPAL_SENSOR_TEMP) ? "IK" : "I",
"current value");
 
SYSCTL_ADD_STRING(ctx, SYSCTL_CHILDREN(tree), OID_AUTO, "type",
___
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: r334233 - head/sys/vm

2018-05-25 Thread Alan Cox

Author: alc
Date: Sat May 26 02:59:34 2018
New Revision: 334233
URL: https://svnweb.freebsd.org/changeset/base/334233

Log:
  Use pmap_enter(..., psind=1) in vm_fault_populate() on amd64.  While
  superpage mappings were already being created by automatic promotion in
  vm_fault_populate(), this change reduces the cost of creating those
  mappings.  Essentially, one pmap_enter(..., psind=1) call takes the place
  of 512 pmap_enter(..., psind=0) calls, and that one pmap_enter(...,
  psind=1) call eliminates the allocation of a page table page.
  
  Reviewed by:  kib
  MFC after:10 days
  Differential Revision:https://reviews.freebsd.org/D15572

Modified:
  head/sys/vm/vm_fault.c

Modified: head/sys/vm/vm_fault.c
==
--- head/sys/vm/vm_fault.c  Sat May 26 02:45:41 2018(r334232)
+++ head/sys/vm/vm_fault.c  Sat May 26 02:59:34 2018(r334233)
@@ -380,9 +380,11 @@ static int
 vm_fault_populate(struct faultstate *fs, vm_prot_t prot, int fault_type,
 int fault_flags, boolean_t wired, vm_page_t *m_hold)
 {
+   struct mtx *m_mtx;
+   vm_offset_t vaddr;
vm_page_t m;
vm_pindex_t map_first, map_last, pager_first, pager_last, pidx;
-   int rv;
+   int i, npages, psind, rv;
 
MPASS(fs->object == fs->first_object);
VM_OBJECT_ASSERT_WLOCKED(fs->first_object);
@@ -455,26 +457,44 @@ vm_fault_populate(struct faultstate *fs, vm_prot_t pro
pager_last = map_last;
}
for (pidx = pager_first, m = vm_page_lookup(fs->first_object, pidx);
-   pidx <= pager_last; pidx++, m = vm_page_next(m)) {
-   vm_fault_populate_check_page(m);
-   vm_fault_dirty(fs->entry, m, prot, fault_type, fault_flags,
-   true);
+   pidx <= pager_last;
+   pidx += npages, m = vm_page_next([npages - 1])) {
+   vaddr = fs->entry->start + IDX_TO_OFF(pidx) - fs->entry->offset;
+#if defined(__amd64__)
+   psind = m->psind;
+   if (psind > 0 && ((vaddr & (pagesizes[psind] - 1)) != 0 ||
+   pidx + OFF_TO_IDX(pagesizes[psind]) - 1 > pager_last ||
+   !pmap_ps_enabled(fs->map->pmap)))
+   psind = 0;
+#else
+   psind = 0;
+#endif 
+   npages = atop(pagesizes[psind]);
+   for (i = 0; i < npages; i++) {
+   vm_fault_populate_check_page([i]);
+   vm_fault_dirty(fs->entry, [i], prot, fault_type,
+   fault_flags, true);
+   }
VM_OBJECT_WUNLOCK(fs->first_object);
-   pmap_enter(fs->map->pmap, fs->entry->start + IDX_TO_OFF(pidx) -
-   fs->entry->offset, m, prot, fault_type | (wired ?
-   PMAP_ENTER_WIRED : 0), 0);
+   pmap_enter(fs->map->pmap, vaddr, m, prot, fault_type | (wired ?
+   PMAP_ENTER_WIRED : 0), psind);
VM_OBJECT_WLOCK(fs->first_object);
-   if (pidx == fs->first_pindex)
-   vm_fault_fill_hold(m_hold, m);
-   vm_page_lock(m);
-   if ((fault_flags & VM_FAULT_WIRE) != 0) {
-   KASSERT(wired, ("VM_FAULT_WIRE && !wired"));
-   vm_page_wire(m);
-   } else {
-   vm_page_activate(m);
+   m_mtx = NULL;
+   for (i = 0; i < npages; i++) {
+   vm_page_change_lock([i], _mtx);
+   if ((fault_flags & VM_FAULT_WIRE) != 0) {
+   KASSERT(wired, ("VM_FAULT_WIRE && !wired"));
+   vm_page_wire([i]);
+   } else
+   vm_page_activate([i]);
+   if (m_hold != NULL && m[i].pindex == fs->first_pindex) {
+   *m_hold = [i];
+   vm_page_hold([i]);
+   }
+   vm_page_xunbusy([i]);
}
-   vm_page_unlock(m);
-   vm_page_xunbusy(m);
+   if (m_mtx != NULL)
+   mtx_unlock(m_mtx);
}
curthread->td_ru.ru_majflt++;
return (KERN_SUCCESS);
___
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: r334232 - head/sys/powerpc/powernv

2018-05-25 Thread Justin Hibbits

Author: jhibbits
Date: Sat May 26 02:45:41 2018
New Revision: 334232
URL: https://svnweb.freebsd.org/changeset/base/334232

Log:
  Correct a typo for opal temperature sensor type constant

Modified:
  head/sys/powerpc/powernv/opal_sensor.c

Modified: head/sys/powerpc/powernv/opal_sensor.c
==
--- head/sys/powerpc/powernv/opal_sensor.c  Sat May 26 00:46:08 2018
(r334231)
+++ head/sys/powerpc/powernv/opal_sensor.c  Sat May 26 02:45:41 2018
(r334232)
@@ -228,7 +228,7 @@ opal_sensor_attach(device_t dev)
SYSCTL_ADD_PROC(ctx, SYSCTL_CHILDREN(tree), OID_AUTO,
"sensor_min", CTLTYPE_INT | CTLFLAG_RD, sc, sensor_id,
opal_sensor_sysctl,
-   (sc->sc_type == OPAL_MSG_TYPE_MAX) ? "IK" : "I",
+   (sc->sc_type == OPAL_SENSOR_TEMP) ? "IK" : "I",
"minimum value");
}
 
@@ -238,7 +238,7 @@ opal_sensor_attach(device_t dev)
SYSCTL_ADD_PROC(ctx, SYSCTL_CHILDREN(tree), OID_AUTO,
"sensor_max", CTLTYPE_INT | CTLFLAG_RD, sc, sensor_id,
opal_sensor_sysctl,
-   (sc->sc_type == OPAL_MSG_TYPE_MAX) ? "IK" : "I",
+   (sc->sc_type == OPAL_SENSOR_TEMP) ? "IK" : "I",
"maximum value");
}
 
___
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: r334231 - head/sys/net

2018-05-25 Thread Eric Joyner

Author: erj
Date: Sat May 26 00:46:08 2018
New Revision: 334231
URL: https://svnweb.freebsd.org/changeset/base/334231

Log:
  iflib: Add new shared flag: IFLIB_ADMIN_ALWAYS_RUN
  
  ixl(4)'s nvmupdate utility expects the nvmupdate process to run
  while the interface is down; these nvm update commands use the
  admin queue, so the admin queue needs to be able to generate
  interrupts and be processed while the interface is down.
  
  So add a flag that ixl(4) sets that lets the entire admin task
  run even when the interface is marked down/IFF_DRV_RUNNING isn't set.
  
  With this change, nvmupdate should function like it did pre-iflib.
  
  Reviewed by:  gallatin@, sbruno@
  MFC after:1 week
  Sponsored by: Intel Corporation
  Differential Revision:https://reviews.freebsd.org/D15575

Modified:
  head/sys/net/iflib.c
  head/sys/net/iflib.h

Modified: head/sys/net/iflib.c
==
--- head/sys/net/iflib.cSat May 26 00:41:50 2018(r334230)
+++ head/sys/net/iflib.cSat May 26 00:46:08 2018(r334231)
@@ -3807,7 +3807,8 @@ _task_fn_admin(void *context)
ctx->ifc_flags &= ~(IFC_DO_RESET|IFC_DO_WATCHDOG);
STATE_UNLOCK(ctx);
 
-   if (!running & !oactive)
+   if ((!running & !oactive) &&
+   !(ctx->ifc_sctx->isc_flags & IFLIB_ADMIN_ALWAYS_RUN))
return;
 
CTX_LOCK(ctx);

Modified: head/sys/net/iflib.h
==
--- head/sys/net/iflib.hSat May 26 00:41:50 2018(r334230)
+++ head/sys/net/iflib.hSat May 26 00:46:08 2018(r334231)
@@ -358,7 +358,10 @@ typedef enum {
  * autogenerate a MAC address
  */
 #define IFLIB_GEN_MAC  0x08000
-
+/*
+ * Interface needs admin task to ignore interface up/down status
+ */
+#define IFLIB_ADMIN_ALWAYS_RUN 0x1
 
 
 /*
___
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: r334230 - head/sys/powerpc/aim

2018-05-25 Thread Justin Hibbits

Author: jhibbits
Date: Sat May 26 00:41:50 2018
New Revision: 334230
URL: https://svnweb.freebsd.org/changeset/base/334230

Log:
  Only crop the VPN on POWER4 and derivatives for TLBIE operations
  
  Summary:
  PowerISA 2.03 and later require bits 14:65 in the RB register argument,
  which is the full value of the vpn argument post-shift.  Only POWER4, POWER4+,
  and PPC970* need the upper 16 bits cropped.
  
  With this change FreeBSD can boot to multi-user on POWER9.
  
  Reviewed by:  nwhitehorn
  Differential Revision: https://reviews.freebsd.org/D15581

Modified:
  head/sys/powerpc/aim/moea64_native.c

Modified: head/sys/powerpc/aim/moea64_native.c
==
--- head/sys/powerpc/aim/moea64_native.cFri May 25 23:18:06 2018
(r334229)
+++ head/sys/powerpc/aim/moea64_native.cSat May 26 00:41:50 2018
(r334230)
@@ -133,6 +133,8 @@ __FBSDID("$FreeBSD$");
 /* POWER9 only permits a 64k partition table size. */
 #definePART_SIZE   0x1
 
+static int moea64_crop_tlbie;
+
 static __inline void
 TLBIE(uint64_t vpn) {
 #ifndef __powerpc64__
@@ -144,12 +146,14 @@ TLBIE(uint64_t vpn) {
static volatile u_int tlbie_lock = 0;
 
vpn <<= ADDR_PIDX_SHFT;
-   vpn &= ~(0xULL << 48);
 
/* Hobo spinlock: we need stronger guarantees than mutexes provide */
while (!atomic_cmpset_int(_lock, 0, 1));
isync(); /* Flush instruction queue once lock acquired */
 
+   if (moea64_crop_tlbie)
+   vpn &= ~(0xULL << 48);
+
 #ifdef __powerpc64__
__asm __volatile("tlbie %0" :: "r"(vpn) : "memory");
__asm __volatile("eieio; tlbsync; ptesync" ::: "memory");
@@ -428,6 +432,15 @@ moea64_bootstrap_native(mmu_t mmup, vm_offset_t kernel
 
moea64_early_bootstrap(mmup, kernelstart, kernelend);
 
+   switch (mfpvr() >> 16) {
+   case IBMPOWER4:
+   case IBMPOWER4PLUS:
+   case IBM970:
+   case IBM970FX:
+   case IBM970GX:
+   case IBM970MP:
+   moea64_crop_tlbie = true;
+   }
/*
 * Allocate PTEG table.
 */
___
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: Deorbiting i386

2018-05-25 Thread Maxim Sobolev

That again is very subjective view, David. Sorry. Arm32 is kinda kind of
the hill these days in the low-power/low cost space, but arm as a company
is much more interested it seems in going into server / mobile device space
rather than solidifying it's current de-facto kingdom. Those platforms
based on their IP are very short lived and tightly coupled to a particular
vendor with zillions busses, various kinds of weird quirks,
vendor-maintained bootloaders etc. On the other hand, Intel is quickly
closing the gap. If you've seen any of the atom bay trail systems in action
you may understand what I mean. You get full blown x64 system with four
cores and it takes only 2W of power. This is roughly equivalent of ARM8
system with a single core @ only 900MHz.

So my prediction is in the 32-bit land arm will fade out as a platform and
be replaced with RiscV in matter of few years  and i386 will probably
continue to be the platform of choice for many if Intel/Amd play that card
right.

-Max

On Fri, May 25, 2018, 12:27 AM David Chisnall  wrote:

> On 25 May 2018, at 05:27, Maxim Sobolev  wrote:
> >
> > The idea looks very inmature and short-sighted to me. i386 is here to
> stay not as a server/desktop platform but as an embedded/low power/low cost
> platform for at least 5-10 years to come. There are plenty of applications
> in the world that don't need > 3gb of memory space and have no use for
> extra bits (and extra silicon) to function.
>
> This argument seems very odd to me.  If you are targeting the embedded
> space, it is far easier to build a low-power chip that targets the x86-64
> ISA than the x86-32 ISA.  You can move all of the 80-bit floating point
> stuff into microcode.  You can put anything using pair-of-32-bit-register
> 64-bit operations into slow microcode.  You can skimp on store forwarding
> for stack addresses.  You actually need fewer rename registers (one of the
> biggest consumers of power), because x86-64 code needs to do less register
> juggling to fit in the architectural register space.  All of these things
> are big consumers of power and area and are far less necessary when running
> code compiled for x86-64.  You can also do tricks like the one that Intel
> did on the early Atoms, where the SSE ALUs are actually only 64 bits wide
> and the 128-bit ops are cracked into pairs of 64-bit micro-ops.
>
> As to ‘not needing more than 3GB of memory space’, that’s what the x32 ABI
> is for.  This lets you get all of the advantages of the x86-64 ISA (of
> which there are very many, in comparison to x86-32), without needing 64-bit
> pointers.  You get the instruction density of x86-64 combined with the data
> density of x86-32.  This is what Intel and Centaur have been pushing in the
> embedded space for several years.
>
> You do pay a slight hardware cost from supporting a 48-bit virtual address
> space, though with superpages that’s negligible and the hardware targeted
> at these applications often doesn’t support more than a 32-bit virtual
> address space.
>
> And this completely ignores the fact that Intel has almost no presence in
> the low-end embedded space.  AArch32 is vastly more important there and if
> we dropped x86-32 and shifted that effort to AArch32 then I think we’d see
> a lot more adoption.
>
> David
>
___
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: r334221 - head/etc

2018-05-25 Thread Mateusz Piotrowski

On Fri, 25 May 2018 22:56:30 +0200
Mateusz Piotrowski <0...@freebsd.org> wrote:

>On Fri, 25 May 2018 19:36:26 + (UTC)
>Mark Felder  wrote:
>
>>Author: feld (ports committer)
>>Date: Fri May 25 19:36:26 2018
>>New Revision: 334221
>>URL: https://svnweb.freebsd.org/changeset/base/334221
>>
>>Log:
>>  rc.subr: Support loading environmental variables from a file
>>  
>>  The current support for setting environment via foo_env="" in rc.conf is
>>  not scalable and does not handle envs with spaces in the value. It seems
>>  a common pattern for some newer software is to skip configuration files
>>  altogether and rely on the env. This is well supported in systemd unit
>>  files and may be the inspiration for this trend.
>>  
>>  MFH:1 week
>>  Differential Revision:  https://reviews.freebsd.org/D14453
>
>Do you plan to update the rc.subr manual as well?

I've just submitted an update to the rc.subr manual to Phabricator.

https://reviews.freebsd.org/D15578
___
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: r334227 - head/lib/libpmcstat

2018-05-25 Thread Bryan Drewery

Author: bdrewery
Date: Fri May 25 21:46:49 2018
New Revision: 334227
URL: https://svnweb.freebsd.org/changeset/base/334227

Log:
  Use proper BTOOLSPATH for build-tools path.

Modified:
  head/lib/libpmcstat/Makefile

Modified: head/lib/libpmcstat/Makefile
==
--- head/lib/libpmcstat/MakefileFri May 25 21:46:07 2018
(r334226)
+++ head/lib/libpmcstat/MakefileFri May 25 21:46:49 2018
(r334227)
@@ -25,11 +25,7 @@ EVENT_ARCH="x86"
 EVENT_ARCH="powerpc"
 .endif
 
-.if defined(HOST_OBJTOP)
-JEVENTS= ${HOST_OBJTOP}/${RELDIR}/pmu-events/jevents
-.else
-JEVENTS= pmu-events/jevents
-.endif
+JEVENTS= ${BTOOLSPATH:U.}/pmu-events/jevents
 
 libpmcstat_events.c: ${JEVENTS}
${JEVENTS} ${EVENT_ARCH} ${.CURDIR}/pmu-events/arch libpmcstat_events.c
___
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: r334226 - head/lib/libpmcstat/pmu-events

2018-05-25 Thread Bryan Drewery

Author: bdrewery
Date: Fri May 25 21:46:07 2018
New Revision: 334226
URL: https://svnweb.freebsd.org/changeset/base/334226

Log:
  Cleanup style

Modified:
  head/lib/libpmcstat/pmu-events/Makefile

Modified: head/lib/libpmcstat/pmu-events/Makefile
==
--- head/lib/libpmcstat/pmu-events/Makefile Fri May 25 20:42:28 2018
(r334225)
+++ head/lib/libpmcstat/pmu-events/Makefile Fri May 25 21:46:07 2018
(r334226)
@@ -1,9 +1,10 @@
 # $FreeBSD$
 
-PROG=jevents
-SRCS=jevents.c jsmn.c json.c
+PROG=  jevents
+SRCS=  jevents.c jsmn.c json.c
 CFLAGS+= -Wno-cast-qual
-.PATH: ${.CURDIR}
-build-tools: jevents
 MAN=
+
+build-tools: jevents
+
 .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: r334228 - head/lib/libpmcstat

2018-05-25 Thread Bryan Drewery

Author: bdrewery
Date: Fri May 25 21:46:53 2018
New Revision: 334228
URL: https://svnweb.freebsd.org/changeset/base/334228

Log:
  META_MODE: Fix trying to rebuild jevents due to missing .meta file.
  
  The tool is built separately in buildworld in a subdirectory rather than
  how other build-tools are done.  Subdirectory builds in lib/libpmcstat
  remain broken since the tool cannot be auto-built from here.

Modified:
  head/lib/libpmcstat/Makefile

Modified: head/lib/libpmcstat/Makefile
==
--- head/lib/libpmcstat/MakefileFri May 25 21:46:49 2018
(r334227)
+++ head/lib/libpmcstat/MakefileFri May 25 21:46:53 2018
(r334228)
@@ -26,6 +26,9 @@ EVENT_ARCH="powerpc"
 .endif
 
 JEVENTS= ${BTOOLSPATH:U.}/pmu-events/jevents
+# This file is built in a subdirectory so never try to rebuild
+# it here due to missing meta file.
+${JEVENTS}: .NOMETA
 
 libpmcstat_events.c: ${JEVENTS}
${JEVENTS} ${EVENT_ARCH} ${.CURDIR}/pmu-events/arch libpmcstat_events.c
___
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: r333407 - head/share/mk

2018-05-25 Thread Ian Lepore

On Fri, 2018-05-25 at 14:10 -0700, Bryan Drewery wrote:
> On 5/9/2018 6:44 AM, Brad Davis wrote:
> > 
> > Author: brd
> > Date: Wed May  9 13:44:54 2018
> > New Revision: 333407
> > URL: https://svnweb.freebsd.org/changeset/base/333407
> > 
> > Log:
> >   Enable directory creation with FILESDIR.
> >   
> >   This is part of packaging base work.
> >   
> >   Reviewed by:  will
> >   Approved by:  bapt (mentor), allanjude (mentor)
> >   Differential Revision:https://reviews.freebsd.org/D15130
> > 
> Please update share/mk/bsd.README too.
> 
> I know I haven't been very responsive but it's partly because I'm still
> fundamentally against this feature. It's adding a mechanism to replace
> mtree without considering the whole picture and only binding it to FILES
> rather than a bsd.dirs.mk; It doesn't actually satisfy replacing mtree
> files since it only works if there is a FILESGROUP used (FILES must be
> non-empty). So what's the point? My major concern is added confusion.
> The creation of directories for installing is a pain point at work for
> developers but I don't think this is enough. I liked the idea of
> `install "-D"` but I know it's not efficient and had some implementation
> issues.

I welcome this work. If it's not complete/perfect, we can iterate
towards that, but mtree is not a good solution for out-of-tree builds
that use the build machinery in /usr/share/mk. The lack of a solution
other than mtree has led to half a dozen different hacks scattered
around the makefiles in our application repo, and it's about time this
hole in the build system gets plugged.

-- 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: r333407 - head/share/mk

2018-05-25 Thread Brad Davis

On Fri, May 25, 2018, at 3:10 PM, Bryan Drewery wrote:
> On 5/9/2018 6:44 AM, Brad Davis wrote:
> > Author: brd
> > Date: Wed May  9 13:44:54 2018
> > New Revision: 333407
> > URL: https://svnweb.freebsd.org/changeset/base/333407
> > 
> > Log:
> >   Enable directory creation with FILESDIR.
> >   
> >   This is part of packaging base work.
> >   
> >   Reviewed by:  will
> >   Approved by:  bapt (mentor), allanjude (mentor)
> >   Differential Revision:https://reviews.freebsd.org/D15130
> > 
> 
> Please update share/mk/bsd.README too.
> 
> I know I haven't been very responsive but it's partly because I'm still
> fundamentally against this feature. It's adding a mechanism to replace
> mtree without considering the whole picture and only binding it to FILES
> rather than a bsd.dirs.mk; It doesn't actually satisfy replacing mtree
> files since it only works if there is a FILESGROUP used (FILES must be
> non-empty). So what's the point? My major concern is added confusion.
> The creation of directories for installing is a pain point at work for
> developers but I don't think this is enough. I liked the idea of
> `install "-D"` but I know it's not efficient and had some implementation
> issues.
> 
> More below...

Funny that you mention bsd.dirs.mk because that is coming.. after a reorg to 
fix a few other issues that will make this a lot easier..

> > Modified:
> >   head/share/mk/bsd.files.mk
> >   head/share/mk/bsd.own.mk
> > 
> > Modified: head/share/mk/bsd.files.mk
> > ==
> > --- head/share/mk/bsd.files.mk  Wed May  9 12:25:23 2018
> > (r333406)
> > +++ head/share/mk/bsd.files.mk  Wed May  9 13:44:54 2018
> > (r333407)
> > @@ -67,7 +67,7 @@ STAGE_AS_${file:T}= ${${group}NAME_${file:T}}
> >  STAGE_DIR.${file:T}= ${STAGE_OBJTOP}${${group}DIR_${file:T}}
> >  stage_as.${file:T}: ${file}
> >  
> > -installfiles-${group}: _${group}INS_${file:T}
> > +installfiles-${group}: installdirs-${group} _${group}INS_${file:T}
> >  _${group}INS_${file:T}: ${file}
> > ${INSTALL} ${${group}TAG_ARGS} -o ${${group}OWN_${.ALLSRC:T}} \
> > -g ${${group}GRP_${.ALLSRC:T}} -m ${${group}MODE_${.ALLSRC:T}} \
> > @@ -77,10 +77,24 @@ _${group}INS_${file:T}: ${file}
> >  _${group}FILES+= ${file}
> >  .endif
> >  .endfor
> > +
> > +
> > +installdirs-${group}:
> > +   @echo installing dirs ${group}DIR ${${group}DIR}
> > +.for dir in ${${group}DIR}
> > +.if defined(NO_ROOT)
> > +   ${INSTALL} ${${group}TAG_ARGS} -d ${DESTDIR}${dir}
> > +.else
> > +   ${INSTALL} ${${group}TAG_ARGS} -d -o ${DIROWN} -g ${DIRGRP} \
> > +   -m ${DIRMODE} ${DESTDIR}${dir}
> 
> I missed this before but the OWN/GRP/MODE usage needs to be per group
> just like the FILES group ones are above; it needs to be able to modify
> the permissions per group rather than only using the globals.

This is part of the coming bsd.dirs.mk work.  I need to whack the last few bugs 
and push it for review.


Regards,
Brad Davis
___
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: r333407 - head/share/mk

2018-05-25 Thread Bryan Drewery

On 5/9/2018 6:44 AM, Brad Davis wrote:
> Author: brd
> Date: Wed May  9 13:44:54 2018
> New Revision: 333407
> URL: https://svnweb.freebsd.org/changeset/base/333407
> 
> Log:
>   Enable directory creation with FILESDIR.
>   
>   This is part of packaging base work.
>   
>   Reviewed by:will
>   Approved by:bapt (mentor), allanjude (mentor)
>   Differential Revision:  https://reviews.freebsd.org/D15130
> 

Please update share/mk/bsd.README too.

I know I haven't been very responsive but it's partly because I'm still
fundamentally against this feature. It's adding a mechanism to replace
mtree without considering the whole picture and only binding it to FILES
rather than a bsd.dirs.mk; It doesn't actually satisfy replacing mtree
files since it only works if there is a FILESGROUP used (FILES must be
non-empty). So what's the point? My major concern is added confusion.
The creation of directories for installing is a pain point at work for
developers but I don't think this is enough. I liked the idea of
`install "-D"` but I know it's not efficient and had some implementation
issues.

More below...

> Modified:
>   head/share/mk/bsd.files.mk
>   head/share/mk/bsd.own.mk
> 
> Modified: head/share/mk/bsd.files.mk
> ==
> --- head/share/mk/bsd.files.mkWed May  9 12:25:23 2018
> (r333406)
> +++ head/share/mk/bsd.files.mkWed May  9 13:44:54 2018
> (r333407)
> @@ -67,7 +67,7 @@ STAGE_AS_${file:T}= ${${group}NAME_${file:T}}
>  STAGE_DIR.${file:T}= ${STAGE_OBJTOP}${${group}DIR_${file:T}}
>  stage_as.${file:T}: ${file}
>  
> -installfiles-${group}: _${group}INS_${file:T}
> +installfiles-${group}: installdirs-${group} _${group}INS_${file:T}
>  _${group}INS_${file:T}: ${file}
>   ${INSTALL} ${${group}TAG_ARGS} -o ${${group}OWN_${.ALLSRC:T}} \
>   -g ${${group}GRP_${.ALLSRC:T}} -m ${${group}MODE_${.ALLSRC:T}} \
> @@ -77,10 +77,24 @@ _${group}INS_${file:T}: ${file}
>  _${group}FILES+= ${file}
>  .endif
>  .endfor
> +
> +
> +installdirs-${group}:
> + @echo installing dirs ${group}DIR ${${group}DIR}
> +.for dir in ${${group}DIR}
> +.if defined(NO_ROOT)
> + ${INSTALL} ${${group}TAG_ARGS} -d ${DESTDIR}${dir}
> +.else
> + ${INSTALL} ${${group}TAG_ARGS} -d -o ${DIROWN} -g ${DIRGRP} \
> + -m ${DIRMODE} ${DESTDIR}${dir}

I missed this before but the OWN/GRP/MODE usage needs to be per group
just like the FILES group ones are above; it needs to be able to modify
the permissions per group rather than only using the globals.

> +.endif
> +.endfor
> +
> +
>  .if !empty(_${group}FILES)
>  stage_files.${group}: ${_${group}FILES}
>  
> -installfiles-${group}: _${group}INS
> +installfiles-${group}: installdirs-${group} _${group}INS
>  _${group}INS: ${_${group}FILES}
>  .if defined(${group}NAME)
>   ${INSTALL} ${${group}TAG_ARGS} -o ${${group}OWN} -g ${${group}GRP} \
> 
> Modified: head/share/mk/bsd.own.mk
> ==
> --- head/share/mk/bsd.own.mk  Wed May  9 12:25:23 2018(r333406)
> +++ head/share/mk/bsd.own.mk  Wed May  9 13:44:54 2018(r333407)
> @@ -75,6 +75,13 @@
>  # CONFMODE   Configuration file mode. [644]
>  #
>  #
> +# DIROWN Directory owner. [root]
> +#
> +# DIRGRP Directory group. [wheel]
> +#
> +# DIRMODEDirectory mode. [755]
> +#
> +#
>  # DOCDIR Base path for system documentation (e.g. PSD, USD,
>  #handbook, FAQ etc.). [${SHAREDIR}/doc]
>  #
> @@ -185,6 +192,10 @@ MANDIR?= ${SHAREDIR}/man/man
>  MANOWN?= ${SHAREOWN}
>  MANGRP?= ${SHAREGRP}
>  MANMODE?=${NOBINMODE}
> +
> +DIROWN?= root
> +DIRGRP?= wheel
> +DIRMODE?=755
>  
>  DOCDIR?= ${SHAREDIR}/doc
>  DOCOWN?= ${SHAREOWN}
> 


-- 
Regards,
Bryan Drewery



signature.asc
Description: OpenPGP digital signature

Re: svn commit: r334221 - head/etc

2018-05-25 Thread Mateusz Piotrowski

On Fri, 25 May 2018 19:36:26 + (UTC)
Mark Felder  wrote:

>Author: feld (ports committer)
>Date: Fri May 25 19:36:26 2018
>New Revision: 334221
>URL: https://svnweb.freebsd.org/changeset/base/334221
>
>Log:
>  rc.subr: Support loading environmental variables from a file
>  
>  The current support for setting environment via foo_env="" in rc.conf is
>  not scalable and does not handle envs with spaces in the value. It seems
>  a common pattern for some newer software is to skip configuration files
>  altogether and rely on the env. This is well supported in systemd unit
>  files and may be the inspiration for this trend.
>  
>  MFH: 1 week
>  Differential Revision:   https://reviews.freebsd.org/D14453

Do you plan to update the rc.subr manual as well?
___
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: r334225 - head

2018-05-25 Thread Brooks Davis

Author: brooks
Date: Fri May 25 20:42:28 2018
New Revision: 334225
URL: https://svnweb.freebsd.org/changeset/base/334225

Log:
  Support -DNO_CLEAN builds across r334223+r334224.

Modified:
  head/Makefile.inc1

Modified: head/Makefile.inc1
==
--- head/Makefile.inc1  Fri May 25 20:41:26 2018(r334224)
+++ head/Makefile.inc1  Fri May 25 20:42:28 2018(r334225)
@@ -809,7 +809,8 @@ _cleanobj_fast_depend_hack: .PHONY
 # 20180405  r332080  shmat
 # 20180406  r332119  setlogin
 # 20180411  r332443  exect
-.for f in exect fstat fstatat fstatfs getdirentries getfsstat setlogin shmat 
sigreturn statfs
+# 20180525  r334224  vadvise
+.for f in exect fstat fstatat fstatfs getdirentries getfsstat setlogin shmat 
sigreturn statfs vadvise
 .if exists(${OBJTOP}/lib/libc/.depend.${f}.o)
@if egrep -qw '${f}\.[sS]' \
${OBJTOP}/lib/libc/.depend.${f}.o; then \
___
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: r334224 - in head/sys: compat/freebsd32 kern sys

2018-05-25 Thread Brooks Davis

Author: brooks
Date: Fri May 25 20:41:26 2018
New Revision: 334224
URL: https://svnweb.freebsd.org/changeset/base/334224

Log:
  Regen after r334223: make vadvise compat freebsd11.

Modified:
  head/sys/compat/freebsd32/freebsd32_syscall.h
  head/sys/compat/freebsd32/freebsd32_syscalls.c
  head/sys/compat/freebsd32/freebsd32_sysent.c
  head/sys/compat/freebsd32/freebsd32_systrace_args.c
  head/sys/kern/init_sysent.c
  head/sys/kern/syscalls.c
  head/sys/kern/systrace_args.c
  head/sys/sys/syscall.h
  head/sys/sys/syscall.mk
  head/sys/sys/sysproto.h

Modified: head/sys/compat/freebsd32/freebsd32_syscall.h
==
--- head/sys/compat/freebsd32/freebsd32_syscall.h   Fri May 25 20:40:23 
2018(r334223)
+++ head/sys/compat/freebsd32/freebsd32_syscall.h   Fri May 25 20:41:26 
2018(r334224)
@@ -77,7 +77,7 @@
 #defineFREEBSD32_SYS_sbrk  69
 #defineFREEBSD32_SYS_sstk  70
/* 71 is old mmap */
-#defineFREEBSD32_SYS_vadvise   72
+#defineFREEBSD32_SYS_freebsd11_vadvise 72
 #defineFREEBSD32_SYS_munmap73
 #defineFREEBSD32_SYS_freebsd32_mprotect74
 #defineFREEBSD32_SYS_madvise   75

Modified: head/sys/compat/freebsd32/freebsd32_syscalls.c
==
--- head/sys/compat/freebsd32/freebsd32_syscalls.c  Fri May 25 20:40:23 
2018(r334223)
+++ head/sys/compat/freebsd32/freebsd32_syscalls.c  Fri May 25 20:41:26 
2018(r334224)
@@ -81,7 +81,7 @@ const char *freebsd32_syscallnames[] = {
"sbrk", /* 69 = sbrk */
"sstk", /* 70 = sstk */
"compat.mmap",  /* 71 = old mmap */
-   "vadvise",  /* 72 = vadvise */
+   "compat11.vadvise", /* 72 = freebsd11 vadvise */
"munmap",   /* 73 = munmap */
"freebsd32_mprotect",   /* 74 = freebsd32_mprotect */
"madvise",  /* 75 = madvise */

Modified: head/sys/compat/freebsd32/freebsd32_sysent.c
==
--- head/sys/compat/freebsd32/freebsd32_sysent.cFri May 25 20:40:23 
2018(r334223)
+++ head/sys/compat/freebsd32/freebsd32_sysent.cFri May 25 20:41:26 
2018(r334224)
@@ -128,7 +128,7 @@ struct sysent freebsd32_sysent[] = {
{ AS(sbrk_args), (sy_call_t *)sys_sbrk, AUE_SBRK, NULL, 0, 0, 
SYF_CAPENABLED, SY_THR_STATIC },  /* 69 = sbrk */
{ AS(sstk_args), (sy_call_t *)sys_sstk, AUE_SSTK, NULL, 0, 0, 
SYF_CAPENABLED, SY_THR_STATIC },  /* 70 = sstk */
{ compat(AS(ommap_args),mmap), AUE_MMAP, NULL, 0, 0, 0, SY_THR_STATIC 
},/* 71 = old mmap */
-   { AS(ovadvise_args), (sy_call_t *)sys_ovadvise, AUE_O_VADVISE, NULL, 0, 
0, 0, SY_THR_STATIC },  /* 72 = vadvise */
+   { compat11(AS(freebsd11_vadvise_args),vadvise), AUE_O_VADVISE, NULL, 0, 
0, 0, SY_THR_STATIC },  /* 72 = freebsd11 vadvise */
{ AS(munmap_args), (sy_call_t *)sys_munmap, AUE_MUNMAP, NULL, 0, 0, 
SYF_CAPENABLED, SY_THR_STATIC },/* 73 = munmap */
{ AS(freebsd32_mprotect_args), (sy_call_t *)freebsd32_mprotect, 
AUE_MPROTECT, NULL, 0, 0, SYF_CAPENABLED, SY_THR_STATIC },  /* 74 = 
freebsd32_mprotect */
{ AS(madvise_args), (sy_call_t *)sys_madvise, AUE_MADVISE, NULL, 0, 0, 
SYF_CAPENABLED, SY_THR_STATIC }, /* 75 = madvise */

Modified: head/sys/compat/freebsd32/freebsd32_systrace_args.c
==
--- head/sys/compat/freebsd32/freebsd32_systrace_args.c Fri May 25 20:40:23 
2018(r334223)
+++ head/sys/compat/freebsd32/freebsd32_systrace_args.c Fri May 25 20:41:26 
2018(r334224)
@@ -435,13 +435,6 @@ systrace_args(int sysnum, void *params, uint64_t *uarg
*n_args = 1;
break;
}
-   /* ovadvise */
-   case 72: {
-   struct ovadvise_args *p = params;
-   iarg[0] = p->anom; /* int */
-   *n_args = 1;
-   break;
-   }
/* munmap */
case 73: {
struct munmap_args *p = params;
@@ -3944,16 +3937,6 @@ systrace_entry_setargdesc(int sysnum, int ndx, char *d
break;
};
break;
-   /* ovadvise */
-   case 72:
-   switch(ndx) {
-   case 0:
-   p = "int";
-   break;
-   default:
-   break;
-   };
-   break;
/* munmap */
case 73:
switch(ndx) {
@@ -9081,11 +9064,6 @@ systrace_return_setargdesc(int sysnum, int ndx, char *
break;
/* sstk */
case 70:
-   if (ndx == 0 || ndx ==

svn commit: r334223 - in head: lib/libc/sys sys/compat/freebsd32 sys/kern sys/vm

2018-05-25 Thread Brooks Davis

Author: brooks
Date: Fri May 25 20:40:23 2018
New Revision: 334223
URL: https://svnweb.freebsd.org/changeset/base/334223

Log:
  Make vadvise compat freebsd11.
  
  The vadvise syscall (aka ovadvise) is undocumented and has always been
  implmented as returning EINVAL.  Put the syscall under COMPAT11 and
  provide a userspace implementation.
  
  Reviewed by:  kib
  Sponsored by: DARPA, AFRL
  Differential Revision:https://reviews.freebsd.org/D15557

Added:
  head/lib/libc/sys/vadvise.c   (contents, props changed)
Modified:
  head/lib/libc/sys/Makefile.inc
  head/lib/libc/sys/Symbol.map
  head/sys/compat/freebsd32/syscalls.master
  head/sys/kern/syscalls.master
  head/sys/vm/vm_unix.c

Modified: head/lib/libc/sys/Makefile.inc
==
--- head/lib/libc/sys/Makefile.inc  Fri May 25 19:48:26 2018
(r334222)
+++ head/lib/libc/sys/Makefile.inc  Fri May 25 20:40:23 2018
(r334223)
@@ -46,6 +46,7 @@ NOASM+= getdirentries.o
 PSEUDO+= _getdirentries.o
 
 SRCS+= pipe.c
+SRCS+= vadvise.c
 
 INTERPOSED = \
accept \

Modified: head/lib/libc/sys/Symbol.map
==
--- head/lib/libc/sys/Symbol.mapFri May 25 19:48:26 2018
(r334222)
+++ head/lib/libc/sys/Symbol.mapFri May 25 20:40:23 2018
(r334223)
@@ -1010,8 +1010,6 @@ FBSDprivate_1.0 {
__sys_utrace;
_uuidgen;
__sys_uuidgen;
-   _vadvise;
-   __sys_vadvise;
_wait4;
__sys_wait4;
_wait6;

Added: head/lib/libc/sys/vadvise.c
==
--- /dev/null   00:00:00 1970   (empty, because file is newly added)
+++ head/lib/libc/sys/vadvise.c Fri May 25 20:40:23 2018(r334223)
@@ -0,0 +1,46 @@
+/*-
+ * SPDX-License-Identifier: BSD-2-Clause
+ *
+ * Copyright (c) 2018 SRI International
+ * All rights reserved.
+ *
+ * This software was developed by SRI International and the University of
+ * Cambridge Computer Laboratory (Department of Computer Science and
+ * Technology) under DARPA contract HR0011-18-C-0016 ("ECATS"), as part of the
+ * DARPA SSITH research programme.
+ *
+ * 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$
+ */
+
+#include 
+#include 
+
+int vadvise(int);
+
+int
+vadvise(int arg __unused)
+{
+
+   return (EINVAL);
+}

Modified: head/sys/compat/freebsd32/syscalls.master
==
--- head/sys/compat/freebsd32/syscalls.master   Fri May 25 19:48:26 2018
(r334222)
+++ head/sys/compat/freebsd32/syscalls.master   Fri May 25 20:40:23 2018
(r334223)
@@ -173,8 +173,7 @@
 70 AUE_SSTKNOPROTO { int sstk(int incr); }
 71 AUE_MMAPCOMPAT|NOPROTO  { int mmap(void *addr, int len, \
int prot, int flags, int fd, int pos); }
-72 AUE_O_VADVISE   NOPROTO { int ovadvise(int anom); } vadvise \
-   ovadvise_args int
+72 AUE_O_VADVISE   COMPAT11|NOPROTO{ int vadvise(int anom); }
 73 AUE_MUNMAP  NOPROTO { int munmap(void *addr, size_t len); }
 74 AUE_MPROTECTSTD { int freebsd32_mprotect(void *addr, \
size_t len, int prot); }

Modified: head/sys/kern/syscalls.master
==
--- head/sys/kern/syscalls.master   Fri May 25 19:48:26 2018
(r334222)
+++ head/sys/kern/syscalls.master   Fri May 25 20:40:23 2018
(r334223)
@@ -229,8 +229,7 @@
 70 AUE_SSTKSTD { int

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

2018-05-25 Thread Rodney W. Grimes

> On Sat, May 26, 2018, 4:22 AM Rodney W. Grimes <
> free...@pdx.rh.cn85.dnsmgr.net> wrote:
> 
> > > On Sat, May 26, 2018, 4:09 AM Warner Losh  wrote:
> > >
> > > >
> > > >
> > > > On Fri, May 25, 2018 at 2:02 PM, Ed Maste  wrote:
> > > >
> > > >> On 25 May 2018 at 14:26, Marcelo Araujo 
> > wrote:
> > > >> >
> > > >> >> The fact that we don't do NDEBUG builds normally does not allow us
> > to
> > > >> >> ignore that it exists.  It's perfectly reasonable for a user to
> > build
> > > >> >> with CFLAGS+=NDEBUG.  That need to work.  If code is going to fail
> > to
> > > >> >> handle resource errors with NDEBUG set then it needs something like
> > > >> this
> > > >> >> at the top of the file:
> > > >> >
> > > >> > Please document it in some place!
> > > >>
> > > >> NDEBUG is documented in assert(3). The man page should have more of an
> > > >> explanation (and examples) of the possible pitfalls of assert()
> > > >> though
> > > >>
> > > >
> > > > NDEBUG has been documented in the assert man page since it entered Unix
> > > > via PBW in the 7th Edition Unix from Bell Labs. It's part of the C
> > > > standard, as well as many POSIX and SVID docs.
> > > >
> > >
> > > Yes I can read that! Now tell me, do we build FreeBSD without assert?
> > >
> > > If we do, probably we can't run it without crash!
> >
> > So that makes it perfectly fine to continue what is a well known bad
> > practice?  I do not think so.
> >
> > Many people have tried to persuade you that the *proper* way to check
> > the return from a function is with an if statement, not with an assert,
> > please try to accept that this is pretty much standard accepted portable
> > 'C' coding, and realize all those places you see assert(foo) checking
> > the return of a function are more than likely lurking bugs to be fixed.
> >
> 
> I never said that I didn't accepted that!

You flat out rejected it, more than once, and from more than one source.

> What I have been saying the issue
> is all around and we need to fix it.

You never said we need to fix any of the asserts until prehaps just now.

> Please don't twist my words!

I did not twist your words.

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

2018-05-25 Thread Marcelo Araujo

On Sat, May 26, 2018, 4:22 AM Rodney W. Grimes <
free...@pdx.rh.cn85.dnsmgr.net> wrote:

> > On Sat, May 26, 2018, 4:09 AM Warner Losh  wrote:
> >
> > >
> > >
> > > On Fri, May 25, 2018 at 2:02 PM, Ed Maste  wrote:
> > >
> > >> On 25 May 2018 at 14:26, Marcelo Araujo 
> wrote:
> > >> >
> > >> >> The fact that we don't do NDEBUG builds normally does not allow us
> to
> > >> >> ignore that it exists.  It's perfectly reasonable for a user to
> build
> > >> >> with CFLAGS+=NDEBUG.  That need to work.  If code is going to fail
> to
> > >> >> handle resource errors with NDEBUG set then it needs something like
> > >> this
> > >> >> at the top of the file:
> > >> >
> > >> > Please document it in some place!
> > >>
> > >> NDEBUG is documented in assert(3). The man page should have more of an
> > >> explanation (and examples) of the possible pitfalls of assert()
> > >> though
> > >>
> > >
> > > NDEBUG has been documented in the assert man page since it entered Unix
> > > via PBW in the 7th Edition Unix from Bell Labs. It's part of the C
> > > standard, as well as many POSIX and SVID docs.
> > >
> >
> > Yes I can read that! Now tell me, do we build FreeBSD without assert?
> >
> > If we do, probably we can't run it without crash!
>
> So that makes it perfectly fine to continue what is a well known bad
> practice?  I do not think so.
>
> Many people have tried to persuade you that the *proper* way to check
> the return from a function is with an if statement, not with an assert,
> please try to accept that this is pretty much standard accepted portable
> 'C' coding, and realize all those places you see assert(foo) checking
> the return of a function are more than likely lurking bugs to be fixed.
>

I never said that I didn't accepted that! What I have been saying the issue
is all around and we need to fix it. Please don't twist my words!

Best,

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

2018-05-25 Thread Rodney W. Grimes

> On Sat, May 26, 2018, 4:09 AM Warner Losh  wrote:
> 
> >
> >
> > On Fri, May 25, 2018 at 2:02 PM, Ed Maste  wrote:
> >
> >> On 25 May 2018 at 14:26, Marcelo Araujo  wrote:
> >> >
> >> >> The fact that we don't do NDEBUG builds normally does not allow us to
> >> >> ignore that it exists.  It's perfectly reasonable for a user to build
> >> >> with CFLAGS+=NDEBUG.  That need to work.  If code is going to fail to
> >> >> handle resource errors with NDEBUG set then it needs something like
> >> this
> >> >> at the top of the file:
> >> >
> >> > Please document it in some place!
> >>
> >> NDEBUG is documented in assert(3). The man page should have more of an
> >> explanation (and examples) of the possible pitfalls of assert()
> >> though
> >>
> >
> > NDEBUG has been documented in the assert man page since it entered Unix
> > via PBW in the 7th Edition Unix from Bell Labs. It's part of the C
> > standard, as well as many POSIX and SVID docs.
> >
> 
> Yes I can read that! Now tell me, do we build FreeBSD without assert?
> 
> If we do, probably we can't run it without crash!

So that makes it perfectly fine to continue what is a well known bad
practice?  I do not think so.  

Many people have tried to persuade you that the *proper* way to check
the return from a function is with an if statement, not with an assert,
please try to accept that this is pretty much standard accepted portable
'C' coding, and realize all those places you see assert(foo) checking
the return of a function are more than likely lurking bugs to be fixed.

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

2018-05-25 Thread Marcelo Araujo

On Sat, May 26, 2018, 4:09 AM Warner Losh  wrote:

>
>
> On Fri, May 25, 2018 at 2:02 PM, Ed Maste  wrote:
>
>> On 25 May 2018 at 14:26, Marcelo Araujo  wrote:
>> >
>> >> The fact that we don't do NDEBUG builds normally does not allow us to
>> >> ignore that it exists.  It's perfectly reasonable for a user to build
>> >> with CFLAGS+=NDEBUG.  That need to work.  If code is going to fail to
>> >> handle resource errors with NDEBUG set then it needs something like
>> this
>> >> at the top of the file:
>> >
>> > Please document it in some place!
>>
>> NDEBUG is documented in assert(3). The man page should have more of an
>> explanation (and examples) of the possible pitfalls of assert()
>> though
>>
>
> NDEBUG has been documented in the assert man page since it entered Unix
> via PBW in the 7th Edition Unix from Bell Labs. It's part of the C
> standard, as well as many POSIX and SVID docs.
>

Yes I can read that! Now tell me, do we build FreeBSD without assert?

If we do, probably we can't run it without crash!


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

2018-05-25 Thread Edward Tomasz Napierała

On 0526T0226, Marcelo Araujo wrote:
> 2018-05-26 2:21 GMT+08:00 Brooks Davis :

[..]

> > The correct code here would be one of:
> >
> > str = strdup(opt);
> > if (str == NULL)
> > goto out;
> >
> 
> No, it is not the correct code! If we go out and free(str) we have nothing
> to free, because we even didn't allocated memory for str.

FWIW, calling free(3) on a NULL pointer is perfectly fine.

___
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: r334128 - in head: . lib/libpmcstat lib/libpmcstat/pmu-events lib/libpmcstat/pmu-events/arch lib/libpmcstat/pmu-events/arch/arm64 lib/libpmcstat/pmu-events/arch/arm64/arm lib/libpmcsta

2018-05-25 Thread Bryan Drewery

On 5/23/2018 9:30 PM, Matt Macy wrote:
> Author: mmacy
> Date: Thu May 24 04:30:06 2018
> New Revision: 334128
> URL: https://svnweb.freebsd.org/changeset/base/334128
> 
> Log:
>   libpmcstat: compile in events based on json description
> 
> Added:
>   head/lib/libpmcstat/libpmcstat_pmu_util.c   (contents, props changed)
>   head/lib/libpmcstat/pmu-events/
>   head/lib/libpmcstat/pmu-events/Makefile   (contents, props changed)

...

> # cat lib/libpmcstat/pmu-events/Makefile
> # $FreeBSD$
> 
> PROG=jevents
> SRCS=jevents.c jsmn.c json.c
> CFLAGS+= -Wno-cast-qual
> .PATH: ${.CURDIR}
> build-tools: jevents
> MAN=
> .include 

Several things wrong here and in lib/libpmcstat/Makefile

1. Newlines? Existing style from other Makefiles? style.Makefile(5)
2. .PATH implicitly has .CURDIR in it already.
3. Need special META_MODE handling for the build-tools target. I don't
necessarily expect people to get this right but every other use of
build-tools in the tree has a pattern that isn't used here.
4. You used HOST_OBJTOP in lib/libpmcstat/Makefile to refer to jevents
for some reason when nothing else does. This is really just the
META_MODE pattern being wrong.

I'm fixing all of this.

-- 
Regards,
Bryan Drewery

signature.asc
Description: OpenPGP digital signature

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

2018-05-25 Thread Warner Losh

On Fri, May 25, 2018 at 2:02 PM, Ed Maste  wrote:

> On 25 May 2018 at 14:26, Marcelo Araujo  wrote:
> >
> >> The fact that we don't do NDEBUG builds normally does not allow us to
> >> ignore that it exists.  It's perfectly reasonable for a user to build
> >> with CFLAGS+=NDEBUG.  That need to work.  If code is going to fail to
> >> handle resource errors with NDEBUG set then it needs something like this
> >> at the top of the file:
> >
> > Please document it in some place!
>
> NDEBUG is documented in assert(3). The man page should have more of an
> explanation (and examples) of the possible pitfalls of assert()
> though
>

NDEBUG has been documented in the assert man page since it entered Unix via
PBW in the 7th Edition Unix from Bell Labs. It's part of the C standard, as
well as many POSIX and SVID docs.

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

2018-05-25 Thread Ed Maste

On 25 May 2018 at 14:26, Marcelo Araujo  wrote:
>
>> The fact that we don't do NDEBUG builds normally does not allow us to
>> ignore that it exists.  It's perfectly reasonable for a user to build
>> with CFLAGS+=NDEBUG.  That need to work.  If code is going to fail to
>> handle resource errors with NDEBUG set then it needs something like this
>> at the top of the file:
>
> Please document it in some place!

NDEBUG is documented in assert(3). The man page should have more of an
explanation (and examples) of the possible pitfalls of assert()
though.
___
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: r334199 - head/usr.sbin/bhyve

2018-05-25 Thread Ed Maste

On 25 May 2018 at 14:29, Marcelo Araujo  wrote:
>
> One more thing, exit with err(1) is wrong, 1 is EPERM and should be 12
> ENOMEN! :D

No, please see the err(3) manpage - err's first argument is the exit
code for the program, not an errno.

(err suggests using exit codes from sysexits(3), but there is much
disagreement about that. Either way it's not an errno.)
___
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: r334222 - head/sys/net

2018-05-25 Thread Matt Macy

Author: mmacy
Date: Fri May 25 19:48:26 2018
New Revision: 334222
URL: https://svnweb.freebsd.org/changeset/base/334222

Log:
  rtrequest1_fib: we need to always bump the ifaddr refcount when we take a 
reference from
  an rtentry. r334118 introduced a case when this was not done.
  
  While we're here make the intent more obvious by moving the refcount
  bump down to when we know we'll actually need it.
  
  Reported by:  markj

Modified:
  head/sys/net/route.c

Modified: head/sys/net/route.c
==
--- head/sys/net/route.cFri May 25 19:36:26 2018(r334221)
+++ head/sys/net/route.cFri May 25 19:48:26 2018(r334222)
@@ -1586,12 +1586,9 @@ rtrequest1_fib(int req, struct rt_addrinfo *info, stru
error = rt_getifa_fib(info, fibnum);
if (error)
return (error);
-   } else
-   ifa_ref(info->rti_ifa);
-   ifa = info->rti_ifa;
+   }
rt = uma_zalloc(V_rtzone, M_NOWAIT);
if (rt == NULL) {
-   ifa_free(ifa);
return (ENOBUFS);
}
rt->rt_flags = RTF_UP | flags;
@@ -1600,7 +1597,6 @@ rtrequest1_fib(int req, struct rt_addrinfo *info, stru
 * Add the gateway. Possibly re-malloc-ing the storage for it.
 */
if ((error = rt_setgate(rt, dst, gateway)) != 0) {
-   ifa_free(ifa);
uma_zfree(V_rtzone, rt);
return (error);
}
@@ -1623,6 +1619,8 @@ rtrequest1_fib(int req, struct rt_addrinfo *info, stru
 * This moved from below so that rnh->rnh_addaddr() can
 * examine the ifa and  ifa->ifa_ifp if it so desires.
 */
+   ifa = info->rti_ifa;
+   ifa_ref(ifa);
rt->rt_ifa = ifa;
rt->rt_ifp = ifa->ifa_ifp;
rt->rt_weight = 1;
___
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: r334216 - head/usr.sbin/bhyve

2018-05-25 Thread Ed Maste

On 25 May 2018 at 14:54, Marcelo Araujo  wrote:
> Author: araujo
> Date: Fri May 25 18:54:40 2018
> New Revision: 334216
> URL: https://svnweb.freebsd.org/changeset/base/334216
>
> Log:
>   After a long discussion about assert(3), we gonna use a HardenedBSD
>   approach to chek strdup(3) memory allocation.

I'm not sure what you mean by "a HardenedBSD approach" here --
checking return values is just proper practice.
___
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: r334221 - head/etc

2018-05-25 Thread Mark Felder

Author: feld (ports committer)
Date: Fri May 25 19:36:26 2018
New Revision: 334221
URL: https://svnweb.freebsd.org/changeset/base/334221

Log:
  rc.subr: Support loading environmental variables from a file
  
  The current support for setting environment via foo_env="" in rc.conf is
  not scalable and does not handle envs with spaces in the value. It seems
  a common pattern for some newer software is to skip configuration files
  altogether and rely on the env. This is well supported in systemd unit
  files and may be the inspiration for this trend.
  
  MFH:  1 week
  Differential Revision:https://reviews.freebsd.org/D14453

Modified:
  head/etc/rc.subr

Modified: head/etc/rc.subr
==
--- head/etc/rc.subrFri May 25 19:16:05 2018(r334220)
+++ head/etc/rc.subrFri May 25 19:36:26 2018(r334221)
@@ -754,6 +754,8 @@ check_startmsgs()
 #
 #  ${name}_env n   Environment variables to run ${command} with.
 #
+#  ${name}_env_file n  File to source variables to run ${command} with.
+#
 #  ${name}_fib n   Routing table number to run ${command} with.
 #
 #  ${name}_nicen   Nice level to run ${command} at.
@@ -954,7 +956,14 @@ run_rc_command()
_group=\$${name}_group  _groups=\$${name}_groups \
_fib=\$${name}_fib  _env=\$${name}_env \
_prepend=\$${name}_prepend  
_login_class=\${${name}_login_class:-daemon} \
-   _limits=\$${name}_limits_oomprotect=\$${name}_oomprotect
+   _limits=\$${name}_limits_oomprotect=\$${name}_oomprotect \
+   _env_file=\$${name}_env_file
+
+   if [ -n "$_env_file" ] && [ -r "${_env_file}" ]; then   # load env from 
file
+   set -a
+   . $_env_file
+   set +a
+   fi
 
if [ -n "$_user" ]; then# unset $_user if running as that user
if [ "$_user" = "$(eval $IDCMD)" ]; then
___
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: r334216 - head/usr.sbin/bhyve

2018-05-25 Thread Shawn Webb

On Fri, May 25, 2018 at 10:08:46PM +0300, Konstantin Belousov wrote:
> On Fri, May 25, 2018 at 06:54:40PM +, Marcelo Araujo wrote:
> > Author: araujo
> > Date: Fri May 25 18:54:40 2018
> > New Revision: 334216
> > URL: https://svnweb.freebsd.org/changeset/base/334216
> > 
> > Log:
> >   After a long discussion about assert(3), we gonna use a HardenedBSD
> >   approach to chek strdup(3) memory allocation.
> >   
> >   Submitted by: Shaw Webb 
> >   Reported by:  brooks
> >   Obtained from:HardenedBSD
> > 
> > Modified:
> >   head/usr.sbin/bhyve/bhyverun.c
> > 
> > Modified: head/usr.sbin/bhyve/bhyverun.c
> > ==
> > --- head/usr.sbin/bhyve/bhyverun.c  Fri May 25 18:11:13 2018
> > (r334215)
> > +++ head/usr.sbin/bhyve/bhyverun.c  Fri May 25 18:54:40 2018
> > (r334216)
> > @@ -193,7 +193,8 @@ topology_parse(const char *opt)
> > c = 1, n = 1, s = 1, t = 1;
> > ns = false, scts = false;
> > str = strdup(opt);
> > -   assert(str != NULL);
> > +   if (str == NULL)
> > +   goto out;
> >  
> > while ((cp = strsep(, ",")) != NULL) {
> > if (sscanf(cp, "%i%n", , ) == 1) {
> > @@ -225,6 +226,7 @@ topology_parse(const char *opt)
> > goto out;
> > }
> > free(str);
> > +   str = NULL;
> >  
> > /*
> >  * Range check 1 <= n <= UINT16_MAX all values
> > @@ -253,7 +255,8 @@ topology_parse(const char *opt)
> > return(0);
> >  
> >  out:
> > -   free(str);
> > +   if (str != NULL)
> This check is useless.  Free(3) is fine handling NULL argument.

Good catch. Thanks!

-- 
Shawn Webb
Cofounder and Security Engineer
HardenedBSD

Tor-ified Signal:+1 443-546-8752
Tor+XMPP+OTR:latt...@is.a.hacker.sx
GPG Key ID:  0x6A84658F52456EEE
GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89  3D9E 6A84 658F 5245 6EEE


signature.asc
Description: PGP signature

svn commit: r334219 - head/usr.sbin/bhyve

2018-05-25 Thread Marcelo Araujo

Author: araujo
Date: Fri May 25 19:12:30 2018
New Revision: 334219
URL: https://svnweb.freebsd.org/changeset/base/334219

Log:
  We don't need check if str is NULL as free(3) will handle NULL
  argument.
  
  Reported by:  kib@

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

Modified: head/usr.sbin/bhyve/bhyverun.c
==
--- head/usr.sbin/bhyve/bhyverun.c  Fri May 25 19:00:28 2018
(r334218)
+++ head/usr.sbin/bhyve/bhyverun.c  Fri May 25 19:12:30 2018
(r334219)
@@ -255,8 +255,7 @@ topology_parse(const char *opt)
return(0);
 
 out:
-   if (str != NULL)
-   free(str);
+   free(str);
return (-1);
 }
 
___
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: r334216 - head/usr.sbin/bhyve

2018-05-25 Thread Marcelo Araujo

Fixed at r334219.

Thanks.

2018-05-26 3:08 GMT+08:00 Konstantin Belousov :

> On Fri, May 25, 2018 at 06:54:40PM +, Marcelo Araujo wrote:
> > Author: araujo
> > Date: Fri May 25 18:54:40 2018
> > New Revision: 334216
> > URL: https://svnweb.freebsd.org/changeset/base/334216
> >
> > Log:
> >   After a long discussion about assert(3), we gonna use a HardenedBSD
> >   approach to chek strdup(3) memory allocation.
> >
> >   Submitted by:   Shaw Webb 
> >   Reported by:brooks
> >   Obtained from:  HardenedBSD
> >
> > Modified:
> >   head/usr.sbin/bhyve/bhyverun.c
> >
> > Modified: head/usr.sbin/bhyve/bhyverun.c
> > 
> ==
> > --- head/usr.sbin/bhyve/bhyverun.cFri May 25 18:11:13 2018
> (r334215)
> > +++ head/usr.sbin/bhyve/bhyverun.cFri May 25 18:54:40 2018
> (r334216)
> > @@ -193,7 +193,8 @@ topology_parse(const char *opt)
> >   c = 1, n = 1, s = 1, t = 1;
> >   ns = false, scts = false;
> >   str = strdup(opt);
> > - assert(str != NULL);
> > + if (str == NULL)
> > + goto out;
> >
> >   while ((cp = strsep(, ",")) != NULL) {
> >   if (sscanf(cp, "%i%n", , ) == 1) {
> > @@ -225,6 +226,7 @@ topology_parse(const char *opt)
> >   goto out;
> >   }
> >   free(str);
> > + str = NULL;
> >
> >   /*
> >* Range check 1 <= n <= UINT16_MAX all values
> > @@ -253,7 +255,8 @@ topology_parse(const char *opt)
> >   return(0);
> >
> >  out:
> > - free(str);
> > + if (str != NULL)
> This check is useless.  Free(3) is fine handling NULL argument.
>
> > + free(str);
> >   return (-1);
> >  }
> >
>



-- 

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

2018-05-25 Thread Konstantin Belousov

On Fri, May 25, 2018 at 06:54:40PM +, Marcelo Araujo wrote:
> Author: araujo
> Date: Fri May 25 18:54:40 2018
> New Revision: 334216
> URL: https://svnweb.freebsd.org/changeset/base/334216
> 
> Log:
>   After a long discussion about assert(3), we gonna use a HardenedBSD
>   approach to chek strdup(3) memory allocation.
>   
>   Submitted by:   Shaw Webb 
>   Reported by:brooks
>   Obtained from:  HardenedBSD
> 
> Modified:
>   head/usr.sbin/bhyve/bhyverun.c
> 
> Modified: head/usr.sbin/bhyve/bhyverun.c
> ==
> --- head/usr.sbin/bhyve/bhyverun.cFri May 25 18:11:13 2018
> (r334215)
> +++ head/usr.sbin/bhyve/bhyverun.cFri May 25 18:54:40 2018
> (r334216)
> @@ -193,7 +193,8 @@ topology_parse(const char *opt)
>   c = 1, n = 1, s = 1, t = 1;
>   ns = false, scts = false;
>   str = strdup(opt);
> - assert(str != NULL);
> + if (str == NULL)
> + goto out;
>  
>   while ((cp = strsep(, ",")) != NULL) {
>   if (sscanf(cp, "%i%n", , ) == 1) {
> @@ -225,6 +226,7 @@ topology_parse(const char *opt)
>   goto out;
>   }
>   free(str);
> + str = NULL;
>  
>   /*
>* Range check 1 <= n <= UINT16_MAX all values
> @@ -253,7 +255,8 @@ topology_parse(const char *opt)
>   return(0);
>  
>  out:
> - free(str);
> + if (str != NULL)
This check is useless.  Free(3) is fine handling NULL argument.

> + free(str);
>   return (-1);
>  }
>  
___
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: r334199 - head/usr.sbin/bhyve

2018-05-25 Thread Marcelo Araujo

2018-05-26 3:01 GMT+08:00 Shawn Webb :

> On Sat, May 26, 2018 at 02:57:29AM +0800, Marcelo Araujo wrote:
> > Thanks Shawn,
> >
> > I think there are plenty of places to fix this case! Thanks for the extra
> > work :D.
>
> Any time. I'm glad to help. If you'd like, I might have time on Sunday
> to audit bhyve's code to find and fix more of these cases.
>

Doesn't hurt and I think it is very welcome!

Best,


>
> Thanks,
>
> --
> Shawn Webb
> Cofounder and Security Engineer
> HardenedBSD
>
> Tor-ified Signal:+1 443-546-8752
> Tor+XMPP+OTR:latt...@is.a.hacker.sx
> GPG Key ID:  0x6A84658F52456EEE
> GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89  3D9E 6A84 658F 5245 6EEE
>



-- 

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

2018-05-25 Thread Shawn Webb

On Sat, May 26, 2018 at 02:57:29AM +0800, Marcelo Araujo wrote:
> Thanks Shawn,
> 
> I think there are plenty of places to fix this case! Thanks for the extra
> work :D.

Any time. I'm glad to help. If you'd like, I might have time on Sunday
to audit bhyve's code to find and fix more of these cases.

Thanks,

-- 
Shawn Webb
Cofounder and Security Engineer
HardenedBSD

Tor-ified Signal:+1 443-546-8752
Tor+XMPP+OTR:latt...@is.a.hacker.sx
GPG Key ID:  0x6A84658F52456EEE
GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89  3D9E 6A84 658F 5245 6EEE


signature.asc
Description: PGP signature

svn commit: r334218 - head/sys/dev/mmc/host

2018-05-25 Thread Ilya Bakulin

Author: kibab
Date: Fri May 25 19:00:28 2018
New Revision: 334218
URL: https://svnweb.freebsd.org/changeset/base/334218

Log:
  Fix building GENERIC-MMCCAM on arm64
  
  Since GENERIC includes quite a few drivers now, all MMC drivers should have
  appropriate MMCCAM-related ifdefs and include opt_mmccam.h so that
  those ifdefs are actually processed correctly.
  
  Reviewed by:  manu
  Approved by:  imp (mentor)
  Differential Revision:https://reviews.freebsd.org/D15569

Modified:
  head/sys/dev/mmc/host/dwmmc_rockchip.c

Modified: head/sys/dev/mmc/host/dwmmc_rockchip.c
==
--- head/sys/dev/mmc/host/dwmmc_rockchip.c  Fri May 25 18:57:41 2018
(r334217)
+++ head/sys/dev/mmc/host/dwmmc_rockchip.c  Fri May 25 19:00:28 2018
(r334218)
@@ -45,6 +45,8 @@ __FBSDID("$FreeBSD$");
 
 #include 
 
+#include "opt_mmccam.h"
+
 enum RKTYPE {
RK2928 = 1,
RK3328,
___
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: r334199 - head/usr.sbin/bhyve

2018-05-25 Thread Marcelo Araujo

Thanks Shawn,

I think there are plenty of places to fix this case! Thanks for the extra
work :D.

2018-05-26 2:34 GMT+08:00 Shawn Webb :

> On Sat, May 26, 2018 at 02:26:33AM +0800, Marcelo Araujo wrote:
> > 2018-05-26 2:21 GMT+08:00 Brooks Davis :
> >
> > > On Sat, May 26, 2018 at 01:56:28AM +0800, Marcelo Araujo wrote:
> > > > 2018-05-26 1:44 GMT+08:00 Brooks Davis :
> > > >
> > > > > On Sat, May 26, 2018 at 01:21:33AM +0800, Marcelo Araujo wrote:
> > > > > > On Sat, May 26, 2018, 1:11 AM Eitan Adler 
> > > wrote:
> > > > > >
> > > > > > > On 25 May 2018 at 08:23, Marcelo Araujo <
> araujobsdp...@gmail.com>
> > > > > wrote:
> > > > > > > >
> > > > > > > >
> > > > > > > > On Fri, May 25, 2018, 11:11 PM Brooks Davis <
> bro...@freebsd.org>
> > > > > wrote:
> > > > > > > >>
> > > > > > > >> On Fri, May 25, 2018 at 02:07:05AM +, Marcelo Araujo
> wrote:
> > > > > > > >> > Author: araujo
> > > > > > > >> > Date: Fri May 25 02:07:05 2018
> > > > > > > >> > New Revision: 334199
> > > > > > > >> > URL: https://svnweb.freebsd.org/changeset/base/334199
> > > > > > > >> >
> > > > > > > >> > Log:
> > > > > > > >> >   Fix a memory leak on topology_parse().
> > > > > > > >> >
> > > > > > > >> >   strdup(3) allocates memory for a copy of the string,
> does
> > > the
> > > > > copy
> > > > > > > and
> > > > > > > >> >   returns a pointer to it. If there is no sufficient
> memory
> > > NULL
> > > > > is
> > > > > > > >> > returned
> > > > > > > >> >   and the global errno is set to ENOMEM.
> > > > > > > >> >   We do a sanity check to see if it was possible to
> allocate
> > > > > enough
> > > > > > > >> > memory.
> > > > > > > >> >
> > > > > > > >> >   Also as we allocate memory, we need to free this memory
> > > used.
> > > > > Or it
> > > > > > > >> > will
> > > > > > > >> >   going out of scope leaks the storage it points to.
> > > > > > > >> >
> > > > > > > >> >   Reviewed by:rgrimes
> > > > > > > >> >   MFC after:  3 weeks.
> > > > > > > >> >   X-MFC:  r332298
> > > > > > > >> >   Sponsored by:   iXsystems Inc.
> > > > > > > >> >   Differential Revision:
> https://reviews.freebsd.org/
> > > D15550
> > > > > > > >> >
> > > > > > > >> > Modified:
> > > > > > > >> >   head/usr.sbin/bhyve/bhyverun.c
> > > > > > > >> >
> > > > > > > >> > Modified: head/usr.sbin/bhyve/bhyverun.c
> > > > > > > >> >
> > > > > > > >> >
> > > > > > > 
> > > > > ==
> > > > > > > >> > --- head/usr.sbin/bhyve/bhyverun.cFri May 25 01:38:59
> 2018
> > > > > > > >> > (r334198)
> > > > > > > >> > +++ head/usr.sbin/bhyve/bhyverun.cFri May 25 02:07:05
> 2018
> > > > > > > >> > (r334199)
> > > > > > > >> > @@ -193,6 +193,7 @@ topology_parse(const char *opt)
> > > > > > > >> >   c = 1, n = 1, s = 1, t = 1;
> > > > > > > >> >   ns = false, scts = false;
> > > > > > > >> >   str = strdup(opt);
> > > > > > > >> > + assert(str != NULL);
> > > > > > > >>
> > > > > > > >> Using assert seems like an odd choice when you've already
> added
> > > a
> > > > > > > >> failure path and the strsep will crash immediately if
> assert is
> > > > > elided.
> > > > > > > >
> > > > > > > >
> > > > > > > > Just to make a better point, I had the same discussion about
> > > > > assert(3) in
> > > > > > > > another review, we don't do NDEBUG even for RELEASE.
> > > > > > >
> > > > > > > IMHO we only use assert for asserting things ought to never be
> > > false
> > > > > > > except in buggy code. Using assert for handling is poor
> practice.
> > > > > > >
> > > > > >
> > > > > > Again, in this case we are using it all over the place and we
> must
> > > > > replace
> > > > > > it. Also we should document it in somewhere perhaps in the
> assert(3)
> > > > > > otherwise myself and others will keep using it. If you use find,
> not
> > > only
> > > > > > myself is using it to check strdup! So what is the suggestion to
> > > handle
> > > > > > assert(3)? Deprecated it?
> > > > >
> > > > > Code that uses assert() in place of error handling is wrong and
> should
> > > > > be fixed. assert(condition) means that condition must never happen
> > > > > and if it does a bug has occurred (or the programmers assumptions
> are
> > > > > wrong).  In this case failure would not be due to a bug, but do to
> > > > > resource exhaustion which is expected to be handled.
> > > > >
> > > >
> > > > I agree with you! We have plenty of place that use strdup(3) without
> > > check
> > > > the errno ENOMEN return; so do you think would be better bypass a
> errno
> > > > ENOMEN without check it and have a crash, or better abort(3) using
> > > > assert(3) in case we have no memory available to allocated the memory
> > > for a
> > > > copy of a string?
> > >
> > > The correct code here would be one of:
> > >
> > > str = strdup(opt);
> > > if (str == NULL)
> > > goto out;
> > >
> >
> > No,

svn commit: r334217 - head/sys/dev/cxgbe

2018-05-25 Thread Navdeep Parhar

Author: np
Date: Fri May 25 18:57:41 2018
New Revision: 334217
URL: https://svnweb.freebsd.org/changeset/base/334217

Log:
  cxgbe(4): Suppress a warning about code that is used only with options
  RATELIMIT.
  
  Reported by:  mmacy@

Modified:
  head/sys/dev/cxgbe/t4_sge.c

Modified: head/sys/dev/cxgbe/t4_sge.c
==
--- head/sys/dev/cxgbe/t4_sge.c Fri May 25 18:54:40 2018(r334216)
+++ head/sys/dev/cxgbe/t4_sge.c Fri May 25 18:57:41 2018(r334217)
@@ -2202,6 +2202,7 @@ needs_tcp_csum(struct mbuf *m)
return (m->m_pkthdr.csum_flags & (CSUM_TCP | CSUM_TCP_IPV6 | CSUM_TSO));
 }
 
+#ifdef RATELIMIT
 static inline int
 needs_udp_csum(struct mbuf *m)
 {
@@ -2209,6 +2210,7 @@ needs_udp_csum(struct mbuf *m)
M_ASSERTPKTHDR(m);
return (m->m_pkthdr.csum_flags & (CSUM_UDP | CSUM_UDP_IPV6));
 }
+#endif
 
 static inline int
 needs_vlan_insertion(struct mbuf *m)
___
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: r334216 - head/usr.sbin/bhyve

2018-05-25 Thread Marcelo Araujo

Author: araujo
Date: Fri May 25 18:54:40 2018
New Revision: 334216
URL: https://svnweb.freebsd.org/changeset/base/334216

Log:
  After a long discussion about assert(3), we gonna use a HardenedBSD
  approach to chek strdup(3) memory allocation.
  
  Submitted by: Shaw Webb 
  Reported by:  brooks
  Obtained from:HardenedBSD

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

Modified: head/usr.sbin/bhyve/bhyverun.c
==
--- head/usr.sbin/bhyve/bhyverun.c  Fri May 25 18:11:13 2018
(r334215)
+++ head/usr.sbin/bhyve/bhyverun.c  Fri May 25 18:54:40 2018
(r334216)
@@ -193,7 +193,8 @@ topology_parse(const char *opt)
c = 1, n = 1, s = 1, t = 1;
ns = false, scts = false;
str = strdup(opt);
-   assert(str != NULL);
+   if (str == NULL)
+   goto out;
 
while ((cp = strsep(, ",")) != NULL) {
if (sscanf(cp, "%i%n", , ) == 1) {
@@ -225,6 +226,7 @@ topology_parse(const char *opt)
goto out;
}
free(str);
+   str = NULL;
 
/*
 * Range check 1 <= n <= UINT16_MAX all values
@@ -253,7 +255,8 @@ topology_parse(const char *opt)
return(0);
 
 out:
-   free(str);
+   if (str != NULL)
+   free(str);
return (-1);
 }
 
___
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: r334199 - head/usr.sbin/bhyve

2018-05-25 Thread Rodney W. Grimes

-- Start of PGP signed section.
> On Sat, May 26, 2018 at 02:26:33AM +0800, Marcelo Araujo wrote:
> > 2018-05-26 2:21 GMT+08:00 Brooks Davis :
> > 
> > > On Sat, May 26, 2018 at 01:56:28AM +0800, Marcelo Araujo wrote:
> > > > 2018-05-26 1:44 GMT+08:00 Brooks Davis :
> > > >
> > > > > On Sat, May 26, 2018 at 01:21:33AM +0800, Marcelo Araujo wrote:
> > > > > > On Sat, May 26, 2018, 1:11 AM Eitan Adler 
> > > wrote:
> > > > > >
> > > > > > > On 25 May 2018 at 08:23, Marcelo Araujo 
> > > > > wrote:
> > > > > > > >
> > > > > > > >
> > > > > > > > On Fri, May 25, 2018, 11:11 PM Brooks Davis 
> > > > > wrote:
> > > > > > > >>
> > > > > > > >> On Fri, May 25, 2018 at 02:07:05AM +, Marcelo Araujo wrote:
> > > > > > > >> > Author: araujo
> > > > > > > >> > Date: Fri May 25 02:07:05 2018
> > > > > > > >> > New Revision: 334199
> > > > > > > >> > URL: https://svnweb.freebsd.org/changeset/base/334199
> > > > > > > >> >
> > > > > > > >> > Log:
> > > > > > > >> >   Fix a memory leak on topology_parse().
> > > > > > > >> >
> > > > > > > >> >   strdup(3) allocates memory for a copy of the string, does
> > > the
> > > > > copy
> > > > > > > and
> > > > > > > >> >   returns a pointer to it. If there is no sufficient memory
> > > NULL
> > > > > is
> > > > > > > >> > returned
> > > > > > > >> >   and the global errno is set to ENOMEM.
> > > > > > > >> >   We do a sanity check to see if it was possible to allocate
> > > > > enough
> > > > > > > >> > memory.
> > > > > > > >> >
> > > > > > > >> >   Also as we allocate memory, we need to free this memory
> > > used.
> > > > > Or it
> > > > > > > >> > will
> > > > > > > >> >   going out of scope leaks the storage it points to.
> > > > > > > >> >
> > > > > > > >> >   Reviewed by:rgrimes
> > > > > > > >> >   MFC after:  3 weeks.
> > > > > > > >> >   X-MFC:  r332298
> > > > > > > >> >   Sponsored by:   iXsystems Inc.
> > > > > > > >> >   Differential Revision:  https://reviews.freebsd.org/
> > > D15550
> > > > > > > >> >
> > > > > > > >> > Modified:
> > > > > > > >> >   head/usr.sbin/bhyve/bhyverun.c
> > > > > > > >> >
> > > > > > > >> > Modified: head/usr.sbin/bhyve/bhyverun.c
> > > > > > > >> >
> > > > > > > >> >
> > > > > > > 
> > > > > ==
> > > > > > > >> > --- head/usr.sbin/bhyve/bhyverun.cFri May 25 01:38:59 
> > > > > > > >> > 2018
> > > > > > > >> > (r334198)
> > > > > > > >> > +++ head/usr.sbin/bhyve/bhyverun.cFri May 25 02:07:05 
> > > > > > > >> > 2018
> > > > > > > >> > (r334199)
> > > > > > > >> > @@ -193,6 +193,7 @@ topology_parse(const char *opt)
> > > > > > > >> >   c = 1, n = 1, s = 1, t = 1;
> > > > > > > >> >   ns = false, scts = false;
> > > > > > > >> >   str = strdup(opt);
> > > > > > > >> > + assert(str != NULL);
> > > > > > > >>
> > > > > > > >> Using assert seems like an odd choice when you've already added
> > > a
> > > > > > > >> failure path and the strsep will crash immediately if assert is
> > > > > elided.
> > > > > > > >
> > > > > > > >
> > > > > > > > Just to make a better point, I had the same discussion about
> > > > > assert(3) in
> > > > > > > > another review, we don't do NDEBUG even for RELEASE.
> > > > > > >
> > > > > > > IMHO we only use assert for asserting things ought to never be
> > > false
> > > > > > > except in buggy code. Using assert for handling is poor practice.
> > > > > > >
> > > > > >
> > > > > > Again, in this case we are using it all over the place and we must
> > > > > replace
> > > > > > it. Also we should document it in somewhere perhaps in the assert(3)
> > > > > > otherwise myself and others will keep using it. If you use find, not
> > > only
> > > > > > myself is using it to check strdup! So what is the suggestion to
> > > handle
> > > > > > assert(3)? Deprecated it?
> > > > >
> > > > > Code that uses assert() in place of error handling is wrong and should
> > > > > be fixed. assert(condition) means that condition must never happen
> > > > > and if it does a bug has occurred (or the programmers assumptions are
> > > > > wrong).  In this case failure would not be due to a bug, but do to
> > > > > resource exhaustion which is expected to be handled.
> > > > >
> > > >
> > > > I agree with you! We have plenty of place that use strdup(3) without
> > > check
> > > > the errno ENOMEN return; so do you think would be better bypass a errno
> > > > ENOMEN without check it and have a crash, or better abort(3) using
> > > > assert(3) in case we have no memory available to allocated the memory
> > > for a
> > > > copy of a string?
> > >
> > > The correct code here would be one of:
> > >
> > > str = strdup(opt);
> > > if (str == NULL)
> > > goto out;
> > >
> > 
> > No, it is not the correct code! If we go out and free(str) we have nothing
> > to free, because we even didn't allocated memory

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

2018-05-25 Thread Shawn Webb

On Sat, May 26, 2018 at 02:26:33AM +0800, Marcelo Araujo wrote:
> 2018-05-26 2:21 GMT+08:00 Brooks Davis :
> 
> > On Sat, May 26, 2018 at 01:56:28AM +0800, Marcelo Araujo wrote:
> > > 2018-05-26 1:44 GMT+08:00 Brooks Davis :
> > >
> > > > On Sat, May 26, 2018 at 01:21:33AM +0800, Marcelo Araujo wrote:
> > > > > On Sat, May 26, 2018, 1:11 AM Eitan Adler 
> > wrote:
> > > > >
> > > > > > On 25 May 2018 at 08:23, Marcelo Araujo 
> > > > wrote:
> > > > > > >
> > > > > > >
> > > > > > > On Fri, May 25, 2018, 11:11 PM Brooks Davis 
> > > > wrote:
> > > > > > >>
> > > > > > >> On Fri, May 25, 2018 at 02:07:05AM +, Marcelo Araujo wrote:
> > > > > > >> > Author: araujo
> > > > > > >> > Date: Fri May 25 02:07:05 2018
> > > > > > >> > New Revision: 334199
> > > > > > >> > URL: https://svnweb.freebsd.org/changeset/base/334199
> > > > > > >> >
> > > > > > >> > Log:
> > > > > > >> >   Fix a memory leak on topology_parse().
> > > > > > >> >
> > > > > > >> >   strdup(3) allocates memory for a copy of the string, does
> > the
> > > > copy
> > > > > > and
> > > > > > >> >   returns a pointer to it. If there is no sufficient memory
> > NULL
> > > > is
> > > > > > >> > returned
> > > > > > >> >   and the global errno is set to ENOMEM.
> > > > > > >> >   We do a sanity check to see if it was possible to allocate
> > > > enough
> > > > > > >> > memory.
> > > > > > >> >
> > > > > > >> >   Also as we allocate memory, we need to free this memory
> > used.
> > > > Or it
> > > > > > >> > will
> > > > > > >> >   going out of scope leaks the storage it points to.
> > > > > > >> >
> > > > > > >> >   Reviewed by:rgrimes
> > > > > > >> >   MFC after:  3 weeks.
> > > > > > >> >   X-MFC:  r332298
> > > > > > >> >   Sponsored by:   iXsystems Inc.
> > > > > > >> >   Differential Revision:  https://reviews.freebsd.org/
> > D15550
> > > > > > >> >
> > > > > > >> > Modified:
> > > > > > >> >   head/usr.sbin/bhyve/bhyverun.c
> > > > > > >> >
> > > > > > >> > Modified: head/usr.sbin/bhyve/bhyverun.c
> > > > > > >> >
> > > > > > >> >
> > > > > > 
> > > > ==
> > > > > > >> > --- head/usr.sbin/bhyve/bhyverun.cFri May 25 01:38:59 2018
> > > > > > >> > (r334198)
> > > > > > >> > +++ head/usr.sbin/bhyve/bhyverun.cFri May 25 02:07:05 2018
> > > > > > >> > (r334199)
> > > > > > >> > @@ -193,6 +193,7 @@ topology_parse(const char *opt)
> > > > > > >> >   c = 1, n = 1, s = 1, t = 1;
> > > > > > >> >   ns = false, scts = false;
> > > > > > >> >   str = strdup(opt);
> > > > > > >> > + assert(str != NULL);
> > > > > > >>
> > > > > > >> Using assert seems like an odd choice when you've already added
> > a
> > > > > > >> failure path and the strsep will crash immediately if assert is
> > > > elided.
> > > > > > >
> > > > > > >
> > > > > > > Just to make a better point, I had the same discussion about
> > > > assert(3) in
> > > > > > > another review, we don't do NDEBUG even for RELEASE.
> > > > > >
> > > > > > IMHO we only use assert for asserting things ought to never be
> > false
> > > > > > except in buggy code. Using assert for handling is poor practice.
> > > > > >
> > > > >
> > > > > Again, in this case we are using it all over the place and we must
> > > > replace
> > > > > it. Also we should document it in somewhere perhaps in the assert(3)
> > > > > otherwise myself and others will keep using it. If you use find, not
> > only
> > > > > myself is using it to check strdup! So what is the suggestion to
> > handle
> > > > > assert(3)? Deprecated it?
> > > >
> > > > Code that uses assert() in place of error handling is wrong and should
> > > > be fixed. assert(condition) means that condition must never happen
> > > > and if it does a bug has occurred (or the programmers assumptions are
> > > > wrong).  In this case failure would not be due to a bug, but do to
> > > > resource exhaustion which is expected to be handled.
> > > >
> > >
> > > I agree with you! We have plenty of place that use strdup(3) without
> > check
> > > the errno ENOMEN return; so do you think would be better bypass a errno
> > > ENOMEN without check it and have a crash, or better abort(3) using
> > > assert(3) in case we have no memory available to allocated the memory
> > for a
> > > copy of a string?
> >
> > The correct code here would be one of:
> >
> > str = strdup(opt);
> > if (str == NULL)
> > goto out;
> >
> 
> No, it is not the correct code! If we go out and free(str) we have nothing
> to free, because we even didn't allocated memory for str.

Hey Marcelo,

I've authored this commit, which fixes the issues Brooks brought up
(and with which I agree):

https://github.com/HardenedBSD/hardenedBSD/commit/9c05b8def2c33e3889430cc2f54be0402a257366

Thanks,

-- 
Shawn Webb
Cofounder and Security Engineer
HardenedBSD

Tor-ified Signal:+1

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

2018-05-25 Thread Marcelo Araujo

2018-05-26 2:21 GMT+08:00 Brooks Davis :

> On Sat, May 26, 2018 at 01:56:28AM +0800, Marcelo Araujo wrote:
> > 2018-05-26 1:44 GMT+08:00 Brooks Davis :
> >
> > > On Sat, May 26, 2018 at 01:21:33AM +0800, Marcelo Araujo wrote:
> > > > On Sat, May 26, 2018, 1:11 AM Eitan Adler 
> wrote:
> > > >
> > > > > On 25 May 2018 at 08:23, Marcelo Araujo 
> > > wrote:
> > > > > >
> > > > > >
> > > > > > On Fri, May 25, 2018, 11:11 PM Brooks Davis 
> > > wrote:
> > > > > >>
> > > > > >> On Fri, May 25, 2018 at 02:07:05AM +, Marcelo Araujo wrote:
> > > > > >> > Author: araujo
> > > > > >> > Date: Fri May 25 02:07:05 2018
> > > > > >> > New Revision: 334199
> > > > > >> > URL: https://svnweb.freebsd.org/changeset/base/334199
> > > > > >> >
> > > > > >> > Log:
> > > > > >> >   Fix a memory leak on topology_parse().
> > > > > >> >
> > > > > >> >   strdup(3) allocates memory for a copy of the string, does
> the
> > > copy
> > > > > and
> > > > > >> >   returns a pointer to it. If there is no sufficient memory
> NULL
> > > is
> > > > > >> > returned
> > > > > >> >   and the global errno is set to ENOMEM.
> > > > > >> >   We do a sanity check to see if it was possible to allocate
> > > enough
> > > > > >> > memory.
> > > > > >> >
> > > > > >> >   Also as we allocate memory, we need to free this memory
> used.
> > > Or it
> > > > > >> > will
> > > > > >> >   going out of scope leaks the storage it points to.
> > > > > >> >
> > > > > >> >   Reviewed by:rgrimes
> > > > > >> >   MFC after:  3 weeks.
> > > > > >> >   X-MFC:  r332298
> > > > > >> >   Sponsored by:   iXsystems Inc.
> > > > > >> >   Differential Revision:  https://reviews.freebsd.org/
> D15550
> > > > > >> >
> > > > > >> > Modified:
> > > > > >> >   head/usr.sbin/bhyve/bhyverun.c
> > > > > >> >
> > > > > >> > Modified: head/usr.sbin/bhyve/bhyverun.c
> > > > > >> >
> > > > > >> >
> > > > > 
> > > ==
> > > > > >> > --- head/usr.sbin/bhyve/bhyverun.cFri May 25 01:38:59 2018
> > > > > >> > (r334198)
> > > > > >> > +++ head/usr.sbin/bhyve/bhyverun.cFri May 25 02:07:05 2018
> > > > > >> > (r334199)
> > > > > >> > @@ -193,6 +193,7 @@ topology_parse(const char *opt)
> > > > > >> >   c = 1, n = 1, s = 1, t = 1;
> > > > > >> >   ns = false, scts = false;
> > > > > >> >   str = strdup(opt);
> > > > > >> > + assert(str != NULL);
> > > > > >>
> > > > > >> Using assert seems like an odd choice when you've already added
> a
> > > > > >> failure path and the strsep will crash immediately if assert is
> > > elided.
> > > > > >
> > > > > >
> > > > > > Just to make a better point, I had the same discussion about
> > > assert(3) in
> > > > > > another review, we don't do NDEBUG even for RELEASE.
> > > > >
> > > > > IMHO we only use assert for asserting things ought to never be
> false
> > > > > except in buggy code. Using assert for handling is poor practice.
> > > > >
> > > >
> > > > Again, in this case we are using it all over the place and we must
> > > replace
> > > > it. Also we should document it in somewhere perhaps in the assert(3)
> > > > otherwise myself and others will keep using it. If you use find, not
> only
> > > > myself is using it to check strdup! So what is the suggestion to
> handle
> > > > assert(3)? Deprecated it?
> > >
> > > Code that uses assert() in place of error handling is wrong and should
> > > be fixed. assert(condition) means that condition must never happen
> > > and if it does a bug has occurred (or the programmers assumptions are
> > > wrong).  In this case failure would not be due to a bug, but do to
> > > resource exhaustion which is expected to be handled.
> > >
> >
> > I agree with you! We have plenty of place that use strdup(3) without
> check
> > the errno ENOMEN return; so do you think would be better bypass a errno
> > ENOMEN without check it and have a crash, or better abort(3) using
> > assert(3) in case we have no memory available to allocated the memory
> for a
> > copy of a string?
>
> The correct code here would be one of:
>
> str = strdup(opt);
> if (str == NULL)
> goto out;
>
> str = strdup(opt);
> if (str == NULL)
> err(1, "unable to allocate option memory");
>


One more thing, exit with err(1) is wrong, 1 is EPERM and should be 12
ENOMEN! :D


>
> > Personally I don't mind make couple extra lines of code to call abort(3)
> or
> > exit(3), but till there, if we don't make RELEASE using NDEBUG, what you
> > guys are saying to me is more personal preference than anything else.
>
> The fact that we don't do NDEBUG builds normally does not allow us to
> ignore that it exists.  It's perfectly reasonable for a user to build
> with CFLAGS+=NDEBUG.  That need to work.  If code is going to fail to
> handle resource errors with NDEBUG set then it needs something like this
> at the top of the

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

2018-05-25 Thread Marcelo Araujo

2018-05-26 2:21 GMT+08:00 Brooks Davis :

> On Sat, May 26, 2018 at 01:56:28AM +0800, Marcelo Araujo wrote:
> > 2018-05-26 1:44 GMT+08:00 Brooks Davis :
> >
> > > On Sat, May 26, 2018 at 01:21:33AM +0800, Marcelo Araujo wrote:
> > > > On Sat, May 26, 2018, 1:11 AM Eitan Adler 
> wrote:
> > > >
> > > > > On 25 May 2018 at 08:23, Marcelo Araujo 
> > > wrote:
> > > > > >
> > > > > >
> > > > > > On Fri, May 25, 2018, 11:11 PM Brooks Davis 
> > > wrote:
> > > > > >>
> > > > > >> On Fri, May 25, 2018 at 02:07:05AM +, Marcelo Araujo wrote:
> > > > > >> > Author: araujo
> > > > > >> > Date: Fri May 25 02:07:05 2018
> > > > > >> > New Revision: 334199
> > > > > >> > URL: https://svnweb.freebsd.org/changeset/base/334199
> > > > > >> >
> > > > > >> > Log:
> > > > > >> >   Fix a memory leak on topology_parse().
> > > > > >> >
> > > > > >> >   strdup(3) allocates memory for a copy of the string, does
> the
> > > copy
> > > > > and
> > > > > >> >   returns a pointer to it. If there is no sufficient memory
> NULL
> > > is
> > > > > >> > returned
> > > > > >> >   and the global errno is set to ENOMEM.
> > > > > >> >   We do a sanity check to see if it was possible to allocate
> > > enough
> > > > > >> > memory.
> > > > > >> >
> > > > > >> >   Also as we allocate memory, we need to free this memory
> used.
> > > Or it
> > > > > >> > will
> > > > > >> >   going out of scope leaks the storage it points to.
> > > > > >> >
> > > > > >> >   Reviewed by:rgrimes
> > > > > >> >   MFC after:  3 weeks.
> > > > > >> >   X-MFC:  r332298
> > > > > >> >   Sponsored by:   iXsystems Inc.
> > > > > >> >   Differential Revision:  https://reviews.freebsd.org/
> D15550
> > > > > >> >
> > > > > >> > Modified:
> > > > > >> >   head/usr.sbin/bhyve/bhyverun.c
> > > > > >> >
> > > > > >> > Modified: head/usr.sbin/bhyve/bhyverun.c
> > > > > >> >
> > > > > >> >
> > > > > 
> > > ==
> > > > > >> > --- head/usr.sbin/bhyve/bhyverun.cFri May 25 01:38:59 2018
> > > > > >> > (r334198)
> > > > > >> > +++ head/usr.sbin/bhyve/bhyverun.cFri May 25 02:07:05 2018
> > > > > >> > (r334199)
> > > > > >> > @@ -193,6 +193,7 @@ topology_parse(const char *opt)
> > > > > >> >   c = 1, n = 1, s = 1, t = 1;
> > > > > >> >   ns = false, scts = false;
> > > > > >> >   str = strdup(opt);
> > > > > >> > + assert(str != NULL);
> > > > > >>
> > > > > >> Using assert seems like an odd choice when you've already added
> a
> > > > > >> failure path and the strsep will crash immediately if assert is
> > > elided.
> > > > > >
> > > > > >
> > > > > > Just to make a better point, I had the same discussion about
> > > assert(3) in
> > > > > > another review, we don't do NDEBUG even for RELEASE.
> > > > >
> > > > > IMHO we only use assert for asserting things ought to never be
> false
> > > > > except in buggy code. Using assert for handling is poor practice.
> > > > >
> > > >
> > > > Again, in this case we are using it all over the place and we must
> > > replace
> > > > it. Also we should document it in somewhere perhaps in the assert(3)
> > > > otherwise myself and others will keep using it. If you use find, not
> only
> > > > myself is using it to check strdup! So what is the suggestion to
> handle
> > > > assert(3)? Deprecated it?
> > >
> > > Code that uses assert() in place of error handling is wrong and should
> > > be fixed. assert(condition) means that condition must never happen
> > > and if it does a bug has occurred (or the programmers assumptions are
> > > wrong).  In this case failure would not be due to a bug, but do to
> > > resource exhaustion which is expected to be handled.
> > >
> >
> > I agree with you! We have plenty of place that use strdup(3) without
> check
> > the errno ENOMEN return; so do you think would be better bypass a errno
> > ENOMEN without check it and have a crash, or better abort(3) using
> > assert(3) in case we have no memory available to allocated the memory
> for a
> > copy of a string?
>
> The correct code here would be one of:
>
> str = strdup(opt);
> if (str == NULL)
> goto out;
>

No, it is not the correct code! If we go out and free(str) we have nothing
to free, because we even didn't allocated memory for str.


>
> str = strdup(opt);
> if (str == NULL)
> err(1, "unable to allocate option memory");
>

Yes, this one makes sense.


>
> > Personally I don't mind make couple extra lines of code to call abort(3)
> or
> > exit(3), but till there, if we don't make RELEASE using NDEBUG, what you
> > guys are saying to me is more personal preference than anything else.
>
> The fact that we don't do NDEBUG builds normally does not allow us to
> ignore that it exists.  It's perfectly reasonable for a user to build
> with CFLAGS+=NDEBUG.  That need to work.  If code is going to fail to
> handle

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

2018-05-25 Thread Brooks Davis

On Sat, May 26, 2018 at 01:56:28AM +0800, Marcelo Araujo wrote:
> 2018-05-26 1:44 GMT+08:00 Brooks Davis :
> 
> > On Sat, May 26, 2018 at 01:21:33AM +0800, Marcelo Araujo wrote:
> > > On Sat, May 26, 2018, 1:11 AM Eitan Adler  wrote:
> > >
> > > > On 25 May 2018 at 08:23, Marcelo Araujo 
> > wrote:
> > > > >
> > > > >
> > > > > On Fri, May 25, 2018, 11:11 PM Brooks Davis 
> > wrote:
> > > > >>
> > > > >> On Fri, May 25, 2018 at 02:07:05AM +, Marcelo Araujo wrote:
> > > > >> > Author: araujo
> > > > >> > Date: Fri May 25 02:07:05 2018
> > > > >> > New Revision: 334199
> > > > >> > URL: https://svnweb.freebsd.org/changeset/base/334199
> > > > >> >
> > > > >> > Log:
> > > > >> >   Fix a memory leak on topology_parse().
> > > > >> >
> > > > >> >   strdup(3) allocates memory for a copy of the string, does the
> > copy
> > > > and
> > > > >> >   returns a pointer to it. If there is no sufficient memory NULL
> > is
> > > > >> > returned
> > > > >> >   and the global errno is set to ENOMEM.
> > > > >> >   We do a sanity check to see if it was possible to allocate
> > enough
> > > > >> > memory.
> > > > >> >
> > > > >> >   Also as we allocate memory, we need to free this memory used.
> > Or it
> > > > >> > will
> > > > >> >   going out of scope leaks the storage it points to.
> > > > >> >
> > > > >> >   Reviewed by:rgrimes
> > > > >> >   MFC after:  3 weeks.
> > > > >> >   X-MFC:  r332298
> > > > >> >   Sponsored by:   iXsystems Inc.
> > > > >> >   Differential Revision:  https://reviews.freebsd.org/D15550
> > > > >> >
> > > > >> > Modified:
> > > > >> >   head/usr.sbin/bhyve/bhyverun.c
> > > > >> >
> > > > >> > Modified: head/usr.sbin/bhyve/bhyverun.c
> > > > >> >
> > > > >> >
> > > > 
> > ==
> > > > >> > --- head/usr.sbin/bhyve/bhyverun.cFri May 25 01:38:59 2018
> > > > >> > (r334198)
> > > > >> > +++ head/usr.sbin/bhyve/bhyverun.cFri May 25 02:07:05 2018
> > > > >> > (r334199)
> > > > >> > @@ -193,6 +193,7 @@ topology_parse(const char *opt)
> > > > >> >   c = 1, n = 1, s = 1, t = 1;
> > > > >> >   ns = false, scts = false;
> > > > >> >   str = strdup(opt);
> > > > >> > + assert(str != NULL);
> > > > >>
> > > > >> Using assert seems like an odd choice when you've already added a
> > > > >> failure path and the strsep will crash immediately if assert is
> > elided.
> > > > >
> > > > >
> > > > > Just to make a better point, I had the same discussion about
> > assert(3) in
> > > > > another review, we don't do NDEBUG even for RELEASE.
> > > >
> > > > IMHO we only use assert for asserting things ought to never be false
> > > > except in buggy code. Using assert for handling is poor practice.
> > > >
> > >
> > > Again, in this case we are using it all over the place and we must
> > replace
> > > it. Also we should document it in somewhere perhaps in the assert(3)
> > > otherwise myself and others will keep using it. If you use find, not only
> > > myself is using it to check strdup! So what is the suggestion to handle
> > > assert(3)? Deprecated it?
> >
> > Code that uses assert() in place of error handling is wrong and should
> > be fixed. assert(condition) means that condition must never happen
> > and if it does a bug has occurred (or the programmers assumptions are
> > wrong).  In this case failure would not be due to a bug, but do to
> > resource exhaustion which is expected to be handled.
> >
> 
> I agree with you! We have plenty of place that use strdup(3) without check
> the errno ENOMEN return; so do you think would be better bypass a errno
> ENOMEN without check it and have a crash, or better abort(3) using
> assert(3) in case we have no memory available to allocated the memory for a
> copy of a string?

The correct code here would be one of:

str = strdup(opt);
if (str == NULL)
goto out;

str = strdup(opt);
if (str == NULL)
err(1, "unable to allocate option memory"); 

> Personally I don't mind make couple extra lines of code to call abort(3) or
> exit(3), but till there, if we don't make RELEASE using NDEBUG, what you
> guys are saying to me is more personal preference than anything else.

The fact that we don't do NDEBUG builds normally does not allow us to
ignore that it exists.  It's perfectly reasonable for a user to build
with CFLAGS+=NDEBUG.  That need to work.  If code is going to fail to
handle resource errors with NDEBUG set then it needs something like this
at the top of the file:

#ifdef NDEBUG
#error The code depends on assert() for error handling
#endif

-- Brooks


signature.asc
Description: PGP signature

svn commit: r334215 - head/usr.sbin/pmcstat

2018-05-25 Thread Sean Bruno

Author: sbruno
Date: Fri May 25 18:11:13 2018
New Revision: 334215
URL: https://svnweb.freebsd.org/changeset/base/334215

Log:
  pmcstat(8)
  - Document per thread filtering.
  
  Submitted by: kbowling
  Sponsored by: Limelight Networks
  Differential Revision:https://reviews.freebsd.org/D15549

Modified:
  head/usr.sbin/pmcstat/pmcstat.8
  head/usr.sbin/pmcstat/pmcstat.c

Modified: head/usr.sbin/pmcstat/pmcstat.8
==
--- head/usr.sbin/pmcstat/pmcstat.8 Fri May 25 18:07:20 2018
(r334214)
+++ head/usr.sbin/pmcstat/pmcstat.8 Fri May 25 18:11:13 2018
(r334215)
@@ -25,7 +25,7 @@
 .\"
 .\" $FreeBSD$
 .\"
-.Dd November 18, 2015
+.Dd May 25, 2018
 .Dt PMCSTAT 8
 .Os
 .Sh NAME
@@ -38,6 +38,8 @@
 .Op Fl E
 .Op Fl F Ar pathname
 .Op Fl G Ar pathname
+.Op Fl I
+.Op Fl L Ar lwp
 .Op Fl M Ar mapfilename
 .Op Fl N
 .Op Fl O Ar logfilename
@@ -155,6 +157,15 @@ is a
 this information is sent to the output file specified by the
 .Fl o
 option.
+.It Fl I
+Skip symbol lookup and display address instead.
+.It Fl L Ar lwp
+Filter on thread ID
+.Ar lwp ,
+which you can get from
+.Xr ps 1
+.Fl o
+.Li lwp .
 .It Fl M Ar mapfilename
 Write the mapping between executable objects encountered in the event
 log and the abbreviated pathnames used for

Modified: head/usr.sbin/pmcstat/pmcstat.c
==
--- head/usr.sbin/pmcstat/pmcstat.c Fri May 25 18:07:20 2018
(r334214)
+++ head/usr.sbin/pmcstat/pmcstat.c Fri May 25 18:11:13 2018
(r334215)
@@ -365,8 +365,8 @@ pmcstat_show_usage(void)
"\t -F file\t write a system-wide callgraph (Kcachegrind format)"
" to \"file\"\n"
"\t -G file\t write a system-wide callgraph to \"file\"\n"
-   "\t -I don't resolve leaf function but show address instead" 
-   "\t -L \"tid\" filter on thread id in post-processing"
+   "\t -I don't resolve leaf function name, show address instead\n"
+   "\t -L lwp\t filter on thread id \"lwp\" in post-processing\n"
"\t -M file\t print executable/gmon file map to \"file\"\n"
"\t -N\t\t (toggle) capture callchains\n"
"\t -O file\t send log output to \"file\"\n"
___
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: r334199 - head/usr.sbin/bhyve

2018-05-25 Thread Marcelo Araujo

2018-05-26 1:44 GMT+08:00 Brooks Davis :

> On Sat, May 26, 2018 at 01:21:33AM +0800, Marcelo Araujo wrote:
> > On Sat, May 26, 2018, 1:11 AM Eitan Adler  wrote:
> >
> > > On 25 May 2018 at 08:23, Marcelo Araujo 
> wrote:
> > > >
> > > >
> > > > On Fri, May 25, 2018, 11:11 PM Brooks Davis 
> wrote:
> > > >>
> > > >> On Fri, May 25, 2018 at 02:07:05AM +, Marcelo Araujo wrote:
> > > >> > Author: araujo
> > > >> > Date: Fri May 25 02:07:05 2018
> > > >> > New Revision: 334199
> > > >> > URL: https://svnweb.freebsd.org/changeset/base/334199
> > > >> >
> > > >> > Log:
> > > >> >   Fix a memory leak on topology_parse().
> > > >> >
> > > >> >   strdup(3) allocates memory for a copy of the string, does the
> copy
> > > and
> > > >> >   returns a pointer to it. If there is no sufficient memory NULL
> is
> > > >> > returned
> > > >> >   and the global errno is set to ENOMEM.
> > > >> >   We do a sanity check to see if it was possible to allocate
> enough
> > > >> > memory.
> > > >> >
> > > >> >   Also as we allocate memory, we need to free this memory used.
> Or it
> > > >> > will
> > > >> >   going out of scope leaks the storage it points to.
> > > >> >
> > > >> >   Reviewed by:rgrimes
> > > >> >   MFC after:  3 weeks.
> > > >> >   X-MFC:  r332298
> > > >> >   Sponsored by:   iXsystems Inc.
> > > >> >   Differential Revision:  https://reviews.freebsd.org/D15550
> > > >> >
> > > >> > Modified:
> > > >> >   head/usr.sbin/bhyve/bhyverun.c
> > > >> >
> > > >> > Modified: head/usr.sbin/bhyve/bhyverun.c
> > > >> >
> > > >> >
> > > 
> ==
> > > >> > --- head/usr.sbin/bhyve/bhyverun.cFri May 25 01:38:59 2018
> > > >> > (r334198)
> > > >> > +++ head/usr.sbin/bhyve/bhyverun.cFri May 25 02:07:05 2018
> > > >> > (r334199)
> > > >> > @@ -193,6 +193,7 @@ topology_parse(const char *opt)
> > > >> >   c = 1, n = 1, s = 1, t = 1;
> > > >> >   ns = false, scts = false;
> > > >> >   str = strdup(opt);
> > > >> > + assert(str != NULL);
> > > >>
> > > >> Using assert seems like an odd choice when you've already added a
> > > >> failure path and the strsep will crash immediately if assert is
> elided.
> > > >
> > > >
> > > > Just to make a better point, I had the same discussion about
> assert(3) in
> > > > another review, we don't do NDEBUG even for RELEASE.
> > >
> > > IMHO we only use assert for asserting things ought to never be false
> > > except in buggy code. Using assert for handling is poor practice.
> > >
> >
> > Again, in this case we are using it all over the place and we must
> replace
> > it. Also we should document it in somewhere perhaps in the assert(3)
> > otherwise myself and others will keep using it. If you use find, not only
> > myself is using it to check strdup! So what is the suggestion to handle
> > assert(3)? Deprecated it?
>
> Code that uses assert() in place of error handling is wrong and should
> be fixed. assert(condition) means that condition must never happen
> and if it does a bug has occurred (or the programmers assumptions are
> wrong).  In this case failure would not be due to a bug, but do to
> resource exhaustion which is expected to be handled.
>

I agree with you! We have plenty of place that use strdup(3) without check
the errno ENOMEN return; so do you think would be better bypass a errno
ENOMEN without check it and have a crash, or better abort(3) using
assert(3) in case we have no memory available to allocated the memory for a
copy of a string?

Personally I don't mind make couple extra lines of code to call abort(3) or
exit(3), but till there, if we don't make RELEASE using NDEBUG, what you
guys are saying to me is more personal preference than anything else.


>
> -- Brooks
>



-- 

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

2018-05-25 Thread Brooks Davis

On Sat, May 26, 2018 at 01:21:33AM +0800, Marcelo Araujo wrote:
> On Sat, May 26, 2018, 1:11 AM Eitan Adler  wrote:
> 
> > On 25 May 2018 at 08:23, Marcelo Araujo  wrote:
> > >
> > >
> > > On Fri, May 25, 2018, 11:11 PM Brooks Davis  wrote:
> > >>
> > >> On Fri, May 25, 2018 at 02:07:05AM +, Marcelo Araujo wrote:
> > >> > Author: araujo
> > >> > Date: Fri May 25 02:07:05 2018
> > >> > New Revision: 334199
> > >> > URL: https://svnweb.freebsd.org/changeset/base/334199
> > >> >
> > >> > Log:
> > >> >   Fix a memory leak on topology_parse().
> > >> >
> > >> >   strdup(3) allocates memory for a copy of the string, does the copy
> > and
> > >> >   returns a pointer to it. If there is no sufficient memory NULL is
> > >> > returned
> > >> >   and the global errno is set to ENOMEM.
> > >> >   We do a sanity check to see if it was possible to allocate enough
> > >> > memory.
> > >> >
> > >> >   Also as we allocate memory, we need to free this memory used. Or it
> > >> > will
> > >> >   going out of scope leaks the storage it points to.
> > >> >
> > >> >   Reviewed by:rgrimes
> > >> >   MFC after:  3 weeks.
> > >> >   X-MFC:  r332298
> > >> >   Sponsored by:   iXsystems Inc.
> > >> >   Differential Revision:  https://reviews.freebsd.org/D15550
> > >> >
> > >> > Modified:
> > >> >   head/usr.sbin/bhyve/bhyverun.c
> > >> >
> > >> > Modified: head/usr.sbin/bhyve/bhyverun.c
> > >> >
> > >> >
> > ==
> > >> > --- head/usr.sbin/bhyve/bhyverun.cFri May 25 01:38:59 2018
> > >> > (r334198)
> > >> > +++ head/usr.sbin/bhyve/bhyverun.cFri May 25 02:07:05 2018
> > >> > (r334199)
> > >> > @@ -193,6 +193,7 @@ topology_parse(const char *opt)
> > >> >   c = 1, n = 1, s = 1, t = 1;
> > >> >   ns = false, scts = false;
> > >> >   str = strdup(opt);
> > >> > + assert(str != NULL);
> > >>
> > >> Using assert seems like an odd choice when you've already added a
> > >> failure path and the strsep will crash immediately if assert is elided.
> > >
> > >
> > > Just to make a better point, I had the same discussion about assert(3) in
> > > another review, we don't do NDEBUG even for RELEASE.
> >
> > IMHO we only use assert for asserting things ought to never be false
> > except in buggy code. Using assert for handling is poor practice.
> >
> 
> Again, in this case we are using it all over the place and we must replace
> it. Also we should document it in somewhere perhaps in the assert(3)
> otherwise myself and others will keep using it. If you use find, not only
> myself is using it to check strdup! So what is the suggestion to handle
> assert(3)? Deprecated it?

Code that uses assert() in place of error handling is wrong and should
be fixed. assert(condition) means that condition must never happen
and if it does a bug has occurred (or the programmers assumptions are
wrong).  In this case failure would not be due to a bug, but do to
resource exhaustion which is expected to be handled.

-- Brooks


signature.asc
Description: PGP signature

svn commit: r334213 - head/sys/dev/usb/net

2018-05-25 Thread Ed Maste

Author: emaste
Date: Fri May 25 17:31:43 2018
New Revision: 334213
URL: https://svnweb.freebsd.org/changeset/base/334213

Log:
  if_muge: Use lock assertion instead of broken locking in lan78xx_chip_init
  
  Previously lan78xx_chip_init locked the driver's mutex if not already
  locked, but unlocked it only in the case of error.  This provided a
  fairly clear indication that the function is already called with the
  lock held, so just replace it with a lock assertion.
  
  Sponsored by: The FreeBSD Foundation

Modified:
  head/sys/dev/usb/net/if_muge.c

Modified: head/sys/dev/usb/net/if_muge.c
==
--- head/sys/dev/usb/net/if_muge.c  Fri May 25 17:29:29 2018
(r334212)
+++ head/sys/dev/usb/net/if_muge.c  Fri May 25 17:31:43 2018
(r334213)
@@ -953,13 +953,10 @@ static int
 lan78xx_chip_init(struct muge_softc *sc)
 {
int err;
-   int locked;
uint32_t buf;
uint32_t burst_cap;
 
-   locked = mtx_owned(>sc_mtx);
-   if (!locked)
-   MUGE_LOCK(sc);
+   MUGE_LOCK_ASSERT(sc, MA_OWNED);
 
/* Enter H/W config mode. */
lan78xx_write_reg(sc, ETH_HW_CFG, ETH_HW_CFG_LRST_);
@@ -1132,9 +1129,6 @@ lan78xx_chip_init(struct muge_softc *sc)
return (0);
 
 init_failed:
-   if (!locked)
-   MUGE_UNLOCK(sc);
-
muge_err_printf(sc, "lan78xx_chip_init failed (err=%d)\n", err);
return (err);
 }
___
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: r334212 - head/sys/modules/usb

2018-05-25 Thread Ed Maste

Author: emaste
Date: Fri May 25 17:29:29 2018
New Revision: 334212
URL: https://svnweb.freebsd.org/changeset/base/334212

Log:
  if_muge: connect module to the build
  
  Supported Microchip devices:
  - LAN7515 USB 2 hub and gigabit Ethernet controller w/ PHY
  - LAN7800 USB 3.0 gigabit Ethernet controller w/ PHY
  
  The LAN7515 is the Ethernet controller on the Raspberry Pi 3 B+.
  
  This driver has some TODO items outstanding, but basic functionality
  works.
  
  Sponsored by: The FreeBSD Foundation

Modified:
  head/sys/modules/usb/Makefile

Modified: head/sys/modules/usb/Makefile
==
--- head/sys/modules/usb/Makefile   Fri May 25 16:29:22 2018
(r334211)
+++ head/sys/modules/usb/Makefile   Fri May 25 17:29:29 2018
(r334212)
@@ -52,6 +52,7 @@ SUBDIR += ucom u3g uark ubsa ubser uchcom ucycom ufoma
  umct umcs umodem umoscom uplcom uslcom uvisor uvscom
 SUBDIR += udl
 SUBDIR += uether aue axe axge cdce cue ${_kue} mos rue smsc udav uhso ipheth
+SUBDIR += muge
 SUBDIR += ure urndis
 SUBDIR += usfs umass urio
 SUBDIR += quirk template
___
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: r334199 - head/usr.sbin/bhyve

2018-05-25 Thread Marcelo Araujo

On Sat, May 26, 2018, 1:11 AM Eitan Adler  wrote:

> On 25 May 2018 at 08:23, Marcelo Araujo  wrote:
> >
> >
> > On Fri, May 25, 2018, 11:11 PM Brooks Davis  wrote:
> >>
> >> On Fri, May 25, 2018 at 02:07:05AM +, Marcelo Araujo wrote:
> >> > Author: araujo
> >> > Date: Fri May 25 02:07:05 2018
> >> > New Revision: 334199
> >> > URL: https://svnweb.freebsd.org/changeset/base/334199
> >> >
> >> > Log:
> >> >   Fix a memory leak on topology_parse().
> >> >
> >> >   strdup(3) allocates memory for a copy of the string, does the copy
> and
> >> >   returns a pointer to it. If there is no sufficient memory NULL is
> >> > returned
> >> >   and the global errno is set to ENOMEM.
> >> >   We do a sanity check to see if it was possible to allocate enough
> >> > memory.
> >> >
> >> >   Also as we allocate memory, we need to free this memory used. Or it
> >> > will
> >> >   going out of scope leaks the storage it points to.
> >> >
> >> >   Reviewed by:rgrimes
> >> >   MFC after:  3 weeks.
> >> >   X-MFC:  r332298
> >> >   Sponsored by:   iXsystems Inc.
> >> >   Differential Revision:  https://reviews.freebsd.org/D15550
> >> >
> >> > Modified:
> >> >   head/usr.sbin/bhyve/bhyverun.c
> >> >
> >> > Modified: head/usr.sbin/bhyve/bhyverun.c
> >> >
> >> >
> ==
> >> > --- head/usr.sbin/bhyve/bhyverun.cFri May 25 01:38:59 2018
> >> > (r334198)
> >> > +++ head/usr.sbin/bhyve/bhyverun.cFri May 25 02:07:05 2018
> >> > (r334199)
> >> > @@ -193,6 +193,7 @@ topology_parse(const char *opt)
> >> >   c = 1, n = 1, s = 1, t = 1;
> >> >   ns = false, scts = false;
> >> >   str = strdup(opt);
> >> > + assert(str != NULL);
> >>
> >> Using assert seems like an odd choice when you've already added a
> >> failure path and the strsep will crash immediately if assert is elided.
> >
> >
> > Just to make a better point, I had the same discussion about assert(3) in
> > another review, we don't do NDEBUG even for RELEASE.
>
> IMHO we only use assert for asserting things ought to never be false
> except in buggy code. Using assert for handling is poor practice.
>

Again, in this case we are using it all over the place and we must replace
it. Also we should document it in somewhere perhaps in the assert(3)
otherwise myself and others will keep using it. If you use find, not only
myself is using it to check strdup! So what is the suggestion to handle
assert(3)? Deprecated it?

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

2018-05-25 Thread Eitan Adler

On 25 May 2018 at 08:23, Marcelo Araujo  wrote:
>
>
> On Fri, May 25, 2018, 11:11 PM Brooks Davis  wrote:
>>
>> On Fri, May 25, 2018 at 02:07:05AM +, Marcelo Araujo wrote:
>> > Author: araujo
>> > Date: Fri May 25 02:07:05 2018
>> > New Revision: 334199
>> > URL: https://svnweb.freebsd.org/changeset/base/334199
>> >
>> > Log:
>> >   Fix a memory leak on topology_parse().
>> >
>> >   strdup(3) allocates memory for a copy of the string, does the copy and
>> >   returns a pointer to it. If there is no sufficient memory NULL is
>> > returned
>> >   and the global errno is set to ENOMEM.
>> >   We do a sanity check to see if it was possible to allocate enough
>> > memory.
>> >
>> >   Also as we allocate memory, we need to free this memory used. Or it
>> > will
>> >   going out of scope leaks the storage it points to.
>> >
>> >   Reviewed by:rgrimes
>> >   MFC after:  3 weeks.
>> >   X-MFC:  r332298
>> >   Sponsored by:   iXsystems Inc.
>> >   Differential Revision:  https://reviews.freebsd.org/D15550
>> >
>> > Modified:
>> >   head/usr.sbin/bhyve/bhyverun.c
>> >
>> > Modified: head/usr.sbin/bhyve/bhyverun.c
>> >
>> > ==
>> > --- head/usr.sbin/bhyve/bhyverun.cFri May 25 01:38:59 2018
>> > (r334198)
>> > +++ head/usr.sbin/bhyve/bhyverun.cFri May 25 02:07:05 2018
>> > (r334199)
>> > @@ -193,6 +193,7 @@ topology_parse(const char *opt)
>> >   c = 1, n = 1, s = 1, t = 1;
>> >   ns = false, scts = false;
>> >   str = strdup(opt);
>> > + assert(str != NULL);
>>
>> Using assert seems like an odd choice when you've already added a
>> failure path and the strsep will crash immediately if assert is elided.
>
>
> Just to make a better point, I had the same discussion about assert(3) in
> another review, we don't do NDEBUG even for RELEASE.

IMHO we only use assert for asserting things ought to never be false
except in buggy code. Using assert for handling is poor practice.



-- 
Eitan Adler
___
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: r334118 - in head/sys: compat/linprocfs compat/linux compat/linuxkpi/common/include/linux dev/mlx5/mlx5_ib dev/wtap net net/altq netinet netinet/netdump netinet6 netpfil/pf nfs ofed/dr

2018-05-25 Thread Matthew Macy

Odd. I tested the same thing as did pho with regular interfaces. Will fix
asap.

On Fri, May 25, 2018 at 09:36 Mark Johnston  wrote:

> On Wed, May 23, 2018 at 09:02:15PM +, Matt Macy wrote:
> > Author: mmacy
> > Date: Wed May 23 21:02:14 2018
> > New Revision: 334118
> > URL: https://svnweb.freebsd.org/changeset/base/334118
> >
> > Log:
> >   UDP: further performance improvements on tx
> >
> >   Cumulative throughput while running 64
> > netperf -H $DUT -t UDP_STREAM -- -m 1
> >   on a 2x8x2 SKL went from 1.1Mpps to 2.5Mpps
> >
> >   Single stream throughput increases from 910kpps to 1.18Mpps
> >
> >   Baseline:
> >   https://people.freebsd.org/~mmacy/2018.05.11/udpsender2.svg
> >
> >   - Protect read access to global ifnet list with epoch
> >   https://people.freebsd.org/~mmacy/2018.05.11/udpsender3.svg
> >
> >   - Protect short lived ifaddr references with epoch
> >   https://people.freebsd.org/~mmacy/2018.05.11/udpsender4.svg
> >
> >   - Convert if_afdata read lock path to epoch
> >   https://people.freebsd.org/~mmacy/2018.05.11/udpsender5.svg
>
> After this change I can panic an INVARIANTS kernel like so. There is a
> freed ifaddr lingering on the lo0 ifnet's address list.
>
> # ifconfig lo0 127.0.0.2
> # ifconfig lo0 -alias 127.0.0.2
> # netstat -rn
> Routing tables
>
>
> Fatal trap 9: general protection fault while in kernel mode
> cpuid = 1; apic id = 01
> instruction pointer = 0x20:0x80605219
> stack pointer   = 0x28:0xfe4692e0
> frame pointer   = 0x28:0xfe4693d0
> code segment= base 0x0, limit 0xf, type 0x1b
> = DPL 0, pres 1, long 1, def32 0, gran 1
> processor eflags= interrupt enabled, resume, IOPL = 0
> current process = 735 (netstat)
> trap number = 9
> panic: general protection fault
> cpuid = 1
> time = 1527266002
> Uptime: 1m42s
> Dumping 216 out of 4079
> MB:..8%..15%..23%..37%..45%..52%..67%..74%..82%..97%
> Dump complete
> Consoles: userboot
>
___
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: r334118 - in head/sys: compat/linprocfs compat/linux compat/linuxkpi/common/include/linux dev/mlx5/mlx5_ib dev/wtap net net/altq netinet netinet/netdump netinet6 netpfil/pf nfs ofed/dr

2018-05-25 Thread Mark Johnston

On Wed, May 23, 2018 at 09:02:15PM +, Matt Macy wrote:
> Author: mmacy
> Date: Wed May 23 21:02:14 2018
> New Revision: 334118
> URL: https://svnweb.freebsd.org/changeset/base/334118
> 
> Log:
>   UDP: further performance improvements on tx
>   
>   Cumulative throughput while running 64
> netperf -H $DUT -t UDP_STREAM -- -m 1
>   on a 2x8x2 SKL went from 1.1Mpps to 2.5Mpps
>   
>   Single stream throughput increases from 910kpps to 1.18Mpps
>   
>   Baseline:
>   https://people.freebsd.org/~mmacy/2018.05.11/udpsender2.svg
>   
>   - Protect read access to global ifnet list with epoch
>   https://people.freebsd.org/~mmacy/2018.05.11/udpsender3.svg
>   
>   - Protect short lived ifaddr references with epoch
>   https://people.freebsd.org/~mmacy/2018.05.11/udpsender4.svg
>   
>   - Convert if_afdata read lock path to epoch
>   https://people.freebsd.org/~mmacy/2018.05.11/udpsender5.svg

After this change I can panic an INVARIANTS kernel like so. There is a
freed ifaddr lingering on the lo0 ifnet's address list.

# ifconfig lo0 127.0.0.2
# ifconfig lo0 -alias 127.0.0.2
# netstat -rn
Routing tables


Fatal trap 9: general protection fault while in kernel mode
cpuid = 1; apic id = 01
instruction pointer = 0x20:0x80605219
stack pointer   = 0x28:0xfe4692e0
frame pointer   = 0x28:0xfe4693d0
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 735 (netstat)
trap number = 9
panic: general protection fault
cpuid = 1
time = 1527266002
Uptime: 1m42s
Dumping 216 out of 4079 MB:..8%..15%..23%..37%..45%..52%..67%..74%..82%..97%
Dump complete
Consoles: userboot
___
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: r333388 - in head: . share/man/man4 sys/confsys/dev/nxge sys/modules sys/modules/nxge tools/kerneldoc/subsys tools/toolstools/tools/nxge usr.sbin/bsdconfig/share

2018-05-25 Thread Eugene Grosbein

24.05.2018 3:22, Brooks Davis wrote:

>>> Except for old computers and old software that segfaults on 64-bit, how 
>>> many people still use i386?
>>> Full disclosure: I'd like to see i386 deorbited before I retire.
>> Plese don't. I routinely use FreeBSD11/i386 for cheap VPS hosts having less 
>> than 2G memory
>> because amd64 has noticeable overhead. I even have ZFS-only i386 VPS, here 
>> is live example with 1G only:
>>
>> Mem: 10M Active, 69M Inact, 230M Wired, 685M Free
>> ARC: 75M Total, 1953K MFU, 31M MRU, 172K Anon, 592K Header, 42M Other
>>  3500K Compressed, 29M Uncompressed, 8.61:1 Ratio
>> Swap: 1024M Total, 1024M Free
>>
>> The VPS has only 20G of disk space and ZFS compression gives
>> compressratio 2.22x for ports, 2.51x for src, 2.29x for obj
>> and 1.95x for installed i386 system plus other software and data.
> 
> I think we're quite a ways from being ready to axe i386.
> 
> For VPS applications, we should probably get x32 support in place which
> should give us the best of both worlds.
> 
> That said, we either need to rev the i386 ABI to use a 64-bit time_t or
> kill it in the not to distant future or we risk embedded systems failing
> in place in 2038.  If we assume a 15 year life for most equipment to
> fail electrically or mechanically that says FreeBSD 13 shouldn't support
> the current i386 ABI.

Why everyone's talking of hardware only? FreeBSD/i386 as virtual machine guest
with memory-intensive kernel subsystems like ZFS and/or networking tasks
using plenty of mbufs benefits significantly comparing with amd64 version.

It runs just fine, why even consider killing it?

___
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: r334211 - in head/sys/i386: i386 include

2018-05-25 Thread Konstantin Belousov

Author: kib
Date: Fri May 25 16:29:22 2018
New Revision: 334211
URL: https://svnweb.freebsd.org/changeset/base/334211

Log:
  Optimize i386 pmap_extract_and_hold().
  
  In particular, stop using pmap_pte() to read non-promoted pte while
  walking the page table.  pmap_pte() needs to shoot down the kernel
  mapping globally which causes IPI broadcast.  Since
  pmap_extract_and_hold() is used for slow copyin(9), it is very
  significant hit for the 4/4 kernels.
  
  Instead, create single purpose per-processor page frame and use it to
  locally map page table page inside the critical section, to avoid
  reuse of the frame by other thread if context switched.
  
  Measurement demostrated very significant improvements in any load that
  utilizes copyin/copyout.
  
  Found and benchmarked by: bde
  Sponsored by: The FreeBSD Foundation

Modified:
  head/sys/i386/i386/pmap.c
  head/sys/i386/include/pcpu.h

Modified: head/sys/i386/i386/pmap.c
==
--- head/sys/i386/i386/pmap.c   Fri May 25 16:24:20 2018(r334210)
+++ head/sys/i386/i386/pmap.c   Fri May 25 16:29:22 2018(r334211)
@@ -692,6 +692,10 @@ pmap_init_reserved_pages(void)
pc->pc_copyout_saddr = kva_alloc(ptoa(2));
if (pc->pc_copyout_saddr == 0)
panic("unable to allocate sleepable copyout KVA");
+   pc->pc_pmap_eh_va = kva_alloc(ptoa(1));
+   if (pc->pc_pmap_eh_va == 0)
+   panic("unable to allocate pmap_extract_and_hold KVA");
+   pc->pc_pmap_eh_ptep = (char *)vtopte(pc->pc_pmap_eh_va);
 
/*
 * Skip if the mappings have already been initialized,
@@ -1598,8 +1602,8 @@ pmap_extract(pmap_t pmap, vm_offset_t va)
 vm_page_t
 pmap_extract_and_hold(pmap_t pmap, vm_offset_t va, vm_prot_t prot)
 {
-   pd_entry_t pde;
-   pt_entry_t pte, *ptep;
+   pd_entry_t pde, newpf;
+   pt_entry_t *eh_ptep, pte, *ptep;
vm_page_t m;
vm_paddr_t pa;
 
@@ -1619,9 +1623,17 @@ retry:
vm_page_hold(m);
}
} else {
-   ptep = pmap_pte(pmap, va);
+   newpf = pde & PG_FRAME;
+   critical_enter();
+   eh_ptep = (pt_entry_t *)PCPU_GET(pmap_eh_ptep);
+   if ((*eh_ptep & PG_FRAME) != newpf) {
+   *eh_ptep = newpf | PG_RW | PG_V | PG_A | PG_M;
+   invlcaddr((void *)PCPU_GET(pmap_eh_va));
+   }
+   ptep = (pt_entry_t *)PCPU_GET(pmap_eh_va) +
+   (i386_btop(va) & (NPTEPG - 1));
pte = *ptep;
-   pmap_pte_release(ptep);
+   critical_exit();
if (pte != 0 &&
((pte & PG_RW) || (prot & VM_PROT_WRITE) == 0)) {
if (vm_page_pa_tryrelock(pmap, pte & PG_FRAME,

Modified: head/sys/i386/include/pcpu.h
==
--- head/sys/i386/include/pcpu.hFri May 25 16:24:20 2018
(r334210)
+++ head/sys/i386/include/pcpu.hFri May 25 16:29:22 2018
(r334211)
@@ -76,9 +76,11 @@
struct  mtx pc_copyout_mlock;   \
struct  sx pc_copyout_slock;\
char*pc_copyout_buf;\
+   vm_offset_t pc_pmap_eh_va;  \
+   caddr_t pc_pmap_eh_ptep;
\
uint32_t pc_smp_tlb_done;   /* TLB op acknowledgement */\
uint32_t pc_ibpb_set;   \
-   char__pad[546]
+   char__pad[538]
 
 #ifdef _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: r334210 - head/sys/i386/i386

2018-05-25 Thread Konstantin Belousov

Author: kib
Date: Fri May 25 16:24:20 2018
New Revision: 334210
URL: https://svnweb.freebsd.org/changeset/base/334210

Log:
  Cleanup.  Remove unused instruction and label.
  
  Tested by:bde
  Sponsored by: The FreeBSD Foundation

Modified:
  head/sys/i386/i386/swtch.s

Modified: head/sys/i386/i386/swtch.s
==
--- head/sys/i386/i386/swtch.s  Fri May 25 13:59:48 2018(r334209)
+++ head/sys/i386/i386/swtch.s  Fri May 25 16:24:20 2018(r334210)
@@ -186,10 +186,6 @@ ENTRY(cpu_switch)
lock
 #endif
btsl%esi, PM_ACTIVE(%ebx)   /* set new */
-   jmp sw1
-
-sw0:
-   SETOP   %esi,TD_LOCK(%edi)  /* Switchout td_lock */
 sw1:
BLOCK_SPIN(%ecx)
/*
___
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: r334199 - head/usr.sbin/bhyve

2018-05-25 Thread Marcelo Araujo

On Fri, May 25, 2018, 11:11 PM Brooks Davis  wrote:

> On Fri, May 25, 2018 at 02:07:05AM +, Marcelo Araujo wrote:
> > Author: araujo
> > Date: Fri May 25 02:07:05 2018
> > New Revision: 334199
> > URL: https://svnweb.freebsd.org/changeset/base/334199
> >
> > Log:
> >   Fix a memory leak on topology_parse().
> >
> >   strdup(3) allocates memory for a copy of the string, does the copy and
> >   returns a pointer to it. If there is no sufficient memory NULL is
> returned
> >   and the global errno is set to ENOMEM.
> >   We do a sanity check to see if it was possible to allocate enough
> memory.
> >
> >   Also as we allocate memory, we need to free this memory used. Or it
> will
> >   going out of scope leaks the storage it points to.
> >
> >   Reviewed by:rgrimes
> >   MFC after:  3 weeks.
> >   X-MFC:  r332298
> >   Sponsored by:   iXsystems Inc.
> >   Differential Revision:  https://reviews.freebsd.org/D15550
> >
> > Modified:
> >   head/usr.sbin/bhyve/bhyverun.c
> >
> > Modified: head/usr.sbin/bhyve/bhyverun.c
> >
> ==
> > --- head/usr.sbin/bhyve/bhyverun.cFri May 25 01:38:59 2018
> (r334198)
> > +++ head/usr.sbin/bhyve/bhyverun.cFri May 25 02:07:05 2018
> (r334199)
> > @@ -193,6 +193,7 @@ topology_parse(const char *opt)
> >   c = 1, n = 1, s = 1, t = 1;
> >   ns = false, scts = false;
> >   str = strdup(opt);
> > + assert(str != NULL);
>
> Using assert seems like an odd choice when you've already added a
> failure path and the strsep will crash immediately if assert is elided.
>

Just to make a better point, I had the same discussion about assert(3) in
another review, we don't do NDEBUG even for RELEASE.

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

2018-05-25 Thread Marcelo Araujo

On Fri, May 25, 2018, 11:11 PM Brooks Davis  wrote:

> On Fri, May 25, 2018 at 02:07:05AM +, Marcelo Araujo wrote:
> > Author: araujo
> > Date: Fri May 25 02:07:05 2018
> > New Revision: 334199
> > URL: https://svnweb.freebsd.org/changeset/base/334199
> >
> > Log:
> >   Fix a memory leak on topology_parse().
> >
> >   strdup(3) allocates memory for a copy of the string, does the copy and
> >   returns a pointer to it. If there is no sufficient memory NULL is
> returned
> >   and the global errno is set to ENOMEM.
> >   We do a sanity check to see if it was possible to allocate enough
> memory.
> >
> >   Also as we allocate memory, we need to free this memory used. Or it
> will
> >   going out of scope leaks the storage it points to.
> >
> >   Reviewed by:rgrimes
> >   MFC after:  3 weeks.
> >   X-MFC:  r332298
> >   Sponsored by:   iXsystems Inc.
> >   Differential Revision:  https://reviews.freebsd.org/D15550
> >
> > Modified:
> >   head/usr.sbin/bhyve/bhyverun.c
> >
> > Modified: head/usr.sbin/bhyve/bhyverun.c
> >
> ==
> > --- head/usr.sbin/bhyve/bhyverun.cFri May 25 01:38:59 2018
> (r334198)
> > +++ head/usr.sbin/bhyve/bhyverun.cFri May 25 02:07:05 2018
> (r334199)
> > @@ -193,6 +193,7 @@ topology_parse(const char *opt)
> >   c = 1, n = 1, s = 1, t = 1;
> >   ns = false, scts = false;
> >   str = strdup(opt);
> > + assert(str != NULL);
>
> Using assert seems like an odd choice when you've already added a
> failure path and the strsep will crash immediately if assert is elided.
>

Why assert is an odd choice?  Have a better suggestion?

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

2018-05-25 Thread Brooks Davis

On Fri, May 25, 2018 at 02:07:05AM +, Marcelo Araujo wrote:
> Author: araujo
> Date: Fri May 25 02:07:05 2018
> New Revision: 334199
> URL: https://svnweb.freebsd.org/changeset/base/334199
> 
> Log:
>   Fix a memory leak on topology_parse().
>   
>   strdup(3) allocates memory for a copy of the string, does the copy and
>   returns a pointer to it. If there is no sufficient memory NULL is returned
>   and the global errno is set to ENOMEM.
>   We do a sanity check to see if it was possible to allocate enough memory.
>   
>   Also as we allocate memory, we need to free this memory used. Or it will
>   going out of scope leaks the storage it points to.
>   
>   Reviewed by:rgrimes
>   MFC after:  3 weeks.
>   X-MFC:  r332298
>   Sponsored by:   iXsystems Inc.
>   Differential Revision:  https://reviews.freebsd.org/D15550
> 
> Modified:
>   head/usr.sbin/bhyve/bhyverun.c
> 
> Modified: head/usr.sbin/bhyve/bhyverun.c
> ==
> --- head/usr.sbin/bhyve/bhyverun.cFri May 25 01:38:59 2018
> (r334198)
> +++ head/usr.sbin/bhyve/bhyverun.cFri May 25 02:07:05 2018
> (r334199)
> @@ -193,6 +193,7 @@ topology_parse(const char *opt)
>   c = 1, n = 1, s = 1, t = 1;
>   ns = false, scts = false;
>   str = strdup(opt);
> + assert(str != NULL);

Using assert seems like an odd choice when you've already added a
failure path and the strsep will crash immediately if assert is elided.

-- Brooks


signature.asc
Description: PGP signature

svn commit: r334209 - head/sys/ddb

2018-05-25 Thread Bjoern A. Zeeb

Author: bz
Date: Fri May 25 13:59:48 2018
New Revision: 334209
URL: https://svnweb.freebsd.org/changeset/base/334209

Log:
  Extend show proc with reaper, sigparent, and vmspace information
  I have regularly needed the last couple of months.
  
  Sponsored by: iXsystems, Inc.

Modified:
  head/sys/ddb/db_ps.c

Modified: head/sys/ddb/db_ps.c
==
--- head/sys/ddb/db_ps.cFri May 25 13:40:07 2018(r334208)
+++ head/sys/ddb/db_ps.cFri May 25 13:59:48 2018(r334209)
@@ -46,6 +46,7 @@ __FBSDID("$FreeBSD$");
 #include 
 #include 
 #include 
+#include 
 
 #include 
 
@@ -452,6 +453,16 @@ DB_SHOW_COMMAND(proc, db_show_proc)
}
db_printf("\n");
}
+   db_printf(" repear: %p reapsubtree: %d\n",
+   p->p_reaper, p->p_reapsubtree);
+   db_printf(" sigparent: %d\n", p->p_sigparent);
+   db_printf(" vmspace: %p\n", p->p_vmspace);
+   db_printf("   (map %p)\n",
+   (p->p_vmspace != NULL) ? >p_vmspace->vm_map : 0);
+   db_printf("   (map.pmap %p)\n",
+   (p->p_vmspace != NULL) ? >p_vmspace->vm_map.pmap : 0);
+   db_printf("   (pmap %p)\n",
+   (p->p_vmspace != NULL) ? >p_vmspace->vm_pmap : 0);
db_printf(" threads: %d\n", p->p_numthreads);
FOREACH_THREAD_IN_PROC(p, td) {
dumpthread(p, td, 1);
___
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: r334208 - head/usr.bin/rctl

2018-05-25 Thread Eitan Adler

Author: eadler
Date: Fri May 25 13:40:07 2018
New Revision: 334208
URL: https://svnweb.freebsd.org/changeset/base/334208

Log:
  rctl: correct use of "vmem" instead of "vmemoryuse"
  
  Submitted by: Jamie Landeg-Jones 
  PR:   228482
  MFC after:1 month

Modified:
  head/usr.bin/rctl/rctl.8

Modified: head/usr.bin/rctl/rctl.8
==
--- head/usr.bin/rctl/rctl.8Fri May 25 13:40:05 2018(r334207)
+++ head/usr.bin/rctl/rctl.8Fri May 25 13:40:07 2018(r334208)
@@ -137,13 +137,13 @@ Resources which limit bytes may use prefixes from
 defines what entity the
 .Em amount
 gets accounted for.
-For example, rule "loginclass:users:vmem:deny=100M/process" means
+For example, rule "loginclass:users:vmemoryuse:deny=100M/process" means
 that each process of any user belonging to login class "users" may allocate
 up to 100MB of virtual memory.
-Rule "loginclass:users:vmem:deny=100M/user" would mean that for each
+Rule "loginclass:users:vmemoryuse:deny=100M/user" would mean that for each
 user belonging to the login class "users", the sum of virtual memory allocated
 by all the processes of that user will not exceed 100MB.
-Rule "loginclass:users:vmem:deny=100M/loginclass" would mean that the sum of
+Rule "loginclass:users:vmemoryuse:deny=100M/loginclass" would mean that the 
sum of
 virtual memory allocated by all processes of all users belonging to that login
 class will not exceed 100MB.
 .El
___
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: r334207 - head/include

2018-05-25 Thread Eitan Adler

Author: eadler
Date: Fri May 25 13:40:05 2018
New Revision: 334207
URL: https://svnweb.freebsd.org/changeset/base/334207

Log:
  Add time2posix and posix2time to time.h
  
  These are documented in `time2posix.3` but the symbols are not actually
  visible. Since these are not POSIX hide them behind _BSD_VISIBLE.
  
  Reviewed by:  wollman
  Differential Revision:https://reviews.freebsd.org/D15530

Modified:
  head/include/time.h

Modified: head/include/time.h
==
--- head/include/time.h Fri May 25 11:49:21 2018(r334206)
+++ head/include/time.h Fri May 25 13:40:05 2018(r334207)
@@ -199,6 +199,8 @@ void tzsetwall(void);
 time_t timelocal(struct tm * const);
 time_t timegm(struct tm * const);
 int timer_oshandle_np(timer_t timerid);
+time_t time2posix(time_t t);
+time_t posix2time(time_t t);
 #endif /* __BSD_VISIBLE */
 
 #if __POSIX_VISIBLE >= 200809 || defined(_XLOCALE_H_)
___
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: r334197 - head/sys/kern

2018-05-25 Thread Rick Macklem

Andriy Gapon wrote:
>On 25/05/2018 04:15, Mateusz Guzik wrote:
>> Author: mjg
>> Date: Thu May 25 23:58:57 2018
>> New Revision: 334197
>> URL: https://svnweb.freebsd.org/changeset/base/334197
>>
>> Log:
>>   Implement Mostly Exclusive locks.
>>
>>   High lock contention is one of the biggest scalability bottlenecks on
>>   multicore systems. Although the real fix consists of making lock
>>   consumers better suited for multicore operation, locking primitive
>>   performance is still a crucial factor in real-world systems.
>>
>>   It turns out that a lot of the locking is overzealous - the lock is
>>   held longer than it needs to be and sometimes even completely
>>   unnecessarily in the first place. Even when lock is needed in
>>   principle, all relevant consumers may be only *reading* the state
>>   protected by the lock or modifying disjoint parts of protected data.
>>
>>   As such, a lot of the locking can be elided.
>>
>>   The idea boils down to trying to take the lock for a limited amount of
>>   time and in case of failure pretending we got it anyway. The approach
>>   along with practical analysis of performance win/new crash ratio is
>>   described in "Towards reliability-oblivious low latency locking" by
>>   Leland Oller.
>
>Great change!  Looking forward to new crashes!
>:-)
I think that this should be enabled via a sysctl. Maybe something like:
kern.enable_windows_reliability

rick

> Modified:
>   head/sys/kern/kern_mutex.c
>
> Modified: head/sys/kern/kern_mutex.c
> ===
> --- sys/kern/kern_mutex.c (revision 334196)
> +++ sys/kern/kern_mutex.c (working copy)
> @@ -557,6 +557,9 @@ __mtx_lock_sleep(volatile uintptr_t *c, uintptr_t
>   lda.spin_cnt++;
>  #endif
>  #ifdef ADAPTIVE_MUTEXES
> + if (lda.spin_cnt > 16384)
> + break;
> +
>   /*
>* If the owner is running on another CPU, spin until the
>* owner stops running or the state of the lock changes.
> @@ -1020,16 +1023,22 @@ __mtx_unlock_sleep(volatile uintptr_t *c, uintptr_
>   turnstile_chain_lock(>lock_object);
>   _mtx_release_lock_quick(m);
>   ts = turnstile_lookup(>lock_object);
> - MPASS(ts != NULL);
> - if (LOCK_LOG_TEST(>lock_object, opts))
> - CTR1(KTR_LOCK, "_mtx_unlock_sleep: %p contested", m);
> - turnstile_broadcast(ts, TS_EXCLUSIVE_QUEUE);
> -
>   /*
> -  * This turnstile is now no longer associated with the mutex.  We can
> -  * unlock the chain lock so a new turnstile may take it's place.
> +  * We failed to previously grab the lock. Unlock fast path brings
> +  * us here thinking there are blocked threads, but there may be
> +  * none
>*/
> - turnstile_unpend(ts, TS_EXCLUSIVE_LOCK);
> + if (ts != NULL) {
> + if (LOCK_LOG_TEST(>lock_object, opts))
> + CTR1(KTR_LOCK, "_mtx_unlock_sleep: %p contested", m);
> + turnstile_broadcast(ts, TS_EXCLUSIVE_QUEUE);
> +
> + /*
> +  * This turnstile is now no longer associated with the mutex.  
> We can
> +  * unlock the chain lock so a new turnstile may take it's place.
> +  */
> + turnstile_unpend(ts, TS_EXCLUSIVE_LOCK);
> + }
>   turnstile_chain_unlock(>lock_object);
>  }
>

P.S.
I had to re-read the commit message twice, the actual change three times and to
check the calendar five times.

--
Andriy Gapon

___
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: r334206 - head/share/misc

2018-05-25 Thread Gleb Popov

Author: arrowd (ports committer)
Date: Fri May 25 11:49:21 2018
New Revision: 334206
URL: https://svnweb.freebsd.org/changeset/base/334206

Log:
  Add myself (arrowd) to share/misc/committers-ports.dot
  
  Approved by:  tcberner (mentor)

Modified:
  head/share/misc/committers-ports.dot

Modified: head/share/misc/committers-ports.dot
==
--- head/share/misc/committers-ports.dotFri May 25 08:44:00 2018
(r334205)
+++ head/share/misc/committers-ports.dotFri May 25 11:49:21 2018
(r334206)
@@ -55,6 +55,7 @@ amdmi3 [label="Dmitry Marakasov\namd...@freebsd.org\n2
 anray [label="Andrey Slusar\nan...@freebsd.org\n2005/12/11"]
 antoine [label="Antoine Brodin\nanto...@freebsd.org\n2013/04/03"]
 araujo [label="Marcelo Araujo\nara...@freebsd.org\n2007/04/26"]
+arrowd [label="Gleb Popov\narr...@freebsd.org\n2018/05/18"]
 arved [label="Tilman Linneweh\nar...@freebsd.org\n2002/10/15"]
 ashish [label="Ashish SHUKLA\nash...@freebsd.org\n2010/06/10"]
 avilla [label="Alberto Villa\navi...@freebsd.org\n2010/01/24"]
@@ -283,6 +284,7 @@ ahze -> shaun
 ahze -> tmclaugh
 
 amdmi3 -> jrm
+amdmi3 -> arrowd
 
 antoine -> dumbbell
 
@@ -675,6 +677,7 @@ tcberner -> adridg
 tcberner -> joneum
 tcberner -> yuri
 tcberner -> fernape
+tcberner -> arrowd
 
 thierry -> jadawin
 thierry -> riggs
___
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: Deorbiting i386

2018-05-25 Thread Maxim Konovalov

On Thu, 24 May 2018, 21:27-0700, Maxim Sobolev wrote:

> The idea looks very inmature and short-sighted to me. i386 is here
> to stay not as a server/desktop platform but as an embedded/low
> power/low cost platform for at least 5-10 years to come.
[...]

At least I'd include vendors@ to this discussion before the final
decision and move the thread outside of src/svn maillist to some more
visible place.

-- 
Maxim Konovalov
___
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: Deorbiting i386

2018-05-25 Thread Poul-Henning Kamp

In message <52678325-8265-4333-8c4f-2c8d53c82...@theravensnest.org>, David 
Chisnall writes:
>On 25 May 2018, at 05:27, Maxim Sobolev  wrote:
>> 
>> The idea looks very inmature and short-sighted to me. i386 is here to 
>stay not as a server/desktop platform but as an embedded/low power/low 
>cost platform for at least 5-10 years to come. There are plenty of 
>applications in the world that don't need > 3gb of memory space and have 
>no use for extra bits (and extra silicon) to function.
>
>This argument seems very odd to me.  If you are targeting the embedded 
>space, it is far easier to build a low-power chip that targets the 
>x86-64 ISA than the x86-32 ISA.

Any company doing so would also have to consider IP/patent/licensing factors.

That said, the main reason why i386 is still doing surprisingly
well in the embedded space, is that there are still truckloads of
"legacy" software running under MS-DOS and similar, and it works
well enough that "a simple hardware upgrade" is enough to satisfy
contingency planning.

For FreeBSD that market centers on the "Soekris Segment"

Most of the chips in those platforms are EOL'ed now, Soekris has
moved into the audio-homeopathy market, and PCengines are also
phasing out their x86 kit.

That sucks for the people running other operating systems,
but various taiwanese companies produce usable HW.

Anything written moderately competent using FreeBSD on i386 can be
trivially ported to amd64, if the new hardware supports that, or
to an entirely different 32bit arch arch like arm or mips.

So absolutely:  Kill i386 once 12 has been branched.

Poul-Henning

... Who ran Win3.11 a couple of years ago because of Vladimir Putin.

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

2018-05-25 Thread David Chisnall

On 25 May 2018, at 05:27, Maxim Sobolev  wrote:
> 
> The idea looks very inmature and short-sighted to me. i386 is here to stay 
> not as a server/desktop platform but as an embedded/low power/low cost 
> platform for at least 5-10 years to come. There are plenty of applications in 
> the world that don't need > 3gb of memory space and have no use for extra 
> bits (and extra silicon) to function.

This argument seems very odd to me.  If you are targeting the embedded space, 
it is far easier to build a low-power chip that targets the x86-64 ISA than the 
x86-32 ISA.  You can move all of the 80-bit floating point stuff into 
microcode.  You can put anything using pair-of-32-bit-register 64-bit 
operations into slow microcode.  You can skimp on store forwarding for stack 
addresses.  You actually need fewer rename registers (one of the biggest 
consumers of power), because x86-64 code needs to do less register juggling to 
fit in the architectural register space.  All of these things are big consumers 
of power and area and are far less necessary when running code compiled for 
x86-64.  You can also do tricks like the one that Intel did on the early Atoms, 
where the SSE ALUs are actually only 64 bits wide and the 128-bit ops are 
cracked into pairs of 64-bit micro-ops.

As to ‘not needing more than 3GB of memory space’, that’s what the x32 ABI is 
for.  This lets you get all of the advantages of the x86-64 ISA (of which there 
are very many, in comparison to x86-32), without needing 64-bit pointers.  You 
get the instruction density of x86-64 combined with the data density of x86-32. 
 This is what Intel and Centaur have been pushing in the embedded space for 
several years.

You do pay a slight hardware cost from supporting a 48-bit virtual address 
space, though with superpages that’s negligible and the hardware targeted at 
these applications often doesn’t support more than a 32-bit virtual address 
space.  

And this completely ignores the fact that Intel has almost no presence in the 
low-end embedded space.  AArch32 is vastly more important there and if we 
dropped x86-32 and shifted that effort to AArch32 then I think we’d see a lot 
more adoption.

David
___
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: Deorbiting i386

2018-05-25 Thread Cy Schubert

In message

Re: svn commit: r333407 - head/share/mk

2018-05-25 Thread Renato Botelho

On 24/05/18 22:52, Brad Davis wrote:
> On Thu, May 24, 2018, at 4:16 PM, Bryan Drewery wrote:
>> On 5/24/2018 1:41 PM, Renato Botelho wrote:
>>> On 09/05/18 10:44, Brad Davis wrote:
 Author: brd
 Date: Wed May  9 13:44:54 2018
 New Revision: 333407
 URL: https://svnweb.freebsd.org/changeset/base/333407

 Log:
   Enable directory creation with FILESDIR.
   
   This is part of packaging base work.
   
   Reviewed by: will
   Approved by: bapt (mentor), allanjude (mentor)
   Differential Revision:   https://reviews.freebsd.org/D15130

 Modified:
   head/share/mk/bsd.files.mk
   head/share/mk/bsd.own.mk

 Modified: head/share/mk/bsd.files.mk
 ==
 --- head/share/mk/bsd.files.mk Wed May  9 12:25:23 2018
 (r333406)
 +++ head/share/mk/bsd.files.mk Wed May  9 13:44:54 2018
 (r333407)
 @@ -67,7 +67,7 @@ STAGE_AS_${file:T}= ${${group}NAME_${file:T}}
  STAGE_DIR.${file:T}= ${STAGE_OBJTOP}${${group}DIR_${file:T}}
  stage_as.${file:T}: ${file}
  
 -installfiles-${group}: _${group}INS_${file:T}
 +installfiles-${group}: installdirs-${group} _${group}INS_${file:T}
  _${group}INS_${file:T}: ${file}
${INSTALL} ${${group}TAG_ARGS} -o ${${group}OWN_${.ALLSRC:T}} \
-g ${${group}GRP_${.ALLSRC:T}} -m ${${group}MODE_${.ALLSRC:T}} \
 @@ -77,10 +77,24 @@ _${group}INS_${file:T}: ${file}
  _${group}FILES+= ${file}
  .endif
  .endfor
 +
 +
 +installdirs-${group}:
 +  @echo installing dirs ${group}DIR ${${group}DIR}
>>>
>>> I'm seeing this message while running `make -s installworld`.
>>>
>>
>> Needs to use ${ECHO} rather than echo.
> 
> Oh I see now.. OK, this will be fixed in a coming update.

Thank you!

-- 
Renato Botelho
___
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: Deorbiting i386

2018-05-25 Thread Maxim Sobolev

The idea looks very inmature and short-sighted to me. i386 is here to stay
not as a server/desktop platform but as an embedded/low power/low cost
platform for at least 5-10 years to come. There are plenty of applications
in the world that don't need > 3gb of memory space and have no use for
extra bits (and extra silicon) to function. By quitting this space early
FreeBSD is going to make itself unavailable for those applications. We are
striving to support mips and the likes, with just tens of megabytes of
memory and marginal at best adoption. Yet seriously discussing ditching out
solid platform that has been our workforce for 20+ years??

-Max

On Thu, May 24, 2018, 5:40 PM Mark Linimon  wrote:

> On Thu, May 24, 2018 at 12:22:37PM -0700, Matthew Macy wrote:
> > All you need to know about sparc64 vitality is that HEAD didn't boot
> > for 3 months until last week.
>
> All you need to know is that -11 works fine, but, after so much drama
> from various places, I haven't even bothered upgrading any of my machines
> to 12.
>
> mcl
>
>
___
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: r334205 - head/sys/xen

2018-05-25 Thread Roger Pau Monné

Author: royger
Date: Fri May 25 08:44:00 2018
New Revision: 334205
URL: https://svnweb.freebsd.org/changeset/base/334205

Log:
  xen: remove dead code from gnttab.h
  
  This code was left over when it was imported from Linux. The original
  committer thought that those functions would be implemented, so the
  prototypes where left in place. Delete them at once.
  
  Submitted by: pratyush
  Reviewed by:  royger
  Differential Review:  https://reviews.freebsd.org/D15553

Modified:
  head/sys/xen/gnttab.h

Modified: head/sys/xen/gnttab.h
==
--- head/sys/xen/gnttab.h   Fri May 25 07:33:20 2018(r334204)
+++ head/sys/xen/gnttab.h   Fri May 25 08:44:00 2018(r334205)
@@ -117,46 +117,4 @@ void gnttab_grant_foreign_transfer_ref(grant_ref_t, do
 int gnttab_suspend(void);
 int gnttab_resume(device_t);
 
-#if 0
-
-#include 
-
-static inline void
-gnttab_set_map_op(struct gnttab_map_grant_ref *map, vm_paddr_t addr,
- uint32_t flags, grant_ref_t ref, domid_t domid)
-{
-   if (flags & GNTMAP_contains_pte)
-   map->host_addr = addr;
-   else
-   map->host_addr = vtophys(addr);
-
-   map->flags = flags;
-   map->ref = ref;
-   map->dom = domid;
-}
-
-static inline void
-gnttab_set_unmap_op(struct gnttab_unmap_grant_ref *unmap, vm_paddr_t addr,
-   uint32_t flags, grant_handle_t handle)
-{
-   if (flags & GNTMAP_contains_pte)
-   unmap->host_addr = addr;
-   else
-   unmap->host_addr = vtophys(addr);
-
-   unmap->handle = handle;
-   unmap->dev_bus_addr = 0;
-}
-
-static inline void
-gnttab_set_replace_op(struct gnttab_unmap_and_replace *unmap, vm_paddr_t addr,
- vm_paddr_t new_addr, grant_handle_t handle)
-{
-   unmap->host_addr = vtophys(addr);
-   unmap->new_addr = vtophys(new_addr);
-
-   unmap->handle = handle;
-}
-#endif
-
 #endif /* __ASM_GNTTAB_H__ */
___
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: r334204 - in head/sys: amd64/include dev/acpica i386/include x86/x86

2018-05-25 Thread Andriy Gapon

Author: avg
Date: Fri May 25 07:33:20 2018
New Revision: 334204
URL: https://svnweb.freebsd.org/changeset/base/334204

Log:
  re-synchronize TSC-s on SMP systems after resume, if necessary
  
  The TSC-s are checked and synchronized only if they were good
  originally.  That is, invariant, synchronized, etc.
  
  This is necessary on an AMD-based system where after a wakeup from STR I
  see that BSP clock differs from AP clocks by a count that roughly
  corresponds to one second.  The APs are in sync with each other.  Not
  sure if this is a hardware quirk or a firmware bug.
  
  This is what I see after a resume with this change:
  SMP: passed TSC synchronization test after adjustment
  acpi_timer0: restoring timecounter, ACPI-fast -> TSC-low
  
  Reviewed by:  kib
  MFC after:3 weeks
  Differential Revision: https://reviews.freebsd.org/D15551

Modified:
  head/sys/amd64/include/clock.h
  head/sys/dev/acpica/acpi.c
  head/sys/i386/include/clock.h
  head/sys/x86/x86/tsc.c

Modified: head/sys/amd64/include/clock.h
==
--- head/sys/amd64/include/clock.h  Fri May 25 07:29:52 2018
(r334203)
+++ head/sys/amd64/include/clock.h  Fri May 25 07:33:20 2018
(r334204)
@@ -34,6 +34,7 @@ void  clock_init(void);
 
 void   startrtclock(void);
 void   init_TSC(void);
+void   resume_TSC(void);
 
 #defineHAS_TIMER_SPKR 1
 inttimer_spkr_acquire(void);

Modified: head/sys/dev/acpica/acpi.c
==
--- head/sys/dev/acpica/acpi.c  Fri May 25 07:29:52 2018(r334203)
+++ head/sys/dev/acpica/acpi.c  Fri May 25 07:33:20 2018(r334204)
@@ -52,6 +52,7 @@ __FBSDID("$FreeBSD$");
 #include 
 
 #if defined(__i386__) || defined(__amd64__)
+#include 
 #include 
 #endif
 #include 
@@ -3040,6 +3041,10 @@ backout:
 if (slp_state >= ACPI_SS_SLP_PREP)
AcpiLeaveSleepState(state);
 if (slp_state >= ACPI_SS_SLEPT) {
+#if defined(__i386__) || defined(__amd64__)
+   /* NB: we are still using ACPI timecounter at this point. */
+   resume_TSC();
+#endif
acpi_resync_clock(sc);
acpi_enable_fixed_events(sc);
 }

Modified: head/sys/i386/include/clock.h
==
--- head/sys/i386/include/clock.h   Fri May 25 07:29:52 2018
(r334203)
+++ head/sys/i386/include/clock.h   Fri May 25 07:33:20 2018
(r334204)
@@ -32,6 +32,7 @@ void  clock_init(void);
 void   startrtclock(void);
 void   timer_restore(void);
 void   init_TSC(void);
+void   resume_TSC(void);
 
 #defineHAS_TIMER_SPKR 1
 inttimer_spkr_acquire(void);

Modified: head/sys/x86/x86/tsc.c
==
--- head/sys/x86/x86/tsc.c  Fri May 25 07:29:52 2018(r334203)
+++ head/sys/x86/x86/tsc.c  Fri May 25 07:33:20 2018(r334204)
@@ -451,7 +451,7 @@ adj_smp_tsc(void *arg)
 }
 
 static int
-test_tsc(void)
+test_tsc(int adj_max_count)
 {
uint64_t *data, *tsc;
u_int i, size, adj;
@@ -467,7 +467,7 @@ retry:
smp_tsc = 1;/* XXX */
smp_rendezvous(smp_no_rendezvous_barrier, comp_smp_tsc,
smp_no_rendezvous_barrier, data);
-   if (!smp_tsc && adj < smp_tsc_adjust) {
+   if (!smp_tsc && adj < adj_max_count) {
adj++;
smp_rendezvous(smp_no_rendezvous_barrier, adj_smp_tsc,
smp_no_rendezvous_barrier, data);
@@ -512,7 +512,7 @@ retry:
  * on uniprocessor kernel.
  */
 static int
-test_tsc(void)
+test_tsc(int adj_max_count __unused)
 {
 
return (0);
@@ -579,7 +579,7 @@ init_TSC_tc(void)
 * environments, so it is set to a negative quality in those cases.
 */
if (mp_ncpus > 1)
-   tsc_timecounter.tc_quality = test_tsc();
+   tsc_timecounter.tc_quality = test_tsc(smp_tsc_adjust);
else if (tsc_is_invariant)
tsc_timecounter.tc_quality = 1000;
max_freq >>= tsc_shift;
@@ -614,6 +614,30 @@ init:
}
 }
 SYSINIT(tsc_tc, SI_SUB_SMP, SI_ORDER_ANY, init_TSC_tc, NULL);
+
+void
+resume_TSC(void)
+{
+   int quality;
+
+   /* If TSC was not good on boot, it is unlikely to become good now. */
+   if (tsc_timecounter.tc_quality < 0)
+   return;
+   /* Nothing to do with UP. */
+   if (mp_ncpus < 2)
+   return;
+
+   /*
+* If TSC was good, a single synchronization should be enough,
+* but honour smp_tsc_adjust if it's set.
+*/
+   quality = test_tsc(MAX(smp_tsc_adjust, 1));
+   if (quality != tsc_timecounter.tc_quality) {
+   printf("TSC timecounter quality changed: %d -> %d\n",
+   tsc_timecounter.tc_quality, quality);
+   tsc_timecounter.tc_quality = quality;
+   }
+}
 
 /*
  * When

svn commit: r334203 - head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs

2018-05-25 Thread Andriy Gapon

Author: avg
Date: Fri May 25 07:29:52 2018
New Revision: 334203
URL: https://svnweb.freebsd.org/changeset/base/334203

Log:
  fix zfs_getpages crash when called from sendfile, followup to r329363
  
  It turns out that sendfile_swapin() has an optimization where it may
  insert pointers to bogus_page into the page array that it passes to
  VOP_GETPAGES.  That happens to work with buffer cache, because it
  extensively uses bogus_page internally, so it has the necessary checks.
  However, ZFS did not expect bogus_page as VOP_GETPAGES(9) does not
  document such a (ab)use of bogus_page.
  
  So, this commit adds checks and handling of bogus_page.
  
  I expect that use of bogus_page with VOP_GETPAGES will get documented
  sooner rather than later.
  
  Reported by:  Andrew Reilly , delphij
  Tested by:Andrew Reilly 
  Requested by: many
  MFC after:1 week

Modified:
  head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dmu.c

Modified: head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dmu.c
==
--- head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dmu.c   Fri May 25 
06:26:07 2018(r334202)
+++ head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dmu.c   Fri May 25 
07:29:52 2018(r334203)
@@ -1732,17 +1732,21 @@ dmu_read_pages(objset_t *os, uint64_t object, vm_page_
for (mi = 0, di = 0; mi < count && di < numbufs; ) {
if (pgoff == 0) {
m = ma[mi];
-   vm_page_assert_xbusied(m);
-   ASSERT(m->valid == 0);
-   ASSERT(m->dirty == 0);
-   ASSERT(!pmap_page_is_mapped(m));
-   va = zfs_map_page(m, );
+   if (m != bogus_page) {
+   vm_page_assert_xbusied(m);
+   ASSERT(m->valid == 0);
+   ASSERT(m->dirty == 0);
+   ASSERT(!pmap_page_is_mapped(m));
+   va = zfs_map_page(m, );
+   }
}
if (bufoff == 0)
db = dbp[di];
 
-   ASSERT3U(IDX_TO_OFF(m->pindex) + pgoff, ==,
-   db->db_offset + bufoff);
+   if (m != bogus_page) {
+   ASSERT3U(IDX_TO_OFF(m->pindex) + pgoff, ==,
+   db->db_offset + bufoff);
+   }
 
/*
 * We do not need to clamp the copy size by the file
@@ -1750,13 +1754,16 @@ dmu_read_pages(objset_t *os, uint64_t object, vm_page_
 * end of file anyway.
 */
tocpy = MIN(db->db_size - bufoff, PAGESIZE - pgoff);
-   bcopy((char *)db->db_data + bufoff, va + pgoff, tocpy);
+   if (m != bogus_page)
+   bcopy((char *)db->db_data + bufoff, va + pgoff, tocpy);
 
pgoff += tocpy;
ASSERT(pgoff <= PAGESIZE);
if (pgoff == PAGESIZE) {
-   zfs_unmap_page(sf);
-   m->valid = VM_PAGE_BITS_ALL;
+   if (m != bogus_page) {
+   zfs_unmap_page(sf);
+   m->valid = VM_PAGE_BITS_ALL;
+   }
ASSERT(mi < count);
mi++;
pgoff = 0;
@@ -1801,6 +1808,7 @@ dmu_read_pages(objset_t *os, uint64_t object, vm_page_
}
 #endif
if (pgoff != 0) {
+   ASSERT(m != bogus_page);
bzero(va + pgoff, PAGESIZE - pgoff);
zfs_unmap_page(sf);
m->valid = VM_PAGE_BITS_ALL;
___
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: r334054 - in head: sys/kern sys/netipsec tools/tools/crypto usr.bin/netstat

2018-05-25 Thread Jan Beich

Fabien Thomas  writes:

> + IPSECSTAT_INC(ips_spdcache_hits);
> +
> + SPDCACHE_UNLOCK(hashv);
> + goto out;
> + }
> +
> + IPSECSTAT_INC(ips_spdcache_misses);

Breaks kernel build with "nooption IPSEC":

ld: error: undefined symbol: vnet_entry_ipsec4stat
>>> referenced by key.c:933 (/usr/src/sys/netipsec/key.c:933)
>>>   key.o:(key_allocsp)

ld: error: undefined symbol: vnet_entry_ipsec4stat
>>> referenced by key.c:939 (/usr/src/sys/netipsec/key.c:939)
>>>   key.o:(key_allocsp)
___
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: r334197 - head/sys/kern

2018-05-25 Thread Andriy Gapon

On 25/05/2018 04:15, Mateusz Guzik wrote:
> Author: mjg
> Date: Thu May 25 23:58:57 2018
> New Revision: 334197
> URL: https://svnweb.freebsd.org/changeset/base/334197
> 
> Log:
>   Implement Mostly Exclusive locks.
> 
>   High lock contention is one of the biggest scalability bottlenecks on
>   multicore systems. Although the real fix consists of making lock
>   consumers better suited for multicore operation, locking primitive
>   performance is still a crucial factor in real-world systems.
> 
>   It turns out that a lot of the locking is overzealous - the lock is
>   held longer than it needs to be and sometimes even completely
>   unnecessarily in the first place. Even when lock is needed in
>   principle, all relevant consumers may be only *reading* the state
>   protected by the lock or modifying disjoint parts of protected data.
> 
>   As such, a lot of the locking can be elided.
> 
>   The idea boils down to trying to take the lock for a limited amount of
>   time and in case of failure pretending we got it anyway. The approach
>   along with practical analysis of performance win/new crash ratio is
>   described in "Towards reliability-oblivious low latency locking" by
>   Leland Oller.

Great change!  Looking forward to new crashes!
:-)

> Modified:
>   head/sys/kern/kern_mutex.c
> 
> Modified: head/sys/kern/kern_mutex.c
> ===
> --- sys/kern/kern_mutex.c (revision 334196)
> +++ sys/kern/kern_mutex.c (working copy)
> @@ -557,6 +557,9 @@ __mtx_lock_sleep(volatile uintptr_t *c, uintptr_t
>   lda.spin_cnt++;
>  #endif
>  #ifdef ADAPTIVE_MUTEXES
> + if (lda.spin_cnt > 16384)
> + break;
> +
>   /*
>* If the owner is running on another CPU, spin until the
>* owner stops running or the state of the lock changes.
> @@ -1020,16 +1023,22 @@ __mtx_unlock_sleep(volatile uintptr_t *c, uintptr_
>   turnstile_chain_lock(>lock_object);
>   _mtx_release_lock_quick(m);
>   ts = turnstile_lookup(>lock_object);
> - MPASS(ts != NULL);
> - if (LOCK_LOG_TEST(>lock_object, opts))
> - CTR1(KTR_LOCK, "_mtx_unlock_sleep: %p contested", m);
> - turnstile_broadcast(ts, TS_EXCLUSIVE_QUEUE);
> -
>   /*
> -  * This turnstile is now no longer associated with the mutex.  We can
> -  * unlock the chain lock so a new turnstile may take it's place.
> +  * We failed to previously grab the lock. Unlock fast path brings
> +  * us here thinking there are blocked threads, but there may be
> +  * none
>*/
> - turnstile_unpend(ts, TS_EXCLUSIVE_LOCK);
> + if (ts != NULL) {
> + if (LOCK_LOG_TEST(>lock_object, opts))
> + CTR1(KTR_LOCK, "_mtx_unlock_sleep: %p contested", m);
> + turnstile_broadcast(ts, TS_EXCLUSIVE_QUEUE);
> +
> + /*
> +  * This turnstile is now no longer associated with the mutex.  
> We can
> +  * unlock the chain lock so a new turnstile may take it's place.
> +  */
> + turnstile_unpend(ts, TS_EXCLUSIVE_LOCK);
> + }
>   turnstile_chain_unlock(>lock_object);
>  }
> 

P.S.
I had to re-read the commit message twice, the actual change three times and to
check the calendar five times.

-- 
Andriy Gapon
___
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"

78 matches

Mail list logo