(re)name cpumem_realloc to cpumem_malloc_ncpus

2016-10-23 Thread David Gwynne
cos its not resizing the allocation, its allocating them for new cpus.

the same goes for counters_realloc being named counters_alloc_ncpus.

this adds doco for them too.

ok?

Index: share/man/man9/counters_alloc.9
===
RCS file: /cvs/src/share/man/man9/counters_alloc.9,v
retrieving revision 1.2
diff -u -p -r1.2 counters_alloc.9
--- share/man/man9/counters_alloc.9 21 Oct 2016 12:39:13 -  1.2
+++ share/man/man9/counters_alloc.9 24 Oct 2016 04:43:33 -
@@ -20,6 +20,9 @@
 .Sh NAME
 .Nm counters_alloc ,
 .Nm counters_free ,
+.Nm COUNTERS_BOOT_MEMORY ,
+.Nm COUNTERS_BOOT_INITIALIZER ,
+.Nm counters_alloc_ncpus ,
 .Nm counters_enter ,
 .Nm counters_leave ,
 .Nm counters_read ,
@@ -31,6 +34,14 @@
 .Fn counters_alloc "unsigned int ncounters" "int type"
 .Ft void
 .Fn counters_free "struct cpumem *cm" "unsigned int ncounters" "int type"
+.Fn COUNTERS_BOOT_MEMORY "NAME" "unsigned int ncounters"
+.Fn COUNTERS_BOOT_INITIALIZER "NAME"
+.Ft struct cpumemt *
+.Fo counters_alloc_ncpus
+.Fa "struct cpumem *cm"
+.Fa "unsigned int ncounters"
+.Fa "int type"
+.Fc
 .Ft uint64_t *
 .Fn counters_enter "struct counters_ref *ref" "struct cpumem *cm"
 .Ft void
@@ -84,6 +95,60 @@ arguments type originally provided to
 must be passed to
 .Fn counters_free .
 .Pp
+If a set of per CPU counters needs to be usable as soon as the
+kernel is booted, instead of after devices (which includes CPUs)
+are attached, a cpumem pointer and counters for the boot CPU may be
+statically allocated.
+.Pp
+.Fn COUNTERS_BOOT_MEMORY
+allocates counters for use by the boot CPU in the kernel and before
+the other CPUs are attached and run.
+The allocation is identified by
+.Fa NAME ,
+and provides memory for the number of counters specified by
+.Fa ncounters .
+.Pp
+.Pp
+.Fn COUNTERS_BOOT_INITIALIZER
+is used to initialise a cpumem pointer with the memory that was previously
+allocated using
+.Fn COUNTERS_BOOT_MEMORY
+and identified by
+.Fa NAME .
+.Pp
+.Fn counters_alloc_ncpus
+allocates additional per CPU counters for the CPUs that were attached
+during boot to the cpumem structure
+.Fa cm
+that was previously allocated statically using
+.Fn COUNTERS_BOOT_MEMORY
+and initialised with
+.Fn COUNTERS_BOOT_INITIALIZER .
+.Fn counters_alloc_ncpus
+allocates space for a number of counters specified by
+.Fa ncounters .
+The
+.Fa type
+argument specifies the type of memory that the counters will be
+allocated as via
+.Xr malloc 9 .
+The memory will be zeroed on allocation by passing
+.Fn M_ZERO
+to
+.Xr malloc 9 .
+The same number of counters originally passed to
+.Fa COUNTERS_BOOT_MEMORY
+must be specified by
+.Fa ncounters .
+.Pp
+Counters that have been allocated with
+.Fn COUNTERS_BOOT_MEMORY
+and
+.Fn counters_alloc_ncpus
+cannot be deallocated with
+.Fa counters_free .
+Any attempt to do so will lead to undefined behaviour.
+.Pp
 .Fn counters_enter
 provides access to the current CPU's set of counters referenced by
 .Fa cm .
@@ -119,6 +184,7 @@ up to the caller to serialise this call 
 .Sh CONTEXT
 .Fn counters_alloc ,
 .Fn counters_free ,
+.Fn counters_alloc_ncpus ,
 and
 .Fn counters_read
 may be called during autoconf, or from process context.
@@ -136,7 +202,9 @@ It is up to the caller to provide approp
 around calls to these functions to prevent concurrent access to the
 relevant data structures.
 .Sh RETURN VALUES
-.Fn counters_get
+.Fn counters_alloc
+and
+.Fn counters_alloc_ncpus
 will return an opaque cpumem pointer that references each CPU's
 set of counters.
 .Pp
Index: share/man/man9/cpumem_get.9
===
RCS file: /cvs/src/share/man/man9/cpumem_get.9,v
retrieving revision 1.5
diff -u -p -r1.5 cpumem_get.9
--- share/man/man9/cpumem_get.9 21 Oct 2016 15:00:30 -  1.5
+++ share/man/man9/cpumem_get.9 24 Oct 2016 04:43:33 -
@@ -21,7 +21,10 @@
 .Nm cpumem_get ,
 .Nm cpumem_put ,
 .Nm cpumem_malloc ,
+.Nm cpumem_malloc_ncpus ,
 .Nm cpumem_free ,
+.Nm CPUMEM_BOOT_MEMORY ,
+.Nm CPUMEM_BOOT_INITIALIZER ,
 .Nm cpumem_enter ,
 .Nm cpumem_leave ,
 .Nm cpumem_first ,
@@ -37,6 +40,10 @@
 .Fn cpumem_malloc "size_t sz" "int type"
 .Ft void
 .Fn cpumem_free "struct cpumem *cm" "int type" "size_t sz"
+.Fn CPUMEM_BOOT_MEMORY "NAME" "size_t sz"
+.Fn CPUMEM_BOOT_INITIALIZER "NAME"
+.Ft struct cpumem *
+.Fn cpumem_malloc_ncpus "struct cpumem *cm" "size_t sz" "int type"
 .Ft void *
 .Fn cpumem_enter "struct cpumem *cm"
 .Ft void
@@ -100,6 +107,59 @@ must be specified by
 and
 .Fa type
 respectively.
+.Pp
+If a per CPU memory allocation needs to be usable as soon as the
+kernel is booted, instead of after devices (which includes CPUs)
+are attached, a cpumem pointer and memory for the boot CPU may be
+statically allocated.
+.Pp
+.Fn CPUMEM_BOOT_MEMORY
+allocates memory for use by the boot CPU in the kernel and before
+the other CPUs are attached and run.  The allocation is identified
+by
+.Fn NAME ,
+and provides
+.Fn 

Re: fix carp "carppeer" + "real mac-address"

2016-10-23 Thread YASUOKA Masahiko
FYI.  I just commited regress tests on regress/netinet/carp/ .
carp_4.sh demostrates the problem which the diff fixes.

On Tue, 18 Oct 2016 19:33:01 +0900 (JST)
YASUOKA Masahiko  wrote:
> Currenlty when carppeer + "real mac-address" are used at once,
> changing MASTER by carpdemote causes "MASTER-MASTER" problem, BACKUP
> is to become MASTER but the present MASTER also will keep its state.
> 
> The diff following will fix this problem.
> 
> ok?
> 
> Accept CARP advertisement packets whose destination is not for multicast.
> When both "carppeer" and "real mac-address" are used at once and the
> BACKUP is to take over the new MASTER, the present MASTER receives
> such packets.
> 
> found by and diff from nagasaka at iij
> 
> diff --git a/sys/netinet/ip_carp.c b/sys/netinet/ip_carp.c
> index 9eb5552..bfbf430 100644
> --- a/sys/netinet/ip_carp.c
> +++ b/sys/netinet/ip_carp.c
> @@ -453,7 +453,7 @@ carp_proto_input_if(struct ifnet *ifp, struct mbuf *m, 
> int hlen)
>   ismulti = IN_MULTICAST(ip->ip_dst.s_addr);
>  
>   /* check if received on a valid carp interface */
> - if (!((ifp->if_type == IFT_CARP && ismulti) ||
> + if (!(ifp->if_type == IFT_CARP ||
>   (ifp->if_type != IFT_CARP && !ismulti && ifp->if_carp != NULL))) {
>   carpstats.carps_badif++;
>   CARP_LOG(LOG_INFO, sc,
> 



Re: Quirks for pkcbc?

2016-10-23 Thread Theo de Raadt
> Since the patch isn't a proper solution, I was wondering whether there's
> a quirks mechanism for pckbc, similar to what e.g. some of the USB HID
> drivers do for things like joysticks with weird button mappings.

No way. quirk layers are really unacceptable to maintain in the long term.
Instead, I ask you to figure out logical conditions under which this
should happen, or if some interaction is wrong.  This is very complicated
stuff with a lot of legacy, prepare for it to take months to get good
sufficient reports from people, for your proposals.



> 
> -- 
>   Gregor
> 
> Index: dev/ic/pckbc.c
> ===
> RCS file: /mnt/media/cvs/src/sys/dev/ic/pckbc.c,v
> retrieving revision 1.49
> diff -u -p -r1.49 pckbc.c
> --- dev/ic/pckbc.c  24 May 2015 10:57:47 -  1.49
> +++ dev/ic/pckbc.c  23 Oct 2016 21:19:56 -
> @@ -378,6 +378,8 @@ pckbc_attach(struct pckbc_softc *sc, int
> bus_space_write_1(iot, ioh_d, 0, 0x5a); /* a random value */
> res = pckbc_poll_data1(iot, ioh_d, ioh_c, PCKBC_AUX_SLOT, 1);
> 
> +   t->t_flags |= PCKBC_NEED_AUXWRITE;
> +
> if (ISSET(t->t_flags, PCKBC_NEED_AUXWRITE)) {
> /*
>  * The following code is necessary to find the aux port on the
> 



Quirks for pkcbc?

2016-10-23 Thread Gregor Best
Hi people,

the patch below the signature makes the touchpad on my new laptop work.
pms(4) didnt' attach previously because the AUX slot on the keyboard was
not enabled.

Since the patch isn't a proper solution, I was wondering whether there's
a quirks mechanism for pckbc, similar to what e.g. some of the USB HID
drivers do for things like joysticks with weird button mappings.

-- 
Gregor

Index: dev/ic/pckbc.c
===
RCS file: /mnt/media/cvs/src/sys/dev/ic/pckbc.c,v
retrieving revision 1.49
diff -u -p -r1.49 pckbc.c
--- dev/ic/pckbc.c  24 May 2015 10:57:47 -  1.49
+++ dev/ic/pckbc.c  23 Oct 2016 21:19:56 -
@@ -378,6 +378,8 @@ pckbc_attach(struct pckbc_softc *sc, int
bus_space_write_1(iot, ioh_d, 0, 0x5a); /* a random value */
res = pckbc_poll_data1(iot, ioh_d, ioh_c, PCKBC_AUX_SLOT, 1);

+   t->t_flags |= PCKBC_NEED_AUXWRITE;
+
if (ISSET(t->t_flags, PCKBC_NEED_AUXWRITE)) {
/*
 * The following code is necessary to find the aux port on the



Re: FAQ entry for vmm

2016-10-23 Thread Edd Barrett
Hi,

On Wed, Oct 19, 2016 at 06:42:08PM +0200, Daniel Jakots wrote:
> The second sentence in the FAQ is 'It covers the latest release of
> OpenBSD.'. Maybe it would be worth adding a sentence about the fact
> that it covers mainly current (as in -stable vmm is not enabled).

Just to keep the list in the loop, here is the version of the vmm faq
diff which I now have OKs for. We have decided however, to not commit
this until 6.1 release.

Thanks for all the feedback.


Index: faq/faq6.html
===
RCS file: /home/edd/cvsync/www/faq/faq6.html,v
retrieving revision 1.419
diff -u -p -r1.419 faq6.html
--- faq/faq6.html   8 Oct 2016 03:17:45 -   1.419
+++ faq/faq6.html   21 Oct 2016 15:22:13 -
@@ -50,6 +50,7 @@
 Setting up a network bridge
 Equal-cost multipath routing
 Adding and replacing NICs
+Networking vmm(4) guests
 
 
 
@@ -1183,6 +1184,89 @@ Some likely candidates might include:
   Bridge configuration (/etc/hostname.bridge*)
   Trunk configuration (/etc/hostname.trunk*)
 
+
+Networking vmm(4) guests
+
+Giving network access to a http://man.openbsd.org/vmm;>vmm(4)
+guest is easy if the host machine uses a wired connection.
+You can simply put the guest's http://man.openbsd.org/tap;>tap(4)
+interface into a bridged virtual switch with the host's wired interface.
+Inside the guest, the http://man.openbsd.org/vio;>vio(4)
+interface can then be configured as if it were a real machine physically
+connected to the host network.
+Unfortunately, this strategy does not work if the host machine uses a wireless
+network interface.
+Due to a limitation of the IEEE 802.11 standard, wireless interfaces cannot
+participate in network bridges.
+One way to work around this is to give the guest VM its own network and use
+network address translation (NAT) to the host's network.
+
+
+Suppose we have a host machine with network access via a wireless iwn0
+interface on the 192.168.1.0/24 network.
+We want to install an OpenBSD guest onto the 10.0.0.0/24 network and
+give the guest access to the host's network via NAT.
+Assume that we configured the guest's host-side interface to be fixed as
+tap0.
+Although we could set up NAT directly between the tap0 and
+iwn0, this tends to complicate matters, as tap0 will appear
+and disappear as the guest is powered up and down.
+In that case, we would have to reconfigure tap0 manually after each
+guest power-on.
+A more robust approach is to use an always-existing
+http://man.openbsd.org/vether;>vether(4) interface and
+have http://man.openbsd.org/vmd;>vmd(8) bridge this with
+tap0 when the guest is powered on.
+Since vether0 always exists regardless of whether the guest is powered
+up or not, its configuration will persist across guest power cycles.
+
+
+Let's make a vether0 interface:
+
+
+# echo "inet 10.0.0.1 255.255.255.0" > /etc/hostname.vether0
+# sh /etc/netstart vether0
+
+
+Add the following to /etc/pf.conf:
+
+
+match out on iwn0 inet from vether0:network to any nat-to (iwn0)
+
+
+And to finish off the NAT configuration:
+
+
+# pfctl -f /etc/pf.conf
+# echo "net.inet.ip.forwarding=1" >> /etc/sysctl.conf
+# sysctl net.inet.ip.forwarding=1
+net.inet.ip.forwarding: 0 -> 1
+
+
+In http://man.openbsd.org/vm.conf;vm.conf(5), ensure that you
+put vether0 into a virtual switch alongside tap0.
+For example:
+
+
+switch "my_switch" {
+add vether0
+interface bridge0
+}
+
+vm "my_vm" {
+...
+interface tap0 { switch "my_switch" }
+}
+
+
+Inside the guest, if we now assign vio0 an address on the
+10.0.0.0/24 network and set the default route to 10.0.0.1, we
+should be able to ping systems on the host network.
+For convenience, you may wish to set up a DHCP server on vether0.
+See http://man.openbsd.org/dhcpd;>dhcpd(8) and
+http://man.openbsd.org/dhcpd.conf;>dhcpd.conf(5) for details on
+how to set up a DHCP server (an example config file can be found at
+/etc/examples/dhcpd.conf).
 
 
 
Index: faq/index.html
===
RCS file: /home/edd/cvsync/www/faq/index.html,v
retrieving revision 1.495
diff -u -p -r1.495 index.html
--- faq/index.html  2 Oct 2016 21:16:26 -   1.495
+++ faq/index.html  20 Oct 2016 13:36:18 -
@@ -112,6 +112,7 @@ that are not covered in the FAQ.
 Setting up a network bridge
 Equal-cost multipath routing
 Adding and replacing NICs
+Networking vmm(4) guests
 
 
 Keyboard and Display Controls

-- 
Best Regards
Edd Barrett

http://www.theunixzoo.co.uk



snmpd(8): turn snmpd_env the only global

2016-10-23 Thread Rafael Zalamena
This diff removes all "extern struct snmpd *" lines from source files,
replaces all 'env' occurences with 'snmpd_env' and adds the extern
declaration for snmpd_env in the snmpd.h header.

With this diff we only need to guarantee that this variable is set,
we avoid shadowing other 'env' variables and we diminish the confusion
about this env variable thing.

We need this diff (or something with the same effect) to proceed with
fork+exec, because jca@ found out that traphandler child process do not
set env. We could alternatively just set env in traphandler p_init() and
remove snmpd_env, however it looks cleaner to me to not have all this
extern in all .c files and have a propper name for 'env'.

ok?


Index: kroute.c
===
RCS file: /home/obsdcvs/src/usr.sbin/snmpd/kroute.c,v
retrieving revision 1.33
diff -u -p -r1.33 kroute.c
--- kroute.c3 Sep 2016 15:45:02 -   1.33
+++ kroute.c22 Oct 2016 22:20:00 -
@@ -44,8 +44,6 @@
 
 #include "snmpd.h"
 
-extern struct snmpd*env;
-
 struct ktable  **krt;
 u_intkrt_size;
 
@@ -173,8 +171,9 @@ kr_init(void)
, sizeof(opt)) == -1)
log_warn("%s: SO_USELOOPBACK", __func__);   /* not fatal */
 
-   if (env->sc_rtfilter && setsockopt(kr_state.ks_fd, PF_ROUTE,
-   ROUTE_MSGFILTER, >sc_rtfilter, sizeof(env->sc_rtfilter)) == -1)
+   if (snmpd_env->sc_rtfilter && setsockopt(kr_state.ks_fd, PF_ROUTE,
+   ROUTE_MSGFILTER, _env->sc_rtfilter,
+   sizeof(snmpd_env->sc_rtfilter)) == -1)
log_warn("%s: ROUTE_MSGFILTER", __func__);
 
/* grow receive buffer, don't wanna miss messages */
Index: mib.c
===
RCS file: /home/obsdcvs/src/usr.sbin/snmpd/mib.c,v
retrieving revision 1.80
diff -u -p -r1.80 mib.c
--- mib.c   17 Nov 2015 12:30:23 -  1.80
+++ mib.c   22 Oct 2016 22:26:52 -
@@ -58,8 +58,6 @@
 #include "snmpd.h"
 #include "mib.h"
 
-extern struct snmpd*env;
-
 /*
  * Defined in SNMPv2-MIB.txt (RFC 3418)
  */
@@ -255,7 +253,7 @@ mib_sysor(struct oid *oid, struct ber_oi
 int
 mib_getsnmp(struct oid *oid, struct ber_oid *o, struct ber_element **elm)
 {
-   struct snmp_stats   *stats = >sc_stats;
+   struct snmp_stats   *stats = _env->sc_stats;
long longi;
struct statsmap {
u_int8_t m_id;
@@ -316,7 +314,7 @@ mib_getsnmp(struct oid *oid, struct ber_
 int
 mib_setsnmp(struct oid *oid, struct ber_oid *o, struct ber_element **elm)
 {
-   struct snmp_stats   *stats = >sc_stats;
+   struct snmp_stats   *stats = _env->sc_stats;
long longi;
 
if (ber_get_integer(*elm, ) == -1)
@@ -354,11 +352,11 @@ mib_engine(struct oid *oid, struct ber_o
 {
switch (oid->o_oid[OIDIDX_snmpEngine]) {
case 1:
-   *elm = ber_add_nstring(*elm, env->sc_engineid,
-   env->sc_engineid_len);
+   *elm = ber_add_nstring(*elm, snmpd_env->sc_engineid,
+   snmpd_env->sc_engineid_len);
break;
case 2:
-   *elm = ber_add_integer(*elm, env->sc_engine_boots);
+   *elm = ber_add_integer(*elm, snmpd_env->sc_engine_boots);
break;
case 3:
*elm = ber_add_integer(*elm, snmpd_engine_time());
@@ -375,7 +373,7 @@ mib_engine(struct oid *oid, struct ber_o
 int
 mib_usmstats(struct oid *oid, struct ber_oid *o, struct ber_element **elm)
 {
-   struct snmp_stats   *stats = >sc_stats;
+   struct snmp_stats   *stats = _env->sc_stats;
long longi;
struct statsmap {
u_int8_t m_id;
@@ -697,7 +695,7 @@ mib_hrdevice(struct oid *oid, struct ber
 
/* Get and verify the current row index */
idx = o->bo_id[OIDIDX_hrDeviceEntry];
-   if (idx > (u_int)env->sc_ncpu)
+   if (idx > (u_int)snmpd_env->sc_ncpu)
return (1);
 
/* Tables need to prepend the OID on their own */
@@ -748,7 +746,7 @@ mib_hrprocessor(struct oid *oid, struct 
 
/* Get and verify the current row index */
idx = o->bo_id[OIDIDX_hrDeviceEntry];
-   if (idx > (u_int)env->sc_ncpu)
+   if (idx > (u_int)snmpd_env->sc_ncpu)
return (1);
else if (idx < 1)
idx = 1;
@@ -766,9 +764,9 @@ mib_hrprocessor(struct oid *oid, struct 
 * The percentage of time that the system was not
 * idle during the last minute.
 */
-   if (env->sc_cpustates == NULL)
+   if (snmpd_env->sc_cpustates == NULL)
return (-1);
-   cptime2 = env->sc_cpustates + (CPUSTATES * (idx - 1));
+   cptime2 = snmpd_env->sc_cpustates + (CPUSTATES * (idx - 1));
val = 100 -
 

Re: FreeType 2.7

2016-10-23 Thread Matthieu Herrb
On Sat, Oct 22, 2016 at 02:24:39PM +0200, Matthieu Herrb wrote:
> On Sat, Oct 22, 2016 at 02:02:12PM +0200, David Coppa wrote:
> > On Sat, Oct 22, 2016 at 11:52 AM, Matthieu Herrb  wrote:
> > > On Mon, Oct 10, 2016 at 12:46:41PM +0200, David Coppa wrote:
> > >>
> > >> Hi all,
> > >>
> > >> Here's the update to FreeType 2.7 (a gzipped diff is also attached).
> > >>
> > >> The biggest change is that now Subpixel hinting, also known as
> > >> ClearType hinting, is enabled by default.
> > >>
> > >> As usual, a ports bulk build is appreciated.
> > >
> > > Hi,
> > >
> > > I'm not really sure that the bumping of the major revision of
> > > libfontconfig, libXft and libXfont is needed or will help with out of
> > > date packages. Can you explain ?
> > 
> > We did this before.
> > Yes, it's to avoid problems like the message below.
> >
> 
> Unfortunatly it will not avoid all of them. For now, after upgrading
> xenocara, but with packages still linked to freetype.26 I get this
> from firefox:
> 
> firefox:/usr/X11R6/lib/libfreetype.so.26.0: 
> /usr/X11R6/lib/libfreetype.so.27.0 : WARNING: symbol(af_blue_strings) size 
> mismatch, relink your program
> 
> For the extra major bumps to be useful in this situation, ld.so
> would need to only load the revisions of the libs that the program was
> linked against, and ignore the more recent versions But with dlopen()
> which doesn't do versionning it won't be trivial.
> 
> -- 
> Matthieu Herrb

That said, the update (with fontconfig/Xft/Xfont bumps) survived a
rebuild of my standard set of packages (including firefox, chrome,
libreoffice & xfce4).

So ok matthieu@ 

-- 
Matthieu Herrb


signature.asc
Description: PGP signature