date:20171115

Re: svn commit: r325825 - head/sys/kern

2017-11-15 Thread Bruce Evans


On Tue, 14 Nov 2017, Ed Maste wrote:


Log:
 disallow clock_settime too far in the future to avoid panic

 clock_ts_to_ct has a KASSERT that the converted year fits into four
 digits.  By default (sysctl debug.allow_insane_settime is 0) the kernel
 disallows a time too far in the future, using a value of  366-day
 years.  However, clock_settime is epoch-relative and the assertion will
 fail with a tv_sec corresponding to some 8030 years.

 Avoid trying to be too clever, and just use a limit of 8000 365-day
 years past the epoch.

 Submitted by:  Heqing Yan 
 Reported by:   Syzkaller (https://github.com/google/syzkaller)
 MFC after: 1 week
 Sponsored by:  The FreeBSD Foundation


I reported this panic and several others in reply to previous attempted fixes.


Modified: head/sys/kern/kern_time.c
==
--- head/sys/kern/kern_time.c   Tue Nov 14 18:17:23 2017(r325824)
+++ head/sys/kern/kern_time.c   Tue Nov 14 18:18:18 2017(r325825)
@@ -408,7 +408,7 @@ kern_clock_settime(struct thread *td, clockid_t clock_
if (ats->tv_nsec < 0 || ats->tv_nsec >= 10 ||
ats->tv_sec < 0)
return (EINVAL);
-   if (!allow_insane_settime && ats->tv_sec > ULL * 366 * 24 * 60 * 60)
+   if (!allow_insane_settime && ats->tv_sec > 8000ULL * 365 * 24 * 60 * 60)
return (EINVAL);
/* XXX Don't convert nsec->usec and back */
TIMESPEC_TO_TIMEVAL(&atv, ats);


Panics still occur when year 10K is reached via:

tv_sec = 8000ULL * 365 * 24 * 60 * 60 - 1 (approx. 7994.5 years)
POSIX Epoch offset = 1970 years
utc_offset() <= (approx. 7994.5 + 1970) - 10 = approx. -36.5 years
(utc_offset() in seconds is the combined timezone offset
  60 * tz.tz_minuteswest + (wall_cmos_clock ? adjkerntz : 0).)

A utc_offset() of -36.5 years is preposterous but easy to reach without
overflow (utc_offset() has blind overflow at approx. +-69 years).

For 32-bit time_t, both of the above abominable ULL checks are vacuously
false, but panics still occurs for all widths of time_t with non-
preposterous values near the Epoch:

tv_sec = 0  (Epoch in UTC)
utc_offset() = 10 * 60  (garbage or panic in RTC; should be 1969)

Wthout INVARIANTS, this writes the RTC with the garbage time 70/01/01
00:5c:05, where at least the 5c is from a buffer overrun.  With
INVARIANTS, garbage produced by clock_tv_to_ct() is detected there.

   tv_sec = INT_MAX (2038 in UTC)
   utc_offset() = -1(garbage or panic in RTC; should be EINVAL)

This takes 32-bit time_t.  Then tv_sec - utc_offset() blindly overflows
to INT_MIN on supported arches.  The resulting garbage or panic in the
RTC is not much worse than for any other negative value of
tv_sec - utc_offset().

The settime() level doesn't know about utc_offset() (except for the
historical mistake of setting the timezone using settimeofday()), and
this is correct.  Only the RTC level uses utc_offset() (or the timezone).
The correct error handling is to not KASSERT() anything, but avoid overflow
and just don't continue after overflow or set the RTC to a preposterous
or unportable value.

Bruce
___
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: r325841 - in head/sys: conf dev/mlx4 dev/mlx4/mlx4_core dev/mlx4/mlx4_en dev/mlx4/mlx4_ib modules/mlx4

2017-11-15 Thread Hans Petter Selasky

Author: hselasky
Date: Wed Nov 15 11:14:39 2017
New Revision: 325841
URL: https://svnweb.freebsd.org/changeset/base/325841

Log:
  Update the mlx4 core and mlx4en(4) modules towards Linux v4.9.
  
  Background:
  The coming ibcore update forces an update of mlx4ib(4) which in turn requires
  an updated mlx4 core module. This also affects the mlx4en(4) module because
  commonly used APIs are updated. This commit is a middle step updating the
  mlx4 modules towards the new ibcore.
  
  This change contains no major new features.
  
  Changes in mlx4:
a) Improved error handling when mlx4 PCI devices are
detached inside VMs.
b) Major update of codebase towards Linux 4.9.
  
  Changes in mlx4ib(4):
a) Minimal changes needed in order to compile using the
updated mlx4 core APIs.
  
  Changes in mlx4en(4):
a) Update flow steering code in mlx4en to use new APIs for
registering MAC addresses and IP addresses.
b) Update all statistics counters to be 64-bit.
c) Minimal changes needed in order to compile using the
updated mlx4 core APIs.
  
  Sponsored by: Mellanox Technologies
  MFC after:1 week

Added:
  head/sys/dev/mlx4/mlx4_core/fw_qos.h   (contents, props changed)
  head/sys/dev/mlx4/mlx4_core/mlx4_fw_qos.c   (contents, props changed)
Deleted:
  head/sys/dev/mlx4/mlx4_core/mlx4_sys_tune.c
Modified:
  head/sys/conf/files
  head/sys/dev/mlx4/cmd.h
  head/sys/dev/mlx4/cq.h
  head/sys/dev/mlx4/device.h
  head/sys/dev/mlx4/driver.h
  head/sys/dev/mlx4/mlx4_core/fw.h
  head/sys/dev/mlx4/mlx4_core/icm.h
  head/sys/dev/mlx4/mlx4_core/mlx4.h
  head/sys/dev/mlx4/mlx4_core/mlx4_alloc.c
  head/sys/dev/mlx4/mlx4_core/mlx4_catas.c
  head/sys/dev/mlx4/mlx4_core/mlx4_cmd.c
  head/sys/dev/mlx4/mlx4_core/mlx4_cq.c
  head/sys/dev/mlx4/mlx4_core/mlx4_eq.c
  head/sys/dev/mlx4/mlx4_core/mlx4_fw.c
  head/sys/dev/mlx4/mlx4_core/mlx4_icm.c
  head/sys/dev/mlx4/mlx4_core/mlx4_intf.c
  head/sys/dev/mlx4/mlx4_core/mlx4_main.c
  head/sys/dev/mlx4/mlx4_core/mlx4_mcg.c
  head/sys/dev/mlx4/mlx4_core/mlx4_mr.c
  head/sys/dev/mlx4/mlx4_core/mlx4_pd.c
  head/sys/dev/mlx4/mlx4_core/mlx4_port.c
  head/sys/dev/mlx4/mlx4_core/mlx4_profile.c
  head/sys/dev/mlx4/mlx4_core/mlx4_qp.c
  head/sys/dev/mlx4/mlx4_core/mlx4_reset.c
  head/sys/dev/mlx4/mlx4_core/mlx4_resource_tracker.c
  head/sys/dev/mlx4/mlx4_core/mlx4_sense.c
  head/sys/dev/mlx4/mlx4_core/mlx4_srq.c
  head/sys/dev/mlx4/mlx4_en/en.h
  head/sys/dev/mlx4/mlx4_en/en_port.h
  head/sys/dev/mlx4/mlx4_en/mlx4_en_cq.c
  head/sys/dev/mlx4/mlx4_en/mlx4_en_main.c
  head/sys/dev/mlx4/mlx4_en/mlx4_en_netdev.c
  head/sys/dev/mlx4/mlx4_en/mlx4_en_port.c
  head/sys/dev/mlx4/mlx4_en/mlx4_en_resources.c
  head/sys/dev/mlx4/mlx4_en/mlx4_en_rx.c
  head/sys/dev/mlx4/mlx4_en/mlx4_en_tx.c
  head/sys/dev/mlx4/mlx4_ib/mlx4_ib.h
  head/sys/dev/mlx4/mlx4_ib/mlx4_ib_cq.c
  head/sys/dev/mlx4/mlx4_ib/mlx4_ib_mad.c
  head/sys/dev/mlx4/mlx4_ib/mlx4_ib_main.c
  head/sys/dev/mlx4/mlx4_ib/mlx4_ib_mr.c
  head/sys/dev/mlx4/mlx4_ib/mlx4_ib_qp.c
  head/sys/dev/mlx4/mlx4_ib/mlx4_ib_srq.c
  head/sys/dev/mlx4/mlx4_ib/mlx4_ib_sysfs.c
  head/sys/dev/mlx4/qp.h
  head/sys/dev/mlx4/stats.h
  head/sys/modules/mlx4/Makefile

Modified: head/sys/conf/files
==
--- head/sys/conf/files Wed Nov 15 06:45:33 2017(r325840)
+++ head/sys/conf/files Wed Nov 15 11:14:39 2017(r325841)
@@ -4569,6 +4569,8 @@ dev/mlx4/mlx4_core/mlx4_eq.c  
optional mlx4 pci \
compile-with "${OFED_C}"
 dev/mlx4/mlx4_core/mlx4_fw.c   optional mlx4 pci \
compile-with "${OFED_C}"
+dev/mlx4/mlx4_core/mlx4_fw_qos.c   optional mlx4 pci \
+   compile-with "${OFED_C}"
 dev/mlx4/mlx4_core/mlx4_icm.c  optional mlx4 pci \
compile-with "${OFED_C}"
 dev/mlx4/mlx4_core/mlx4_intf.c optional mlx4 pci \
@@ -4594,8 +4596,6 @@ dev/mlx4/mlx4_core/mlx4_sense.c   
optional mlx4 pci \
 dev/mlx4/mlx4_core/mlx4_srq.c  optional mlx4 pci \
compile-with "${OFED_C}"
 dev/mlx4/mlx4_core/mlx4_resource_tracker.c optional mlx4 pci \
-   compile-with "${OFED_C}"
-dev/mlx4/mlx4_core/mlx4_sys_tune.c optional mlx4 pci \
compile-with "${OFED_C}"
 
 dev/mlx4/mlx4_en/mlx4_en_cq.c  optional mlx4en pci inet inet6  
\

Modified: head/sys/dev/mlx4/cmd.h
==
--- head/sys/dev/mlx4/cmd.h Wed Nov 15 06:45:33 2017(r325840)
+++ head/sys/dev/mlx4/cmd.h Wed Nov 15 11:14:39 2017(r325841)
@@ -36,6 +36,8 @@
 #include 
 #include 
 
+struct mlx4_counter;
+
 enum {
/* initialization and general commands */
MLX4_CMD_SYS_EN  = 0x1,
@@ -67,8 +69,13 @@ enum {
MLX4_CMD_MAP_ICM_AUX = 0xffc,
MLX4_CMD_UNMAP_ICM_AUX   = 0xffb,
MLX4_CMD_SET_ICM_SIZE= 0xffd,
+   MLX4_

svn commit: r325850 - head/sbin/pfctl

2017-11-15 Thread Kristof Provost

Author: kp
Date: Wed Nov 15 12:27:02 2017
New Revision: 325850
URL: https://svnweb.freebsd.org/changeset/base/325850

Log:
  pfctl: teach route-to to deal with interfaces with multiple addresses
  
  The route_host parsing code set the interface name, but only for the first
  node_host in the list. If that one happened to be the inet6 address and the
  rule wanted an inet address it'd get removed by remove_invalid_hosts() later
  on, and we'd have no interface name.
  
  We must set the interface name for all node_host entries in the list, not just
  the first one.
  
  PR:   223208
  MFC after:2 weeks

Modified:
  head/sbin/pfctl/parse.y

Modified: head/sbin/pfctl/parse.y
==
--- head/sbin/pfctl/parse.y Wed Nov 15 12:23:01 2017(r325849)
+++ head/sbin/pfctl/parse.y Wed Nov 15 12:27:02 2017(r325850)
@@ -4390,8 +4390,11 @@ route_host   : STRING{
$$->tail = $$;
}
| '(' STRING host ')'   {
+   struct node_host *n;
+
$$ = $3;
-   $$->ifname = $2;
+   for (n = $3; n != NULL; n = n->next)
+   n->ifname = $2;
}
;
 
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

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

2017-11-15 Thread Baptiste Daroussin

Author: bapt
Date: Wed Nov 15 12:48:36 2017
New Revision: 325851
URL: https://svnweb.freebsd.org/changeset/base/325851

Log:
  remove the poor emulation of the IllumOS needfree global variable to prevent
  the ARC reclaim thread running longer than needed.
  
  Update the arc::needfree dtrace probe triggered in arc_lowmem() to also report
  the value we may want to free.
  
  Submitted by: Nikita Kozlov 
  Reviewed by:  avg
  Approved by:  avg
  MFC after:3 weeks
  Sponsored by: blade
  Differential Revision:https://reviews.freebsd.org/D12163

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

Modified: head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c
==
--- head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c   Wed Nov 15 
12:27:02 2017(r325850)
+++ head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c   Wed Nov 15 
12:48:36 2017(r325851)
@@ -4199,8 +4199,6 @@ arc_shrink(int64_t to_free)
}
 }
 
-static long needfree = 0;
-
 typedef enum free_memory_reason_t {
FMR_UNKNOWN,
FMR_NEEDFREE,
@@ -4238,14 +4236,6 @@ arc_available_memory(void)
free_memory_reason_t r = FMR_UNKNOWN;
 
 #ifdef _KERNEL
-   if (needfree > 0) {
-   n = PAGESIZE * (-needfree);
-   if (n < lowest) {
-   lowest = n;
-   r = FMR_NEEDFREE;
-   }
-   }
-
/*
 * Cooperate with pagedaemon when it's time for it to scan
 * and reclaim some pages.
@@ -4510,9 +4500,6 @@ arc_reclaim_thread(void *dummy __unused)
int64_t to_free =
(arc_c >> arc_shrink_shift) - free_memory;
if (to_free > 0) {
-#ifdef _KERNEL
-   to_free = MAX(to_free, ptob(needfree));
-#endif
arc_shrink(to_free);
}
} else if (free_memory < arc_c >> arc_no_grow_shift) {
@@ -4533,9 +4520,6 @@ arc_reclaim_thread(void *dummy __unused)
 * infinite loop.
 */
if (arc_size <= arc_c || evicted == 0) {
-#ifdef _KERNEL
-   needfree = 0;
-#endif
/*
 * We're either no longer overflowing, or we
 * can't evict anything more, so we should wake
@@ -6310,9 +6294,7 @@ arc_lowmem(void *arg __unused, int howto __unused)
 {
 
mutex_enter(&arc_reclaim_lock);
-   /* XXX: Memory deficit should be passed as argument. */
-   needfree = btoc(arc_c >> arc_shrink_shift);
-   DTRACE_PROBE(arc__needfree);
+   DTRACE_PROBE1(arc__needfree, int64_t, ((int64_t)freemem - 
zfs_arc_free_target) * PAGESIZE);
cv_signal(&arc_reclaim_thread_cv);
 
/*
___
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: r325852 - in head/sys: sys vm

2017-11-15 Thread Konstantin Belousov

Author: kib
Date: Wed Nov 15 13:41:03 2017
New Revision: 325852
URL: https://svnweb.freebsd.org/changeset/base/325852

Log:
  vmtotal: extend memory counters to accomodate for current and future
  hardware sizes.
  
  32bit counters already overflow on approachable virtual memory page
  counts, and soon would overflow on the physical pages counts as well.
  Bump sizes to 64bit types.  Bump __FreeBSD_version.
  
  It is impossible to provide perfect backward ABI compat for this
  change.  If a program requests an old structure, it can be detected by
  size.  But if it queries the size first by passing NULL old req
  pointer, there is almost nothing we can do to detect the desired ABI.
  As a partial solution, check p_osrel of the quering process when
  selecting the size to report.
  
  Submitted by: Pawel Biernacki 
  Differential revision:https://reviews.freebsd.org/D13018

Modified:
  head/sys/sys/param.h
  head/sys/sys/vmmeter.h
  head/sys/vm/vm_meter.c

Modified: head/sys/sys/param.h
==
--- head/sys/sys/param.hWed Nov 15 12:48:36 2017(r325851)
+++ head/sys/sys/param.hWed Nov 15 13:41:03 2017(r325852)
@@ -58,7 +58,7 @@
  * in the range 5 to 9.
  */
 #undef __FreeBSD_version
-#define __FreeBSD_version 1200053  /* Master, propagated to newvers */
+#define __FreeBSD_version 1200054  /* Master, propagated to newvers */
 
 /*
  * __FreeBSD_kernel__ indicates that this system uses the kernel of FreeBSD,
@@ -84,6 +84,7 @@
 #defineP_OSREL_SHUTDOWN_ENOTCONN   1100077
 #defineP_OSREL_MAP_GUARD   1200035
 #defineP_OSREL_WRFSBASE1200041
+#defineP_OSREL_VMTOTAL64   1200054
 
 #defineP_OSREL_MAJOR(x)((x) / 10)
 #endif

Modified: head/sys/sys/vmmeter.h
==
--- head/sys/sys/vmmeter.h  Wed Nov 15 12:48:36 2017(r325851)
+++ head/sys/sys/vmmeter.h  Wed Nov 15 13:41:03 2017(r325852)
@@ -41,20 +41,23 @@
 
 /* Systemwide totals computed every five seconds. */
 struct vmtotal {
-   int16_t t_rq;   /* length of the run queue */
-   int16_t t_dw;   /* jobs in ``disk wait'' (neg priority) */
-   int16_t t_pw;   /* jobs in page wait */
-   int16_t t_sl;   /* jobs sleeping in core */
-   int16_t t_sw;   /* swapped out runnable/short block jobs */
-   int32_t t_vm;   /* total virtual memory */
-   int32_t t_avm;  /* active virtual memory */
-   int32_t t_rm;   /* total real memory in use */
-   int32_t t_arm;  /* active real memory */
-   int32_t t_vmshr;/* shared virtual memory */
-   int32_t t_avmshr;   /* active shared virtual memory */
-   int32_t t_rmshr;/* shared real memory */
-   int32_t t_armshr;   /* active shared real memory */
-   int32_t t_free; /* free memory pages */
+   uint64_tt_vm;   /* total virtual memory */
+   uint64_tt_avm;  /* active virtual memory */
+   uint64_tt_rm;   /* total real memory in use */
+   uint64_tt_arm;  /* active real memory */
+   uint64_tt_vmshr;/* shared virtual memory */
+   uint64_tt_avmshr;   /* active shared virtual memory */
+   uint64_tt_rmshr;/* shared real memory */
+   uint64_tt_armshr;   /* active shared real memory */
+   uint64_tt_free; /* free memory pages */
+   int16_t t_rq;   /* length of the run queue */
+   int16_t t_dw;   /* jobs in ``disk wait'' (neg
+  priority) */
+   int16_t t_pw;   /* jobs in page wait */
+   int16_t t_sl;   /* jobs sleeping in core */
+   int16_t t_sw;   /* swapped out runnable/short
+  block jobs */
+   uint16_tt_pad[3];
 };
 
 #if defined(_KERNEL) || defined(_WANT_VMMETER)

Modified: head/sys/vm/vm_meter.c
==
--- head/sys/vm/vm_meter.c  Wed Nov 15 12:48:36 2017(r325851)
+++ head/sys/vm/vm_meter.c  Wed Nov 15 13:41:03 2017(r325852)
@@ -152,14 +152,43 @@ is_object_active(vm_object_t obj)
return (obj->ref_count > obj->shadow_count);
 }
 
+#if defined(COMPAT_FREEBSD11)
+struct vmtotal11 {
+   int16_t t_rq;
+   int16_t t_dw;
+   int16_t t_pw;
+   int16_t t_sl;
+   int16_t t_sw;
+   int32_t t_vm;
+   int32_t t_avm;
+   int32_t t_rm;
+   int32_t t_arm;
+   int32_t t_vmshr;
+   int32_t t_avmshr;
+   int32_t t_rmshr;
+   int32_t t_armshr;
+   int

Re: svn commit: r325828 - head/usr.bin/fortune/datfiles

2017-11-15 Thread Jeremie Le Hen

Hi Benno,

On Tue, Nov 14, 2017 at 10:18 PM, Benno Rice  wrote:
> Author: benno
> Date: Tue Nov 14 21:18:30 2017
> New Revision: 325828
> URL: https://svnweb.freebsd.org/changeset/base/325828
>
> Log:
>   Remove all fortune datfiles except freebsd-tips.
>
>   Humour is a funny thing. What is funny to one person is not funny to all
>   people. What is insightful to one person is similarly not universal. The
>   fortune datfiles have been around a long time and have undoubtedly amused
>   people but it's time to acknowledge their subjective, and in some cases
>   at least potentially offensive, nature and stop distributing them with the
>   imprimatur of the FreeBSD project.

Sorry to ask, I'm only loosely following the project, but was this
discussed somewhere?


>   If anyone wishes to distribute these via other mechanisms they are welcome 
> to
>   check them out of history and do so.

I don't think there's any rule saying that, but I know people are
usually happy to have a replacing port.  As you removed them, can I
please ask you do this?

Thanks.
-- Jeremie


>   MFC after:2 days
>
> Deleted:
>   head/usr.bin/fortune/datfiles/fortunes
>   head/usr.bin/fortune/datfiles/fortunes.sp.ok
>   head/usr.bin/fortune/datfiles/gerrold.limerick
>   head/usr.bin/fortune/datfiles/limerick
>   head/usr.bin/fortune/datfiles/limerick.sp.ok
>   head/usr.bin/fortune/datfiles/murphy
>   head/usr.bin/fortune/datfiles/murphy-o
>   head/usr.bin/fortune/datfiles/murphy.sp.ok
>   head/usr.bin/fortune/datfiles/startrek
>   head/usr.bin/fortune/datfiles/startrek.sp.ok
>   head/usr.bin/fortune/datfiles/zippy
>   head/usr.bin/fortune/datfiles/zippy.sp.ok
> Modified:
>   head/usr.bin/fortune/datfiles/Makefile
>
> Modified: head/usr.bin/fortune/datfiles/Makefile
> ==
> --- head/usr.bin/fortune/datfiles/Makefile  Tue Nov 14 21:11:55 2017  
>   (r325827)
> +++ head/usr.bin/fortune/datfiles/Makefile  Tue Nov 14 21:18:30 2017  
>   (r325828)
> @@ -1,11 +1,7 @@
>  #  @(#)Makefile8.2 (Berkeley) 4/19/94
>  # $FreeBSD$
>
> -DB=fortunes freebsd-tips murphy startrek zippy
> -
> -# TO AVOID INSTALLING THE POTENTIALLY OFFENSIVE FORTUNES, COMMENT OUT THE
> -# NEXT LINE.
> -DB+=   limerick murphy-o gerrold.limerick
> +DB=freebsd-tips
>
>  BLDS=  ${DB:S/$/.dat/}
>  FILES= ${DB} ${BLDS}
> ___
> svn-src-...@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/svn-src-all
> To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"



-- 
Jeremie Le Hen
j...@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"

svn commit: r325854 - head/share/man/man7

2017-11-15 Thread Warner Losh

Author: imp
Date: Wed Nov 15 15:00:02 2017
New Revision: 325854
URL: https://svnweb.freebsd.org/changeset/base/325854

Log:
  Reword a bit for clarity.
  
  Sponsored by: Netflix

Modified:
  head/share/man/man7/arch.7

Modified: head/share/man/man7/arch.7
==
--- head/share/man/man7/arch.7  Wed Nov 15 14:35:42 2017(r325853)
+++ head/share/man/man7/arch.7  Wed Nov 15 15:00:02 2017(r325854)
@@ -418,9 +418,12 @@ For example,
 .Dv MACHINE_CPUARCH
 is defined to be mips for all the flavors of mips that we support
 since we support them all with a shared set of sources.
-One might thing that it should be x86 for both amd64 and i386.
-However, since we don't support these two architectures with the same
-source base, that's not done despite it's logical appeal.
+While amd64 and i386 are closely related, MACHINE_CPUARCH is not x86
+for them.
+The FreeBSD source base supports amd64 and i386 with two
+distinct source bases living in subdirectories named amd64 and i386
+(though behind the scenes there's some sharing that fits into this
+framework).
 .It Dv CPUTYPE Sets the flavor of
 .Dv MACHINE_ARCH
 to build.
@@ -433,7 +436,8 @@ Unused outside of that scope.
 It is not passed down to the rest of the build.
 Makefiles outside of the top level shouldn't use it at all (though
 some have their own private copy for hysterical raisons).
-.It Dv TARGET_ARCH Used to set Dv MACHINE_ARCH by Fx's top level Makefile 
for cross building.
+.It Dv TARGET_ARCH Used to set
+.Dv MACHINE_ARCH by Fx's top level Makefile for cross building.
 Like
 .Dv TARGET , it is unused outside of that scope.
 .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: r325855 - head/share/man/man7

2017-11-15 Thread Warner Losh

Author: imp
Date: Wed Nov 15 15:02:45 2017
New Revision: 325855
URL: https://svnweb.freebsd.org/changeset/base/325855

Log:
  Replace Fx's with 'the' since expanding FreeBSD here didn't seem quite
  right.
  
  Sponsored by: Netflix

Modified:
  head/share/man/man7/arch.7

Modified: head/share/man/man7/arch.7
==
--- head/share/man/man7/arch.7  Wed Nov 15 15:00:02 2017(r325854)
+++ head/share/man/man7/arch.7  Wed Nov 15 15:02:45 2017(r325855)
@@ -437,7 +437,7 @@ It is not passed down to the rest of the build.
 Makefiles outside of the top level shouldn't use it at all (though
 some have their own private copy for hysterical raisons).
 .It Dv TARGET_ARCH Used to set
-.Dv MACHINE_ARCH by Fx's top level Makefile for cross building.
+.Dv MACHINE_ARCH by the top level Makefile for cross building.
 Like
 .Dv TARGET , it is unused outside of that scope.
 .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: r325857 - head/sys/cam

2017-11-15 Thread Alan Somers

Author: asomers
Date: Wed Nov 15 15:52:06 2017
New Revision: 325857
URL: https://svnweb.freebsd.org/changeset/base/325857

Log:
  Remove a double free(9) in xpt_bus_register
  
  In xpt_bus_register(), remove superfluous call to free().  This was mostly
  benign since free(9) checks for NULL before doing anything, and
  xpt_create_path() is nice enough to NULL out the pointer on failure.
  However, it could've segfaulted if malloc(9) failed during
  xpt_create_path().
  
  Submitted by: gibbs
  MFC after:3 weeks
  Sponsored by: Spectra Logic Corp

Modified:
  head/sys/cam/cam_xpt.c

Modified: head/sys/cam/cam_xpt.c
==
--- head/sys/cam/cam_xpt.c  Wed Nov 15 15:24:28 2017(r325856)
+++ head/sys/cam/cam_xpt.c  Wed Nov 15 15:52:06 2017(r325857)
@@ -4049,7 +4049,6 @@ xpt_bus_register(struct cam_sim *sim, device_t parent,
  CAM_TARGET_WILDCARD, CAM_LUN_WILDCARD);
if (status != CAM_REQ_CMP) {
xpt_release_bus(new_bus);
-   free(path, M_CAMXPT);
return (CAM_RESRC_UNAVAIL);
}
 
___
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: r325828 - head/usr.bin/fortune/datfiles

2017-11-15 Thread Benno Rice

> On Nov 15, 2017, at 06:54, Jeremie Le Hen  wrote:
> 
> Hi Benno,
> 
> On Tue, Nov 14, 2017 at 10:18 PM, Benno Rice  > wrote:
>> Author: benno
>> Date: Tue Nov 14 21:18:30 2017
>> New Revision: 325828
>> URL: https://svnweb.freebsd.org/changeset/base/325828
>> 
>> Log:
>>  Remove all fortune datfiles except freebsd-tips.
>> 
>>  Humour is a funny thing. What is funny to one person is not funny to all
>>  people. What is insightful to one person is similarly not universal. The
>>  fortune datfiles have been around a long time and have undoubtedly amused
>>  people but it's time to acknowledge their subjective, and in some cases
>>  at least potentially offensive, nature and stop distributing them with the
>>  imprimatur of the FreeBSD project.
> 
> Sorry to ask, I'm only loosely following the project, but was this
> discussed somewhere?

It was raised to core but I decided to take unilateral action. That’s not an 
indication of any disagreement in core per se, I just made the call that in the 
light of finding Hitler quotes in the file, and the fact that there were still 
files clearly marked as offensive in the Makefile, that trying to be the 
editors of humour is not something we’re really cut out for and that we should 
get out of the game. I put the MFC timer on it so that if anyone wants to mount 
an argument as to why they should stay they can.

>>  If anyone wishes to distribute these via other mechanisms they are welcome 
>> to
>>  check them out of history and do so.
> 
> I don't think there's any rule saying that, but I know people are
> usually happy to have a replacing port.  As you removed them, can I
> please ask you do this?

Personally I feel that this is the kind of thing that doesn’t need to live on. 
I won’t be making a port of it. If someone else wants to distribute these then 
they can.

Thanks,
Benno.

___
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: r325859 - head

2017-11-15 Thread Ed Maste

Author: emaste
Date: Wed Nov 15 18:03:31 2017
New Revision: 325859
URL: https://svnweb.freebsd.org/changeset/base/325859

Log:
  Sort pkgbase mtree metadata, for reproducible builds
  
  Packaged base packages are created by running the stageworld and
  stagekernel targets with -DNO_ROOT, and converting the resulting mtree
  file into a set of pkg plists.  If stage* is run with multiple processes
  the order of entries in the mtree file may be nondeterministic, and the
  resulting package tbz also had nondeterministic file ordering.
  
  The mtree file generated by -DNO_ROOT builds consists of one line per
  file, with the filename starting in the first column, so is easily
  sorted.  There's one exception: the first line of the mtree file is a
  comment, but the # character sorts before the filenames anyhow and needs
  no special treatment.
  
  PR:   223673
  Reviewed by:  bapt, gjb
  Sponsored by: The Linux Foundation, Core Infrastructure Initiative
  Sponsored by: The FreeBSD Foundation
  Differential Revision:https://reviews.freebsd.org/D13103

Modified:
  head/Makefile.inc1

Modified: head/Makefile.inc1
==
--- head/Makefile.inc1  Wed Nov 15 15:56:08 2017(r325858)
+++ head/Makefile.inc1  Wed Nov 15 18:03:31 2017(r325859)
@@ -1613,8 +1613,8 @@ create-packages: .PHONY create-packages-world create-p
 create-world-packages: _pkgbootstrap .PHONY
@rm -f ${WSTAGEDIR}/*.plist 2>/dev/null || :
@cd ${WSTAGEDIR} ; \
-   awk -f ${SRCDIR}/release/scripts/mtree-to-plist.awk \
-   ${WSTAGEDIR}/METALOG
+   env -i LC_COLLATE=C sort ${WSTAGEDIR}/METALOG | \
+   awk -f ${SRCDIR}/release/scripts/mtree-to-plist.awk
@for plist in ${WSTAGEDIR}/*.plist; do \
  plist=$${plist##*/} ; \
  pkgname=$${plist%.plist} ; \
@@ -1658,9 +1658,9 @@ _debug=-debug
 create-kernel-packages: 
create-kernel-packages-flavor${flavor:C,^""$,${_default_flavor},}
 create-kernel-packages-flavor${flavor:C,^""$,${_default_flavor},}: 
_pkgbootstrap .PHONY
@cd ${KSTAGEDIR}/${DISTDIR} ; \
+   env -i LC_COLLATE=C sort ${KSTAGEDIR}/kernel.meta | \
awk -f ${SRCDIR}/release/scripts/mtree-to-plist.awk \
-   -v kernel=yes -v _kernconf=${INSTALLKERNEL} \
-   ${KSTAGEDIR}/kernel.meta ; \
+   -v kernel=yes -v _kernconf=${INSTALLKERNEL} ; \
cap_arg=`cd ${SRCDIR}/etc ; ${MAKE} -VCAP_MKDB_ENDIAN` ; \
pwd_arg=`cd ${SRCDIR}/etc ; ${MAKE} -VPWD_MKDB_ENDIAN` ; \
sed -e "s/%VERSION%/${PKG_VERSION}/" \
@@ -1693,9 +1693,9 @@ _debug=-debug
 create-kernel-packages: 
create-kernel-packages-extra-flavor${flavor:C,^""$,${_default_flavor},}-${_kernel}
 
create-kernel-packages-extra-flavor${flavor:C,^""$,${_default_flavor},}-${_kernel}:
 _pkgbootstrap .PHONY
@cd ${KSTAGEDIR}/kernel.${_kernel} ; \
+   env -i LC_COLLATE=C sort ${KSTAGEDIR}/kernel.${_kernel}.meta | \
awk -f ${SRCDIR}/release/scripts/mtree-to-plist.awk \
-   -v kernel=yes -v _kernconf=${_kernel} \
-   ${KSTAGEDIR}/kernel.${_kernel}.meta ; \
+   -v kernel=yes -v _kernconf=${_kernel} ; \
cap_arg=`cd ${SRCDIR}/etc ; ${MAKE} -VCAP_MKDB_ENDIAN` ; \
pwd_arg=`cd ${SRCDIR}/etc ; ${MAKE} -VPWD_MKDB_ENDIAN` ; \
sed -e "s/%VERSION%/${PKG_VERSION}/" \
___
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: r325860 - head/sbin/newfs

2017-11-15 Thread Ed Maste

Author: emaste
Date: Wed Nov 15 18:40:40 2017
New Revision: 325860
URL: https://svnweb.freebsd.org/changeset/base/325860

Log:
  newfs: warn if newer than kernel
  
  Creating a UFS filesystem with a newfs newer than the running kernel,
  and then mounting that filesystem, can lead to interesting failures.
  
  Add a safety belt to explicitly warn when newfs is newer than the
  running kernel.
  
  Reviewed by:  gjb, jhb, mckusick
  Sponsored by: The FreeBSD Foundation
  Differential Revision:https://reviews.freebsd.org/D12765

Modified:
  head/sbin/newfs/newfs.c

Modified: head/sbin/newfs/newfs.c
==
--- head/sbin/newfs/newfs.c Wed Nov 15 18:03:31 2017(r325859)
+++ head/sbin/newfs/newfs.c Wed Nov 15 18:40:40 2017(r325860)
@@ -398,6 +398,10 @@ main(int argc, char *argv[])
if (pp != NULL)
pp->p_size *= secperblk;
}
+   if (getosreldate() < __FreeBSD_version) {
+   warnx("%s is newer than the running kernel and may not be 
compatible",
+   getprogname());
+   }
mkfs(pp, special);
ufs_disk_close(&disk);
if (!jflag)
___
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: r325860 - head/sbin/newfs

2017-11-15 Thread Rodney W. Grimes

> Author: emaste
> Date: Wed Nov 15 18:40:40 2017
> New Revision: 325860
> URL: https://svnweb.freebsd.org/changeset/base/325860
> 
> Log:
>   newfs: warn if newer than kernel
>   
>   Creating a UFS filesystem with a newfs newer than the running kernel,
>   and then mounting that filesystem, can lead to interesting failures.
>   
>   Add a safety belt to explicitly warn when newfs is newer than the
>   running kernel.

You should probably make the warning if (newer || older) as
either is likely to have interesting side effects, as are
mounting ufs file systems on different versions.

*Sigh*  why did not UFS grow a version number of its own
when things started to change other than UFS1 vs UFS2.


>   Reviewed by:gjb, jhb, mckusick
>   Sponsored by:   The FreeBSD Foundation
>   Differential Revision:  https://reviews.freebsd.org/D12765
> 
> Modified:
>   head/sbin/newfs/newfs.c
> 
> Modified: head/sbin/newfs/newfs.c
> ==
> --- head/sbin/newfs/newfs.c   Wed Nov 15 18:03:31 2017(r325859)
> +++ head/sbin/newfs/newfs.c   Wed Nov 15 18:40:40 2017(r325860)
> @@ -398,6 +398,10 @@ main(int argc, char *argv[])
>   if (pp != NULL)
>   pp->p_size *= secperblk;
>   }
> + if (getosreldate() < __FreeBSD_version) {
> + warnx("%s is newer than the running kernel and may not be 
> compatible",
> + getprogname());
> + }
>   mkfs(pp, special);
>   ufs_disk_close(&disk);
>   if (!jflag)
> 
> 

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

svn commit: r325861 - head/release/arm

2017-11-15 Thread Emmanuel Vadot

Author: manu
Date: Wed Nov 15 19:03:06 2017
New Revision: 325861
URL: https://svnweb.freebsd.org/changeset/base/325861

Log:
  release: Update u-boot and firmware file for RPI-B target
  
  THe u-boot port for RPI-B was updated to use u-boot-master, this cause
  an update in u-boot version to v2017.09 and changing the filename.
  The various firmware files for the RPI* are now in a common ports
  sysutils/rpi-firmware as they are shared on all the RPI version.
  
  Update the release files to copy the right files from the right location.
  
  Reviewed by:  gjb
  MFC after:3 days

Modified:
  head/release/arm/RPI-B.conf

Modified: head/release/arm/RPI-B.conf
==
--- head/release/arm/RPI-B.conf Wed Nov 15 18:40:40 2017(r325860)
+++ head/release/arm/RPI-B.conf Wed Nov 15 19:03:06 2017(r325861)
@@ -6,7 +6,7 @@
 EMBEDDEDBUILD=1
 EMBEDDED_TARGET="arm"
 EMBEDDED_TARGET_ARCH="armv6"
-EMBEDDEDPORTS="sysutils/u-boot-rpi"
+EMBEDDEDPORTS="sysutils/u-boot-rpi sysutils/rpi-firmware"
 KERNEL="RPI-B"
 IMAGE_SIZE="3072M"
 PART_SCHEME="MBR"
@@ -17,8 +17,11 @@ NODOC=1
 
 arm_install_uboot() {
UBOOT_DIR="/usr/local/share/u-boot/u-boot-rpi"
-   UBOOT_FILES="bootcode.bin config.txt fixup.dat fixup_cd.dat \
-   start.elf start_cd.elf u-boot.img"
+   RPI_FIRMWARE_DIR="/usr/local/share/rpi-firmware"
+   UBOOT_FILES="u-boot.bin"
+   RPI_FIRMWARE_FILES="bootcode.bin config.txt \
+   fixup.dat fixup_cd.dat fixup_db.dat fixup_x.dat \
+   start.elf start_cd.elf start_db.elf start_x.elf"
FATMOUNT="${DESTDIR%${KERNEL}}/fat"
UFSMOUNT="${DESTDIR%${KERNEL}}/ufs"
chroot ${CHROOTDIR} mkdir -p "${FATMOUNT}" "${UFSMOUNT}"
@@ -26,6 +29,10 @@ arm_install_uboot() {
chroot ${CHROOTDIR} mount /dev/${mddev}s2a ${UFSMOUNT}
for _UF in ${UBOOT_FILES}; do
chroot ${CHROOTDIR} cp -p ${UBOOT_DIR}/${_UF} \
+   ${FATMOUNT}/${_UF}
+   done
+   for _UF in ${RPI_FIRMWARE_FILES}; do
+   chroot ${CHROOTDIR} cp -p ${RPI_FIRMWARE_DIR}/${_UF} \
${FATMOUNT}/${_UF}
done
chroot ${CHROOTDIR} cp -p ${UFSMOUNT}/boot/ubldr.bin \
___
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: r325862 - head/release/arm

2017-11-15 Thread Emmanuel Vadot

Author: manu
Date: Wed Nov 15 19:04:23 2017
New Revision: 325862
URL: https://svnweb.freebsd.org/changeset/base/325862

Log:
  release: Update u-boot and firmware file for RPI2 target
  
  The u-boot port for RPI-2 was updated to use u-boot-master, this cause
  an update in u-boot version to v2017.09 and changing the filename.
  The various firmware files for the RPI* are now in a common ports
  sysutils/rpi-firmware as they are shared on all the RPI version.
  
  Update the release files to copy the right files from the right location.
  
  Reviewed by:  gjb
  MFC after:3 days

Modified:
  head/release/arm/RPI2.conf

Modified: head/release/arm/RPI2.conf
==
--- head/release/arm/RPI2.conf  Wed Nov 15 19:03:06 2017(r325861)
+++ head/release/arm/RPI2.conf  Wed Nov 15 19:04:23 2017(r325862)
@@ -6,7 +6,7 @@
 EMBEDDEDBUILD=1
 EMBEDDED_TARGET="arm"
 EMBEDDED_TARGET_ARCH="armv7"
-EMBEDDEDPORTS="sysutils/u-boot-rpi2"
+EMBEDDEDPORTS="sysutils/u-boot-rpi2 sysutils/rpi-firmware"
 KERNEL="GENERIC"
 IMAGE_SIZE="3072M"
 PART_SCHEME="MBR"
@@ -18,8 +18,11 @@ export BOARDNAME="RPI2"
 
 arm_install_uboot() {
UBOOT_DIR="/usr/local/share/u-boot/u-boot-rpi2"
-   UBOOT_FILES="bootcode.bin config.txt fixup.dat fixup_cd.dat \
-   fixup_x.dat start.elf start_cd.elf start_x.elf u-boot.bin"
+   RPI_FIRMWARE_DIR="/usr/local/share/rpi-firmware"
+   UBOOT_FILES="u-boot.bin"
+   RPI_FIRMWARE_FILES="bootcode.bin config.txt \
+   fixup.dat fixup_cd.dat fixup_db.dat fixup_x.dat \
+   start.elf start_cd.elf start_db.elf start_x.elf"
FATMOUNT="${DESTDIR%${KERNEL}}/fat"
UFSMOUNT="${DESTDIR%${KERNEL}}/ufs"
chroot ${CHROOTDIR} mkdir -p "${FATMOUNT}" "${UFSMOUNT}"
@@ -27,6 +30,10 @@ arm_install_uboot() {
chroot ${CHROOTDIR} mount /dev/${mddev}s2a ${UFSMOUNT}
for _UF in ${UBOOT_FILES}; do
chroot ${CHROOTDIR} cp -p ${UBOOT_DIR}/${_UF} \
+   ${FATMOUNT}/${_UF}
+   done
+   for _UF in ${RPI_FIRMWARE_FILES}; do
+   chroot ${CHROOTDIR} cp -p ${RPI_FIRMWARE_DIR}/${_UF} \
${FATMOUNT}/${_UF}
done
chroot ${CHROOTDIR} cp -p ${UFSMOUNT}/boot/ubldr.bin \
___
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: r325863 - head/release

2017-11-15 Thread Glen Barber

Author: gjb
Date: Wed Nov 15 19:14:44 2017
New Revision: 325863
URL: https://svnweb.freebsd.org/changeset/base/325863

Log:
  Only copy /etc/resolv.conf to ${CHROOTDIR} if /etc/resolv.conf does
  not already exist within ${CHROOTDIR}.  This allows re-using a build
  chroot with CHROOTBUILD_SKIP set to a non-empty value and CHROOTDIR
  set to '/' in release.conf.
  
  MFC after:3 days
  Sponsored by: The FreeBSD Foundation

Modified:
  head/release/release.sh

Modified: head/release/release.sh
==
--- head/release/release.sh Wed Nov 15 19:04:23 2017(r325862)
+++ head/release/release.sh Wed Nov 15 19:14:44 2017(r325863)
@@ -252,8 +252,8 @@ chroot_setup() {
 extra_chroot_setup() {
mkdir -p ${CHROOTDIR}/dev
mount -t devfs devfs ${CHROOTDIR}/dev
-   [ -e /etc/resolv.conf ] && cp /etc/resolv.conf \
-   ${CHROOTDIR}/etc/resolv.conf
+   [ -e /etc/resolv.conf -a ! -e ${CHROOTDIR}/etc/resolv.conf ] && \
+   cp /etc/resolv.conf ${CHROOTDIR}/etc/resolv.conf
# Run ldconfig(8) in the chroot directory so /var/run/ld-elf*.so.hints
# is created.  This is needed by ports-mgmt/pkg.
eval chroot ${CHROOTDIR} /etc/rc.d/ldconfig forcerestart
___
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: r325828 - head/usr.bin/fortune/datfiles

2017-11-15 Thread Cy Schubert

Tips become stale and can be themselves contentious. Just consider our bike 
sheds. Besides, people should read the handbook anyway. Let's simply remove 
fortune altogether.

---
Sent using a tiny phone keyboard.
Apologies for any typos and autocorrect.

Cy Schubert
 or 

---

-Original Message-
From: Benno Rice
Sent: 15/11/2017 08:58
To: Jeremie Le Hen
Cc: src-committers; svn-src-...@freebsd.org; svn-src-head@freebsd.org
Subject: Re: svn commit: r325828 - head/usr.bin/fortune/datfiles






On Nov 15, 2017, at 06:54, Jeremie Le Hen  wrote:


Hi Benno,

On Tue, Nov 14, 2017 at 10:18 PM, Benno Rice  wrote:

Author: benno
Date: Tue Nov 14 21:18:30 2017
New Revision: 325828
URL: https://svnweb.freebsd.org/changeset/base/325828

Log:
 Remove all fortune datfiles except freebsd-tips.

 Humour is a funny thing. What is funny to one person is not funny to all
 people. What is insightful to one person is similarly not universal. The
 fortune datfiles have been around a long time and have undoubtedly amused
 people but it's time to acknowledge their subjective, and in some cases
 at least potentially offensive, nature and stop distributing them with the
 imprimatur of the FreeBSD project.


Sorry to ask, I'm only loosely following the project, but was this
discussed somewhere?



It was raised to core but I decided to take unilateral action. That’s not an 
indication of any disagreement in core per se, I just made the call that in the 
light of finding Hitler quotes in the file, and the fact that there were still 
files clearly marked as offensive in the Makefile, that trying to be the 
editors of humour is not something we’re really cut out for and that we should 
get out of the game. I put the MFC timer on it so that if anyone wants to mount 
an argument as to why they should stay they can.




 If anyone wishes to distribute these via other mechanisms they are welcome to
 check them out of history and do so.


I don't think there's any rule saying that, but I know people are
usually happy to have a replacing port.  As you removed them, can I
please ask you do this?


Personally I feel that this is the kind of thing that doesn’t need to live on. 
I won’t be making a port of it. If someone else wants to distribute these then 
they can.




Thanks,

 Benno.
___
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: r325860 - head/sbin/newfs

2017-11-15 Thread Warner Losh

On Nov 15, 2017 11:47 AM, "Rodney W. Grimes" 
wrote:

> Author: emaste
> Date: Wed Nov 15 18:40:40 2017
> New Revision: 325860
> URL: https://svnweb.freebsd.org/changeset/base/325860
>
> Log:
>   newfs: warn if newer than kernel
>
>   Creating a UFS filesystem with a newfs newer than the running kernel,
>   and then mounting that filesystem, can lead to interesting failures.
>
>   Add a safety belt to explicitly warn when newfs is newer than the
>   running kernel.

You should probably make the warning if (newer || older) as
either is likely to have interesting side effects, as are
mounting ufs file systems on different versions.


Not really. The cg stuff is really only a hassle for the case ed is testing
for.

*Sigh*  why did not UFS grow a version number of its own
when things started to change other than UFS1 vs UFS2.


This isn't anything like those changes..

Warner

>   Reviewed by:gjb, jhb, mckusick
>   Sponsored by:   The FreeBSD Foundation
>   Differential Revision:  https://reviews.freebsd.org/D12765
>
> Modified:
>   head/sbin/newfs/newfs.c
>
> Modified: head/sbin/newfs/newfs.c
> 
==
> --- head/sbin/newfs/newfs.c   Wed Nov 15 18:03:31 2017(r325859)
> +++ head/sbin/newfs/newfs.c   Wed Nov 15 18:40:40 2017(r325860)
> @@ -398,6 +398,10 @@ main(int argc, char *argv[])
>   if (pp != NULL)
>   pp->p_size *= secperblk;
>   }
> + if (getosreldate() < __FreeBSD_version) {
> + warnx("%s is newer than the running kernel and may not be
compatible",
> + getprogname());
> + }
>   mkfs(pp, special);
>   ufs_disk_close(&disk);
>   if (!jflag)
>
>

--
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: r325860 - head/sbin/newfs

2017-11-15 Thread Rodney W. Grimes

[ Charset UTF-8 unsupported, converting... ]
> On Nov 15, 2017 11:47 AM, "Rodney W. Grimes" 
> wrote:
> 
> > Author: emaste
> > Date: Wed Nov 15 18:40:40 2017
> > New Revision: 325860
> > URL: https://svnweb.freebsd.org/changeset/base/325860
> >
> > Log:
> >   newfs: warn if newer than kernel
> >
> >   Creating a UFS filesystem with a newfs newer than the running kernel,
> >   and then mounting that filesystem, can lead to interesting failures.
> >
> >   Add a safety belt to explicitly warn when newfs is newer than the
> >   running kernel.
> 
> You should probably make the warning if (newer || older) as
> either is likely to have interesting side effects, as are
> mounting ufs file systems on different versions.
> 
> 
> Not really. The cg stuff is really only a hassle for the case ed is testing
> for.

Its too late now, but if you take a newer ufs with the cg
stuff in them and mount it on an old system it politly well
corrupt the data that the newer kernel needs.  So your right,
doing this check in newfs wont do anything, but I can tell
you this tiny little chain has been a PITA for people that
move HD around

> *Sigh*  why did not UFS grow a version number of its own
> when things started to change other than UFS1 vs UFS2.
> 
> 
> This isn't anything like those changes..

UFS changed in a way that makes it difficult to move
UFS drives accross systems that are at differing versions.
That IS bad no mater how you slice it.  I now have to make
sure I fsck a drive when moving it from an old to new
system to get the cg checksum stuff fixed.


> Warner
> 
> >   Reviewed by:gjb, jhb, mckusick
> >   Sponsored by:   The FreeBSD Foundation
> >   Differential Revision:  https://reviews.freebsd.org/D12765
> >
> > Modified:
> >   head/sbin/newfs/newfs.c
> >
> > Modified: head/sbin/newfs/newfs.c
> > 
> ==
> > --- head/sbin/newfs/newfs.c   Wed Nov 15 18:03:31 2017(r325859)
> > +++ head/sbin/newfs/newfs.c   Wed Nov 15 18:40:40 2017(r325860)
> > @@ -398,6 +398,10 @@ main(int argc, char *argv[])
> >   if (pp != NULL)
> >   pp->p_size *= secperblk;
> >   }
> > + if (getosreldate() < __FreeBSD_version) {
> > + warnx("%s is newer than the running kernel and may not be
> compatible",
> > + getprogname());
> > + }
> >   mkfs(pp, special);
> >   ufs_disk_close(&disk);
> >   if (!jflag)
> >
> >
> 
> --
> Rod Grimes
> rgri...@freebsd.org

-- 
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: r325860 - head/sbin/newfs

2017-11-15 Thread Warner Losh

On Nov 15, 2017 1:51 PM, "Rodney W. Grimes" 
wrote:

[ Charset UTF-8 unsupported, converting... ]
> On Nov 15, 2017 11:47 AM, "Rodney W. Grimes" 
> wrote:
>
> > Author: emaste
> > Date: Wed Nov 15 18:40:40 2017
> > New Revision: 325860
> > URL: https://svnweb.freebsd.org/changeset/base/325860
> >
> > Log:
> >   newfs: warn if newer than kernel
> >
> >   Creating a UFS filesystem with a newfs newer than the running kernel,
> >   and then mounting that filesystem, can lead to interesting failures.
> >
> >   Add a safety belt to explicitly warn when newfs is newer than the
> >   running kernel.
>
> You should probably make the warning if (newer || older) as
> either is likely to have interesting side effects, as are
> mounting ufs file systems on different versions.
>
>
> Not really. The cg stuff is really only a hassle for the case ed is
testing
> for.

Its too late now, but if you take a newer ufs with the cg
stuff in them and mount it on an old system it politly well
corrupt the data that the newer kernel needs.  So your right,
doing this check in newfs wont do anything, but I can tell
you this tiny little chain has been a PITA for people that
move HD around


Fsck automatically fixes issues like that. It recomputes the checksums.

> *Sigh*  why did not UFS grow a version number of its own
> when things started to change other than UFS1 vs UFS2.
>
>
> This isn't anything like those changes..

UFS changed in a way that makes it difficult to move
UFS drives accross systems that are at differing versions.
That IS bad no mater how you slice it.  I now have to make
sure I fsck a drive when moving it from an old to new
system to get the cg checksum stuff fixed.


Except it isn't as bad as you say.

Warner


> Warner
>
> >   Reviewed by:gjb, jhb, mckusick
> >   Sponsored by:   The FreeBSD Foundation
> >   Differential Revision:  https://reviews.freebsd.org/D12765
> >
> > Modified:
> >   head/sbin/newfs/newfs.c
> >
> > Modified: head/sbin/newfs/newfs.c
> > 
> ==
> > --- head/sbin/newfs/newfs.c   Wed Nov 15 18:03:31 2017(r325859)
> > +++ head/sbin/newfs/newfs.c   Wed Nov 15 18:40:40 2017(r325860)
> > @@ -398,6 +398,10 @@ main(int argc, char *argv[])
> >   if (pp != NULL)
> >   pp->p_size *= secperblk;
> >   }
> > + if (getosreldate() < __FreeBSD_version) {
> > + warnx("%s is newer than the running kernel and may not be
> compatible",
> > + getprogname());
> > + }
> >   mkfs(pp, special);
> >   ufs_disk_close(&disk);
> >   if (!jflag)
> >
> >
>
> --
> Rod Grimes
> rgri...@freebsd.org

--
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: r325860 - head/sbin/newfs

2017-11-15 Thread Rodney W. Grimes

[ Charset UTF-8 unsupported, converting... ]
> On Nov 15, 2017 1:51 PM, "Rodney W. Grimes" 
> wrote:
> 
> [ Charset UTF-8 unsupported, converting... ]
> > On Nov 15, 2017 11:47 AM, "Rodney W. Grimes"  net>
> > wrote:
> >
> > > Author: emaste
> > > Date: Wed Nov 15 18:40:40 2017
> > > New Revision: 325860
> > > URL: https://svnweb.freebsd.org/changeset/base/325860
> > >
> > > Log:
> > >   newfs: warn if newer than kernel
> > >
> > >   Creating a UFS filesystem with a newfs newer than the running kernel,
> > >   and then mounting that filesystem, can lead to interesting failures.
> > >
> > >   Add a safety belt to explicitly warn when newfs is newer than the
> > >   running kernel.
> >
> > You should probably make the warning if (newer || older) as
> > either is likely to have interesting side effects, as are
> > mounting ufs file systems on different versions.
> >
> >
> > Not really. The cg stuff is really only a hassle for the case ed is
> testing
> > for.
> 
> Its too late now, but if you take a newer ufs with the cg
> stuff in them and mount it on an old system it politly well
> corrupt the data that the newer kernel needs.  So your right,
> doing this check in newfs wont do anything, but I can tell
> you this tiny little chain has been a PITA for people that
> move HD around
> 
> 
> Fsck automatically fixes issues like that. It recomputes the checksums.

Yes, but you do not know that this is needed until AFTER
you have mounted the "Clean" file system and started using it,
and then you get some nasty messages (though they are a little
better now than the original ones).  So then you have to
manually fire off a fsck on the volume...

> 
> > *Sigh*  why did not UFS grow a version number of its own
> > when things started to change other than UFS1 vs UFS2.
> >
> >
> > This isn't anything like those changes..
> 
> UFS changed in a way that makes it difficult to move
> UFS drives accross systems that are at differing versions.
> That IS bad no mater how you slice it.  I now have to make
> sure I fsck a drive when moving it from an old to new
> system to get the cg checksum stuff fixed.
> 
> 
> Except it isn't as bad as you say.

It is a distracting PITA, you probably dont move a
UFS formatted flash drive around between as many
differing systems as I do.


Oh, and can you please get a mail client that does
proper quoting?

> Rod Grimes
> rgri...@freebsd.org

-- 
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: r325860 - head/sbin/newfs

2017-11-15 Thread Warner Losh

On Nov 15, 2017 2:13 PM, "Rodney W. Grimes" 
wrote:

[ Charset UTF-8 unsupported, converting... ]
> On Nov 15, 2017 1:51 PM, "Rodney W. Grimes" 
> wrote:
>
> [ Charset UTF-8 unsupported, converting... ]
> > On Nov 15, 2017 11:47 AM, "Rodney W. Grimes"
 net>
> > wrote:
> >
> > > Author: emaste
> > > Date: Wed Nov 15 18:40:40 2017
> > > New Revision: 325860
> > > URL: https://svnweb.freebsd.org/changeset/base/325860
> > >
> > > Log:
> > >   newfs: warn if newer than kernel
> > >
> > >   Creating a UFS filesystem with a newfs newer than the running
kernel,
> > >   and then mounting that filesystem, can lead to interesting failures.
> > >
> > >   Add a safety belt to explicitly warn when newfs is newer than the
> > >   running kernel.
> >
> > You should probably make the warning if (newer || older) as
> > either is likely to have interesting side effects, as are
> > mounting ufs file systems on different versions.
> >
> >
> > Not really. The cg stuff is really only a hassle for the case ed is
> testing
> > for.
>
> Its too late now, but if you take a newer ufs with the cg
> stuff in them and mount it on an old system it politly well
> corrupt the data that the newer kernel needs.  So your right,
> doing this check in newfs wont do anything, but I can tell
> you this tiny little chain has been a PITA for people that
> move HD around
>
>
> Fsck automatically fixes issues like that. It recomputes the checksums.

Yes, but you do not know that this is needed until AFTER
you have mounted the "Clean" file system and started using it,
and then you get some nasty messages (though they are a little
better now than the original ones).  So then you have to
manually fire off a fsck on the volume...



It's just a minor annoyance no data is lost.



>
> > *Sigh*  why did not UFS grow a version number of its own
> > when things started to change other than UFS1 vs UFS2.
> >
> >
> > This isn't anything like those changes..
>
> UFS changed in a way that makes it difficult to move
> UFS drives accross systems that are at differing versions.
> That IS bad no mater how you slice it.  I now have to make
> sure I fsck a drive when moving it from an old to new
> system to get the cg checksum stuff fixed.
>
>
> Except it isn't as bad as you say.

It is a distracting PITA, you probably dont move a
UFS formatted flash drive around between as many
differing systems as I do.


I've been dealing with false positives for these messages at work...


Oh, and can you please get a mail client that does
proper quoting?


It's just gmail. And there's really no alternative :(

Warner

> Rod Grimes
> rgri...@freebsd.org

--
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: r325860 - head/sbin/newfs

2017-11-15 Thread Conrad Meyer

On Wed, Nov 15, 2017 at 1:23 PM, Warner Losh  wrote:
> On Nov 15, 2017 2:13 PM, "Rodney W. Grimes" 
> wrote:
> Oh, and can you please get a mail client that does
> proper quoting?
>
>
> It's just gmail. And there's really no alternative :(
>
> Warner

Hi,

Gmail does quoting just fine.  I'm using it right now.  Not sure what
you're doing wrong, but there is a way to use gmail and quote replies.
I don't do anything special when I hit "reply" on an email.

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

svn commit: r325864 - head/sys/netinet

2017-11-15 Thread Michael Tuexen

Author: tuexen
Date: Wed Nov 15 22:13:10 2017
New Revision: 325864
URL: https://svnweb.freebsd.org/changeset/base/325864

Log:
  Fix the handling of ERROR chunks which a lot of error causes.
  While there, clean up the code.
  Thanks to Felix Weinrank who found the bug by using fuzz-testing
  the SCTP userland stack.
  
  MFC after:1 week

Modified:
  head/sys/netinet/sctp_input.c

Modified: head/sys/netinet/sctp_input.c
==
--- head/sys/netinet/sctp_input.c   Wed Nov 15 19:14:44 2017
(r325863)
+++ head/sys/netinet/sctp_input.c   Wed Nov 15 22:13:10 2017
(r325864)
@@ -1098,19 +1098,11 @@ sctp_handle_shutdown_ack(struct sctp_shutdown_ack_chun
 #endif
 }
 
-/*
- * Skip past the param header and then we will find the chunk that caused the
- * problem. There are two possibilities ASCONF or FWD-TSN other than that and
- * our peer must be broken.
- */
 static void
-sctp_process_unrecog_chunk(struct sctp_tcb *stcb, struct sctp_paramhdr *phdr,
+sctp_process_unrecog_chunk(struct sctp_tcb *stcb, uint8_t chunk_type,
 struct sctp_nets *net)
 {
-   struct sctp_chunkhdr *chk;
-
-   chk = (struct sctp_chunkhdr *)((caddr_t)phdr + sizeof(*phdr));
-   switch (chk->chunk_type) {
+   switch (chunk_type) {
case SCTP_ASCONF_ACK:
case SCTP_ASCONF:
sctp_asconf_cleanup(stcb, net);
@@ -1121,8 +1113,8 @@ sctp_process_unrecog_chunk(struct sctp_tcb *stcb, stru
break;
default:
SCTPDBG(SCTP_DEBUG_INPUT2,
-   "Peer does not support chunk type %d(%x)??\n",
-   chk->chunk_type, (uint32_t)chk->chunk_type);
+   "Peer does not support chunk type %d (0x%x).\n",
+   chunk_type, chunk_type);
break;
}
 }
@@ -1134,12 +1126,9 @@ sctp_process_unrecog_chunk(struct sctp_tcb *stcb, stru
  * XXX: Is this the right thing to do?
  */
 static void
-sctp_process_unrecog_param(struct sctp_tcb *stcb, struct sctp_paramhdr *phdr)
+sctp_process_unrecog_param(struct sctp_tcb *stcb, uint16_t parameter_type)
 {
-   struct sctp_paramhdr *pbad;
-
-   pbad = phdr + 1;
-   switch (ntohs(pbad->param_type)) {
+   switch (parameter_type) {
/* pr-sctp draft */
case SCTP_PRSCTP_SUPPORTED:
stcb->asoc.prsctp_supported = 0;
@@ -1164,63 +1153,69 @@ sctp_process_unrecog_param(struct sctp_tcb *stcb, stru
break;
default:
SCTPDBG(SCTP_DEBUG_INPUT2,
-   "Peer does not support param type %d(%x)??\n",
-   pbad->param_type, (uint32_t)pbad->param_type);
+   "Peer does not support param type %d (0x%x)??\n",
+   parameter_type, parameter_type);
break;
}
 }
 
 static int
 sctp_handle_error(struct sctp_chunkhdr *ch,
-struct sctp_tcb *stcb, struct sctp_nets *net)
+struct sctp_tcb *stcb, struct sctp_nets *net, uint32_t limit)
 {
-   int chklen;
-   struct sctp_paramhdr *phdr;
-   uint16_t error, error_type;
-   uint16_t error_len;
+   struct sctp_error_cause *cause;
struct sctp_association *asoc;
-   int adjust;
+   uint32_t remaining_length, adjust;
+   uint16_t code, cause_code, cause_length;
 #if defined(__APPLE__) || defined(SCTP_SO_LOCK_TESTING)
struct socket *so;
 #endif
 
/* parse through all of the errors and process */
asoc = &stcb->asoc;
-   phdr = (struct sctp_paramhdr *)((caddr_t)ch +
+   cause = (struct sctp_error_cause *)((caddr_t)ch +
sizeof(struct sctp_chunkhdr));
-   chklen = ntohs(ch->chunk_length) - sizeof(struct sctp_chunkhdr);
-   error = 0;
-   while ((size_t)chklen >= sizeof(struct sctp_paramhdr)) {
+   remaining_length = ntohs(ch->chunk_length);
+   if (remaining_length > limit) {
+   remaining_length = limit;
+   }
+   if (remaining_length >= sizeof(struct sctp_chunkhdr)) {
+   remaining_length -= sizeof(struct sctp_chunkhdr);
+   } else {
+   remaining_length = 0;
+   }
+   code = 0;
+   while (remaining_length >= sizeof(struct sctp_error_cause)) {
/* Process an Error Cause */
-   error_type = ntohs(phdr->param_type);
-   error_len = ntohs(phdr->param_length);
-   if ((error_len > chklen) || (error_len == 0)) {
-   /* invalid param length for this param */
-   SCTPDBG(SCTP_DEBUG_INPUT1, "Bogus length in error 
param- chunk left:%d errorlen:%d\n",
-   chklen, error_len);
+   cause_code = ntohs(cause->code);
+   cause_length = ntohs(cause->length);
+   if ((cause_length > remaining_length) || (cause_length == 0)) {
+   /* Invalid cause length, possibly due to truncation. *

svn commit: r325865 - in head/sys: compat/freebsd32 kern

2017-11-15 Thread Gordon Tetlow

Author: gordon
Date: Wed Nov 15 22:30:21 2017
New Revision: 325865
URL: https://svnweb.freebsd.org/changeset/base/325865

Log:
  Properly bzero kldstat structure to prevent kernel information leak.
  
  Submitted by: kib
  Reported by:  TJ Corley
  Security: CVE-2017-1088

Modified:
  head/sys/compat/freebsd32/freebsd32_misc.c
  head/sys/kern/kern_linker.c

Modified: head/sys/compat/freebsd32/freebsd32_misc.c
==
--- head/sys/compat/freebsd32/freebsd32_misc.c  Wed Nov 15 22:13:10 2017
(r325864)
+++ head/sys/compat/freebsd32/freebsd32_misc.c  Wed Nov 15 22:30:21 2017
(r325865)
@@ -3331,8 +3331,8 @@ freebsd32_copyout_strings(struct image_params *imgp)
 int
 freebsd32_kldstat(struct thread *td, struct freebsd32_kldstat_args *uap)
 {
-   struct kld_file_stat stat;
-   struct kld32_file_stat stat32;
+   struct kld_file_stat *stat;
+   struct kld32_file_stat *stat32;
int error, version;
 
if ((error = copyin(&uap->stat->version, &version, sizeof(version)))
@@ -3342,17 +3342,22 @@ freebsd32_kldstat(struct thread *td, struct freebsd32_
version != sizeof(struct kld32_file_stat))
return (EINVAL);
 
-   error = kern_kldstat(td, uap->fileid, &stat);
-   if (error != 0)
-   return (error);
-
-   bcopy(&stat.name[0], &stat32.name[0], sizeof(stat.name));
-   CP(stat, stat32, refs);
-   CP(stat, stat32, id);
-   PTROUT_CP(stat, stat32, address);
-   CP(stat, stat32, size);
-   bcopy(&stat.pathname[0], &stat32.pathname[0], sizeof(stat.pathname));
-   return (copyout(&stat32, uap->stat, version));
+   stat = malloc(sizeof(*stat), M_TEMP, M_WAITOK | M_ZERO);
+   stat32 = malloc(sizeof(*stat32), M_TEMP, M_WAITOK | M_ZERO);
+   error = kern_kldstat(td, uap->fileid, stat);
+   if (error == 0) {
+   bcopy(&stat->name[0], &stat32->name[0], sizeof(stat->name));
+   CP(*stat, *stat32, refs);
+   CP(*stat, *stat32, id);
+   PTROUT_CP(*stat, *stat32, address);
+   CP(*stat, *stat32, size);
+   bcopy(&stat->pathname[0], &stat32->pathname[0],
+   sizeof(stat->pathname));
+   error = copyout(stat32, uap->stat, version);
+   }
+   free(stat, M_TEMP);
+   free(stat32, M_TEMP);
+   return (error);
 }
 
 int

Modified: head/sys/kern/kern_linker.c
==
--- head/sys/kern/kern_linker.c Wed Nov 15 22:13:10 2017(r325864)
+++ head/sys/kern/kern_linker.c Wed Nov 15 22:30:21 2017(r325865)
@@ -1229,7 +1229,7 @@ out:
 int
 sys_kldstat(struct thread *td, struct kldstat_args *uap)
 {
-   struct kld_file_stat stat;
+   struct kld_file_stat *stat;
int error, version;
 
/*
@@ -1242,10 +1242,12 @@ sys_kldstat(struct thread *td, struct kldstat_args *ua
version != sizeof(struct kld_file_stat))
return (EINVAL);
 
-   error = kern_kldstat(td, uap->fileid, &stat);
-   if (error != 0)
-   return (error);
-   return (copyout(&stat, uap->stat, version));
+   stat = malloc(sizeof(*stat), M_TEMP, M_WAITOK | M_ZERO);
+   error = kern_kldstat(td, uap->fileid, stat);
+   if (error == 0)
+   error = copyout(stat, uap->stat, version);
+   free(stat, M_TEMP);
+   return (error);
 }
 
 int
___
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: r325872 - head/sys/netipsec

2017-11-15 Thread Conrad Meyer

Author: cem
Date: Wed Nov 15 22:42:20 2017
New Revision: 325872
URL: https://svnweb.freebsd.org/changeset/base/325872

Log:
  ipsec: Use the same keysize values for HMAC as prior to r324017
  
  The HMAC construction natively permits any key size between 0 and the input
  block length. Before r324017, the auth_hash 'keysize' member was the hash
  output length, which was used by ipsec for key sizes. (Non-ipsec consumers
  need the ability to use other keysizes, hence, r324017.)
  
  The ipsec SADB code blindly uses the auth_hash 'keysize' member for both
  minimum and maximum key size, which is wrong (from an HMAC perspective).
  For now, just switch it to 'hashsize', which matches the existing
  expectations.
  
  Instead it should probably use the range [0, keysize]. But there may be
  other broken code in ipsec that rejects hashes with too small a minimum
  key size.
  
  Reported by:  olivier@
  Reviewed by:  olivier, no objection from ae
  Sponsored by: Dell EMC Isilon
  Differential Revision:https://reviews.freebsd.org/D12770

Modified:
  head/sys/netipsec/key.c

Modified: head/sys/netipsec/key.c
==
--- head/sys/netipsec/key.c Wed Nov 15 22:40:46 2017(r325871)
+++ head/sys/netipsec/key.c Wed Nov 15 22:42:20 2017(r325872)
@@ -6263,7 +6263,7 @@ key_getsizes_ah(const struct auth_hash *ah, int alg, u
 u_int16_t* max)
 {
 
-   *min = *max = ah->keysize;
+   *min = *max = ah->hashsize;
if (ah->keysize == 0) {
/*
 * Transform takes arbitrary key size but algorithm
___
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: r325880 - in head: share/man/man4 sys/dev/cxgbe

2017-11-15 Thread Navdeep Parhar

Author: np
Date: Wed Nov 15 23:48:02 2017
New Revision: 325880
URL: https://svnweb.freebsd.org/changeset/base/325880

Log:
  cxgbe(4):  Combine all _10g and _1g tunables and drop the suffix from
  their names.  The finer-grained knobs weren't practically useful.
  
  Sponsored by: Chelsio Communications

Modified:
  head/share/man/man4/cxgbe.4
  head/share/man/man4/cxgbev.4
  head/sys/dev/cxgbe/adapter.h
  head/sys/dev/cxgbe/t4_main.c
  head/sys/dev/cxgbe/t4_vf.c

Modified: head/share/man/man4/cxgbe.4
==
--- head/share/man/man4/cxgbe.4 Wed Nov 15 23:29:32 2017(r325879)
+++ head/share/man/man4/cxgbe.4 Wed Nov 15 23:48:02 2017(r325880)
@@ -172,37 +172,22 @@ types.
 A negative value for such a tunable instructs the driver to create
 up to that many queues if there are enough CPU cores available.
 .Bl -tag -width indent
-.It Va hw.cxgbe.ntxq10g
-Number of tx queues used for a 10Gb or higher-speed port.
+.It Va hw.cxgbe.ntxq
+Number of NIC tx queues used for a port.
 The default is 16 or the number
 of CPU cores in the system, whichever is less.
-.It Va hw.cxgbe.nrxq10g
-Number of rx queues used for a 10Gb or higher-speed port.
+.It Va hw.cxgbe.nrxq
+Number of NIC rx queues used for a port.
 The default is 8 or the number
 of CPU cores in the system, whichever is less.
-.It Va hw.cxgbe.ntxq1g
-Number of tx queues used for a 1Gb port.
-The default is 4 or the number
-of CPU cores in the system, whichever is less.
-.It Va hw.cxgbe.nrxq1g
-Number of rx queues used for a 1Gb port.
-The default is 2 or the number
-of CPU cores in the system, whichever is less.
-.It Va hw.cxgbe.nofldtxq10g
-Number of TOE tx queues used for a 10Gb or higher-speed port.
+.It Va hw.cxgbe.nofldtxq
+Number of TOE tx queues used for a port.
 The default is 8 or the
 number of CPU cores in the system, whichever is less.
-.It Va hw.cxgbe.nofldrxq10g
-Number of TOE rx queues used for a 10Gb or higher-speed port.
+.It Va hw.cxgbe.nofldrxq
+Number of TOE rx queues used for a port.
 The default is 2 or the
 number of CPU cores in the system, whichever is less.
-.It Va hw.cxgbe.nofldtxq1g
-Number of TOE tx queues used for a 1Gb port.
-The default is 2 or the
-number of CPU cores in the system, whichever is less.
-.It Va hw.cxgbe.nofldrxq1g
-Number of TOE rx queues used for a 1Gb port.
-The default is 1.
 .It Va hw.cxgbe.num_vis
 Number of virtual interfaces (VIs) created for each port.
 Each virtual interface creates a separate network interface.
@@ -213,8 +198,7 @@ name from the table above.
 Additional virtual interfaces use a single pair of queues
 for rx and tx as well an additional pair of queues for TOE rx and tx.
 The default is 1.
-.It Va hw.cxgbe.holdoff_timer_idx_10G
-.It Va hw.cxgbe.holdoff_timer_idx_1G
+.It Va hw.cxgbe.holdoff_timer_idx
 .It Va hw.cxgbe.holdoff_timer_idx_ofld
 Timer index value used to delay interrupts.
 The holdoff timer list has the values 1, 5, 10, 50, 100, and 200
@@ -224,8 +208,7 @@ holdoff_timer_idx_ofld applies to queues used for TOE 
 The default value is 1 which means the timer value is 5us.
 Different interfaces can be assigned different values at any time via the
 dev..X.holdoff_tmr_idx and dev..X.holdoff_tmr_idx_ofld sysctls.
-.It Va hw.cxgbe.holdoff_pktc_idx_10G
-.It Va hw.cxgbe.holdoff_pktc_idx_1G
+.It Va hw.cxgbe.holdoff_pktc_idx
 .It Va hw.cxgbe.holdoff_pktc_idx_ofld
 Packet-count index value used to delay interrupts.
 The packet-count list has the values 1, 8, 16, and 32 by default,

Modified: head/share/man/man4/cxgbev.4
==
--- head/share/man/man4/cxgbev.4Wed Nov 15 23:29:32 2017
(r325879)
+++ head/share/man/man4/cxgbev.4Wed Nov 15 23:48:02 2017
(r325880)
@@ -172,24 +172,15 @@ Tunables can be set at the
 prompt before booting the kernel or stored in
 .Xr loader.conf 5 .
 .Bl -tag -width indent
-.It Va hw.cxgbe.ntxq10g
-Number of tx queues used for a 10Gb or higher-speed port.
+.It Va hw.cxgbe.ntxq
+Number of tx queues used for a port.
 The default is 16 or the number
 of CPU cores in the system, whichever is less.
-.It Va hw.cxgbe.nrxq10g
-Number of rx queues used for a 10Gb or higher-speed port.
+.It Va hw.cxgbe.nrxq
+Number of rx queues used for a port.
 The default is 8 or the number
 of CPU cores in the system, whichever is less.
-.It Va hw.cxgbe.ntxq1g
-Number of tx queues used for a 1Gb port.
-The default is 4 or the number
-of CPU cores in the system, whichever is less.
-.It Va hw.cxgbe.nrxq1g
-Number of rx queues used for a 1Gb port.
-The default is 2 or the number
-of CPU cores in the system, whichever is less.
-.It Va hw.cxgbe.holdoff_timer_idx_10G
-.It Va hw.cxgbe.holdoff_timer_idx_1G
+.It Va hw.cxgbe.holdoff_timer_idx
 Timer index value used to delay interrupts.
 The holdoff timer list has the values 1, 5, 10, 50, 100, and 200
 by default (all values are in microseconds) and the index selects

svn commit: r325881 - head/share/man/man7

2017-11-15 Thread Warner Losh

Author: imp
Date: Wed Nov 15 23:51:17 2017
New Revision: 325881
URL: https://svnweb.freebsd.org/changeset/base/325881

Log:
  Fix some formatting issues, bump .Dd to today's date, don't use
  contractions, and make igor almost happy with this (two issues are
  false positives, and I'm not sure a synopsis makes sense).
  
  Sponsored by: Netflix

Modified:
  head/share/man/man7/arch.7

Modified: head/share/man/man7/arch.7
==
--- head/share/man/man7/arch.7  Wed Nov 15 23:48:02 2017(r325880)
+++ head/share/man/man7/arch.7  Wed Nov 15 23:51:17 2017(r325881)
@@ -26,7 +26,7 @@
 .\"
 .\" $FreeBSD$
 .\"
-.Dd May 16, 2017
+.Dd November 15, 2017
 .Dt ARCH 7
 .Os
 .Sh NAME
@@ -68,7 +68,7 @@ and
 .Vt ptrdiff_t
 should be avoided.
 .Pp
-On some architectures, e.g.
+On some architectures, e.g.,
 .Dv sparc64 ,
 .Dv powerpc
 and AIM variants of
@@ -367,7 +367,7 @@ It is often the same as
 just as one CPU architecture can be implemented by many different
 hardware platforms, one hardware platform may support multiple CPU
 architecture family members, though with different binaries.
-For example, 
+For example,
 .Dv MACHINE
 of i386 supported the IBM-AT hardware platform while the
 .Dv MACHINE
@@ -393,12 +393,12 @@ integers (endian).
 It may also encode a variation in the size of the integer or pointer.
 It may also encode a ISA revision.
 It may also encode hard versus soft floating point ABI and usage.
-It may also encode a variant ABI when there other factors don't
+It may also encode a variant ABI when there other factors do not
 uniquely define the ABI (eg, MIPS' n32 ABI).
 It, along with
 .Dv MACHINE, define the ABI used by the system.
 For example, the MIPS CPU processor family supports 9 different
-combinations encoding pointer size, endian and hard vs soft float (for
+combinations encoding pointer size, endian and hard versus soft float (for
 8 combinations) as well as N32 (which only ever had one variation of
 all these).
 Generally, the plain CPU name specifies the most common (or at least
@@ -429,15 +429,18 @@ framework).
 to build.
 It is used to optimize the build for a specific CPU / core that the
 binaries run on.
-Generally, this doesn't change the ABI, though it can be a fine line
+Generally, this does not change the ABI, though it can be a fine line
 between optimization for specific cases.
-.It Dv TARGET  Used to set Dv MACHINE in the top level Makefile for cross 
building.
+.It Dv TARGET  Used to set
+.Dv MACHINE
+in the top level Makefile for cross building.
 Unused outside of that scope.
 It is not passed down to the rest of the build.
-Makefiles outside of the top level shouldn't use it at all (though
+Makefiles outside of the top level should not use it at all (though
 some have their own private copy for hysterical raisons).
 .It Dv TARGET_ARCH Used to set
-.Dv MACHINE_ARCH by the top level Makefile for cross building.
+.Dv MACHINE_ARCH
+by the top level Makefile for cross building.
 Like
 .Dv TARGET , it is unused outside of that scope.
 .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"

Re: svn commit: r325765 - head/lib/libc/string

2017-11-15 Thread Mark Millard

Bruce Evans brde at optusnet.com.au wrote on
Tue Nov 14 12:41:50 UTC 2017 :

> - memcpy.3.  It was already documented in the BUGS section that memcpy() is
>implemented as bcopy() and therefore the "strings" "may overlap" [then
>portability considerations due to this].  This is buggier than before:
>- old bug: only the MI implementation of memcpy() clearly implements
>  memcpy() as bcopy().  The amd64, i386 and arm MD implementations
>  do the same.

head/sys/arm/arm/support.S ( -r283366 ) has

394 ENTRY(bcopy)
395 /* switch the source and destination registers */
396 eor r0, r1, r0
397 eor r1, r0, r1
398 eor r0, r1, r0
399 EENTRY(memmove)
400 /* Do the buffers overlap? */
401 cmp r0, r1
402 RETeq   /* Bail now if src/dst are the same */
403 subcc   r3, r0, r1  /* if (dst > src) r3 = dst - src */
404 subcs   r3, r1, r0  /* if (src > dsr) r3 = src - dst */
405 cmp r3, r2  /* if (r3 < len) we have an overlap */
406 bcc PIC_SYM(_C_LABEL(memcpy), PLT)
. . .


head/lib/libc/arm/string/memmove.S ( -r288373 ) has:

37  #ifndef _BCOPY
38  /* LINTSTUB: Func: void *memmove(void *, const void *, size_t) */
39  ENTRY(memmove)
40  #else
41  /* bcopy = memcpy/memmove with arguments reversed. */
42  /* LINTSTUB: Func: void bcopy(void *, void *, size_t) */
43  ENTRY(bcopy)
44  /* switch the source and destination registers */
45  eor r0, r1, r0 
46  eor r1, r0, r1 
47  eor r0, r1, r0 
48  #endif
49  /* Do the buffers overlap? */
50  cmp r0, r1
51  it  eq
52  RETeq   /* Bail now if src/dst are the same */
53  ite cc
54  subcc   r3, r0, r1  /* if (dst > src) r3 = dst - src */
55  subcs   r3, r1, r0  /* if (src > dsr) r3 = src - dst */
56  cmp r3, r2  /* if (r3 < len) we have an overlap */
57  bcc PIC_SYM(_C_LABEL(memcpy), PLT)
. . .

It looks to me like bcopy and memmove call memcpy under
some conditions, not the other way around. I did not
notice any code in memcpy going back to bcopy (or
memmove) in either area. (That might have lead to
recursion as things are.)

Also netbsd "fixed" the above code for picking when to
use memcpy a few years ago (without making the comments
accurately track the details as I remember). By my
understanding the new netbsd code was the correct variant
but others commenting for bugzilla 217065 disagreed.

(My comments for 217065 were clearly as I was figuring
things out for unfamiliar material. So they are not
simple/clean. But I still reach the same conclusions
as I eventually did there.)

Another issue is if compilers (clang, gcc) are well
controlled for code substitutions to preserve
supposed FreeBSD rules about where overlaps
are well defined. The library code might not be all
there is to it as far as behavior goes for
compiled C/C++ source code.



head/sys/arm64/arm64/ is similar for bcopy/memmove
calling memcpy (but head/lib/libc/amd64/string/ is
not):

head/sys/arm64/arm64/memmove.S ( -r307909 ) has:

87  ENTRY(bcopy)
88  /* Switch the input pointers when called as bcopy */
89  mov x3, x1
90  mov x1, x0
91  mov x0, x3
92  EENTRY(memmove)
93  sub tmp1, dstin, src
94  cmp count, 96
95  ccmptmp1, count, 2, hi
96  b.hsmemcpy
. . .

head/lib/libc/amd64/string/bcopy.S has:

44  #ifdef MEMCOPY
45  ENTRY(memcpy)
46  #else
47  #ifdef MEMMOVE
48  ENTRY(memmove)
49  #else
50  ENTRY(bcopy)
51  #endif
52  #endif
53  #if defined(MEMCOPY) || defined(MEMMOVE)
54  movq%rdi,%rax   /* return dst */
55  #else
56  xchgq   %rdi,%rsi
57  #endif
. . . (the rest being the same for the 3 routines) . . .

> mips is backwards for bcopy() and implements it as
>  memmove().  mips has 2 separate memcpy*.S files, one for plain arm
>  and one for xscale.  The plain arm one is smaller than memmove.S,
>  so presumably doesn't support overlapped copies.  The xscale one
>  is much larger, so has space for overlapped copies and many optimizations
>  that no longer work.  I don't know what it does.


The mix of "mips" and "arm"/"xscale" above confused me. Looking
around this seems to be referencing head/lib/libc/arm/string/
materials instead of head/lib/libc/mips/string/ or
head/sys/mips/mips/ materials.

===
Mark Millard
markmi at dsl-only.net

___
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: r325860 - head/sbin/newfs

2017-11-15 Thread Ed Maste

On 15 November 2017 at 13:47, Rodney W. Grimes
 wrote:
>> Author: emaste
>> Date: Wed Nov 15 18:40:40 2017
>> New Revision: 325860
>> URL: https://svnweb.freebsd.org/changeset/base/325860
>>
>> Log:
>>   newfs: warn if newer than kernel
>>
>>   Creating a UFS filesystem with a newfs newer than the running kernel,
>>   and then mounting that filesystem, can lead to interesting failures.
>>
>>   Add a safety belt to explicitly warn when newfs is newer than the
>>   running kernel.
>
> You should probably make the warning if (newer || older) as
> either is likely to have interesting side effects, as are
> mounting ufs file systems on different versions.

Why would an older newfs cause trouble? Forward compatibility should be 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"

svn commit: r325882 - head/share/man/man7

2017-11-15 Thread Warner Losh

Author: imp
Date: Thu Nov 16 00:19:44 2017
New Revision: 325882
URL: https://svnweb.freebsd.org/changeset/base/325882

Log:
  Use better wording: change there to the and define to defines.
  Also fix a run-a-way macro invocation of Dv.
  
  Noticed by: matteo@

Modified:
  head/share/man/man7/arch.7

Modified: head/share/man/man7/arch.7
==
--- head/share/man/man7/arch.7  Wed Nov 15 23:51:17 2017(r325881)
+++ head/share/man/man7/arch.7  Thu Nov 16 00:19:44 2017(r325882)
@@ -393,10 +393,11 @@ integers (endian).
 It may also encode a variation in the size of the integer or pointer.
 It may also encode a ISA revision.
 It may also encode hard versus soft floating point ABI and usage.
-It may also encode a variant ABI when there other factors do not
-uniquely define the ABI (eg, MIPS' n32 ABI).
+It may also encode a variant ABI when the other factors do not
+uniquely define the ABI (e.g., MIPS' n32 ABI).
 It, along with
-.Dv MACHINE, define the ABI used by the system.
+.Dv MACHINE ,
+defines the ABI used by the system.
 For example, the MIPS CPU processor family supports 9 different
 combinations encoding pointer size, endian and hard versus soft float (for
 8 combinations) as well as N32 (which only ever had one variation of
___
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: r325860 - head/sbin/newfs

2017-11-15 Thread Warner Losh

On Wed, Nov 15, 2017 at 5:05 PM, Ed Maste  wrote:

> On 15 November 2017 at 13:47, Rodney W. Grimes
>  wrote:
> >> Author: emaste
> >> Date: Wed Nov 15 18:40:40 2017
> >> New Revision: 325860
> >> URL: https://svnweb.freebsd.org/changeset/base/325860
> >>
> >> Log:
> >>   newfs: warn if newer than kernel
> >>
> >>   Creating a UFS filesystem with a newfs newer than the running kernel,
> >>   and then mounting that filesystem, can lead to interesting failures.
> >>
> >>   Add a safety belt to explicitly warn when newfs is newer than the
> >>   running kernel.
> >
> > You should probably make the warning if (newer || older) as
> > either is likely to have interesting side effects, as are
> > mounting ufs file systems on different versions.
>
> Why would an older newfs cause trouble? Forward compatibility should be
> fine
>

The only scenario that 'old' would cause problems is that if you did a
newfs with a new binary on a new kernel, mounted the file system, wrote
files to it, then rebooted with an old kernel, mounted the filesystem
there, writing new files to it, and then unmounting and running with a new
kernel. At that point, the new kernel will start printing cg mismatch
errors and will limit its allocation to CGs that weren't modified when it
was mounted under the old kernel (since those CGs will have changed their
checksum, but no new checksum will have been computed). The root cause here
is that the old kernel doesn't know that the CK_CYLGRP tags the cg as
having the proper hash metadata associated with them.

It sounds like this is exactly what Rod does on a regular basis as he's
taking a disk from one system to another and back again, maybe for file
transport on a USB stick. It's not a crazy scenario. At this point, there's
the annoyance of the messages, but that will be fixed with an fsck.

The scenario where I have a newer kernel and an old newfs will be a nop:
the old newfs won't set CK_CYLGRP, so the kernel won't checksum, so there
won't be any mismatch possible.

I'm not sure that the new safety belt is reasonable. Today it's fine, but
over time it will start producing false-positive warnings since the real
issue is just before/after the cg change, not old/new in general. I'd be
tempted to make a check against newfs being >= 1200046 while the kernel is
< 1200046. There wasn't a specific bump for this change to sys/param.h, but
this version was bumped within a few hours of Kirk's change.

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: r325860 - head/sbin/newfs

2017-11-15 Thread Warner Losh

On Wed, Nov 15, 2017 at 2:28 PM, Conrad Meyer  wrote:

> On Wed, Nov 15, 2017 at 1:23 PM, Warner Losh  wrote:
> > On Nov 15, 2017 2:13 PM, "Rodney W. Grimes"  net>
> > wrote:
> > Oh, and can you please get a mail client that does
> > proper quoting?
> >
> >
> > It's just gmail. And there's really no alternative :(
> >
> > Warner
>
> Hi,
>
> Gmail does quoting just fine.  I'm using it right now.  Not sure what
> you're doing wrong, but there is a way to use gmail and quote replies.
> I don't do anything special when I hit "reply" on an email.
>

I usually don't either, but some of my messages today were from my phone.
Maybe that's the client I should avoid.

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"

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

2017-11-15 Thread Navdeep Parhar

Author: np
Date: Thu Nov 16 01:33:53 2017
New Revision: 325883
URL: https://svnweb.freebsd.org/changeset/base/325883

Log:
  cxgbe(4): Sanitize t4_num_vis during MOD_LOAD like all other t4_*
  tunables.  Add num_vis to the intrs_and_queues structure as it affects
  the number of interrupts requested and queues created.  In future
  cfg_itype_and_nqueues might lower it incrementally instead of going
  straight to 1 when enough interrupts aren't available.
  
  Sponsored by: Chelsio Communications

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

Modified: head/sys/dev/cxgbe/t4_main.c
==
--- head/sys/dev/cxgbe/t4_main.cThu Nov 16 00:19:44 2017
(r325882)
+++ head/sys/dev/cxgbe/t4_main.cThu Nov 16 01:33:53 2017
(r325883)
@@ -466,6 +466,7 @@ static int vi_mac_funcs[] = {
 
 struct intrs_and_queues {
uint16_t intr_type; /* INTx, MSI, or MSI-X */
+   uint16_t num_vis;   /* number of VIs for each port */
uint16_t nirq;  /* Total # of vectors */
uint16_t intr_flags;/* Interrupt flags for each port */
uint16_t ntxq;  /* # of NIC txq's for each port */
@@ -505,8 +506,7 @@ static int fwmtype_to_hwmtype(int);
 static int validate_mt_off_len(struct adapter *, int, uint32_t, int,
 uint32_t *);
 static int fixup_devlog_params(struct adapter *);
-static int cfg_itype_and_nqueues(struct adapter *, int, int,
-struct intrs_and_queues *);
+static int cfg_itype_and_nqueues(struct adapter *, struct intrs_and_queues *);
 static int prep_firmware(struct adapter *);
 static int partition_resources(struct adapter *, const struct firmware *,
 const char *);
@@ -965,24 +965,6 @@ t4_attach(device_t dev)
goto done; /* error message displayed already */
 
/*
-* Number of VIs to create per-port.  The first VI is the "main" regular
-* VI for the port.  The rest are additional virtual interfaces on the
-* same physical port.  Note that the main VI does not have native
-* netmap support but the extra VIs do.
-*
-* Limit the number of VIs per port to the number of available
-* MAC addresses per port.
-*/
-   if (t4_num_vis >= 1)
-   num_vis = t4_num_vis;
-   else
-   num_vis = 1;
-   if (num_vis > nitems(vi_mac_funcs)) {
-   num_vis = nitems(vi_mac_funcs);
-   device_printf(dev, "Number of VIs limited to %d\n", num_vis);
-   }
-
-   /*
 * First pass over all the ports - allocate VIs and initialize some
 * basic parameters like mac address, port type, etc.
 */
@@ -999,7 +981,7 @@ t4_attach(device_t dev)
 * XXX: vi[0] is special so we can't delay this allocation until
 * pi->nvi's final value is known.
 */
-   pi->vi = malloc(sizeof(struct vi_info) * num_vis, M_CXGBE,
+   pi->vi = malloc(sizeof(struct vi_info) * t4_num_vis, M_CXGBE,
M_ZERO | M_WAITOK);
 
/*
@@ -1040,12 +1022,11 @@ t4_attach(device_t dev)
 * Interrupt type, # of interrupts, # of rx/tx queues, etc.
 */
nports = sc->params.nports;
-   rc = cfg_itype_and_nqueues(sc, nports, num_vis, &iaq);
+   rc = cfg_itype_and_nqueues(sc, &iaq);
if (rc != 0)
goto done; /* error message displayed already */
-   if (iaq.nrxq_vi + iaq.nofldrxq_vi + iaq.nnmrxq_vi == 0)
-   num_vis = 1;
 
+   num_vis = iaq.num_vis;
sc->intr_type = iaq.intr_type;
sc->intr_count = iaq.nirq;
 
@@ -2662,15 +2643,16 @@ fixup_devlog_params(struct adapter *sc)
 }
 
 static int
-cfg_itype_and_nqueues(struct adapter *sc, int nports, int num_vis,
-struct intrs_and_queues *iaq)
+cfg_itype_and_nqueues(struct adapter *sc, struct intrs_and_queues *iaq)
 {
-   int rc, itype, navail, nrxq, n;
+   int rc, itype, navail, nrxq, nports, n;
int nofldrxq = 0;
 
+   nports = sc->params.nports;
MPASS(nports > 0);
 
bzero(iaq, sizeof(*iaq));
+   iaq->num_vis = t4_num_vis;
iaq->ntxq = t4_ntxq;
iaq->ntxq_vi = t4_ntxq_vi;
iaq->nrxq = nrxq = t4_nrxq;
@@ -2716,9 +2698,9 @@ restart:
 */
iaq->nirq = T4_EXTRA_INTR;
iaq->nirq += nports * (nrxq + nofldrxq);
-   iaq->nirq += nports * (num_vis - 1) *
+   iaq->nirq += nports * (iaq->num_vis - 1) *
max(iaq->nrxq_vi, iaq->nnmrxq_vi);  /* See comment above. */
-   iaq->nirq += nports * (num_vis - 1) * iaq->nofldrxq_vi;
+   iaq->nirq += nports * (iaq->num_vis - 1) * iaq->nofldrxq_vi;
if (iaq->nirq <= navail &&
(itype != INTR_MSI || powerof2(iaq->nirq))) {
iaq->intr_flags = INTR_ALL;
@@ -2726,15 +2708,15 @@ restart:

Re: svn commit: r325860 - head/sbin/newfs

2017-11-15 Thread Ed Maste

On 15 November 2017 at 19:36, Warner Losh  wrote:
>
> On Wed, Nov 15, 2017 at 5:05 PM, Ed Maste  wrote:
>>
>> On 15 November 2017 at 13:47, Rodney W. Grimes
>>  wrote:
>> >> Author: emaste
>> >> Date: Wed Nov 15 18:40:40 2017
>> >> New Revision: 325860
>> >> URL: https://svnweb.freebsd.org/changeset/base/325860
>> >>
>> >> Log:
>> >>   newfs: warn if newer than kernel
>> >>
>> >>   Creating a UFS filesystem with a newfs newer than the running kernel,
>> >>   and then mounting that filesystem, can lead to interesting failures.
>> >>
>> >>   Add a safety belt to explicitly warn when newfs is newer than the
>> >>   running kernel.
>> >
>> > You should probably make the warning if (newer || older) as
>> > either is likely to have interesting side effects, as are
>> > mounting ufs file systems on different versions.
>>
>> Why would an older newfs cause trouble? Forward compatibility should be
>> fine
>
> The only scenario that 'old' would cause problems is that if you did a newfs
> with a new binary on a new kernel, mounted the file system, wrote files to
> it, then rebooted with an old kernel, mounted the filesystem there, writing
> new files to it, and then unmounting and running with a new kernel.

Right, but that's not older newfs. AFAICT there's no reason at all for
a (newer || older) warning.

> I'm not sure that the new safety belt is reasonable. Today it's fine, but
> over time it will start producing false-positive warnings since the real
> issue is just before/after the cg change, not old/new in general. I'd be
> tempted to make a check against newfs being >= 1200046 while the kernel is <
> 1200046. There wasn't a specific bump for this change to sys/param.h, but
> this version was bumped within a few hours of Kirk's change.

Well, we don't in general support using a userland newer than the
running kernel, other than on a best-effort basis to facilitate
upgrades and development. This one is only a warning so I don't see
much harm in leaving it in place, and it would catch any new cases of
a similar nature. If such a warning was already in place we might have
avoided the issue where our snapshots produced checksum mismatch
messages. But I don't have a strong objection to a hardcoded version
check.
___
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: r325884 - head/sys/dev/cxgbe

2017-11-15 Thread Navdeep Parhar

Author: np
Date: Thu Nov 16 02:42:37 2017
New Revision: 325884
URL: https://svnweb.freebsd.org/changeset/base/325884

Log:
  cxgbe(4): Remove rsrv_noflowq from intrs_and_queues structure as it does
  not influence or get affected by the number of interrupts or queues.
  
  Sponsored by: Chelsio Communications

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

Modified: head/sys/dev/cxgbe/t4_main.c
==
--- head/sys/dev/cxgbe/t4_main.cThu Nov 16 01:33:53 2017
(r325883)
+++ head/sys/dev/cxgbe/t4_main.cThu Nov 16 02:42:37 2017
(r325884)
@@ -471,7 +471,6 @@ struct intrs_and_queues {
uint16_t intr_flags;/* Interrupt flags for each port */
uint16_t ntxq;  /* # of NIC txq's for each port */
uint16_t nrxq;  /* # of NIC rxq's for each port */
-   uint16_t rsrv_noflowq;  /* Flag whether to reserve queue 0 */
uint16_t nofldtxq;  /* # of TOE txq's for each port */
uint16_t nofldrxq;  /* # of TOE rxq's for each port */
 
@@ -1124,7 +1123,7 @@ t4_attach(device_t dev)
tqidx += vi->ntxq;
 
if (j == 0 && vi->ntxq > 1)
-   vi->rsrv_noflowq = iaq.rsrv_noflowq ? 1 : 0;
+   vi->rsrv_noflowq = t4_rsrv_noflowq ? 1 : 0;
else
vi->rsrv_noflowq = 0;
 
@@ -2657,7 +2656,6 @@ cfg_itype_and_nqueues(struct adapter *sc, struct intrs
iaq->ntxq_vi = t4_ntxq_vi;
iaq->nrxq = nrxq = t4_nrxq;
iaq->nrxq_vi = t4_nrxq_vi;
-   iaq->rsrv_noflowq = t4_rsrv_noflowq;
 #ifdef TCP_OFFLOAD
if (is_offload(sc)) {
iaq->nofldtxq = t4_nofldtxq;
___
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: r316980 - head/contrib/zstd/programs

2017-11-15 Thread Conrad Meyer

Please revert this change.

First, it introduces the POLA-violating behavior that zstdcat deletes
its source files.  This is not how zcat/bzcat behaves.

Second, it introduces a needless behavioral difference between FreeBSD
zstd and the rest of the world's zstd.  The zstd documentation we ship
continues to claim that zstd preserves source files by default, yet
this change makes that documentation exactly backwards.  While we can
change FreeBSD's documentation to accommodate the change, we can't
change Google results.

Thanks,
Conrad

On Sat, Apr 15, 2017 at 1:15 PM, Baptiste Daroussin  wrote:
> Author: bapt
> Date: Sat Apr 15 20:15:44 2017
> New Revision: 316980
> URL: https://svnweb.freebsd.org/changeset/base/316980
>
> Log:
>   Change some default to make zstd a dropin replacement for gzip,bzip etc
>   in most cases
>
>   Changes ares:
>   - quiet by default
>   - remove the source files one compression completion by default
>
> Modified:
>   head/contrib/zstd/programs/fileio.c
>   head/contrib/zstd/programs/zstdcli.c
>
> Modified: head/contrib/zstd/programs/fileio.c
> ==
> --- head/contrib/zstd/programs/fileio.c Sat Apr 15 20:06:24 2017
> (r316979)
> +++ head/contrib/zstd/programs/fileio.c Sat Apr 15 20:15:44 2017
> (r316980)
> @@ -138,7 +138,7 @@ static U32 g_dictIDFlag = 1;
>  void FIO_setDictIDFlag(unsigned dictIDFlag) { g_dictIDFlag = dictIDFlag; }
>  static U32 g_checksumFlag = 1;
>  void FIO_setChecksumFlag(unsigned checksumFlag) { g_checksumFlag = 
> checksumFlag; }
> -static U32 g_removeSrcFile = 0;
> +static U32 g_removeSrcFile = 1;
>  void FIO_setRemoveSrcFile(unsigned flag) { g_removeSrcFile = (flag>0); }
>  static U32 g_memLimit = 0;
>  void FIO_setMemLimit(unsigned memLimit) { g_memLimit = memLimit; }
>
> Modified: head/contrib/zstd/programs/zstdcli.c
> ==
> --- head/contrib/zstd/programs/zstdcli.cSat Apr 15 20:06:24 2017  
>   (r316979)
> +++ head/contrib/zstd/programs/zstdcli.cSat Apr 15 20:15:44 2017  
>   (r316980)
> @@ -61,7 +61,7 @@
>  #define MB *(1 <<20)
>  #define GB *(1U<<30)
>
> -#define DEFAULT_DISPLAY_LEVEL 2
> +#define DEFAULT_DISPLAY_LEVEL 1
>
>  static const char*g_defaultDictName = "dictionary";
>  static const unsigned g_defaultMaxDictSize = 110 KB;
>
___
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: r325860 - head/sbin/newfs

2017-11-15 Thread Warner Losh

On Wed, Nov 15, 2017 at 6:46 PM, Ed Maste  wrote:

> On 15 November 2017 at 19:36, Warner Losh  wrote:
> >
> > On Wed, Nov 15, 2017 at 5:05 PM, Ed Maste  wrote:
> >>
> >> On 15 November 2017 at 13:47, Rodney W. Grimes
> >>  wrote:
> >> >> Author: emaste
> >> >> Date: Wed Nov 15 18:40:40 2017
> >> >> New Revision: 325860
> >> >> URL: https://svnweb.freebsd.org/changeset/base/325860
> >> >>
> >> >> Log:
> >> >>   newfs: warn if newer than kernel
> >> >>
> >> >>   Creating a UFS filesystem with a newfs newer than the running
> kernel,
> >> >>   and then mounting that filesystem, can lead to interesting
> failures.
> >> >>
> >> >>   Add a safety belt to explicitly warn when newfs is newer than the
> >> >>   running kernel.
> >> >
> >> > You should probably make the warning if (newer || older) as
> >> > either is likely to have interesting side effects, as are
> >> > mounting ufs file systems on different versions.
> >>
> >> Why would an older newfs cause trouble? Forward compatibility should be
> >> fine
> >
> > The only scenario that 'old' would cause problems is that if you did a
> newfs
> > with a new binary on a new kernel, mounted the file system, wrote files
> to
> > it, then rebooted with an old kernel, mounted the filesystem there,
> writing
> > new files to it, and then unmounting and running with a new kernel.
>
> Right, but that's not older newfs. AFAICT there's no reason at all for
> a (newer || older) warning.


I concur.

> I'm not sure that the new safety belt is reasonable. Today it's fine, but
> > over time it will start producing false-positive warnings since the real
> > issue is just before/after the cg change, not old/new in general. I'd be
> > tempted to make a check against newfs being >= 1200046 while the kernel
> is <
> > 1200046. There wasn't a specific bump for this change to sys/param.h, but
> > this version was bumped within a few hours of Kirk's change.
>
> Well, we don't in general support using a userland newer than the
> running kernel, other than on a best-effort basis to facilitate
> upgrades and development. This one is only a warning so I don't see
> much harm in leaving it in place, and it would catch any new cases of
> a similar nature. If such a warning was already in place we might have
> avoided the issue where our snapshots produced checksum mismatch
> messages. But I don't have a strong objection to a hardcoded version
> check.
>

What would have fixed the snapshot isn't a warning that nobody will notice.
But rather something like the following:

diff --git a/sbin/fsck_ffs/pass5.c b/sbin/fsck_ffs/pass5.c
index 16c46bece00..06e1838a7f1 100644
--- a/sbin/fsck_ffs/pass5.c
+++ b/sbin/fsck_ffs/pass5.c
@@ -73,6 +73,7 @@ pass5(void)
newcg->cg_niblk = fs->fs_ipg;
if (preen == 0 && yflag == 0 && fs->fs_magic == FS_UFS2_MAGIC &&
fswritefd != -1 && (fs->fs_metackhash & CK_CYLGRP) == 0 &&
+   getosreldate() >= 1200046 &&
reply("ADD CYLINDER GROUP CHECKSUM PROTECTION") != 0) {
fs->fs_metackhash |= CK_CYLGRP;
rewritecg = 1;
diff --git a/sbin/newfs/mkfs.c b/sbin/newfs/mkfs.c
index f68c42ec6b3..0e7ee539265 100644
--- a/sbin/newfs/mkfs.c
+++ b/sbin/newfs/mkfs.c
@@ -495,7 +495,7 @@ restart:
/*
 * Set flags for metadata that is being check-hashed.
 */
-   if (Oflag > 1)
+   if (Oflag > 1 && getosreldate() >= 1200046)
sblock.fs_metackhash = CK_CYLGRP;

/*

which would avoid setting the flag on a problematical kernel. Here forward
compat is easy, and the consequences are scary messages, so I think we
should do something more like the above. I don't think we need some kind of
"do it anyway" override flag. since that doesn't fit well with the rest of
UFS "works by default where we can figure it out" philosophy.

I'll cleanup the above with a #define for 1200046. I've cc'd Kirk to see
what he thinks of the idea. It generally fits with what we've done in the
past for forward compat that's easy but protects the user from harshness.

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: r325860 - head/sbin/newfs

2017-11-15 Thread Warner Losh

On Wed, Nov 15, 2017 at 10:17 PM, Warner Losh  wrote:

>
>
> On Wed, Nov 15, 2017 at 6:46 PM, Ed Maste  wrote:
>
>> On 15 November 2017 at 19:36, Warner Losh  wrote:
>> >
>> > On Wed, Nov 15, 2017 at 5:05 PM, Ed Maste  wrote:
>> >>
>> >> On 15 November 2017 at 13:47, Rodney W. Grimes
>> >>  wrote:
>> >> >> Author: emaste
>> >> >> Date: Wed Nov 15 18:40:40 2017
>> >> >> New Revision: 325860
>> >> >> URL: https://svnweb.freebsd.org/changeset/base/325860
>> >> >>
>> >> >> Log:
>> >> >>   newfs: warn if newer than kernel
>> >> >>
>> >> >>   Creating a UFS filesystem with a newfs newer than the running
>> kernel,
>> >> >>   and then mounting that filesystem, can lead to interesting
>> failures.
>> >> >>
>> >> >>   Add a safety belt to explicitly warn when newfs is newer than the
>> >> >>   running kernel.
>> >> >
>> >> > You should probably make the warning if (newer || older) as
>> >> > either is likely to have interesting side effects, as are
>> >> > mounting ufs file systems on different versions.
>> >>
>> >> Why would an older newfs cause trouble? Forward compatibility should be
>> >> fine
>> >
>> > The only scenario that 'old' would cause problems is that if you did a
>> newfs
>> > with a new binary on a new kernel, mounted the file system, wrote files
>> to
>> > it, then rebooted with an old kernel, mounted the filesystem there,
>> writing
>> > new files to it, and then unmounting and running with a new kernel.
>>
>> Right, but that's not older newfs. AFAICT there's no reason at all for
>> a (newer || older) warning.
>
>
> I concur.
>
> > I'm not sure that the new safety belt is reasonable. Today it's fine, but
>> > over time it will start producing false-positive warnings since the real
>> > issue is just before/after the cg change, not old/new in general. I'd be
>> > tempted to make a check against newfs being >= 1200046 while the kernel
>> is <
>> > 1200046. There wasn't a specific bump for this change to sys/param.h,
>> but
>> > this version was bumped within a few hours of Kirk's change.
>>
>> Well, we don't in general support using a userland newer than the
>> running kernel, other than on a best-effort basis to facilitate
>> upgrades and development. This one is only a warning so I don't see
>> much harm in leaving it in place, and it would catch any new cases of
>> a similar nature. If such a warning was already in place we might have
>> avoided the issue where our snapshots produced checksum mismatch
>> messages. But I don't have a strong objection to a hardcoded version
>> check.
>>
>
> What would have fixed the snapshot isn't a warning that nobody will
> notice. But rather something like the following:
>
> diff --git a/sbin/fsck_ffs/pass5.c b/sbin/fsck_ffs/pass5.c
> index 16c46bece00..06e1838a7f1 100644
> --- a/sbin/fsck_ffs/pass5.c
> +++ b/sbin/fsck_ffs/pass5.c
> @@ -73,6 +73,7 @@ pass5(void)
> newcg->cg_niblk = fs->fs_ipg;
> if (preen == 0 && yflag == 0 && fs->fs_magic == FS_UFS2_MAGIC &&
> fswritefd != -1 && (fs->fs_metackhash & CK_CYLGRP) == 0 &&
> +   getosreldate() >= 1200046 &&
> reply("ADD CYLINDER GROUP CHECKSUM PROTECTION") != 0) {
> fs->fs_metackhash |= CK_CYLGRP;
> rewritecg = 1;
> diff --git a/sbin/newfs/mkfs.c b/sbin/newfs/mkfs.c
> index f68c42ec6b3..0e7ee539265 100644
> --- a/sbin/newfs/mkfs.c
> +++ b/sbin/newfs/mkfs.c
> @@ -495,7 +495,7 @@ restart:
> /*
>  * Set flags for metadata that is being check-hashed.
>  */
> -   if (Oflag > 1)
> +   if (Oflag > 1 && getosreldate() >= 1200046)
> sblock.fs_metackhash = CK_CYLGRP;
>
> /*
>
> which would avoid setting the flag on a problematical kernel. Here forward
> compat is easy, and the consequences are scary messages, so I think we
> should do something more like the above. I don't think we need some kind of
> "do it anyway" override flag. since that doesn't fit well with the rest of
> UFS "works by default where we can figure it out" philosophy.
>
> I'll cleanup the above with a #define for 1200046. I've cc'd Kirk to see
> what he thinks of the idea. It generally fits with what we've done in the
> past for forward compat that's easy but protects the user from harshness.
>

I've gone ahead and tidied it up in https://reviews.freebsd.org/D13114 for
anybody that's interested.

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: r325860 - head/sbin/newfs

2017-11-15 Thread John Baldwin

On Wednesday, November 15, 2017 10:17:27 PM Warner Losh wrote:
> On Wed, Nov 15, 2017 at 6:46 PM, Ed Maste  wrote:
> 
> > On 15 November 2017 at 19:36, Warner Losh  wrote:
> > >
> > > On Wed, Nov 15, 2017 at 5:05 PM, Ed Maste  wrote:
> > >>
> > >> On 15 November 2017 at 13:47, Rodney W. Grimes
> > >>  wrote:
> > >> >> Author: emaste
> > >> >> Date: Wed Nov 15 18:40:40 2017
> > >> >> New Revision: 325860
> > >> >> URL: https://svnweb.freebsd.org/changeset/base/325860
> > >> >>
> > >> >> Log:
> > >> >>   newfs: warn if newer than kernel
> > >> >>
> > >> >>   Creating a UFS filesystem with a newfs newer than the running
> > kernel,
> > >> >>   and then mounting that filesystem, can lead to interesting
> > failures.
> > >> >>
> > >> >>   Add a safety belt to explicitly warn when newfs is newer than the
> > >> >>   running kernel.
> > >> >
> > >> > You should probably make the warning if (newer || older) as
> > >> > either is likely to have interesting side effects, as are
> > >> > mounting ufs file systems on different versions.
> > >>
> > >> Why would an older newfs cause trouble? Forward compatibility should be
> > >> fine
> > >
> > > The only scenario that 'old' would cause problems is that if you did a
> > newfs
> > > with a new binary on a new kernel, mounted the file system, wrote files
> > to
> > > it, then rebooted with an old kernel, mounted the filesystem there,
> > writing
> > > new files to it, and then unmounting and running with a new kernel.
> >
> > Right, but that's not older newfs. AFAICT there's no reason at all for
> > a (newer || older) warning.
> 
> 
> I concur.
> 
> > I'm not sure that the new safety belt is reasonable. Today it's fine, but
> > > over time it will start producing false-positive warnings since the real
> > > issue is just before/after the cg change, not old/new in general. I'd be
> > > tempted to make a check against newfs being >= 1200046 while the kernel
> > is <
> > > 1200046. There wasn't a specific bump for this change to sys/param.h, but
> > > this version was bumped within a few hours of Kirk's change.
> >
> > Well, we don't in general support using a userland newer than the
> > running kernel, other than on a best-effort basis to facilitate
> > upgrades and development. This one is only a warning so I don't see
> > much harm in leaving it in place, and it would catch any new cases of
> > a similar nature. If such a warning was already in place we might have
> > avoided the issue where our snapshots produced checksum mismatch
> > messages. But I don't have a strong objection to a hardcoded version
> > check.
> >
> 
> What would have fixed the snapshot isn't a warning that nobody will notice.
> But rather something like the following:

No, what would really fix the snapshot is using makefs or the host newfs
instead of the target newfs during the build.  That part of the release
process is still fundamentally broken and fixing that wouldn't require various
one-off fixes for future changes that happen to introduce compatability but
would fix the entire class of issues.

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

svn commit: r325886 - head/cddl/contrib/opensolaris/lib/libdtrace/common

2017-11-15 Thread Mark Johnston

Author: markj
Date: Thu Nov 16 07:14:29 2017
New Revision: 325886
URL: https://svnweb.freebsd.org/changeset/base/325886

Log:
  Take r313504 into account when recomputing the string table length.
  
  When we encounter a USDT probe in a weak symbol, we emit an alias for
  the probe function symbol. Such aliases are named differently from the
  aliases we emit for probes in local functions, so make sure to take that
  difference into account when resizing the output object file's string
  table. Otherwise, we underrun the string table buffer.
  
  PR:   223680

Modified:
  head/cddl/contrib/opensolaris/lib/libdtrace/common/dt_link.c

Modified: head/cddl/contrib/opensolaris/lib/libdtrace/common/dt_link.c
==
--- head/cddl/contrib/opensolaris/lib/libdtrace/common/dt_link.cThu Nov 
16 06:55:57 2017(r325885)
+++ head/cddl/contrib/opensolaris/lib/libdtrace/common/dt_link.cThu Nov 
16 07:14:29 2017(r325886)
@@ -1416,8 +1416,15 @@ process_obj(dtrace_hdl_t *dtp, const char *obj, int *e
"expected %s to be of type function", s));
}
 
-   len = snprintf(NULL, 0, dt_symfmt, dt_symprefix,
-   objkey, s) + 1;
+   /*
+* Aliases of weak symbols don't get a uniquifier.
+*/
+   if (GELF_ST_BIND(fsym.st_info) == STB_WEAK)
+   len = snprintf(NULL, 0, dt_weaksymfmt,
+   dt_symprefix, s) + 1;
+   else
+   len = snprintf(NULL, 0, dt_symfmt, dt_symprefix,
+   objkey, s) + 1;
if ((p = dt_alloc(dtp, len)) == NULL) {
dt_strtab_destroy(strtab);
goto 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"

Re: svn commit: r325765 - head/lib/libc/string

2017-11-15 Thread Bruce Evans


On Wed, 15 Nov 2017, Mark Millard wrote:


Bruce Evans brde at optusnet.com.au wrote on
Tue Nov 14 12:41:50 UTC 2017 :


- memcpy.3.  It was already documented in the BUGS section that memcpy() is
   implemented as bcopy() and therefore the "strings" "may overlap" [then
   portability considerations due to this].  This is buggier than before:
   - old bug: only the MI implementation of memcpy() clearly implements
 memcpy() as bcopy().  The amd64, i386 and arm MD implementations
 do the same.


I was confused between arm and mips and only fixed this in some places.
It is mips that does the same as amd64 and i386.  arm has different MD code,
and the others have no md code.


head/sys/arm/arm/support.S ( -r283366 ) has

394 ENTRY(bcopy)
395 /* switch the source and destination registers */
396 eor r0, r1, r0
397 eor r1, r0, r1
398 eor r0, r1, r0
399 EENTRY(memmove)
400 /* Do the buffers overlap? */
401 cmp r0, r1
402 RETeq   /* Bail now if src/dst are the same */
403 subcc   r3, r0, r1  /* if (dst > src) r3 = dst - src */
404 subcs   r3, r1, r0  /* if (src > dsr) r3 = src - dst */
405 cmp r3, r2  /* if (r3 < len) we have an overlap */
406 bcc PIC_SYM(_C_LABEL(memcpy), PLT)
. . .


I didn't look closely at the arm code, and just noticed more bugs in it.

Falling through like that breaks at least profiling.  Only ENTRY() does
_PROF_PROLOGUE, so profiling of memmove() seems to be broken.

A less worse way to use EENTRY() is ENTRY() then 1 more more EENTRY()'s
with no code in between.  Then the names are just aliases.  Profiling
can't distinguish the aliases, but at least all entries get counted.
amd64 and i386 use ALTENTRY() which handles this as well as possible
(not very well -- like a tail call -- too much gets charged to the
tail function.  sparc64 also has ALTENTRY() but not the complications
needed for it to work only as badly as a tail call.

It is a style bug for memmove() to exist in the kernel.  Especially an MD
version of it.  It is bad enough that libkern has an MI memmove().  This
is not the same as the libc/string one (another style bug), but just
implements memmove() by calling bcopy().  Profiling works right for this
unless it the function is over-optimized to a tail call when it works
like ALTENTRY().


head/lib/libc/arm/string/memmove.S ( -r288373 ) has:

37  #ifndef _BCOPY
38  /* LINTSTUB: Func: void *memmove(void *, const void *, size_t) */
39  ENTRY(memmove)
40  #else
41  /* bcopy = memcpy/memmove with arguments reversed. */
42  /* LINTSTUB: Func: void bcopy(void *, void *, size_t) */
43  ENTRY(bcopy)
44  /* switch the source and destination registers */
45  eor r0, r1, r0
46  eor r1, r0, r1
47  eor r0, r1, r0
48  #endif


This is the correct way to do it -- separate object files with duplication
in source files avoided using ifdefs.


49  /* Do the buffers overlap? */
50  cmp r0, r1
51  it  eq
52  RETeq   /* Bail now if src/dst are the same */
53  ite cc
54  subcc   r3, r0, r1  /* if (dst > src) r3 = dst - src */
55  subcs   r3, r1, r0  /* if (src > dsr) r3 = src - dst */
56  cmp r3, r2  /* if (r3 < len) we have an overlap */
57  bcc PIC_SYM(_C_LABEL(memcpy), PLT)
. . .

It looks to me like bcopy and memmove call memcpy under
some conditions, not the other way around. I did not
notice any code in memcpy going back to bcopy (or
memmove) in either area. (That might have lead to
recursion as things are.)


The above only shows memmove() calling bcopy(), only in the kernel.  This
would be invalid in userland since memmove() is Standard but bcopy() is
supposed to be usable by applications (unless __BSD_VISIBLE).  The
separate object files in userland make this not a problem.  Otherwise,
bcopy and memmove in the same object file would cause namespace problems
even if bcopy is implemented as a [tail] call or fall-through to memmove.


...
Another issue is if compilers (clang, gcc) are well
controlled for code substitutions to preserve
supposed FreeBSD rules about where overlaps
are well defined. The library code might not be all
there is to it as far as behavior goes for
compiled C/C++ source code.


Do you mean the namespace stuff?


head/sys/arm64/arm64/ is similar for bcopy/memmove
calling memcpy (but head/lib/libc/amd64/string/ is
not):


It is reasonable, and possibly best, to implement the usual
non-overlapping case by a call to memcpy() and not try hard to
optimize the overlapping case (or jump far away to it to keep
caches cleaner for the usual case).


head/sys/arm64/arm64/memmove.S ( -r307909 ) has:
...
head/lib/libc/amd64/string/bcopy.S has:
...


Same o

svn commit: r325887 - in head/sys/cddl: compat/opensolaris/kern contrib/opensolaris/uts/intel/dtrace

2017-11-15 Thread Mark Johnston

Author: markj
Date: Thu Nov 16 07:25:12 2017
New Revision: 325887
URL: https://svnweb.freebsd.org/changeset/base/325887

Log:
  Avoid holding the process in uread() and uwrite().
  
  In general, higher-level code will atomically verify that the process
  is not exiting and hold the process. In one case, we were using uwrite()
  to copy a probed instruction to a per-thread scratch space block, but
  copyout() can be used for this purpose instead; this change effectively
  reverts r227291.
  
  MFC after:1 week

Modified:
  head/sys/cddl/compat/opensolaris/kern/opensolaris_proc.c
  head/sys/cddl/contrib/opensolaris/uts/intel/dtrace/fasttrap_isa.c

Modified: head/sys/cddl/compat/opensolaris/kern/opensolaris_proc.c
==
--- head/sys/cddl/compat/opensolaris/kern/opensolaris_proc.cThu Nov 16 
07:14:29 2017(r325886)
+++ head/sys/cddl/compat/opensolaris/kern/opensolaris_proc.cThu Nov 16 
07:25:12 2017(r325887)
@@ -35,9 +35,7 @@ uread(proc_t *p, void *kaddr, size_t len, uintptr_t ua
 {
ssize_t n;
 
-   PHOLD(p);
n = proc_readmem(curthread, p, uaddr, kaddr, len);
-   PRELE(p);
if (n != len)
return (ENOMEM);
return (0);
@@ -48,9 +46,7 @@ uwrite(proc_t *p, void *kaddr, size_t len, uintptr_t u
 {
ssize_t n;
 
-   PHOLD(p);
n = proc_writemem(curthread, p, uaddr, kaddr, len);
-   PRELE(p);
if (n != len)
return (ENOMEM);
return (0);

Modified: head/sys/cddl/contrib/opensolaris/uts/intel/dtrace/fasttrap_isa.c
==
--- head/sys/cddl/contrib/opensolaris/uts/intel/dtrace/fasttrap_isa.c   Thu Nov 
16 07:14:29 2017(r325886)
+++ head/sys/cddl/contrib/opensolaris/uts/intel/dtrace/fasttrap_isa.c   Thu Nov 
16 07:25:12 2017(r325887)
@@ -1715,11 +1715,7 @@ fasttrap_pid_probe(struct reg *rp)
 
ASSERT(i <= sizeof (scratch));
 
-#ifdef illumos
if (fasttrap_copyout(scratch, (char *)addr, i)) {
-#else
-   if (uwrite(p, scratch, i, addr)) {
-#endif
fasttrap_sigtrap(p, curthread, pc);
new_pc = pc;
break;
___
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"

43 matches

Mail list logo