Re: Reported problem: postfix, libressl 2.6.x, DHE-RSA-AES256-SHA

2017-11-10 Thread Kinichiro Inoguchi 
Same kind of issue had been raised for Postfix and LibreSSL 2.2.2 2 years
ago.

http://postfix.1071664.n5.nabble.com/SSL-accept-errors-after-recent-upgrade-to-LibreSSL-2-2-2-td78774.html

In this case,  SSLv2 caused some wrong behavior.

Re: [PATCH 2/2 v3] VMD: regress tests update for switch configuration

2017-11-10 Thread Mike Larkin 
On Wed, Nov 08, 2017 at 06:49:31PM -0800, Carlos Cardenas wrote:
> Update regression tests to match new switch configuration
> 

committed, thanks!

> diff --git regress/usr.sbin/vmd/config/Makefile 
> regress/usr.sbin/vmd/config/Makefile
> index 2adc69ae491..3bf124aff56 100644
> --- regress/usr.sbin/vmd/config/Makefile
> +++ regress/usr.sbin/vmd/config/Makefile
> @@ -5,7 +5,7 @@ VMD ?= /usr/sbin/vmd
>  VMD_PASS=boot-keyword memory-round memory-just-enough
>  VMD_FAIL=kernel-keyword too-few-ram vm-name-too-long too-many-ifs \
>boot-name-too-long disk-path-too-long too-many-disks \
> -  switch-no-interface
> +  switch-no-interface switch-no-add
>  
>  REGRESS_TARGETS=
>  
> diff --git regress/usr.sbin/vmd/config/vmd-fail-switch-no-add.conf 
> regress/usr.sbin/vmd/config/vmd-fail-switch-no-add.conf
> new file mode 100644
> index 000..40117749346
> --- /dev/null
> +++ regress/usr.sbin/vmd/config/vmd-fail-switch-no-add.conf
> @@ -0,0 +1,6 @@
> +#$OpenBSD$
> +# Fail when a switch is attempting to use add
> +switch "x" {
> +interface bridge0
> +add vether0
> +}
> diff --git regress/usr.sbin/vmd/config/vmd-fail-switch-no-add.ok 
> regress/usr.sbin/vmd/config/vmd-fail-switch-no-add.ok
> new file mode 100644
> index 000..c04c2d13732
> --- /dev/null
> +++ regress/usr.sbin/vmd/config/vmd-fail-switch-no-add.ok
> @@ -0,0 +1 @@
> +5: syntax error
> diff --git regress/usr.sbin/vmd/config/vmd-fail-switch-no-interface.conf 
> regress/usr.sbin/vmd/config/vmd-fail-switch-no-interface.conf
> index 891d9c88176..f92c09656d6 100644
> --- regress/usr.sbin/vmd/config/vmd-fail-switch-no-interface.conf
> +++ regress/usr.sbin/vmd/config/vmd-fail-switch-no-interface.conf
> @@ -1,5 +1,5 @@
>  #$OpenBSD: vmd-fail-switch-no-interface.conf,v 1.1 2017/10/30 03:49:30 
> mlarkin Exp $
>  # Fail when a switch is missing interface name
>  switch "x" {
> -add vether0
> +up
>  }
> -- 
> 2.14.3
>

Re: [PATCH 1/2 v3] VMD: remove add from switch configuration

2017-11-10 Thread Mike Larkin 
On Wed, Nov 08, 2017 at 06:49:30PM -0800, Carlos Cardenas wrote:
> Remove configuration items on switches for:
> * adding static interfaces
> 
> Adding static interfaces are to be set in hostname.if.
> 
> Changed rule on rdomain:
> * vm->interface->rdomain takes precedence over sw->rdomain
> 
> Update examples/vm.conf and vm.conf manpage to reflect changes.
> 
> Comments? Ok?
> 
> Ok by reyk@
> 

committed, thanks!

-ml

> diff --git etc/examples/vm.conf etc/examples/vm.conf
> index f35235e3fba..d61ce8c4977 100644
> --- etc/examples/vm.conf
> +++ etc/examples/vm.conf
> @@ -10,15 +10,14 @@ sets="/var/www/htdocs/pub/OpenBSD/snapshots/amd64/"
>  #
>  
>  switch "uplink" {
> - # This interface will default to bridge0, but switch(4) is supported
> + # This switch will use bridge0, defined by /etc/hostname.bridge0, as
> + # the underlying interface.  switch(4) is also supported
>   #interface switch0
> -
> - # Add additional members
> - add em0
> + interface bridge0
>  }
>  
>  switch "local" {
> - add vether0
> + interface bridge1
>   down
>  }
>  
> diff --git usr.sbin/vmd/parse.y usr.sbin/vmd/parse.y
> index a0e96545923..18543a74911 100644
> --- usr.sbin/vmd/parse.y
> +++ usr.sbin/vmd/parse.y
> @@ -88,7 +88,6 @@ int  parse_disk(char *);
>  static struct vmop_create_params vmc;
>  static struct vm_create_params   *vcp;
>  static struct vmd_switch *vsw;
> -static struct vmd_if *vif;
>  static struct vmd_vm *vm;
>  static char   vsw_type[IF_NAMESIZE];
>  static intvcp_disable;
> @@ -193,7 +192,6 @@ switch: SWITCH string {
>   vsw->sw_id = env->vmd_nswitches + 1;
>   vsw->sw_name = $2;
>   vsw->sw_flags = VMIFF_UP;
> - TAILQ_INIT(>sw_ifs);
>  
>   vcp_disable = 0;
>   } '{' optnl switch_opts_l '}'   {
> @@ -224,21 +222,6 @@ switch_opts_l: switch_opts_l switch_opts nl
>  switch_opts  : disable   {
>   vcp_disable = $1;
>   }
> - | ADD string{
> - chartype[IF_NAMESIZE];
> -
> - if ((vif = calloc(1, sizeof(*vif))) == NULL)
> - fatal("could not allocate interface");
> -
> - if (priv_getiftype($2, type, NULL) == -1) {
> - yyerror("invalid interface: %s", $2);
> - free($2);
> - YYERROR;
> - }
> - vif->vif_name = $2;
> -
> - TAILQ_INSERT_TAIL(>sw_ifs, vif, vif_entry);
> - }
>   | GROUP string  {
>   if (priv_validgroup($2) == -1) {
>   yyerror("invalid group name: %s", $2);
> diff --git usr.sbin/vmd/priv.c usr.sbin/vmd/priv.c
> index d585bf75a99..c1d0c0e13be 100644
> --- usr.sbin/vmd/priv.c
> +++ usr.sbin/vmd/priv.c
> @@ -255,9 +255,18 @@ priv_validgroup(const char *name)
>  }
>  
>  /*
> - * Called from the process peer
> + * Called from the Parent process to setup vm interface(s)
> + * - ensure the interface has the description set (tracking purposes)
> + * - if interface is to be attached to a switch, attach it
> + * - check if rdomain is set on interface and switch
> + *   - if interface only or both, use interface rdomain
> + *   - if switch only, use switch rdomain
> + * - check if group is set on interface and switch
> + *   - if interface, add it
> + *   - if switch, add it
> + * - ensure the interface is up/down
> + * - if local interface, set address
>   */
> -
>  int
>  vm_priv_ifconfig(struct privsep *ps, struct vmd_vm *vm)
>  {
> @@ -279,18 +288,6 @@ vm_priv_ifconfig(struct privsep *ps, struct vmd_vm *vm)
>   sizeof(vfr.vfr_name)) >= sizeof(vfr.vfr_name))
>   return (-1);
>  
> - /* Use the configured rdomain or get it from the process */
> - if (vif->vif_flags & VMIFF_RDOMAIN)
> - vfr.vfr_id = vif->vif_rdomain;
> - else
> - vfr.vfr_id = getrtable();
> - if (vfr.vfr_id != 0)
> - log_debug("%s: interface %s rdomain %u", __func__,
> - vfr.vfr_name, vfr.vfr_id);
> -
> - proc_compose(ps, PROC_PRIV, IMSG_VMDOP_PRIV_IFRDOMAIN,
> - , sizeof(vfr));
> -
>   /* Description can be truncated */
>   (void)snprintf(vfr.vfr_value, sizeof(vfr.vfr_value),
>   "vm%u-if%u-%s", vm->vm_vmid, i, vcp->vcp_name);
> @@ -301,8 +298,17 @@ vm_priv_ifconfig(struct privsep *ps, struct vmd_vm *vm)
>   proc_compose(ps, PROC_PRIV, IMSG_VMDOP_PRIV_IFDESCR,
>   , sizeof(vfr));
>  
> - /* Add interface to

[PATCH] scsi style(9) fix for SC_DEBUG{N} macros

2017-11-10 Thread Carlos Cardenas 
Patch fixes a broken compilation when using SCSIDEBUG options(4).

Resolved with krw@ assistance.

Ok?

diff --git sys/scsi/scsi_debug.h sys/scsi/scsi_debug.h
index bf1519fa36d..56c2d530653 100644
--- sys/scsi/scsi_debug.h
+++ sys/scsi/scsi_debug.h
@@ -40,15 +40,17 @@ extern int scsidebug_level;
  * This is the usual debug macro for use with the above bits
  */
 #ifdef SCSIDEBUG
-#defineSC_DEBUG(link,Level,Printstuff) \
+#defineSC_DEBUG(link,Level,Printstuff) do {\
if ((link)->flags & (Level)) {  \
sc_print_addr(link);\
printf Printstuff;  \
-   }
-#defineSC_DEBUGN(link,Level,Printstuff) \
+   } \
+} while (0)
+#defineSC_DEBUGN(link,Level,Printstuff) do {\
if ((link)->flags & (Level)) {  \
printf Printstuff;  \
-   }
+   } \
+} while (0)
 #else
 #define SC_DEBUG(A,B,C)
 #define SC_DEBUGN(A,B,C)
-- 
2.14.3

Re: armv7: newfs efi-partition in when choosing manual-fdisk mbr

2017-11-10 Thread Robert Peichaer 
On Fri, Nov 10, 2017 at 10:27:36AM +0200, Artturi Alm wrote:
> Hi,
> 
> currently, just editing the mbr to give more room for u-boot env growth,
> will result in unbootable system, as the installer will fail to mount it,
> and naturally things won't work beyond u-boot after reboot either.
> 
> i'm not really sure about this diff, but it does seem like it might do,
> what i think it should? might take a while, before i can test myself, so
> i thought i'd mail and ask, if there's a reason for how it is atm.? :)
> 
> -Artturi

I do not know enough about the needed/supported armv7 filesystem layout.
The install notes talk about GPT and MBR partitioning, but the install.md
script only offers MBR. Obviously EFI boot is supported reading install.md
but from MBR. I thought that's only possible from a GPT partition.

Anyways. I will happily help to get this right scripting wise.
But right now I don't know if this is the correct way to fix this.

-- 
-=[rpe]=-

Re: mandoc warning tweak

2017-11-10 Thread Jason McIntyre 
On Fri, Nov 10, 2017 at 10:02:12PM +0100, Ingo Schwarze wrote:
> Hi Jeremie,
> 
> Jeremie Courreges-Anglas wrote on Fri, Nov 10, 2017 at 07:18:54PM +0100:
> 
> > I hit this while reviewing a recent diff:
> > 
> >   ritchie /usr/src/usr.sbin/ospf6d$ mandoc -Tlint ospf6d.conf.5
> >   mandoc: ospf6d.conf.5:211:5: STYLE: typo in section name: \
> >   Sh AREAS instead of CAVEATS
> > 
> > which is a false positive.  The distance between "AREAS" and "CAVEATS"
> > is 3, maybe it's a bit much to warn about possible typos?
> 
> If people feel it is too noisy, we can reduce
> 
>   const int   maxdist = 3;
> 

i don;t feel it's too noisy. i know what jca means about "possible
typos" being a step too far, but in this case mdoclint, and now mandoc,
do catch errors that are very easy to make. think ERROR vs ERRORS. it
helps.

i think the wording tweak proposed by jeremie is a good compromise.

jmc

> in mdoc_validate.c, similar() to 2.  We currently have eight false
> positives of this message in base, which i considered acceptable
> when tuning the parameter.  The grand total of all mandoc warnings
> and style suggestions in base currently is a bit above 4000; of
> course, most of that comes from third-party software we include in
> base.
> 
> > While I don't think this is a big deal, here's a possible tweak to
> > make the message less assertive.
> 
> OK schwarze@
>   Ingo
> 
> 
> > Index: mandoc.1
> > ===
> > RCS file: /d/cvs/src/usr.bin/mandoc/mandoc.1,v
> > retrieving revision 1.143
> > diff -u -p -r1.143 mandoc.1
> > --- mandoc.17 Sep 2017 14:22:58 -   1.143
> > +++ mandoc.110 Nov 2017 18:12:57 -
> > @@ -875,7 +875,7 @@ A single manual page contains two copies
> >  the same operating system.
> >  Consider deleting the later instance and moving the first one up
> >  to the top of the page.
> > -.It Sy "typo in section name"
> > +.It Sy "possible typo in section name"
> >  .Pq mdoc
> >  Fuzzy string matching revealed that the argument of an
> >  .Ic \
> > Index: mandoc.h
> > ===
> > RCS file: /d/cvs/src/usr.bin/mandoc/mandoc.h,v
> > retrieving revision 1.187
> > diff -u -p -r1.187 mandoc.h
> > --- mandoc.h8 Jul 2017 14:51:01 -   1.187
> > +++ mandoc.h10 Nov 2017 18:12:57 -
> > @@ -58,7 +58,7 @@ enum  mandocerr {
> > MANDOCERR_DATE_LEGACY, /* legacy man(7) date format: Dd ... */
> > MANDOCERR_TITLE_CASE, /* lower case character in document title */
> > MANDOCERR_RCS_REP, /* duplicate RCS id: ... */
> > -   MANDOCERR_SEC_TYPO,  /* typo in section name: Sh ... */
> > +   MANDOCERR_SEC_TYPO,  /* possible typo in section name: Sh ... */
> > MANDOCERR_ARG_QUOTE, /* unterminated quoted argument */
> > MANDOCERR_MACRO_USELESS, /* useless macro: macro */
> > MANDOCERR_BX, /* consider using OS macro: macro */
> > Index: read.c
> > ===
> > RCS file: /d/cvs/src/usr.bin/mandoc/read.c,v
> > retrieving revision 1.164
> > diff -u -p -r1.164 read.c
> > --- read.c  20 Jul 2017 14:36:32 -  1.164
> > +++ read.c  10 Nov 2017 18:12:57 -
> > @@ -94,7 +94,7 @@ staticconst char * const  mandocerrs[MAN
> > "legacy man(7) date format",
> > "lower case character in document title",
> > "duplicate RCS id",
> > -   "typo in section name",
> > +   "possible typo in section name",
> > "unterminated quoted argument",
> > "useless macro",
> > "consider using OS macro",
>

Re: mandoc warning tweak

2017-11-10 Thread Ingo Schwarze 
Hi Jeremie,

Jeremie Courreges-Anglas wrote on Fri, Nov 10, 2017 at 07:18:54PM +0100:

> I hit this while reviewing a recent diff:
> 
>   ritchie /usr/src/usr.sbin/ospf6d$ mandoc -Tlint ospf6d.conf.5
>   mandoc: ospf6d.conf.5:211:5: STYLE: typo in section name: \
>   Sh AREAS instead of CAVEATS
> 
> which is a false positive.  The distance between "AREAS" and "CAVEATS"
> is 3, maybe it's a bit much to warn about possible typos?

If people feel it is too noisy, we can reduce

const int   maxdist = 3;

in mdoc_validate.c, similar() to 2.  We currently have eight false
positives of this message in base, which i considered acceptable
when tuning the parameter.  The grand total of all mandoc warnings
and style suggestions in base currently is a bit above 4000; of
course, most of that comes from third-party software we include in
base.

> While I don't think this is a big deal, here's a possible tweak to
> make the message less assertive.

OK schwarze@
  Ingo


> Index: mandoc.1
> ===
> RCS file: /d/cvs/src/usr.bin/mandoc/mandoc.1,v
> retrieving revision 1.143
> diff -u -p -r1.143 mandoc.1
> --- mandoc.1  7 Sep 2017 14:22:58 -   1.143
> +++ mandoc.1  10 Nov 2017 18:12:57 -
> @@ -875,7 +875,7 @@ A single manual page contains two copies
>  the same operating system.
>  Consider deleting the later instance and moving the first one up
>  to the top of the page.
> -.It Sy "typo in section name"
> +.It Sy "possible typo in section name"
>  .Pq mdoc
>  Fuzzy string matching revealed that the argument of an
>  .Ic \
> Index: mandoc.h
> ===
> RCS file: /d/cvs/src/usr.bin/mandoc/mandoc.h,v
> retrieving revision 1.187
> diff -u -p -r1.187 mandoc.h
> --- mandoc.h  8 Jul 2017 14:51:01 -   1.187
> +++ mandoc.h  10 Nov 2017 18:12:57 -
> @@ -58,7 +58,7 @@ enummandocerr {
>   MANDOCERR_DATE_LEGACY, /* legacy man(7) date format: Dd ... */
>   MANDOCERR_TITLE_CASE, /* lower case character in document title */
>   MANDOCERR_RCS_REP, /* duplicate RCS id: ... */
> - MANDOCERR_SEC_TYPO,  /* typo in section name: Sh ... */
> + MANDOCERR_SEC_TYPO,  /* possible typo in section name: Sh ... */
>   MANDOCERR_ARG_QUOTE, /* unterminated quoted argument */
>   MANDOCERR_MACRO_USELESS, /* useless macro: macro */
>   MANDOCERR_BX, /* consider using OS macro: macro */
> Index: read.c
> ===
> RCS file: /d/cvs/src/usr.bin/mandoc/read.c,v
> retrieving revision 1.164
> diff -u -p -r1.164 read.c
> --- read.c20 Jul 2017 14:36:32 -  1.164
> +++ read.c10 Nov 2017 18:12:57 -
> @@ -94,7 +94,7 @@ static  const char * const  mandocerrs[MAN
>   "legacy man(7) date format",
>   "lower case character in document title",
>   "duplicate RCS id",
> - "typo in section name",
> + "possible typo in section name",
>   "unterminated quoted argument",
>   "useless macro",
>   "consider using OS macro",

Re: try to bundle multiple packets on an ifq before sending

2017-11-10 Thread Claudio Jeker 
On Fri, Nov 10, 2017 at 10:58:54AM +1000, David Gwynne wrote:
> this makes ifq_start try to wait for 4 packets before calling
> if->if_qstart.
> 
> this is based on work sephe did in dragonflybsd, and described in
> a comment in their sys/net/if.c. there's a link to it here:
> https://github.com/DragonFlyBSD/DragonFlyBSD/blob/master/sys/net/if.c#L2976-L2987
> 
> the tests we've done generally show a performance bump, but otherwise
> no degradation in performance.
> 
> the mechanism for bundling packets is to but schedule a task to
> service the queue later. if 4 packets get accumulated before the
> task runs, it's cancelled and the code runs the start routine
> directly.
> 
> the most significant difference this implementation has to the dfly
> one is that our ifqs dont (currently) track the number of bytes on
> the q. dfly sends if it can bundle 4 packets, or up to mtu bytes
> worth of packets. this implementation only looks at the number of
> packets.
> 
> the taskq the ifq uses is one of the softnets, which is assigned
> when the ifq is initted and unconditionally used during the ifq's
> lifetime. because ifq work could now be pending in a softnet taskq,
> ifq_barrier also needs to put a barrier in the taskq. this is
> implemented using taskq_barrier, which i wrote ages ago but didn't
> have a use case for at the time.
> 
> tests? ok?

I wonder what the effect on the latency is. Especially the case when using
a managment interface on a else busy router. If I understand it correctly
the delay should not change but I'm unsure.

 
> Index: share/man/man9/task_add.9
> ===
> RCS file: /cvs/src/share/man/man9/task_add.9,v
> retrieving revision 1.16
> diff -u -p -r1.16 task_add.9
> --- share/man/man9/task_add.9 14 Sep 2015 15:14:55 -  1.16
> +++ share/man/man9/task_add.9 10 Nov 2017 00:45:41 -
> @@ -20,6 +20,7 @@
>  .Sh NAME
>  .Nm taskq_create ,
>  .Nm taskq_destroy ,
> +.Nm taskq_barrier ,
>  .Nm task_set ,
>  .Nm task_add ,
>  .Nm task_del ,
> @@ -37,6 +38,8 @@
>  .Ft void
>  .Fn taskq_destroy "struct taskq *tq"
>  .Ft void
> +.Fn taskq_barrier "struct taskq *tq"
> +.Ft void
>  .Fn task_set "struct task *t" "void (*fn)(void *)" "void *arg"
>  .Ft int
>  .Fn task_add "struct taskq *tq" "struct task *t"
> @@ -88,6 +91,15 @@ Calling
>  against the system taskq is an error and will lead to undefined
>  behaviour or a system fault.
>  .Pp
> +.Fn taskq_barrier
> +guarantees that any task that was running on the
> +.Fa tq
> +taskq when the barrier was called has finished by the time the barrier
> +returns.
> +.Fn taskq_barrier
> +is only supported on taskqs serviced by 1 thread,
> +and may not be called by a task running in the specified taskq.
> +.Pp
>  It is the responsibility of the caller to provide the
>  .Fn task_set ,
>  .Fn task_add ,
> @@ -163,6 +175,8 @@ argument given in
>  and
>  .Fn taskq_destroy
>  can be called during autoconf, or from process context.
> +.Fn taskq_barrier
> +can be called from process context.
>  .Fn task_set ,
>  .Fn task_add ,
>  and
> Index: sys/sys/task.h
> ===
> RCS file: /cvs/src/sys/sys/task.h,v
> retrieving revision 1.11
> diff -u -p -r1.11 task.h
> --- sys/sys/task.h7 Jun 2016 07:53:33 -   1.11
> +++ sys/sys/task.h10 Nov 2017 00:45:41 -
> @@ -43,6 +43,7 @@ extern struct taskq *const systqmp;
>  
>  struct taskq *taskq_create(const char *, unsigned int, int, unsigned int);
>  void  taskq_destroy(struct taskq *);
> +void  taskq_barrier(struct taskq *);
>  
>  void  task_set(struct task *, void (*)(void *), void *);
>  int   task_add(struct taskq *, struct task *);
> Index: sys/kern/kern_task.c
> ===
> RCS file: /cvs/src/sys/kern/kern_task.c,v
> retrieving revision 1.20
> diff -u -p -r1.20 kern_task.c
> --- sys/kern/kern_task.c  30 Oct 2017 14:01:42 -  1.20
> +++ sys/kern/kern_task.c  10 Nov 2017 00:45:41 -
> @@ -22,6 +22,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #define TASK_ONQUEUE 1
>  
> @@ -68,6 +69,7 @@ struct taskq *const systqmp = _sys
>  
>  void taskq_init(void); /* called in init_main.c */
>  void taskq_create_thread(void *);
> +void taskq_barrier_task(void *);
>  int  taskq_sleep(const volatile void *, struct mutex *, int,
>   const char *, int);
>  int  taskq_next_work(struct taskq *, struct task *, sleepfn);
> @@ -176,6 +178,30 @@ taskq_create_thread(void *arg)
>   } while (tq->tq_running < tq->tq_nthreads);
>  
>   mtx_leave(>tq_mtx);
> +}
> +
> +void
> +taskq_barrier(struct taskq *tq)
> +{
> + struct sleep_state sls;
> + unsigned int notdone = 1;
> + struct task t = TASK_INITIALIZER(taskq_barrier_task, );
> +
> + task_add(tq, );
> +
> + while (notdone) {
> + sleep_setup(, , PWAIT, "tqbar");
> +

mandoc warning tweak

2017-11-10 Thread Jeremie Courreges-Anglas 

I hit this while reviewing a recent diff:

  ritchie /usr/src/usr.sbin/ospf6d$ mandoc -Tlint ospf6d.conf.5
  mandoc: ospf6d.conf.5:211:5: STYLE: typo in section name: Sh AREAS instead of 
CAVEATS

which is a false positive.  The distance between "AREAS" and "CAVEATS"
is 3, maybe it's a bit much to warn about possible typos?

While I don't think this is a big deal, here's a possible tweak to
make the message less assertive.

Thoughts?


Index: mandoc.1
===
RCS file: /d/cvs/src/usr.bin/mandoc/mandoc.1,v
retrieving revision 1.143
diff -u -p -r1.143 mandoc.1
--- mandoc.17 Sep 2017 14:22:58 -   1.143
+++ mandoc.110 Nov 2017 18:12:57 -
@@ -875,7 +875,7 @@ A single manual page contains two copies
 the same operating system.
 Consider deleting the later instance and moving the first one up
 to the top of the page.
-.It Sy "typo in section name"
+.It Sy "possible typo in section name"
 .Pq mdoc
 Fuzzy string matching revealed that the argument of an
 .Ic \
Index: mandoc.h
===
RCS file: /d/cvs/src/usr.bin/mandoc/mandoc.h,v
retrieving revision 1.187
diff -u -p -r1.187 mandoc.h
--- mandoc.h8 Jul 2017 14:51:01 -   1.187
+++ mandoc.h10 Nov 2017 18:12:57 -
@@ -58,7 +58,7 @@ enum  mandocerr {
MANDOCERR_DATE_LEGACY, /* legacy man(7) date format: Dd ... */
MANDOCERR_TITLE_CASE, /* lower case character in document title */
MANDOCERR_RCS_REP, /* duplicate RCS id: ... */
-   MANDOCERR_SEC_TYPO,  /* typo in section name: Sh ... */
+   MANDOCERR_SEC_TYPO,  /* possible typo in section name: Sh ... */
MANDOCERR_ARG_QUOTE, /* unterminated quoted argument */
MANDOCERR_MACRO_USELESS, /* useless macro: macro */
MANDOCERR_BX, /* consider using OS macro: macro */
Index: read.c
===
RCS file: /d/cvs/src/usr.bin/mandoc/read.c,v
retrieving revision 1.164
diff -u -p -r1.164 read.c
--- read.c  20 Jul 2017 14:36:32 -  1.164
+++ read.c  10 Nov 2017 18:12:57 -
@@ -94,7 +94,7 @@ staticconst char * const  mandocerrs[MAN
"legacy man(7) date format",
"lower case character in document title",
"duplicate RCS id",
-   "typo in section name",
+   "possible typo in section name",
"unterminated quoted argument",
"useless macro",
"consider using OS macro",


-- 
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF  DDCC 0DFA 74AE 1524 E7EE

Re: Reported problem: postfix, libressl 2.6.x, DHE-RSA-AES256-SHA

2017-11-10 Thread Joel Sing 
On Friday 10 November 2017 11:58:04 Stuart Henderson wrote:
>
> From an irc contact using LibreSSL 2.6.3 on FreeBSD:
> 
> 11:14 < matt> Nov 10 11:06:06 tao postfix/smtpd[77685]: Anonymous TLS 
> connection established from email.morrisons.com[192.86.55.223]: TLSv1 with 
> cipher DHE-RSA-AES256-SHA (256/256 bits)
> 11:14 < matt> had to switch postfix to openssl temporarily to get that
> ...
> 11:26 < matt> using libressl 2.6.x I get this from morrisons:
> 11:27 < matt> Nov 10 10:55:57 tao postfix/smtpd[5996]: SSL_accept error from 
> email.morrisons.com[192.86.55.223]: -1
> 11:27 < matt> Nov 10 10:55:57 tao postfix/smtpd[5996]: warning: TLS library 
> problem: error:1403710B:SSL routines:ACCEPT_SR_KEY_EXCH:wrong version 
> number:ssl_pkt.c:376:
> 11:27 < matt> Nov 10 10:55:57 tao postfix/smtpd[5996]: lost connection after 
> STARTTLS from email.morrisons.com[192.86.55.223]
> 11:27 < matt> worked fine on 2.5.x
> ...
> 11:55 < matt> odd then. but yeah. works fine in 2.5.x, breaks in 2.6.x
> 11:56 < matt> it was actually broken on 2.6.0
>
> And Bernard mentioned similar yesterday.
> 
> 18:55 < Barnerd> Trusted TLS connection established from 
> russian-caravan.cloud9.net[2604:8d00:0:1::4]: TLSv1 with cipher 
> DHE-RSA-AES256-SHA (256/256 bits) is all I really know
> 18:58 < Barnerd> Cipher works OK with OpenSMTPd :D
> 
> matt has the mail accepted now and they're not triggerable remotely
> (most of their mails are sent via messagelabs, only certain marketing
> mails are sent this way) so I can't get a pcap or test on-demand. 
> 
> Code generating the error message here:
> 
> 374 /* Lets check version */
> 375 if (!s->internal->first_packet && ssl_version != 
> s->version) {
> 376 SSLerror(s, SSL_R_WRONG_VERSION_NUMBER);
> 377 if ((s->version & 0xFF00) == (ssl_version & 
> 0xFF00) &&
> 378 !s->internal->enc_write_ctx && 
> !s->internal->write_hash)
> 379 /* Send back error using their minor 
> version number :-) */
> 380 s->version = ssl_version;
> 381 al = SSL_AD_PROTOCOL_VERSION;
> 382 goto f_err;
> 383 }
> 
> It hasn't really changed recently, the SSLerror line was touched due to
> refactoring but no real changes there.
> 
> Any ideas?

This effectively suggests that during the TLS handshake (while we're expecting
the Client Key Exchange) the client is sending a record that has a version
number that does not match what we sent in the Server Hello, which is rather
strange. Out of the changes between 2.5.3 and 2.6.0, the only version related
change was the addition of SSL_{,CTX_}_set_{min,max}_proto_version(). However,
that seems unlikely to result in specific client breakage.

I suspect this is going to be difficult to track down without being able to see
what is on the wire (tcpdump or 'smtpd_tls_loglevel = 3' in postfix) or being
able to reproduce/trigger TLS sessions from the client.

Re: Reported problem: postfix, libressl 2.6.x, DHE-RSA-AES256-SHA

2017-11-10 Thread Stuart Henderson 
On 2017/11/10 23:46, Kinichiro Inoguchi wrote:
> Hi,
> 
> In my OpenBSD 6.2, LibreSSL server and OpenSSL client can communicate
> successfully via cipher DHE-RSA-AES256-SHA.

This happens with Postfix, it does not happen with libressl or openssl
(at least 1.0.2m) s_client connecting to the server which reported problems..

> --
> # Server LibreSSL 2.6.3
> $ openssl s_server -cert server.pem
> --
> # Client OpenSSL 1.0.2l
> $ eopenssl s_client -CAfile ca.pem -msg -cipher DHE-RSA-AES256-SHA
> ...
> Verify return code: 0 (ok)
> --
> 
> Can we know about SSL/TLS stack at client side ?

No idea.

> Are there any hint to investigate this issue ?

Only what we have in logs..

> 
> Thanks
> 
> On Fri, Nov 10, 2017 at 11:58:04AM +, Stuart Henderson wrote:
> > From an irc contact using LibreSSL 2.6.3 on FreeBSD:
>

Re: vi: flush trace to disk early

2017-11-10 Thread Todd C. Miller 
On Fri, 10 Nov 2017 12:15:18 +0100, Martijn van Duren wrote:

> When debugging some crashes in vi it can come in handy if TRACE calls
> are actually send to disk before the crash.
> 
> This shouldn't be a problem, since we're running debugging code anyway.

OK millert@

 - todd

Re: Reported problem: postfix, libressl 2.6.x, DHE-RSA-AES256-SHA

2017-11-10 Thread Kinichiro Inoguchi 
Hi,

In my OpenBSD 6.2, LibreSSL server and OpenSSL client can communicate
successfully via cipher DHE-RSA-AES256-SHA.

--
# Server LibreSSL 2.6.3
$ openssl s_server -cert server.pem
--
# Client OpenSSL 1.0.2l
$ eopenssl s_client -CAfile ca.pem -msg -cipher DHE-RSA-AES256-SHA
...
Verify return code: 0 (ok)
--

Can we know about SSL/TLS stack at client side ?
Are there any hint to investigate this issue ?

Thanks

On Fri, Nov 10, 2017 at 11:58:04AM +, Stuart Henderson wrote:
> From an irc contact using LibreSSL 2.6.3 on FreeBSD:

smtpd: simplify header rewrite code-path

2017-11-10 Thread Eric Faurot 
Hi.

The smtp message parser uses the header_domain_append_callback() and
header_masquerade_callback() functions to add missing domains in
header fields, and rewrite the sender in the From field if required.
The two functions are basically the same, except that the latter also
rewrites the sender after appending the missing domain. It is also
conditionnally hooked to the parser, replacing the former callback.
This is a bit confusing.

Instead of having two instances of the same complex code, keep only
one function that handles everything. It simplifies the code-path and
it makes it clear what conditions leads to rewriting the sender.  As a
bonus, it also fixes a bug (actually not triggerable) in the removed
code ("!= 1" should be "== -1").

Please test, especially if you are using the "masquerade" option.

Eric.

Index: smtp_session.c
===
RCS file: /cvs/src/usr.sbin/smtpd/smtp_session.c,v
retrieving revision 1.314
diff -u -p -r1.314 smtp_session.c
--- smtp_session.c  20 Oct 2017 12:23:36 -  1.314
+++ smtp_session.c  10 Nov 2017 13:37:56 -
@@ -325,88 +325,6 @@ header_append_domain_buffer(char *buffer
 }
 
 static void
-header_domain_append_callback(const struct rfc2822_header *hdr, void *arg)
-{
-   struct smtp_session*s = arg;
-   struct rfc2822_line*l;
-   size_t  i, j;
-   int escape, quote, comment, skip;
-   charbuffer[APPEND_DOMAIN_BUFFER_SIZE];
-
-   if (smtp_message_printf(s, "%s:", hdr->name) == -1)
-   return;
-
-   i = j = 0;
-   escape = quote = comment = skip = 0;
-   memset(buffer, 0, sizeof buffer);
-
-   TAILQ_FOREACH(l, >lines, next) {
-   for (i = 0; i < strlen(l->buffer); ++i) {
-   if (l->buffer[i] == '(' && !escape && !quote)
-   comment++;
-   if (l->buffer[i] == '"' && !escape && !comment)
-   quote = !quote;
-   if (l->buffer[i] == ')' && !escape && !quote && comment)
-   comment--;
-   if (l->buffer[i] == '\\' && !escape && !comment && 
!quote)
-   escape = 1;
-   else
-   escape = 0;
-
-   /* found a separator, buffer contains a full address */
-   if (l->buffer[i] == ',' && !escape && !quote && 
!comment) {
-   if (!skip && j + strlen(s->listener->hostname) 
+ 1 < sizeof buffer)
-   header_append_domain_buffer(buffer, 
s->listener->hostname, sizeof buffer);
-   if (smtp_message_printf(s, "%s,", buffer) == -1)
-   return;
-   j = 0;
-   skip = 0;
-   memset(buffer, 0, sizeof buffer);
-   }
-   else {
-   if (skip) {
-   if (smtp_message_printf(s, "%c",
-   l->buffer[i]) == -1)
-   return;
-   }
-   else {
-   buffer[j++] = l->buffer[i];
-   if (j == sizeof (buffer) - 1) {
-   if (smtp_message_printf(s, "%s",
-   buffer) != -1)
-   return;
-   skip = 1;
-   j = 0;
-   memset(buffer, 0, sizeof 
buffer);
-   }
-   }
-   }
-   }
-   if (skip) {
-   if (smtp_message_printf(s, "\n") == -1)
-   return;
-   }
-   else {
-   buffer[j++] = '\n';
-   if (j == sizeof (buffer) - 1) {
-   if (smtp_message_printf(s, "%s", buffer) == -1)
-   return;
-   skip = 1;
-   j = 0;
-   memset(buffer, 0, sizeof buffer);
-   }
-   }
-   }
-
-   /* end of header, if buffer is not empty we'll process it */
-   if (buffer[0]) {
-   if (j + strlen(s->listener->hostname) + 1 < sizeof buffer)
-   header_append_domain_buffer(buffer, 
s->listener->hostname, sizeof buffer);
-

Re: try to bundle multiple packets on an ifq before sending

2017-11-10 Thread Hrvoje Popovski 
On 10.11.2017. 1:58, David Gwynne wrote:
> this makes ifq_start try to wait for 4 packets before calling
> if->if_qstart.
> 
> this is based on work sephe did in dragonflybsd, and described in
> a comment in their sys/net/if.c. there's a link to it here:
> https://github.com/DragonFlyBSD/DragonFlyBSD/blob/master/sys/net/if.c#L2976-L2987
> 
> the tests we've done generally show a performance bump, but otherwise
> no degradation in performance.
> 
> the mechanism for bundling packets is to but schedule a task to
> service the queue later. if 4 packets get accumulated before the
> task runs, it's cancelled and the code runs the start routine
> directly.
> 
> the most significant difference this implementation has to the dfly
> one is that our ifqs dont (currently) track the number of bytes on
> the q. dfly sends if it can bundle 4 packets, or up to mtu bytes
> worth of packets. this implementation only looks at the number of
> packets.
> 
> the taskq the ifq uses is one of the softnets, which is assigned
> when the ifq is initted and unconditionally used during the ifq's
> lifetime. because ifq work could now be pending in a softnet taskq,
> ifq_barrier also needs to put a barrier in the taskq. this is
> implemented using taskq_barrier, which i wrote ages ago but didn't
> have a use case for at the time.
> 
> tests? ok?

Hi all,

i've tested plain ip4 forwarding performance with and without this diff
and here are results.
12 x Intel(R) Xeon(R) CPU E5-2620 v2 @ 2.10GHz, 2400.35 MHz

ix (82599) - sending 14Mpps
plain forwarding - 1.18Mpps
patched forwarding - 1.31Mpps

myx (8BL2-2S) - sending 14Mpps
plain forwarding - 900Kpps
patched forwarding - 1.10Mpps

em (i350) - sending 1.4Mpps
plain forwarding - 1Mpps
patched forwarding - 1.17Mpps

bge (5720) - sending 1.4Mpps
plain forwarding - oscillate from 780Kpps to 940Kpps
patched forwarding - oscillate from 850Kpps to 1Mpps


on box with
6 x Intel(R) Xeon(R) CPU E5-2643 v2 @ 3.50GHz, 3600.55 MHz
and with ix (82599) forwarding performance are the same with or without
diff, which is 1.75Mpps


will play with this diff over weekend just to see if there will be some
ill effect

Re: libfuse: signal handler doesn't cater for "Device busy" and other errors

2017-11-10 Thread Helg Bredow 
On Fri, 10 Nov 2017 10:13:35 +0100
Anton Lindqvist  wrote:

> On Fri, Nov 10, 2017 at 09:36:25AM +0100, Martin Pieuchot wrote:
> > On 09/11/17(Thu) 09:02, Helg Bredow wrote:
> > > The current libfuse signal handling assumes that the file system will 
> > > always be unmounted by the child. One obvious case where this is not true 
> > > is if the file system is busy. To replicate:
> > > 
> > > 1. mount a fuse file system
> > > 2. cd anywhere on the file system
> > > 3. pkill -INT 
> > > 
> > > The result is a zombie child process and no more response to signals even 
> > > if the file system is no longer busy.
> > > 
> > > This patch ensures that the child always exits and that an error is 
> > > printed to stdout if the file system cannot be unmounted. Tested with 
> > > fuse-exfat and ntfs_3g. Suggestions for improvement are welcome.
> > 
> > Nice to see that you're fixing a bug.  However I'd suggest you to go
> > much further in your improvement.
> > 
> > Signal handlers are hard and instead of doing work inside the signal
> > handler you should toggle a global variable/flag and do this work
> > inside the main loop (fuse_loop()?).
> > 
> > For example your code below calls fprintf(3) in the signal handler.  This
> > is incorrect, this functions is not signal handler safe.  What about 
> > fuse_unmount()?  Are you sure it can be called from a signal handler?
> 
> Some more info on making signal handlers asynchronous-safe:
> 
> https://www.securecoding.cert.org/confluence/display/c/SIG30-C.+Call+only+asynchronous-safe+functions+within+signal+handlers

Thanks for the feedback and info guys. I wasn't too confident with this patch 
and you've given me some good pointers to improve it.

-- 
Helg

Reported problem: postfix, libressl 2.6.x, DHE-RSA-AES256-SHA

2017-11-10 Thread Stuart Henderson 
>From an irc contact using LibreSSL 2.6.3 on FreeBSD:

11:14 < matt> Nov 10 11:06:06 tao postfix/smtpd[77685]: Anonymous TLS 
connection established from email.morrisons.com[192.86.55.223]: TLSv1 with 
cipher DHE-RSA-AES256-SHA (256/256 bits)
11:14 < matt> had to switch postfix to openssl temporarily to get that
...
11:26 < matt> using libressl 2.6.x I get this from morrisons:
11:27 < matt> Nov 10 10:55:57 tao postfix/smtpd[5996]: SSL_accept error from 
email.morrisons.com[192.86.55.223]: -1
11:27 < matt> Nov 10 10:55:57 tao postfix/smtpd[5996]: warning: TLS library 
problem: error:1403710B:SSL routines:ACCEPT_SR_KEY_EXCH:wrong version 
number:ssl_pkt.c:376:
11:27 < matt> Nov 10 10:55:57 tao postfix/smtpd[5996]: lost connection after 
STARTTLS from email.morrisons.com[192.86.55.223]
11:27 < matt> worked fine on 2.5.x
...
11:55 < matt> odd then. but yeah. works fine in 2.5.x, breaks in 2.6.x
11:56 < matt> it was actually broken on 2.6.0

And Bernard mentioned similar yesterday.

18:55 < Barnerd> Trusted TLS connection established from 
russian-caravan.cloud9.net[2604:8d00:0:1::4]: TLSv1 with cipher 
DHE-RSA-AES256-SHA (256/256 bits) is all I really know
18:58 < Barnerd> Cipher works OK with OpenSMTPd :D

matt has the mail accepted now and they're not triggerable remotely
(most of their mails are sent via messagelabs, only certain marketing
mails are sent this way) so I can't get a pcap or test on-demand. 

Code generating the error message here:

 374 /* Lets check version */
 375 if (!s->internal->first_packet && ssl_version != 
s->version) {
 376 SSLerror(s, SSL_R_WRONG_VERSION_NUMBER);
 377 if ((s->version & 0xFF00) == (ssl_version & 
0xFF00) &&
 378 !s->internal->enc_write_ctx && 
!s->internal->write_hash)
 379 /* Send back error using their minor 
version number :-) */
 380 s->version = ssl_version;
 381 al = SSL_AD_PROTOCOL_VERSION;
 382 goto f_err;
 383 }

It hasn't really changed recently, the SSLerror line was touched due to
refactoring but no real changes there.

Any ideas?

vi: flush trace to disk early

2017-11-10 Thread Martijn van Duren 
Hello tech@,

When debugging some crashes in vi it can come in handy if TRACE calls
are actually send to disk before the crash.

This shouldn't be a problem, since we're running debugging code anyway.

OK?

martijn@

Index: common/main.c
===
RCS file: /cvs/src/usr.bin/vi/common/main.c,v
retrieving revision 1.40
diff -u -p -r1.40 main.c
--- common/main.c   3 Jul 2017 07:01:14 -   1.40
+++ common/main.c   10 Nov 2017 11:13:56 -
@@ -188,6 +188,7 @@ editor(GS *gp, int argc, char *argv[])
}
(void)fprintf(gp->tracefp,
"\n===\ntrace: open %s\n", optarg);
+   fflush(gp->tracefp);
break;
 #endif
case 't':   /* Tag. */
Index: common/util.c
===
RCS file: /cvs/src/usr.bin/vi/common/util.c,v
retrieving revision 1.15
diff -u -p -r1.15 util.c
--- common/util.c   27 May 2016 09:18:11 -  1.15
+++ common/util.c   10 Nov 2017 11:13:56 -
@@ -174,6 +174,7 @@ TRACE(SCR *sp, const char *fmt, ...)
return;
va_start(ap, fmt);
(void)vfprintf(tfp, fmt, ap);
+   fflush(tfp);
va_end(ap);
 
(void)fflush(tfp);

softraid: missing keydisk message

2017-11-10 Thread sunil+tech 
Hi,
boot(8) displays "unknown KDF type 2" if the keydisk is missing...
>> OpenBSD/amd64 BOOT 3.33
unknown KDF type 2
open(sr0a:/etc/boot.conf): Operation not permitted
boot> 

The following diff makes boot(8) display slightly better information...
>> OpenBSD/amd64 BOOT 3.33
missing keydisk
open(sr0a:/etc/boot.conf): Operation not permitted
boot> 

Index: softraid.c
===
RCS file: /cvs/src/sys/lib/libsa/softraid.c,v
retrieving revision 1.2
diff -u -p -r1.2 softraid.c
--- softraid.c  18 Sep 2016 16:34:59 -  1.2
+++ softraid.c  10 Nov 2017 07:20:34 -
@@ -151,6 +151,9 @@ sr_crypto_decrypt_keys(struct sr_boot_vo
}
if (kd) {
bcopy(>kd_key, , sizeof(kdfinfo.maskkey));
+   } else if (kdfhint->generic.type == SR_CRYPTOKDFT_KEYDISK) {
+   printf("missing keydisk\n");
+   goto done;
} else {
if (kdfhint->generic.type != SR_CRYPTOKDFT_PKCS5_PBKDF2 &&
kdfhint->generic.type != SR_CRYPTOKDFT_BCRYPT_PBKDF) {

Re: libfuse: signal handler doesn't cater for "Device busy" and other errors

2017-11-10 Thread Anton Lindqvist 
On Fri, Nov 10, 2017 at 09:36:25AM +0100, Martin Pieuchot wrote:
> On 09/11/17(Thu) 09:02, Helg Bredow wrote:
> > The current libfuse signal handling assumes that the file system will 
> > always be unmounted by the child. One obvious case where this is not true 
> > is if the file system is busy. To replicate:
> > 
> > 1. mount a fuse file system
> > 2. cd anywhere on the file system
> > 3. pkill -INT 
> > 
> > The result is a zombie child process and no more response to signals even 
> > if the file system is no longer busy.
> > 
> > This patch ensures that the child always exits and that an error is printed 
> > to stdout if the file system cannot be unmounted. Tested with fuse-exfat 
> > and ntfs_3g. Suggestions for improvement are welcome.
> 
> Nice to see that you're fixing a bug.  However I'd suggest you to go
> much further in your improvement.
> 
> Signal handlers are hard and instead of doing work inside the signal
> handler you should toggle a global variable/flag and do this work
> inside the main loop (fuse_loop()?).
> 
> For example your code below calls fprintf(3) in the signal handler.  This
> is incorrect, this functions is not signal handler safe.  What about 
> fuse_unmount()?  Are you sure it can be called from a signal handler?

Some more info on making signal handlers asynchronous-safe:

https://www.securecoding.cert.org/confluence/display/c/SIG30-C.+Call+only+asynchronous-safe+functions+within+signal+handlers

Re: libfuse: signal handler doesn't cater for "Device busy" and other errors

2017-11-10 Thread Martin Pieuchot 
On 09/11/17(Thu) 09:02, Helg Bredow wrote:
> The current libfuse signal handling assumes that the file system will always 
> be unmounted by the child. One obvious case where this is not true is if the 
> file system is busy. To replicate:
> 
> 1. mount a fuse file system
> 2. cd anywhere on the file system
> 3. pkill -INT 
> 
> The result is a zombie child process and no more response to signals even if 
> the file system is no longer busy.
> 
> This patch ensures that the child always exits and that an error is printed 
> to stdout if the file system cannot be unmounted. Tested with fuse-exfat and 
> ntfs_3g. Suggestions for improvement are welcome.

Nice to see that you're fixing a bug.  However I'd suggest you to go
much further in your improvement.

Signal handlers are hard and instead of doing work inside the signal
handler you should toggle a global variable/flag and do this work
inside the main loop (fuse_loop()?).

For example your code below calls fprintf(3) in the signal handler.  This
is incorrect, this functions is not signal handler safe.  What about 
fuse_unmount()?  Are you sure it can be called from a signal handler?

I'd recommend you to read signal(3) and some signal handlers like the ones
from dhclient(8) and ntpd(8).

> Index: fuse.c
> ===
> RCS file: /cvs/src/lib/libfuse/fuse.c,v
> retrieving revision 1.34
> diff -u -p -r1.34 fuse.c
> --- fuse.c4 Nov 2017 13:17:18 -   1.34
> +++ fuse.c9 Nov 2017 08:41:11 -
> @@ -303,26 +303,40 @@ ifuse_get_signal(unused int num)
>  {
>   struct fuse *f;
>   pid_t child;
> - int status;
> + int status, err;
> +
> + if (num == SIGCHLD) {
> + /* child fuse_unmount() completed, check error */
> + while (waitpid(WAIT_ANY, , WNOHANG) == -1) {
> + if (errno != EINTR)
> + fprintf(stderr, "fuse: %s\n", strerror(errno));
> + }
> +
> + if (WIFEXITED(status)) {
> + err = WEXITSTATUS(status);
> + if (err)
> + fprintf(stderr, "fuse: %s\n", strerror(err));
> + }
> +
> + signal(SIGCHLD, SIG_DFL);
> + return;
> + }
>  
>   if (sigse != NULL) {
> + signal(SIGCHLD, ifuse_get_signal);
>   child = fork();
>  
>   if (child < 0)
> - return;
> + return ;
>  
> - f = sigse->args;
>   if (child == 0) {
> + /* try to unmount, file system may be busy */
> + f = sigse->args;
> + errno = 0;
>   fuse_unmount(f->fc->dir, f->fc);
> - sigse = NULL;
> - exit(0);
> + _exit(errno);
>   }
>  
> - fuse_loop(f);
> - while (waitpid(child, , 0) == -1) {
> - if (errno != EINTR)
> - break;
> - }
>   }
>  }
>  
>

armv7: newfs efi-partition in when choosing manual-fdisk mbr

2017-11-10 Thread Artturi Alm 
Hi,

currently, just editing the mbr to give more room for u-boot env growth,
will result in unbootable system, as the installer will fail to mount it,
and naturally things won't work beyond u-boot after reboot either.

i'm not really sure about this diff, but it does seem like it might do,
what i think it should? might take a while, before i can test myself, so
i thought i'd mail and ask, if there's a reason for how it is atm.? :)

-Artturi


diff --git a/distrib/armv7/ramdisk/install.md b/distrib/armv7/ramdisk/install.md
index 23d574e4e7a..1639e06c221 100644
--- a/distrib/armv7/ramdisk/install.md
+++ b/distrib/armv7/ramdisk/install.md
@@ -141,8 +141,14 @@ partition on the disk.
 $(fdisk ${_disk})
 __EOT
fdisk -e ${_disk}
-   disk_has $_disk mbr openbsd && return
-   echo No OpenBSD partition in MBR, try again. ;;
+   disk_has $_disk mbr efi ||
+   { echo No EFI(FAT id 0C) partition in MBR, try 
again.; continue; }
+   disk_has $_disk mbr efi_bootable ||
+   { echo No bootable EFI partition in MBR, try 
again.; continue; }
+   disk_has $_disk mbr openbsd ||
+   { echo No OpenBSD partition in MBR, try again.; 
continue; }
+   newfs -t ${bootfstype} ${newfs_args} ${_disk}i
+   return ;;
esac
done
 }
diff --git a/distrib/miniroot/install.sub b/distrib/miniroot/install.sub
index ef8c069588d..e204dd49d27 100644
--- a/distrib/miniroot/install.sub
+++ b/distrib/miniroot/install.sub
@@ -368,6 +368,8 @@ disk_has() {
local _p_mbr_openbsd='^..: A6 '
local _p_mbr_dos='^..: 06 '
local _p_mbr_dos_active='^\*.: 06 '
+   local _p_mbr_efi='^..: 0C '
+   local _p_mbr_efi_bootable='^\*.: 0C '
local _p_mbr_linux='^..: 83 '
local _p_sr='OPENBSD, SR'
local _p_sr_crypto='OPENBSD, SR CRYPTO'

Re: fuse: vfs create does not map 1:1 to fuse create

2017-11-10 Thread Martin Pieuchot 
On 09/11/17(Thu) 01:20, Helg Bredow wrote:
> > On 08/11/17(Wed) 14:12, Helg Bredow wrote:
> > > There is a bug when creating a file in fuse-exfat and then deleting it
> > > again without first unmounting the file system. The reason for this is
> > > that fuse-exfat maintains strict reference counts and fuse currently
> > > calls the file system create and open functions when it should only
> > > call create. 
> > > [...]
> > 
> > Does it call the userland file system functions because it receives 2
> > FBT messages?
> 
> Yes, fuse receives both create and open from the kernel and blindly
> passes them via FBT messages to userland.
> 
> > 
> > Can you see which FBT messages are generated by the kernel?  Does
> > ktrace(1) has support for that?
> 
> The debug output from libfuse let's you trace the FBT messages and I
> also have judicious printf() statements to help me diagnose.

That's not ideal, having to recompile a kernel is ok for development but
for debugging it would be better to add ktrace(1) hooks to fuse(4).

> > > The VOP_CREATE(9) function does not behave like this so we either need
> > > to simulate it within fuse or fall back to mknod() and open(). 
> > 
> > VOP_CREATE(9) is just a wrapper around the underlying FS.  In your case
> > fusefs_create().  This function enqueues a single FBT_CREATE operation,
> > so it doesn't match what you said before.
> > 
> > So I still don't understand the problem.  Where is the bug?
> > 
> 
> The problem is that the kernel's idea of create is different to the
> fuse FBT_CREATE passed to userland.

That can't be the problem.  Both the kernel and the fusebuf API are an
implementation detail of OpenBSD's FUSE.

> The kernel doesn't expect create to
> also open the file. 

I don't understand this sentence.  Why does the kernel care?


> > If the problem is that the kernel enqueue 2 FBT operations instead of
> > one, then change the kernel.
> > 
> > If the problem is that fusefs_create() does not have all the information
> > for generating a FBT_CREATE message and that it hardcodes (O_CREAT|O_RDWR)
> > then maybe you should delay that operation to fusefs_open().
> > 
> > These are stupid guesses because I don't understand what the problem is.
> 
> Your last suggestion is one that I had not considered. I immediately
> went to implement it but was disappointed to find that it won't work
> without crazy lock management and maintaining state between kernel
> calls. I think it's too complex and prefer the simple solution I've
> proposed because it behaves the same as ffs, nfs etc.

In the end that's your call.  Nobody understand the problem, what you
say is "we are not linux".  Which we already know.  And you're pushing
for a diff which works saying that the best solution.  It believe it
fixes the problem so go for it.