const in crypto code

2017-01-03 Thread Michael W. Bombardieri
Hi,

Add "const" to weak_keys array which is read only (read via bcmp()).
>From what I see all other arrays in src/sys/crypto are already "static const".

- Michael


Index: set_key.c
===
RCS file: /cvs/src/sys/crypto/set_key.c,v
retrieving revision 1.4
diff -u -p -u -r1.4 set_key.c
--- set_key.c   10 Dec 2015 21:00:51 -  1.4
+++ set_key.c   4 Jan 2017 06:34:27 -
@@ -84,7 +84,7 @@ check_parity(des_cblock (*key))
  * (and actual cblock values).
  */
 #define NUM_WEAK_KEY   16
-static des_cblock weak_keys[NUM_WEAK_KEY]={
+static const des_cblock weak_keys[NUM_WEAK_KEY]={
/* weak keys */
{0x01,0x01,0x01,0x01,0x01,0x01,0x01,0x01},
{0xFE,0xFE,0xFE,0xFE,0xFE,0xFE,0xFE,0xFE},



Re: [patch] turn igmpstat into a set of percpu counters

2017-01-03 Thread David Gwynne

> On 22 Dec 2016, at 20:51, Dimitris Papastamos  wrote:
> 
> On Sun, Dec 11, 2016 at 07:24:40PM +, Dimitris Papastamos wrote:
>> Hi,
>> 
>> I converted the igmp stats to use percpu counters.  This work is
>> basically the same as what dlg@ did for other parts of the stack.
>> I looked at the diff and adjusted it for igmp.
> 
> ping

it's in now.

sorry about the delay, i wanted to be around after committing to handle any 
(unlikely) fallout.

cheers,
dlg


Re: qsort.c: remove useless variable

2017-01-03 Thread Alexander Bluhm
On Tue, Jan 03, 2017 at 04:40:47PM -0700, Todd C. Miller wrote:
> On Tue, 03 Jan 2017 21:51:12 +0100, Alexander Bluhm wrote:
> 
> > I think it would be nicer to keep the char * a variable and remove
> > the (char *) casts instead.
> 
> How about this?

The qsort.o does not change.  OK bluhm@

> 
>  - todd
> 
> Index: lib/libc/stdlib/qsort.c
> ===
> RCS file: /cvs/src/lib/libc/stdlib/qsort.c,v
> retrieving revision 1.13
> diff -u -p -u -r1.13 qsort.c
> --- lib/libc/stdlib/qsort.c   13 Sep 2015 08:31:47 -  1.13
> +++ lib/libc/stdlib/qsort.c   3 Jan 2017 23:39:24 -
> @@ -90,16 +90,16 @@ qsort(void *aa, size_t n, size_t es, int
>  
>  loop:SWAPINIT(a, es);
>   if (n < 7) {
> - for (pm = (char *)a + es; pm < (char *) a + n * es; pm += es)
> - for (pl = pm; pl > (char *) a && cmp(pl - es, pl) > 0;
> + for (pm = a + es; pm < a + n * es; pm += es)
> + for (pl = pm; pl > a && cmp(pl - es, pl) > 0;
>pl -= es)
>   swap(pl, pl - es);
>   return;
>   }
> - pm = (char *)a + (n / 2) * es;
> + pm = a + (n / 2) * es;
>   if (n > 7) {
> - pl = (char *)a;
> - pn = (char *)a + (n - 1) * es;
> + pl = a;
> + pn = a + (n - 1) * es;
>   if (n > 40) {
>   d = (n / 8) * es;
>   pl = med3(pl, pl + d, pl + 2 * d, cmp);
> @@ -109,9 +109,9 @@ loop: SWAPINIT(a, es);
>   pm = med3(pl, pm, pn, cmp);
>   }
>   swap(a, pm);
> - pa = pb = (char *)a + es;
> + pa = pb = a + es;
>  
> - pc = pd = (char *)a + (n - 1) * es;
> + pc = pd = a + (n - 1) * es;
>   for (;;) {
>   while (pb <= pc && (cmp_result = cmp(pb, a)) <= 0) {
>   if (cmp_result == 0) {
> @@ -134,8 +134,8 @@ loop: SWAPINIT(a, es);
>   pc -= es;
>   }
>  
> - pn = (char *)a + n * es;
> - r = min(pa - (char *)a, pb - pa);
> + pn = a + n * es;
> + r = min(pa - a, pb - pa);
>   vecswap(a, pb - r, r);
>   r = min(pd - pc, pn - pd - es);
>   vecswap(pb, pn - r, r);



Re: qsort.c: remove useless variable

2017-01-03 Thread Todd C. Miller
On Tue, 03 Jan 2017 21:51:12 +0100, Alexander Bluhm wrote:

> I think it would be nicer to keep the char * a variable and remove
> the (char *) casts instead.

How about this?

 - todd

Index: lib/libc/stdlib/qsort.c
===
RCS file: /cvs/src/lib/libc/stdlib/qsort.c,v
retrieving revision 1.13
diff -u -p -u -r1.13 qsort.c
--- lib/libc/stdlib/qsort.c 13 Sep 2015 08:31:47 -  1.13
+++ lib/libc/stdlib/qsort.c 3 Jan 2017 23:39:24 -
@@ -90,16 +90,16 @@ qsort(void *aa, size_t n, size_t es, int
 
 loop:  SWAPINIT(a, es);
if (n < 7) {
-   for (pm = (char *)a + es; pm < (char *) a + n * es; pm += es)
-   for (pl = pm; pl > (char *) a && cmp(pl - es, pl) > 0;
+   for (pm = a + es; pm < a + n * es; pm += es)
+   for (pl = pm; pl > a && cmp(pl - es, pl) > 0;
 pl -= es)
swap(pl, pl - es);
return;
}
-   pm = (char *)a + (n / 2) * es;
+   pm = a + (n / 2) * es;
if (n > 7) {
-   pl = (char *)a;
-   pn = (char *)a + (n - 1) * es;
+   pl = a;
+   pn = a + (n - 1) * es;
if (n > 40) {
d = (n / 8) * es;
pl = med3(pl, pl + d, pl + 2 * d, cmp);
@@ -109,9 +109,9 @@ loop:   SWAPINIT(a, es);
pm = med3(pl, pm, pn, cmp);
}
swap(a, pm);
-   pa = pb = (char *)a + es;
+   pa = pb = a + es;
 
-   pc = pd = (char *)a + (n - 1) * es;
+   pc = pd = a + (n - 1) * es;
for (;;) {
while (pb <= pc && (cmp_result = cmp(pb, a)) <= 0) {
if (cmp_result == 0) {
@@ -134,8 +134,8 @@ loop:   SWAPINIT(a, es);
pc -= es;
}
 
-   pn = (char *)a + n * es;
-   r = min(pa - (char *)a, pb - pa);
+   pn = a + n * es;
+   r = min(pa - a, pb - pa);
vecswap(a, pb - r, r);
r = min(pd - pc, pn - pd - es);
vecswap(pb, pn - r, r);



Re: find(1): pledge mayexecve codepath

2017-01-03 Thread Ted Unangst
Theo Buehler wrote:
> tedu's -delete diff reminded me of a patch I've had in one of my trees
> for quite a while: find(1) was tamed a few days before execve(2) was
> added to kern_tame.c and I think it was simply forgotten that everything
> was already prepared for this.  Now it's slightly more complicated than
> before because of the -delete option.

Yeah. I had to fiddle because I was adding something. I wasn't sure if it
would be better to add a switch? Pick a string and then call pledge(perms). We
don't typically do that, but is there a tipping point where the if/err dance
gets too repititive?

> 
> Index: find.c
> ===
> RCS file: /cvs/src/usr.bin/find/find.c,v
> retrieving revision 1.21
> diff -u -p -r1.21 find.c
> --- find.c3 Jan 2017 21:31:16 -   1.21
> +++ find.c3 Jan 2017 21:44:50 -
> @@ -162,6 +162,15 @@ find_execute(PLAN *plan, /* search plan 
>   if (pledge("stdio rpath getpw", NULL) == -1)
>   err(1, "pledge");
>   }
> + } else {
> + if (isdelete) {
> + if (pledge("stdio rpath cpath getpw proc exec", NULL)
> + == -1)
> + err(1, "pledge");
> + } else {
> + if (pledge("stdio rpath getpw proc exec", NULL) == -1)
> + err(1, "pledge");
> + }
>   }
>  
>   rval = 0;
> 



Re: find(1): pledge mayexecve codepath

2017-01-03 Thread Todd C. Miller
On Tue, 03 Jan 2017 23:52:46 +0100, Theo Buehler wrote:

> tedu's -delete diff reminded me of a patch I've had in one of my trees
> for quite a while: find(1) was tamed a few days before execve(2) was
> added to kern_tame.c and I think it was simply forgotten that everything
> was already prepared for this.  Now it's slightly more complicated than
> before because of the -delete option.

OK millert@

 - todd



find(1): pledge mayexecve codepath

2017-01-03 Thread Theo Buehler
tedu's -delete diff reminded me of a patch I've had in one of my trees
for quite a while: find(1) was tamed a few days before execve(2) was
added to kern_tame.c and I think it was simply forgotten that everything
was already prepared for this.  Now it's slightly more complicated than
before because of the -delete option.

Index: find.c
===
RCS file: /cvs/src/usr.bin/find/find.c,v
retrieving revision 1.21
diff -u -p -r1.21 find.c
--- find.c  3 Jan 2017 21:31:16 -   1.21
+++ find.c  3 Jan 2017 21:44:50 -
@@ -162,6 +162,15 @@ find_execute(PLAN *plan,   /* search plan 
if (pledge("stdio rpath getpw", NULL) == -1)
err(1, "pledge");
}
+   } else {
+   if (isdelete) {
+   if (pledge("stdio rpath cpath getpw proc exec", NULL)
+   == -1)
+   err(1, "pledge");
+   } else {
+   if (pledge("stdio rpath getpw proc exec", NULL) == -1)
+   err(1, "pledge");
+   }
}
 
rval = 0;



Re: find -delete

2017-01-03 Thread Ted Unangst
Mark Kettenis wrote:
> I really think we should not encourage unportable code like that by
> giving an example in our manual page.

That's fair.

> I'm even tempted to say that you should leave the "-exec rm {} \;"
> example alone.  The + here only works because rm(1) accepts multiple
> file arguments.

This whole adventure started because I was trying to delete 10 old
emails. The default recipe, which execs one rm per file, was taking forever.
It would probably still be running. If I'm reading the find man page because
I'm trying to delete so many files I would overflow argv with shell wildcards,
I definitely want the turbo recipe.

> And I don't understand the sentence about recursively removing
> non-empty directories; rm(1) doesn't remove directories unless you use the
> -r option!

If some of the files you want to delete are directories, the obvious
solution when using xargs or -exec is to add -r to rm. But then this will
change behavior. I think it's possible to cook up a find invocation that uses
-type d -exec rmdir {} \; -o \! -type d -exec rm {} \; but as you see,
it gets unwieldy fast. I thought this would be worth highlighting.



Re: find -delete

2017-01-03 Thread Theo de Raadt
>> From: "Ted Unangst" 
>> Date: Tue, 03 Jan 2017 16:39:48 -0500
>> 
>> I copied this straight from freebsd. Not fixed, but feel free to correct as
>> desired.
>> 
>> This adds a third example showing -delete, mentioning that it's not standard,
>> but also hinting that it may work better than "rm -r" when you want to delete
>> directories.
>
>I really think we should not encourage unportable code like that by
>giving an example in our manual page.

Well lets be honest, we are accepting this feature last; it was only missing
in openbsd and whocaris



Re: find -delete

2017-01-03 Thread Mark Kettenis
> From: "Ted Unangst" 
> Date: Tue, 03 Jan 2017 16:39:48 -0500
> 
> I copied this straight from freebsd. Not fixed, but feel free to correct as
> desired.
> 
> This adds a third example showing -delete, mentioning that it's not standard,
> but also hinting that it may work better than "rm -r" when you want to delete
> directories.

I really think we should not encourage unportable code like that by
giving an example in our manual page.

I'm even tempted to say that you should leave the "-exec rm {} \;"
example alone.  The + here only works because rm(1) accepts multiple
file arguments.

And I don't understand the sentence about recursively removing
non-empty directories; rm(1) doesn't remove directories unless you use the
-r option!

> Index: find.1
> ===
> RCS file: /cvs/src/usr.bin/find/find.1,v
> retrieving revision 1.92
> diff -u -p -r1.92 find.1
> --- find.13 Jan 2017 21:31:16 -   1.92
> +++ find.13 Jan 2017 21:36:30 -
> @@ -575,9 +575,15 @@ ending in a dot and single digit, but sk
>  Find and remove all *.jpg and *.gif files under the current working
>  directory:
>  .Pp
> -.Dl "$ find . \e( -name \e*.jpg -o -name \e*.gif \e) -exec rm {} \e;"
> +.Dl "$ find . \e( -name \e*.jpg -o -name \e*.gif \e) -exec rm {} +"
>  or
>  .Dl "$ find . \e( -name \e*.jpg -o -name \e*.gif \e) -print0 | xargs -0r rm"
> +or
> +.Dl "$ find . \e( -name \e*.jpg -o -name \e*.gif \e) -delete"
> +.Pp
> +Note that this third version is not guaranteed to be portable.
> +However, if it is desired to delete directories as well, it may be safer
> +because it will not accidentally recursively remove non-emtpy directories.
>  .Sh SEE ALSO
>  .Xr chflags 1 ,
>  .Xr chmod 1 ,
> 
> 



Re: find -delete

2017-01-03 Thread Ted Unangst
Jason McIntyre wrote:
> no opinion on the addition, but if there is a better way to write the
> examples that are there, i think you should take the time to do so. i'd
> also slightly prefer we show the more traditional way to do it, though i
> appreciate that might not make a ton of sense for find(1).

Patch below.

> i'd use Sq rather than Dq for single letters if you really need it
> quoted. and check, but i think you need \& after the dot, not before, or
> you'll get a double space injected.

I copied this straight from freebsd. Not fixed, but feel free to correct as
desired.

This adds a third example showing -delete, mentioning that it's not standard,
but also hinting that it may work better than "rm -r" when you want to delete
directories.


Index: find.1
===
RCS file: /cvs/src/usr.bin/find/find.1,v
retrieving revision 1.92
diff -u -p -r1.92 find.1
--- find.1  3 Jan 2017 21:31:16 -   1.92
+++ find.1  3 Jan 2017 21:36:30 -
@@ -575,9 +575,15 @@ ending in a dot and single digit, but sk
 Find and remove all *.jpg and *.gif files under the current working
 directory:
 .Pp
-.Dl "$ find . \e( -name \e*.jpg -o -name \e*.gif \e) -exec rm {} \e;"
+.Dl "$ find . \e( -name \e*.jpg -o -name \e*.gif \e) -exec rm {} +"
 or
 .Dl "$ find . \e( -name \e*.jpg -o -name \e*.gif \e) -print0 | xargs -0r rm"
+or
+.Dl "$ find . \e( -name \e*.jpg -o -name \e*.gif \e) -delete"
+.Pp
+Note that this third version is not guaranteed to be portable.
+However, if it is desired to delete directories as well, it may be safer
+because it will not accidentally recursively remove non-emtpy directories.
 .Sh SEE ALSO
 .Xr chflags 1 ,
 .Xr chmod 1 ,



Re: Recursive NET_LOCK()

2017-01-03 Thread Mark Kettenis
> Date: Tue, 3 Jan 2017 17:13:27 +0100
> From: Martin Pieuchot 
> 
> It seems that most of the problems exposed by the introduction of the
> NET_LOCK() are related to the non-recursive nature of the rwlock.  Some
> known issues involve pflow(4), cloning interfaces an NFS.
> 
> Diff below makes use of a recursive-rwlock instead.  I just finished a
> build on NFS with it, so I'd like to know if it works for your use case.
> 
> Please test and report back.

This does not fix the chrome hang that I was seeing.

> Index: kern/kern_rwlock.c
> ===
> RCS file: /cvs/src/sys/kern/kern_rwlock.c,v
> retrieving revision 1.27
> diff -u -p -r1.27 kern_rwlock.c
> --- kern/kern_rwlock.c14 Mar 2015 07:33:42 -  1.27
> +++ kern/kern_rwlock.c3 Jan 2017 14:23:56 -
> @@ -346,3 +346,23 @@ rrw_status(struct rrwlock *rrwl)
>  {
>   return (rw_status(>rrwl_lock));
>  }
> +
> +int
> +rrw_release_all(struct rrwlock *rrwl)
> +{
> + int rv;
> +
> + rv = rrwl->rrwl_wcnt;
> + KASSERT(rv >= 1);
> + rrwl->rrwl_wcnt = 1;
> + rrw_exit(rrwl);
> +
> + return (rv);
> +}
> +
> +void
> +rrw_acquire_count(struct rrwlock *rrwl, int count, int flags)
> +{
> + while (count--)
> + rrw_enter(rrwl, flags);
> +}
> Index: kern/kern_synch.c
> ===
> RCS file: /cvs/src/sys/kern/kern_synch.c,v
> retrieving revision 1.135
> diff -u -p -r1.135 kern_synch.c
> --- kern/kern_synch.c 13 Sep 2016 08:32:44 -  1.135
> +++ kern/kern_synch.c 3 Jan 2017 14:07:23 -
> @@ -231,27 +231,28 @@ msleep(const volatile void *ident, struc
>   * entered the sleep queue we drop the it. After sleeping we re-lock.
>   */
>  int
> -rwsleep(const volatile void *ident, struct rwlock *wl, int priority,
> +rrwsleep(const volatile void *ident, struct rrwlock *rrwl, int priority,
>  const char *wmesg, int timo)
>  {
>   struct sleep_state sls;
>   int error, error1;
> + int count;
>  
>   KASSERT((priority & ~(PRIMASK | PCATCH | PNORELOCK)) == 0);
> - rw_assert_wrlock(wl);
> + KASSERT(rrw_status(rrwl) == RW_WRITE);
>  
>   sleep_setup(, ident, priority, wmesg);
>   sleep_setup_timeout(, timo);
>   sleep_setup_signal(, priority);
>  
> - rw_exit_write(wl);
> + count = rrw_release_all(rrwl);
>  
>   sleep_finish(, 1);
>   error1 = sleep_finish_timeout();
>   error = sleep_finish_signal();
>  
>   if ((priority & PNORELOCK) == 0)
> - rw_enter_write(wl);
> + rrw_acquire_count(rrwl, count, RW_WRITE);
>  
>   /* Signal errors are higher priority than timeouts. */
>   if (error == 0 && error1 != 0)
> Index: kern/uipc_socket.c
> ===
> RCS file: /cvs/src/sys/kern/uipc_socket.c,v
> retrieving revision 1.171
> diff -u -p -r1.171 uipc_socket.c
> --- kern/uipc_socket.c29 Dec 2016 12:12:43 -  1.171
> +++ kern/uipc_socket.c3 Jan 2017 14:04:42 -
> @@ -256,7 +256,7 @@ soclose(struct socket *so)
>   (so->so_state & SS_NBIO))
>   goto drop;
>   while (so->so_state & SS_ISCONNECTED) {
> - error = tsleep(>so_timeo,
> + error = rrwsleep(>so_timeo, ,
>   PSOCK | PCATCH, "netcls",
>   so->so_linger * hz);
>   if (error)
> @@ -1039,7 +1039,7 @@ sorflush(struct socket *so)
>   struct sockbuf asb;
>  
>   sb->sb_flags |= SB_NOINTR;
> - (void) sblock(sb, M_WAITOK, NULL);
> + (void) sblock(sb, M_WAITOK, );
>   socantrcvmore(so);
>   sbunlock(sb);
>   asb = *sb;
> Index: kern/uipc_socket2.c
> ===
> RCS file: /cvs/src/sys/kern/uipc_socket2.c,v
> retrieving revision 1.70
> diff -u -p -r1.70 uipc_socket2.c
> --- kern/uipc_socket2.c   29 Dec 2016 12:12:43 -  1.70
> +++ kern/uipc_socket2.c   3 Jan 2017 14:06:54 -
> @@ -53,7 +53,7 @@ u_long  sb_max = SB_MAX;/* patchable */
>  extern struct pool mclpools[];
>  extern struct pool mbpool;
>  
> -int sbsleep(struct sockbuf *, struct rwlock *);
> +int sbsleep(struct sockbuf *, struct rrwlock *);
>  
>  /*
>   * Procedures to manipulate state flags of socket
> @@ -276,18 +276,18 @@ sbwait(struct sockbuf *sb)
>   NET_ASSERT_LOCKED();
>  
>   sb->sb_flagsintr |= SB_WAIT;
> - return (tsleep(>sb_cc,
> + return (rrwsleep(>sb_cc, ,
>   (sb->sb_flags & SB_NOINTR) ? PSOCK : PSOCK | PCATCH, "netio",
>   sb->sb_timeo));
>  }
>  
>  int
> -sbsleep(struct sockbuf *sb, struct rwlock *lock)
> +sbsleep(struct sockbuf *sb, struct rrwlock *rrwl)
>  {
>   int error, prio = (sb->sb_flags & SB_NOINTR) ? PSOCK : 

ld.so diff that needs testing on landisk

2017-01-03 Thread Mark Kettenis
The diff below (partly by guenther@) removes ld.so's dependency on the
__got_{start,end} symbols by looking at PT_GNU_RELRO instead.  On some
platforms (hppa and perhaps a few others) this leads to even less
writable pages.  However, we're not sure if this will work correctly
on landisk.  So if somebody with a fairly up-to-date landisk could
give this a spin for us, it would be highly appreciated.


Index: libexec/ld.so/boot.c
===
RCS file: /cvs/src/libexec/ld.so/boot.c,v
retrieving revision 1.14
diff -u -p -r1.14 boot.c
--- libexec/ld.so/boot.c13 Aug 2016 20:57:04 -  1.14
+++ libexec/ld.so/boot.c2 Jan 2017 15:55:52 -
@@ -87,6 +87,8 @@ _dl_boot_bind(const long sp, long *dl_da
longloff;
Elf_Addri;
RELOC_TYPE  *rp;
+   Elf_Ehdr*ehdp;
+   Elf_Phdr*phdp;
 
/*
 * Scan argument and environment vectors. Find dynamic
@@ -189,4 +191,30 @@ _dl_boot_bind(const long sp, long *dl_da
 * we have been fully relocated here, so most things no longer
 * need the loff adjustment
 */
+
+   /*
+* No further changes to the PLT and/or GOT are needed so make
+* them read-only.
+*/
+
+   /* do any RWX -> RX fixups for executable PLTs and apply GNU_RELRO */
+   ehdp = (Elf_Ehdr *)loff;
+   phdp = (Elf_Phdr *)(loff + ehdp->e_phoff);
+   for (i = 0; i < dl_data[AUX_phnum]; i++, phdp++) {
+   switch (phdp->p_type) {
+#if defined(__alpha__) || defined(__hppa__) || defined(__powerpc__) || \
+defined(__sparc64__)
+   case PT_LOAD:
+   if ((phdp->p_flags & (PF_X | PF_W)) != (PF_X | PF_W))
+   break;
+   _dl_mprotect((void *)(phdp->p_vaddr + loff),
+   phdp->p_memsz, PROT_READ);
+   break;
+#endif
+   case PT_GNU_RELRO:
+   _dl_mprotect((void *)(phdp->p_vaddr + loff),
+   phdp->p_memsz, PROT_READ);
+   break;
+   }
+   }
 }
Index: libexec/ld.so/loader.c
===
RCS file: /cvs/src/libexec/ld.so/loader.c,v
retrieving revision 1.167
diff -u -p -r1.167 loader.c
--- libexec/ld.so/loader.c  28 Aug 2016 04:33:17 -  1.167
+++ libexec/ld.so/loader.c  2 Jan 2017 15:55:52 -
@@ -413,25 +413,6 @@ _dl_boot(const char **argv, char **envp,
 #define ROUND_PG(x) (((x) + align) & ~(align))
 #define TRUNC_PG(x) ((x) & ~(align))
 
-   /*
-* now that GOT and PLT have been relocated, and we know
-* page size, protect them from modification
-*/
-#ifndef  RTLD_NO_WXORX
-   {
-   extern char *__got_start;
-   extern char *__got_end;
-
-   if (&__got_start != &__got_end) {
-   _dl_mprotect((void *)ELF_TRUNC((long)&__got_start,
-   _dl_pagesz),
-   ELF_ROUND((long)&__got_end,_dl_pagesz) -
-   ELF_TRUNC((long)&__got_start, _dl_pagesz),
-   GOT_PERMS);
-   }
-   }
-#endif
-
_dl_setup_env(argv[0], envp);
 
DL_DEB(("rtld loading: '%s'\n", __progname));
Index: libexec/ld.so/alpha/archdep.h
===
RCS file: /cvs/src/libexec/ld.so/alpha/archdep.h,v
retrieving revision 1.17
diff -u -p -r1.17 archdep.h
--- libexec/ld.so/alpha/archdep.h   6 Dec 2015 23:36:12 -   1.17
+++ libexec/ld.so/alpha/archdep.h   2 Jan 2017 15:55:52 -
@@ -65,6 +65,4 @@ RELOC_DYN(Elf64_Rela *r, const Elf64_Sym
 
 #define RELOC_GOT(obj, offs)
 
-#define GOT_PERMS PROT_READ
-
 #endif /* _ALPHA_ARCHDEP_H_ */
Index: libexec/ld.so/amd64/archdep.h
===
RCS file: /cvs/src/libexec/ld.so/amd64/archdep.h,v
retrieving revision 1.8
diff -u -p -r1.8 archdep.h
--- libexec/ld.so/amd64/archdep.h   18 May 2016 20:40:20 -  1.8
+++ libexec/ld.so/amd64/archdep.h   2 Jan 2017 15:55:52 -
@@ -68,6 +68,4 @@ RELOC_DYN(Elf64_Rela *r, const Elf64_Sym
 
 #define RELOC_GOT(obj, offs)
 
-#define GOT_PERMS PROT_READ
-
 #endif /* _X86_64_ARCHDEP_H_ */
Index: libexec/ld.so/arm/archdep.h
===
RCS file: /cvs/src/libexec/ld.so/arm/archdep.h,v
retrieving revision 1.8
diff -u -p -r1.8 archdep.h
--- libexec/ld.so/arm/archdep.h 8 Sep 2016 18:56:58 -   1.8
+++ libexec/ld.so/arm/archdep.h 2 Jan 2017 15:55:52 -
@@ -73,6 +73,4 @@ RELOC_DYN(Elf_Rel *r, const Elf_Sym *s, 
 
 #define RELOC_GOT(obj, offs)
 
-#define GOT_PERMS (PROT_READ|PROT_EXEC)
-
 #endif /* _ARM_ARCHDEP_H_ */
Index: libexec/ld.so/hppa/archdep.h

Re: qsort.c: remove useless variable

2017-01-03 Thread Alexander Bluhm
On Tue, Jan 03, 2017 at 12:57:59PM -0700, Todd C. Miller wrote:
> When qsort.c was de-registered, the register version of 'aa' was
> not removed.  Since qsort() already contains casts of a to char *
> there's no need for a separate variable here.

I think it would be nicer to keep the char * a variable and remove
the (char *) casts instead.

bluhm

> 
>  - todd
> 
> Index: lib/libc/stdlib/qsort.c
> ===
> RCS file: /cvs/src/lib/libc/stdlib/qsort.c,v
> retrieving revision 1.13
> diff -u -p -u -r1.13 qsort.c
> --- lib/libc/stdlib/qsort.c   13 Sep 2015 08:31:47 -  1.13
> +++ lib/libc/stdlib/qsort.c   3 Jan 2017 14:29:03 -
> @@ -81,12 +81,11 @@ med3(char *a, char *b, char *c, int (*cm
>  }
>  
>  void
> -qsort(void *aa, size_t n, size_t es, int (*cmp)(const void *, const void *))
> +qsort(void *a, size_t n, size_t es, int (*cmp)(const void *, const void *))
>  {
>   char *pa, *pb, *pc, *pd, *pl, *pm, *pn;
>   int cmp_result, swaptype;
>   size_t d, r;
> - char *a = aa;
>  
>  loop:SWAPINIT(a, es);
>   if (n < 7) {



Re: vndcompress et al import?

2017-01-03 Thread Ted Unangst
Timo Buhrmester wrote:
> > delete [vnd] entirely
> Out of curiosity (I'm mostly a NetBSD user), without vnd what would be
> the OpenBSD-way of providing a disk-ish interface to a file?

Well, the biggest use of vnd in base was just replaced with the makefs. (from
netbsd, actually.) vnd isn't going to be deleted, but it's pretty easy to
make a vscsi provider that talks to a file. If i had a pressing need to mount
compressed disk images, I'd start there. (I had some code for this, but it's
in another castle. It's pretty short, only like 20 lines anyway.)



Re: compiler-rt: upgrade to 3.9.1 / fix gcc personality compile error

2017-01-03 Thread Mark Kettenis
> Date: Tue, 3 Jan 2017 17:49:19 +0100
> From: Patrick Wildt 
> 
> Hi,
> 
> the GCC personality C file does not compile with clang 3.8 on ARM.  They
> have fixed the issue in compiler-rt and released 3.9.1.  Apparently that
> is the only thing they changed in the builtins.  Thus this diff is in
> essence an update to the compiler-rt release 3.9.1.
> 
> ok?

Don't fully understand the issue, but it's probably best to go with
the flow.

ok kettenis@

> diff --git a/lib/libcompiler_rt/gcc_personality_v0.c 
> b/lib/libcompiler_rt/gcc_personality_v0.c
> index 29e5be30712..0bc76562456 100644
> --- a/lib/libcompiler_rt/gcc_personality_v0.c
> +++ b/lib/libcompiler_rt/gcc_personality_v0.c
> @@ -12,6 +12,17 @@
>  #include "int_lib.h"
>  
>  #include 
> +#if defined(__arm__) && !defined(__ARM_DWARF_EH__) && 
> !defined(__USING_SJLJ_EXCEPTIONS__)
> +/*
> + * When building with older compilers (e.g. clang <3.9), it is possible that 
> we
> + * have a version of unwind.h which does not provide the EHABI declarations
> + * which are quired for the C personality to conform to the specification.  
> In
> + * order to provide forward compatibility for such compilers, we re-declare 
> the
> + * necessary interfaces in the helper to permit a standalone compilation of 
> the
> + * builtins (which contains the C unwinding personality for historical 
> reasons).
> + */
> +#include "unwind-ehabi-helpers.h"
> +#endif
>  
>  /*
>   * Pointer encodings documented at:
> diff --git a/lib/libcompiler_rt/unwind-ehabi-helpers.h 
> b/lib/libcompiler_rt/unwind-ehabi-helpers.h
> new file mode 100644
> index 000..ccb0765975a
> --- /dev/null
> +++ b/lib/libcompiler_rt/unwind-ehabi-helpers.h
> @@ -0,0 +1,55 @@
> +/* ===-- arm-ehabi-helpers.h - Supplementary ARM EHABI declarations 
> ===
> + *
> + * The LLVM Compiler Infrastructure
> + *
> + * This file is dual licensed under the MIT and the University of Illinois 
> Open
> + * Source Licenses. See LICENSE.TXT for details.
> + *
> + * 
> ====== */
> +
> +#ifndef UNWIND_EHABI_HELPERS_H
> +#define UNWIND_EHABI_HELPERS_H
> +
> +#include 
> +/* NOTE: see reasoning for this inclusion below */
> +#include 
> +
> +#if !defined(__ARM_EABI_UNWINDER__)
> +
> +/*
> + * NOTE: _URC_OK, _URC_FAILURE must be present as preprocessor tokens.  This
> + * allows for a substitution of a constant which can be cast into the
> + * appropriate enumerated type.  This header is expected to always be 
> included
> + * AFTER unwind.h (which is why it is forcefully included above).  This 
> ensures
> + * that we do not overwrite the token for the enumeration.  Subsequent uses 
> of
> + * the token would be clean to rewrite with constant values.
> + *
> + * The typedef redeclaration should be safe.  Due to the protection granted 
> to
> + * us by the `__ARM_EABI_UNWINDER__` above, we are guaranteed that we are in 
> a
> + * header not vended by gcc.  The HP unwinder (being an itanium unwinder) 
> does
> + * not support EHABI, and the GNU unwinder, derived from the HP unwinder, 
> also
> + * does not support EHABI as of the introduction of this header.  As such, we
> + * are fairly certain that we are in the LLVM case.  Here, _Unwind_State is a
> + * typedef, and so we can get away with a redeclaration.
> + *
> + * Guarded redefinitions of the needed unwind state prevent the redefinition 
> of
> + * those states.
> + */
> +
> +#define _URC_OK   0
> +#define _URC_FAILURE  9
> +
> +typedef uint32_t _Unwind_State;
> +
> +#if !defined(_US_UNWIND_FRAME_STARTING)
> +#define _US_UNWIND_FRAME_STARTING ((_Unwind_State)1)
> +#endif
> +
> +#if !defined(_US_ACTION_MASK)
> +#define _US_ACTION_MASK ((_Unwind_State)3)
> +#endif
> +
> +#endif
> +
> +#endif
> +
> 
> 



Re: vndcompress et al import?

2017-01-03 Thread Timo Buhrmester
> delete [vnd] entirely
Out of curiosity (I'm mostly a NetBSD user), without vnd what would be
the OpenBSD-way of providing a disk-ish interface to a file?



qsort.c: remove useless variable

2017-01-03 Thread Todd C. Miller
When qsort.c was de-registered, the register version of 'aa' was
not removed.  Since qsort() already contains casts of a to char *
there's no need for a separate variable here.

 - todd

Index: lib/libc/stdlib/qsort.c
===
RCS file: /cvs/src/lib/libc/stdlib/qsort.c,v
retrieving revision 1.13
diff -u -p -u -r1.13 qsort.c
--- lib/libc/stdlib/qsort.c 13 Sep 2015 08:31:47 -  1.13
+++ lib/libc/stdlib/qsort.c 3 Jan 2017 14:29:03 -
@@ -81,12 +81,11 @@ med3(char *a, char *b, char *c, int (*cm
 }
 
 void
-qsort(void *aa, size_t n, size_t es, int (*cmp)(const void *, const void *))
+qsort(void *a, size_t n, size_t es, int (*cmp)(const void *, const void *))
 {
char *pa, *pb, *pc, *pd, *pl, *pm, *pn;
int cmp_result, swaptype;
size_t d, r;
-   char *a = aa;
 
 loop:  SWAPINIT(a, es);
if (n < 7) {



Re: vndcompress et al import?

2017-01-03 Thread Theo de Raadt
> Franco Fichtner wrote:
> > Hi,
> > 
> > Is anyone aware or interested in porting vndcompress et al
> > from NetBSD to OpenBSD?
> > 
> > Is there any technical reason against inclusion?
> 
> well, vnd is kind of on life support. my efforts to delete it entirely have
> mostly stalled, but new features are probably best added to some other
> component.

It's not going to happen.  It would be a pointless exercise, I don't see
any point in supporting this.



Re: vndcompress et al import?

2017-01-03 Thread Ted Unangst
Franco Fichtner wrote:
> Hi,
> 
> Is anyone aware or interested in porting vndcompress et al
> from NetBSD to OpenBSD?
> 
> Is there any technical reason against inclusion?

well, vnd is kind of on life support. my efforts to delete it entirely have
mostly stalled, but new features are probably best added to some other
component.



Re: Recursive NET_LOCK()

2017-01-03 Thread Martin Pieuchot
On 03/01/17(Tue) 14:08, Ted Unangst wrote:
> Martin Pieuchot wrote:
> > It seems that most of the problems exposed by the introduction of the
> > NET_LOCK() are related to the non-recursive nature of the rwlock.  Some
> > known issues involve pflow(4), cloning interfaces an NFS.
> > 
> > Diff below makes use of a recursive-rwlock instead.  I just finished a
> > build on NFS with it, so I'd like to know if it works for your use case.
> 
> I don't want to interfere with progress, so if you think this is best, carry
> on.
> 
> But I'll note that using recursive locks leads to sloppy locking discipline,
> which is exactly how we find ourselves in this mess today. Need the lock? Not
> sure? Grab it anyway.
> 
> The rrwlock was added for the particular use case of vfs locking, which is
> already a recursive cluster fuck, but wasn't supposed to be used for new code.
> Of course, the network stack also qualifies as legacy code, so can't object
> much to using it there either.
> 
> I imagine you've already thought of this. :)

I did :) 

To be honest I'm not sure if we should take this direction.  For the
moment I'm trying to learn as much as possible about the problems we're
facing.  If it appears to be just sloppy recursive code then we can
decide what to do with it and when.

I am also looking for more feedbacks and/or inputs so I appreciate your
email on the matter.



Re: libcrypto: fix assembly for clang

2017-01-03 Thread Ted Unangst
Patrick Wildt wrote:
> 
> Maybe they want to support older binutils that do not support the unified 
> syntax?
> What's our policy there?

OpenBSD is just about the oldest binutils around. I wouldn't worry about
anything older than what we have in base.



Re: ed(1) doesn't support adress ranges which begin with comma or semicolon

2017-01-03 Thread Stefan Kempf
Theo Buehler wrote:
> On Sat, Dec 24, 2016 at 10:45:16PM +0100, Theo Buehler wrote:
> > On Sat, Dec 24, 2016 at 05:44:07PM +0100, Jérôme FRGACIC wrote:
> > > Hi @tech,
> > > 
> > > I remark that ed(1) do not support adress ranges which begin with
> > > comma or semicolon, for example ",10p" which is equivalent to "1,10p" or
> > > "; +10p" which is equivalent to ".;+10p". These adress ranges are
> > > specified by Open Group Base Specifications Issue 6 (IEEE Std 1003.1,
> > > 2004 Edition) (in fact, there are also adress ranges like "10," which
> > > is equivalent to "10,10" but they seem useless to me...).
> > > 
> > > I would suggest this diff to add support for these adress ranges.
> > 
> > ok tb@
> 
> anyone willing to commit this or give another ok?

Looks good to me. ok stefan@
 
> > 
> > > Index: main.c
> > > ===
> > > RCS file: /cvs/src/bin/ed/main.c,v
> > > retrieving revision 1.58
> > > diff -u -r1.58 main.c
> > > --- main.c16 Aug 2016 20:04:46 -  1.58
> > > +++ main.c24 Dec 2016 15:26:41 -
> > > @@ -383,7 +383,9 @@
> > >   ibufp++;
> > >   addr_cnt++;
> > >   second_addr = (c == ';') ?
> > > current_addr : 1;
> > > - addr = addr_last;
> > > + addr = next_addr();
> > > + if (addr < 0)
> > > + addr = addr_last;
> > >   break;
> > >   }
> > >   /* FALLTHROUGH */
> > > 
> > > PS : I haven't subcribe to the tech mailing list, so please add me as
> > > recipient if you reply.
> > > PPS : Merry Christmas.
> > > 
> > > 
> > > Kind regards,
> > > 
> > > 
> > > Jérôme FRGACIC
> > > 
> > 
> 



Re: Recursive NET_LOCK()

2017-01-03 Thread Ted Unangst
Martin Pieuchot wrote:
> It seems that most of the problems exposed by the introduction of the
> NET_LOCK() are related to the non-recursive nature of the rwlock.  Some
> known issues involve pflow(4), cloning interfaces an NFS.
> 
> Diff below makes use of a recursive-rwlock instead.  I just finished a
> build on NFS with it, so I'd like to know if it works for your use case.

I don't want to interfere with progress, so if you think this is best, carry
on.

But I'll note that using recursive locks leads to sloppy locking discipline,
which is exactly how we find ourselves in this mess today. Need the lock? Not
sure? Grab it anyway.

The rrwlock was added for the particular use case of vfs locking, which is
already a recursive cluster fuck, but wasn't supposed to be used for new code.
Of course, the network stack also qualifies as legacy code, so can't object
much to using it there either.

I imagine you've already thought of this. :)



libcrypto: fix assembly for clang

2017-01-03 Thread Patrick Wildt
Hi,

clang complains about the ARM assembly, since it expects the conditional
branch instructions to state the condition (in this case pl/ne) after
the "b" for branch.  We also need to state that we're using the unified
syntax, so that binutils 2.17 likes it as well.

OpenSSL fixed that issue in another way:

.text
#if defined(__thumb2__) || defined(__clang__)
.syntax unified
#endif
#if defined(__thumb2__)
.thumb
#else
.code   32
#endif

#ifdef  __clang__
#define ldrplb  ldrbpl
#define ldrneb  ldrbne
#endif

Maybe they want to support older binutils that do not support the unified 
syntax?
What's our policy there?

Comments?

Patrick


diff --git a/lib/libcrypto/modes/asm/ghash-armv4.pl 
b/lib/libcrypto/modes/asm/ghash-armv4.pl
index d91586ee292..4f8372d8974 100644
--- a/lib/libcrypto/modes/asm/ghash-armv4.pl
+++ b/lib/libcrypto/modes/asm/ghash-armv4.pl
@@ -110,6 +110,7 @@ $code=<<___;
 #include "arm_arch.h"
 
 .text
+.syntaxunified
 .code  32
 
 .type  rem_4bit,%object
@@ -182,7 +183,7 @@ gcm_ghash_4bit:
eor $Zlh,$Zlh,$Zhl,lsl#28
ldrh$Tll,[sp,$nlo]  @ rem_4bit[rem]
eor $Zhl,$Thl,$Zhl,lsr#4
-   ldrplb  $nlo,[$inp,$cnt]
+   ldrbpl  $nlo,[$inp,$cnt]
eor $Zhl,$Zhl,$Zhh,lsl#28
eor $Zhh,$Thh,$Zhh,lsr#4
 
@@ -192,7 +193,7 @@ gcm_ghash_4bit:
add $nhi,$nhi,$nhi
ldmia   $Thh,{$Tll-$Thh}@ load Htbl[nhi]
eor $Zll,$Tll,$Zll,lsr#4
-   ldrplb  $Tll,[$Xi,$cnt]
+   ldrbpl  $Tll,[$Xi,$cnt]
eor $Zll,$Zll,$Zlh,lsl#28
eor $Zlh,$Tlh,$Zlh,lsr#4
ldrh$Tlh,[sp,$nhi]
@@ -210,7 +211,7 @@ gcm_ghash_4bit:
add $inp,$inp,#16
mov $nhi,$Zll
 ___
-   ("cmp\t$inp,$len","ldrneb\t$nlo,[$inp,#15]");
+   ("cmp\t$inp,$len","ldrbne\t$nlo,[$inp,#15]");
 $code.=<<___;
bne .Louter
 
@@ -268,7 +269,7 @@ gcm_gmult_4bit:
eor $Zlh,$Zlh,$Zhl,lsl#28
ldrh$Tll,[$rem_4bit,$nlo]   @ rem_4bit[rem]
eor $Zhl,$Thl,$Zhl,lsr#4
-   ldrplb  $nlo,[$Xi,$cnt]
+   ldrbpl  $nlo,[$Xi,$cnt]
eor $Zhl,$Zhl,$Zhh,lsl#28
eor $Zhh,$Thh,$Zhh,lsr#4
 



xargs(1): remove unused variable

2017-01-03 Thread Julien Ramseier
The repllen variable is not used anywhere.

Index: strnsubst.c
===
RCS file: /cvs/src/usr.bin/xargs/strnsubst.c,v
retrieving revision 1.5
diff -u -r1.5 strnsubst.c
--- strnsubst.c 27 Oct 2009 23:59:50 -  1.5
+++ strnsubst.c 3 Jan 2017 10:26:22 -
@@ -31,7 +31,7 @@
 strnsubst(char **str, const char *match, const char *replstr, size_t maxsize)
 {
char *s1, *s2, *this;
-   size_t matchlen, repllen, s2len;
+   size_t matchlen, s2len;
int n;

if ((s1 = *str) == NULL)
@@ -50,7 +50,6 @@
*s2 = '\0';
s2len = 0;
matchlen = strlen(match);
-   repllen = strlen(replstr);
for (;;) {
if ((this = strstr(s1, match)) == NULL)
break;



Re: Recursive NET_LOCK()

2017-01-03 Thread Sebastien Marie
On Tue, Jan 03, 2017 at 05:13:27PM +0100, Martin Pieuchot wrote:
> It seems that most of the problems exposed by the introduction of the
> NET_LOCK() are related to the non-recursive nature of the rwlock.  Some
> known issues involve pflow(4), cloning interfaces an NFS.
> 
> Diff below makes use of a recursive-rwlock instead.  I just finished a
> build on NFS with it, so I'd like to know if it works for your use case.
> 
> Please test and report back.

I started to use it on my gateway (which use pflow and which paniced
previously).

For now, there is no problem, whereas previously panic occurred soon
after starting.

I will keep it running.

Thanks.
-- 
Sebastien Marie



compiler-rt: upgrade to 3.9.1 / fix gcc personality compile error

2017-01-03 Thread Patrick Wildt
Hi,

the GCC personality C file does not compile with clang 3.8 on ARM.  They
have fixed the issue in compiler-rt and released 3.9.1.  Apparently that
is the only thing they changed in the builtins.  Thus this diff is in
essence an update to the compiler-rt release 3.9.1.

ok?

Patrick

diff --git a/lib/libcompiler_rt/gcc_personality_v0.c 
b/lib/libcompiler_rt/gcc_personality_v0.c
index 29e5be30712..0bc76562456 100644
--- a/lib/libcompiler_rt/gcc_personality_v0.c
+++ b/lib/libcompiler_rt/gcc_personality_v0.c
@@ -12,6 +12,17 @@
 #include "int_lib.h"
 
 #include 
+#if defined(__arm__) && !defined(__ARM_DWARF_EH__) && 
!defined(__USING_SJLJ_EXCEPTIONS__)
+/*
+ * When building with older compilers (e.g. clang <3.9), it is possible that we
+ * have a version of unwind.h which does not provide the EHABI declarations
+ * which are quired for the C personality to conform to the specification.  In
+ * order to provide forward compatibility for such compilers, we re-declare the
+ * necessary interfaces in the helper to permit a standalone compilation of the
+ * builtins (which contains the C unwinding personality for historical 
reasons).
+ */
+#include "unwind-ehabi-helpers.h"
+#endif
 
 /*
  * Pointer encodings documented at:
diff --git a/lib/libcompiler_rt/unwind-ehabi-helpers.h 
b/lib/libcompiler_rt/unwind-ehabi-helpers.h
new file mode 100644
index 000..ccb0765975a
--- /dev/null
+++ b/lib/libcompiler_rt/unwind-ehabi-helpers.h
@@ -0,0 +1,55 @@
+/* ===-- arm-ehabi-helpers.h - Supplementary ARM EHABI declarations ===
+ *
+ * The LLVM Compiler Infrastructure
+ *
+ * This file is dual licensed under the MIT and the University of Illinois Open
+ * Source Licenses. See LICENSE.TXT for details.
+ *
+ * ====== 
*/
+
+#ifndef UNWIND_EHABI_HELPERS_H
+#define UNWIND_EHABI_HELPERS_H
+
+#include 
+/* NOTE: see reasoning for this inclusion below */
+#include 
+
+#if !defined(__ARM_EABI_UNWINDER__)
+
+/*
+ * NOTE: _URC_OK, _URC_FAILURE must be present as preprocessor tokens.  This
+ * allows for a substitution of a constant which can be cast into the
+ * appropriate enumerated type.  This header is expected to always be included
+ * AFTER unwind.h (which is why it is forcefully included above).  This ensures
+ * that we do not overwrite the token for the enumeration.  Subsequent uses of
+ * the token would be clean to rewrite with constant values.
+ *
+ * The typedef redeclaration should be safe.  Due to the protection granted to
+ * us by the `__ARM_EABI_UNWINDER__` above, we are guaranteed that we are in a
+ * header not vended by gcc.  The HP unwinder (being an itanium unwinder) does
+ * not support EHABI, and the GNU unwinder, derived from the HP unwinder, also
+ * does not support EHABI as of the introduction of this header.  As such, we
+ * are fairly certain that we are in the LLVM case.  Here, _Unwind_State is a
+ * typedef, and so we can get away with a redeclaration.
+ *
+ * Guarded redefinitions of the needed unwind state prevent the redefinition of
+ * those states.
+ */
+
+#define _URC_OK   0
+#define _URC_FAILURE  9
+
+typedef uint32_t _Unwind_State;
+
+#if !defined(_US_UNWIND_FRAME_STARTING)
+#define _US_UNWIND_FRAME_STARTING ((_Unwind_State)1)
+#endif
+
+#if !defined(_US_ACTION_MASK)
+#define _US_ACTION_MASK ((_Unwind_State)3)
+#endif
+
+#endif
+
+#endif
+



Re: Unable to boot since latest installer HTTPS changes

2017-01-03 Thread Leo Unglaub

Hey,

On 01/03/17 17:29, Theo de Raadt wrote:

I am on AMD64. I cannot provide a dmesg of that machine because i am
unable to boot it at all.

Sure you can -- install 6.0 to do show it.


stupid me, i did not think about that. Here i attached a fresh dmesg for 
you.


Really sorry about that
Greetings
Leo
OpenBSD 6.0 (GENERIC.MP) #2319: Tue Jul 26 13:00:43 MDT 2016
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 17139134464 (16345MB)
avail mem = 16615231488 (15845MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.6 @ 0xead50 (101 entries)
bios0: vendor American Megatrends Inc. version "1606" date 04/26/2011
bios0: ASUSTeK Computer INC. P8P67 DELUXE
acpi0 at bios0: rev 2
acpi0: sleep states S0 S1 S3 S4 S5
acpi0: tables DSDT FACP APIC SSDT MCFG HPET
acpi0: wakeup devices PS2K(S4) PS2M(S4) UAR1(S4) BR20(S3) USBE(S4) P0P3(S4) 
P0P4(S4) P0P1(S4) P0P2(S4) PEX0(S4) PEX4(S4) PEX5(S4) PEX6(S4) PEX7(S4) 
BR24(S4) BR31(S4) [...]
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Core(TM) i7-2600K CPU @ 3.40GHz, 3503.22 MHz
cpu0: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,LONG,LAHF,PERF,ITSC,SENSOR,ARAT
cpu0: 256KB 64b/line 8-way L2 cache
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges
cpu0: apic clock running at 103MHz
cpu0: mwait min=64, max=64, C-substates=0.2.1.1, IBE
cpu1 at mainbus0: apid 2 (application processor)
cpu1: Intel(R) Core(TM) i7-2600K CPU @ 3.40GHz, 3502.64 MHz
cpu1: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,LONG,LAHF,PERF,ITSC,SENSOR,ARAT
cpu1: 256KB 64b/line 8-way L2 cache
cpu1: smt 0, core 1, package 0
cpu2 at mainbus0: apid 4 (application processor)
cpu2: Intel(R) Core(TM) i7-2600K CPU @ 3.40GHz, 3502.64 MHz
cpu2: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,LONG,LAHF,PERF,ITSC,SENSOR,ARAT
cpu2: 256KB 64b/line 8-way L2 cache
cpu2: smt 0, core 2, package 0
cpu3 at mainbus0: apid 6 (application processor)
cpu3: Intel(R) Core(TM) i7-2600K CPU @ 3.40GHz, 3502.64 MHz
cpu3: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,LONG,LAHF,PERF,ITSC,SENSOR,ARAT
cpu3: 256KB 64b/line 8-way L2 cache
cpu3: smt 0, core 3, package 0
cpu4 at mainbus0: apid 1 (application processor)
cpu4: Intel(R) Core(TM) i7-2600K CPU @ 3.40GHz, 3502.64 MHz
cpu4: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,LONG,LAHF,PERF,ITSC,SENSOR,ARAT
cpu4: 256KB 64b/line 8-way L2 cache
cpu4: smt 1, core 0, package 0
cpu5 at mainbus0: apid 3 (application processor)
cpu5: Intel(R) Core(TM) i7-2600K CPU @ 3.40GHz, 3502.64 MHz
cpu5: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,LONG,LAHF,PERF,ITSC,SENSOR,ARAT
cpu5: 256KB 64b/line 8-way L2 cache
cpu5: smt 1, core 1, package 0
cpu6 at mainbus0: apid 5 (application processor)
cpu6: Intel(R) Core(TM) i7-2600K CPU @ 3.40GHz, 3502.64 MHz
cpu6: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,LONG,LAHF,PERF,ITSC,SENSOR,ARAT
cpu6: 256KB 64b/line 8-way L2 cache
cpu6: smt 1, core 2, package 0
cpu7 at mainbus0: apid 7 (application processor)
cpu7: Intel(R) Core(TM) i7-2600K CPU @ 3.40GHz, 3502.64 MHz
cpu7: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,LONG,LAHF,PERF,ITSC,SENSOR,ARAT
cpu7: 256KB 64b/line 8-way L2 cache
cpu7: smt 1, core 3, package 0
ioapic0 at mainbus0: apid 0 pa 0xfec0, version 20, 24 pins
acpimcfg0 at acpi0 addr 0xe000, bus 0-63
acpihpet0 at acpi0: 

Re: Unable to boot since latest installer HTTPS changes

2017-01-03 Thread Theo de Raadt
> Hey tech@
> i wanted to upgrade to the latest snapshot (as i always do, every week) 
> but since you added the HTTPS support to the installer i am unable to 
> boot my system or the install.fs from a flash drive.
> 
> I get to the MBR and then into the PBR but after probing all discs the 
> system restarts instantly. No debug prompt or something else. I tryed it 
> with the latest 3 install.fs or so. But i am unable to boot at all.
> 
> This only happens in MBR mode, i am able to boot in UEFI mode from the 
> install.fs.
> 
> I also tryed a 4 weeks old install.fs and in there it works fine. So its 
> not a hardware issue.
> 
> This started to happend around the same time you added HTTPS support to 
> the installer.
> 
> I am on AMD64. I cannot provide a dmesg of that machine because i am 
> unable to boot it at all.

Sure you can -- install 6.0 to do show it.

It is more likely this is related to some small UEFI changes that
have occured.




Unable to boot since latest installer HTTPS changes

2017-01-03 Thread Leo Unglaub

Hey tech@
i wanted to upgrade to the latest snapshot (as i always do, every week) 
but since you added the HTTPS support to the installer i am unable to 
boot my system or the install.fs from a flash drive.


I get to the MBR and then into the PBR but after probing all discs the 
system restarts instantly. No debug prompt or something else. I tryed it 
with the latest 3 install.fs or so. But i am unable to boot at all.


This only happens in MBR mode, i am able to boot in UEFI mode from the 
install.fs.


I also tryed a 4 weeks old install.fs and in there it works fine. So its 
not a hardware issue.


This started to happend around the same time you added HTTPS support to 
the installer.


I am on AMD64. I cannot provide a dmesg of that machine because i am 
unable to boot it at all.


There is someone else on Reddit having the exact same problem.
Thanks and greetings
Leo



Re: find -delete

2017-01-03 Thread Todd C. Miller
OK millert@ for the code.  I'll defer to jmc@ on the man page bits.

 - todd



Recursive NET_LOCK()

2017-01-03 Thread Martin Pieuchot
It seems that most of the problems exposed by the introduction of the
NET_LOCK() are related to the non-recursive nature of the rwlock.  Some
known issues involve pflow(4), cloning interfaces an NFS.

Diff below makes use of a recursive-rwlock instead.  I just finished a
build on NFS with it, so I'd like to know if it works for your use case.

Please test and report back.

Index: kern/kern_rwlock.c
===
RCS file: /cvs/src/sys/kern/kern_rwlock.c,v
retrieving revision 1.27
diff -u -p -r1.27 kern_rwlock.c
--- kern/kern_rwlock.c  14 Mar 2015 07:33:42 -  1.27
+++ kern/kern_rwlock.c  3 Jan 2017 14:23:56 -
@@ -346,3 +346,23 @@ rrw_status(struct rrwlock *rrwl)
 {
return (rw_status(>rrwl_lock));
 }
+
+int
+rrw_release_all(struct rrwlock *rrwl)
+{
+   int rv;
+
+   rv = rrwl->rrwl_wcnt;
+   KASSERT(rv >= 1);
+   rrwl->rrwl_wcnt = 1;
+   rrw_exit(rrwl);
+
+   return (rv);
+}
+
+void
+rrw_acquire_count(struct rrwlock *rrwl, int count, int flags)
+{
+   while (count--)
+   rrw_enter(rrwl, flags);
+}
Index: kern/kern_synch.c
===
RCS file: /cvs/src/sys/kern/kern_synch.c,v
retrieving revision 1.135
diff -u -p -r1.135 kern_synch.c
--- kern/kern_synch.c   13 Sep 2016 08:32:44 -  1.135
+++ kern/kern_synch.c   3 Jan 2017 14:07:23 -
@@ -231,27 +231,28 @@ msleep(const volatile void *ident, struc
  * entered the sleep queue we drop the it. After sleeping we re-lock.
  */
 int
-rwsleep(const volatile void *ident, struct rwlock *wl, int priority,
+rrwsleep(const volatile void *ident, struct rrwlock *rrwl, int priority,
 const char *wmesg, int timo)
 {
struct sleep_state sls;
int error, error1;
+   int count;
 
KASSERT((priority & ~(PRIMASK | PCATCH | PNORELOCK)) == 0);
-   rw_assert_wrlock(wl);
+   KASSERT(rrw_status(rrwl) == RW_WRITE);
 
sleep_setup(, ident, priority, wmesg);
sleep_setup_timeout(, timo);
sleep_setup_signal(, priority);
 
-   rw_exit_write(wl);
+   count = rrw_release_all(rrwl);
 
sleep_finish(, 1);
error1 = sleep_finish_timeout();
error = sleep_finish_signal();
 
if ((priority & PNORELOCK) == 0)
-   rw_enter_write(wl);
+   rrw_acquire_count(rrwl, count, RW_WRITE);
 
/* Signal errors are higher priority than timeouts. */
if (error == 0 && error1 != 0)
Index: kern/uipc_socket.c
===
RCS file: /cvs/src/sys/kern/uipc_socket.c,v
retrieving revision 1.171
diff -u -p -r1.171 uipc_socket.c
--- kern/uipc_socket.c  29 Dec 2016 12:12:43 -  1.171
+++ kern/uipc_socket.c  3 Jan 2017 14:04:42 -
@@ -256,7 +256,7 @@ soclose(struct socket *so)
(so->so_state & SS_NBIO))
goto drop;
while (so->so_state & SS_ISCONNECTED) {
-   error = tsleep(>so_timeo,
+   error = rrwsleep(>so_timeo, ,
PSOCK | PCATCH, "netcls",
so->so_linger * hz);
if (error)
@@ -1039,7 +1039,7 @@ sorflush(struct socket *so)
struct sockbuf asb;
 
sb->sb_flags |= SB_NOINTR;
-   (void) sblock(sb, M_WAITOK, NULL);
+   (void) sblock(sb, M_WAITOK, );
socantrcvmore(so);
sbunlock(sb);
asb = *sb;
Index: kern/uipc_socket2.c
===
RCS file: /cvs/src/sys/kern/uipc_socket2.c,v
retrieving revision 1.70
diff -u -p -r1.70 uipc_socket2.c
--- kern/uipc_socket2.c 29 Dec 2016 12:12:43 -  1.70
+++ kern/uipc_socket2.c 3 Jan 2017 14:06:54 -
@@ -53,7 +53,7 @@ u_longsb_max = SB_MAX;/* patchable */
 extern struct pool mclpools[];
 extern struct pool mbpool;
 
-int sbsleep(struct sockbuf *, struct rwlock *);
+int sbsleep(struct sockbuf *, struct rrwlock *);
 
 /*
  * Procedures to manipulate state flags of socket
@@ -276,18 +276,18 @@ sbwait(struct sockbuf *sb)
NET_ASSERT_LOCKED();
 
sb->sb_flagsintr |= SB_WAIT;
-   return (tsleep(>sb_cc,
+   return (rrwsleep(>sb_cc, ,
(sb->sb_flags & SB_NOINTR) ? PSOCK : PSOCK | PCATCH, "netio",
sb->sb_timeo));
 }
 
 int
-sbsleep(struct sockbuf *sb, struct rwlock *lock)
+sbsleep(struct sockbuf *sb, struct rrwlock *rrwl)
 {
int error, prio = (sb->sb_flags & SB_NOINTR) ? PSOCK : PSOCK | PCATCH;
 
-   if (lock != NULL)
-   error = rwsleep(>sb_flags, lock, prio, "netlck", 0);
+   if (rrwl != NULL)
+   error = rrwsleep(>sb_flags, rrwl, prio, "netlck", 0);
else
error = tsleep(>sb_flags, prio, "netlck", 0);
 
@@ -295,7 +295,7 @@ sbsleep(struct sockbuf *sb, struct 

Re: [PATCH] iked: Bugfixes for IKE rekeying

2017-01-03 Thread Thomas Klute
Am 09.11.2016 um 20:36 schrieb Vincent Gross:
> On Wed, 9 Nov 2016 13:16:46 +
> Thomas Klute  wrote:
> 
>> Hi tech@,
>>
>> this patch contains fixes for two bugs that break IKE rekeying
>> initiated by iked. Please review, and apply or let me know what has to
>> be changed! Both bugs are fixed by initializing the respective
>> structures of the new IKE SA (struct iked_sa *nsa in the
>> ikev2_ike_sa_rekey function):
> 
> Thanks, we are looking into it.

Hi, is there any progress on this?

>> For [1]: Copying the address information is required to send any
>> request messages over the new IKE SA after rekeying, otherwise errors
>> like the following happen because the IP addresses and ports remain
>> initialized to zero:
>>
>> ikev2_msg_send: INFORMATIONAL request from any to any msgid 1, 80
>> bytes ikev2_msg_send: sendtofrom: Invalid argument
>>
>> For [2]: Setting the DH group based on the currently used one is
>> necessary because iked proposes only the currently used transforms
>> during IKE rekeying, so trying to use any other group for the DH
>> exchange will fail even if it is preferred by local policy (see
>> comment in the patch for details).
>>
>> This patch includes and supersedes the one for only the first bug I
>> sent yesterday.
>>
>> Best regards,
>> Thomas
>>
>> [1] https://marc.info/?l=openbsd-bugs=147739504516767=2
>> [2] https://marc.info/?l=openbsd-bugs=147747405806461=2
>>
>> Index: src/sbin/iked/ikev2.c
>> ===
>> RCS file: /cvs/src/sbin/iked/ikev2.c,v
>> retrieving revision 1.131
>> diff -u -p -u -r1.131 ikev2.c
>> --- src/sbin/iked/ikev2.c2 Jun 2016 07:14:26 -
>> 1.131 +++ src/sbin/iked/ikev2.c  9 Nov 2016 13:12:32 -
>> @@ -2658,6 +2658,18 @@ ikev2_ike_sa_rekey(struct iked *env, voi
>>  goto done;
>>  }
>>  
>> +/* Select the DH group ID based on the currently used
>> + * one. Otherwise the call to ikev2_sa_initiator below would
>> + * set it to the first DH transform in the policy, while the
>> + * SA payload contains only one proposal matching the
>> + * currently used transforms. If a different DH transform has
>> + * been negotiated this means KE payload and negotiated DH
>> + * transform cannot match, causing rekeying to fail. */
>> +if ((nsa->sa_dhgroup = group_get(sa->sa_dhgroup->id)) ==
>> NULL) {
>> +log_debug("%s: failed to initialize DH group",
>> __func__);
>> +goto done;
>> +}
>> +
>>  if (ikev2_sa_initiator(env, nsa, sa, NULL)) {
>>  log_debug("%s: failed to setup DH", __func__);
>>  goto done;
>> @@ -2665,6 +2677,13 @@ ikev2_ike_sa_rekey(struct iked *env, voi
>>  sa_state(env, nsa, IKEV2_STATE_AUTH_SUCCESS);
>>  nonce = nsa->sa_inonce;
>>  
>> +/* Copy local and peer address from the old SA */
>> +if (sa_address(nsa, >sa_peer, >sa_peer.addr) == -1
>> ||
>> +sa_address(nsa, >sa_local, >sa_local.addr) ==
>> -1) {
>> +log_debug("%s: failed copy address data", __func__);
>> +goto done;
>> +}
>> +
>>  if ((e = ibuf_static()) == NULL)
>>  goto done;
>>  
>>
> 



Re: if attach/detach netlocks

2017-01-03 Thread Mike Belopuhov
On 3 January 2017 at 12:06, Reyk Floeter  wrote:
> On Tue, Jan 03, 2017 at 11:42:21AM +0100, Martin Pieuchot wrote:
>> On 02/01/17(Mon) 21:51, Mike Belopuhov wrote:
>> > I got to test the diff and I had to make another adjustment:
>> > vxlan_if_change is setup as a detach hook, however dohooks is
>> > called very early in if_detach before we remove IP addresses
>> > from the interface.  It makes vxlan_config find these IP
>> > addresses just fine and re-add its own detach hook again.
>>
>> Why not fix vxlan_if_change()?
>>
>> >   This
>> > repeats ad infinitum hogging the machine.  I couldn't think of
>> > anything better than deferring an operation via a task.  Seems
>> > to do the trick.
>>
>> That's ugly.  Why would you re-add anything in a detach hook?  This
>> is obviously broken.
>>
>
> It is used for the multicast address (only) and it made sense when the
> source address wasn't mandatory, eg. 0.0.0.0 -> 239.1.1.100 would find
> the next interface that points to the group after detaching the
> current one.
>
> The source is mandatory now, so the diff below should work as well.
>
> Reyk
>

Thanks, this looks good, OK mikeb



splsoftnet() in mroute

2017-01-03 Thread Martin Pieuchot
Diff below gets rid of the various splsoftnet() in multicast forwarding
code.  I've put asserts to ease review.

While here remove #ifdef PIM leftovers.

ok?

Index: netinet/ip_mroute.c
===
RCS file: /cvs/src/sys/netinet/ip_mroute.c,v
retrieving revision 1.101
diff -u -p -r1.101 ip_mroute.c
--- netinet/ip_mroute.c 22 Dec 2016 11:04:44 -  1.101
+++ netinet/ip_mroute.c 3 Jan 2017 11:08:50 -
@@ -316,20 +316,16 @@ mrt_ioctl(struct socket *so, u_long cmd,
 int
 get_sg_cnt(unsigned int rtableid, struct sioc_sg_req *req)
 {
-   int s;
struct mfc *rt;
 
-   s = splsoftnet();
rt = mfc_find(rtableid, >src, >grp);
if (rt == NULL) {
-   splx(s);
req->pktcnt = req->bytecnt = req->wrong_if = 0x;
return (EADDRNOTAVAIL);
}
req->pktcnt = rt->mfc_pkt_cnt;
req->bytecnt = rt->mfc_byte_cnt;
req->wrong_if = rt->mfc_wrong_if;
-   splx(s);
 
return (0);
 }
@@ -478,11 +474,7 @@ ip_mrouter_init(struct socket *so, struc
arc4random_buf([rtableid], sizeof(mfchashkey[rtableid]));
memset(nexpire[rtableid], 0, sizeof(nexpire[rtableid]));
 
-#ifdef PIM
-   pim_assert = 0;
-#endif
-
-   timeout_set(_upcalls_ch[rtableid], expire_upcalls,
+   timeout_set_proc(_upcalls_ch[rtableid], expire_upcalls,
>inp_rtableid);
timeout_add_msec(_upcalls_ch[rtableid], EXPIRE_TIMEOUT);
 
@@ -511,10 +503,9 @@ ip_mrouter_done(struct socket *so)
vifi_t vifi;
struct vif *vifp;
int i;
-   int s;
unsigned int rtableid = inp->inp_rtableid;
 
-   s = splsoftnet();
+   splsoftassert(IPL_SOFTNET);
 
/* Clear out all the vifs currently in use. */
for (vifi = 0; vifi < numvifs; vifi++) {
@@ -526,10 +517,6 @@ ip_mrouter_done(struct socket *so)
numvifs = 0;
mrt_api_config = 0;
 
-#ifdef PIM
-   pim_assert = 0;
-#endif
-
timeout_del(_upcalls_ch[rtableid]);
 
/*
@@ -551,8 +538,6 @@ ip_mrouter_done(struct socket *so)
 
ip_mrouter[rtableid] = NULL;
 
-   splx(s);
-
return (0);
 }
 
@@ -658,7 +643,9 @@ add_vif(struct socket *so, struct mbuf *
struct ifaddr *ifa;
struct ifnet *ifp;
struct ifreq ifr;
-   int error, s;
+   int error;
+
+   splsoftassert(IPL_SOFTNET);
 
if (m == NULL || m->m_len < sizeof(struct vifctl))
return (EINVAL);
@@ -702,8 +689,6 @@ add_vif(struct socket *so, struct mbuf *
return (error);
}
 
-   s = splsoftnet();
-
vifp->v_flags = vifcp->vifc_flags;
vifp->v_threshold = vifcp->vifc_threshold;
vifp->v_lcl_addr = vifcp->vifc_lcl_addr;
@@ -715,8 +700,6 @@ add_vif(struct socket *so, struct mbuf *
vifp->v_bytes_in = 0;
vifp->v_bytes_out = 0;
 
-   splx(s);
-
/* Adjust numvifs up if the vifi is higher than numvifs. */
if (numvifs <= vifcp->vifc_vifi)
numvifs = vifcp->vifc_vifi + 1;
@@ -750,7 +733,8 @@ del_vif(struct mbuf *m)
vifi_t *vifip;
struct vif *vifp;
vifi_t vifi;
-   int s;
+
+   splsoftassert(IPL_SOFTNET);
 
if (m == NULL || m->m_len < sizeof(vifi_t))
return (EINVAL);
@@ -763,8 +747,6 @@ del_vif(struct mbuf *m)
if (in_nullhost(vifp->v_lcl_addr))
return (EADDRNOTAVAIL);
 
-   s = splsoftnet();
-
reset_vif(vifp);
 
/* Adjust numvifs down */
@@ -773,8 +755,6 @@ del_vif(struct mbuf *m)
break;
numvifs = vifi;
 
-   splx(s);
-
return (0);
 }
 
@@ -881,10 +861,11 @@ add_mfc(struct socket *so, struct mbuf *
u_int32_t hash = 0;
struct rtdetq *rte, *nrte;
u_short nstl;
-   int s;
int mfcctl_size = sizeof(struct mfcctl);
unsigned int rtableid = inp->inp_rtableid;
 
+   splsoftassert(IPL_SOFTNET);
+
if (mrt_api_config & MRT_API_FLAGS_ALL)
mfcctl_size = sizeof(struct mfcctl2);
 
@@ -905,19 +886,15 @@ add_mfc(struct socket *so, struct mbuf *
}
mfccp = 
 
-   s = splsoftnet();
/* No hash table allocated for this. */
-   if (mfchashtbl[rtableid] == NULL) {
-   splx(s);
+   if (mfchashtbl[rtableid] == NULL)
return (0);
-   }
 
rt = mfc_find(rtableid, >mfcc_origin, >mfcc_mcastgrp);
 
/* If an entry already exists, just update the fields */
if (rt) {
update_mfc_params(rt, mfccp);
-   splx(s);
return (0);
}
 
@@ -977,10 +954,8 @@ add_mfc(struct socket *so, struct mbuf *
}
if (rt == NULL) {   /* no upcall, so make a new entry */
rt = malloc(sizeof(*rt), M_MRTABLE, M_NOWAIT);
-   if (rt == NULL) {
- 

Re: if attach/detach netlocks

2017-01-03 Thread Reyk Floeter
On Tue, Jan 03, 2017 at 11:42:21AM +0100, Martin Pieuchot wrote:
> On 02/01/17(Mon) 21:51, Mike Belopuhov wrote:
> > On Fri, Dec 30, 2016 at 18:57 +0100, Mike Belopuhov wrote:
> > > On Thu, Dec 29, 2016 at 09:30 +0100, Martin Pieuchot wrote:
> > > > On 29/12/16(Thu) 01:15, Alexander Bluhm wrote:
> > > > > On Fri, Dec 23, 2016 at 12:09:32AM +0100, Martin Pieuchot wrote:
> > > > > > On 22/12/16(Thu) 20:45, Mike Belopuhov wrote:
> > > > > > > I think this is what is required here.  Works here, but YMMV.
> > > > > > 
> > > > > > splnet() in a pseudo-driver seems completely wrong, you could get 
> > > > > > rid of
> > > > > > it.
> > > > > 
> > > > > Yes, but that is another issue.  Can we get the netlock splasserts
> > > > > fixed first?  This diff looks good to me.
> > > > 
> > > > Sure I'm ok with the diff.
> > > > 
> > > 
> > > I agree with Martin and have cooked a diff but couldn't test it yet.
> > > This is it for the reference.
> > > 
> > 
> > I got to test the diff and I had to make another adjustment:
> > vxlan_if_change is setup as a detach hook, however dohooks is
> > called very early in if_detach before we remove IP addresses
> > from the interface.  It makes vxlan_config find these IP
> > addresses just fine and re-add its own detach hook again.
> 
> Why not fix vxlan_if_change()?
> 
> >   This
> > repeats ad infinitum hogging the machine.  I couldn't think of
> > anything better than deferring an operation via a task.  Seems
> > to do the trick.
> 
> That's ugly.  Why would you re-add anything in a detach hook?  This
> is obviously broken.
> 

It is used for the multicast address (only) and it made sense when the
source address wasn't mandatory, eg. 0.0.0.0 -> 239.1.1.100 would find
the next interface that points to the group after detaching the
current one.

The source is mandatory now, so the diff below should work as well.

Reyk

Index: sys/net/if_vxlan.c
===
RCS file: /cvs/src/sys/net/if_vxlan.c,v
retrieving revision 1.54
diff -u -p -u -p -r1.54 if_vxlan.c
--- sys/net/if_vxlan.c  13 Dec 2016 06:51:11 -  1.54
+++ sys/net/if_vxlan.c  3 Jan 2017 11:05:36 -
@@ -947,17 +947,16 @@ vxlan_if_change(void *arg)
 {
struct vxlan_softc  *sc = arg;
struct ifnet*ifp = >sc_ac.ac_if;
-   int  s, error;
+   int  s;
 
/*
 * Reset the configuration after the parent interface disappeared.
 */
s = splnet();
-   if ((error = vxlan_config(ifp, NULL, NULL)) != 0) {
-   /* The configured tunnel addresses are invalid, remove them */
-   bzero(>sc_src, sizeof(sc->sc_src));
-   bzero(>sc_dst, sizeof(sc->sc_dst));
-   }
+   vxlan_multicast_cleanup(ifp);
+   memset(>sc_src, 0, sizeof(sc->sc_src));
+   memset(>sc_dst, 0, sizeof(sc->sc_dst));
+   sc->sc_dstport = htons(VXLAN_PORT);
splx(s);
 }
 



Re: if attach/detach netlocks

2017-01-03 Thread Martin Pieuchot
On 02/01/17(Mon) 21:51, Mike Belopuhov wrote:
> On Fri, Dec 30, 2016 at 18:57 +0100, Mike Belopuhov wrote:
> > On Thu, Dec 29, 2016 at 09:30 +0100, Martin Pieuchot wrote:
> > > On 29/12/16(Thu) 01:15, Alexander Bluhm wrote:
> > > > On Fri, Dec 23, 2016 at 12:09:32AM +0100, Martin Pieuchot wrote:
> > > > > On 22/12/16(Thu) 20:45, Mike Belopuhov wrote:
> > > > > > I think this is what is required here.  Works here, but YMMV.
> > > > > 
> > > > > splnet() in a pseudo-driver seems completely wrong, you could get rid 
> > > > > of
> > > > > it.
> > > > 
> > > > Yes, but that is another issue.  Can we get the netlock splasserts
> > > > fixed first?  This diff looks good to me.
> > > 
> > > Sure I'm ok with the diff.
> > > 
> > 
> > I agree with Martin and have cooked a diff but couldn't test it yet.
> > This is it for the reference.
> > 
> 
> I got to test the diff and I had to make another adjustment:
> vxlan_if_change is setup as a detach hook, however dohooks is
> called very early in if_detach before we remove IP addresses
> from the interface.  It makes vxlan_config find these IP
> addresses just fine and re-add its own detach hook again.

Why not fix vxlan_if_change()?

>   This
> repeats ad infinitum hogging the machine.  I couldn't think of
> anything better than deferring an operation via a task.  Seems
> to do the trick.

That's ugly.  Why would you re-add anything in a detach hook?  This
is obviously broken.



Re: find -delete

2017-01-03 Thread Jason McIntyre
On Tue, Jan 03, 2017 at 12:15:02AM -0500, Ted Unangst wrote:
> This option is not posix (not like that's stopped find accumulating a dozen
> extensions), but it is in gnu and freebsd (for 20 years). it's also somewhat
> popular among sysadmins and blogs, etc. and perhaps most importantly, it
> nicely solves one of the more troublesome caveats of find (which the man page
> actually covers twice because it's so common and easy to screw up). So I think
> it makes a good addition.
> 
> Code snatched from freebsd.
> 
> In passing, I'll also note that the man page example is very inefficient.
> $ find . \( -name \*.jpg -o -name \*.gif \) -exec rm {} \;
> This would be much faster with +. We can fix that too, but I'll add that a lot
> of the online advice suggests -delete, and if not available, -exec rm {} \;,
> instead of the smarter + exec. Not surprising since even the man page gets
> this wrong.
> 

no opinion on the addition, but if there is a better way to write the
examples that are there, i think you should take the time to do so. i'd
also slightly prefer we show the more traditional way to do it, though i
appreciate that might not make a ton of sense for find(1).

some comments on the man parts:

> Index: find.1
> ===
> RCS file: /cvs/src/usr.bin/find/find.1,v
> retrieving revision 1.91
> diff -u -p -r1.91 find.1
> --- find.111 Sep 2015 18:58:16 -  1.91
> +++ find.13 Jan 2017 05:04:52 -
> @@ -182,6 +182,23 @@ was started, rounded up to the next full
>  .Ar n
>  24-hour periods.
>  .Pp
> +.It Ic -delete
> +Delete found files and/or directories.

i think "and" is sufficiently clear.

> +Always returns true.
> +This executes
> +from the current working directory as
> +.Nm
> +recurses down the tree.
> +It will not attempt to delete a filename with a
> +.Dq Pa /
> +character in its pathname relative to
> +.Dq Pa \&.

i'd use Sq rather than Dq for single letters if you really need it
quoted. and check, but i think you need \& after the dot, not before, or
you'll get a double space injected.

jmc

> +for security reasons.
> +Depth-first traversal processing is implied by this option.
> +The
> +.Ic -delete
> +primary will fail to delete a directory if it is not empty.
> +Following symlinks is incompatible with this option.
>  .It Ic -depth
>  This primary always evaluates to true.
>  The same as specifying the
> @@ -587,6 +604,7 @@ primaries
>  .Ic -anewer ,
>  .Ic -cmin ,
>  .Ic -cnewer ,
> +.Ic -delete ,
>  .Ic -empty ,
>  .Ic -execdir ,
>  .Ic -flags ,



Re: libressl symbols

2017-01-03 Thread Peter Hessler
After discussion from jsing and beck, this is wrong.  I've fixed my
issue in the net/py-cryptography port instead.


On 2017 Jan 02 (Mon) at 17:06:46 +0100 (+0100), Reyk Floeter wrote:
:Hi,
:
:the function prototypes have been moved from he header to the .c file - you 
will have to revert this change as well.
:
:+1 from me for exposing the API - I recently also ran into it but didn't speak 
up because my use case was probably not important enough.
:
:Reyk
:
:
:> Am 02.01.2017 um 16:29 schrieb Peter Hessler :
:> 
:> Looks like when libcrypto was convered to use a Symbol map, some
:> functions were not included.
:> 
:> This change lets py-openssl be loaded by python processes.
:> 
:> I did not include the minor version bump, as there might be more issues.
:> 
:> 
:> 
:> Index: lib/libcrypto/Symbols.list
:> ===
:> RCS file: /cvs/src/lib/libcrypto/Symbols.list,v
:> retrieving revision 1.1
:> diff -u -p -u -p -r1.1 Symbols.list
:> --- lib/libcrypto/Symbols.list21 Dec 2016 15:49:29 -1.1
:> +++ lib/libcrypto/Symbols.list2 Jan 2017 15:17:02 -
:> @@ -2805,6 +2805,8 @@ X509_VERIFY_PARAM_inherit
:> X509_VERIFY_PARAM_lookup
:> X509_VERIFY_PARAM_new
:> X509_VERIFY_PARAM_set1
:> +X509_VERIFY_PARAM_set1_email
:> +X509_VERIFY_PARAM_set1_ip
:> X509_VERIFY_PARAM_set1_name
:> X509_VERIFY_PARAM_set1_policies
:> X509_VERIFY_PARAM_set_depth
:> 
:> 
:> -- 
:> Reality is just a convenient measure of complexity.
:>-- Alvy Ray Smith
:> 
:

-- 
Death to all fanatics!



uaudio: preliminary patch for yamaha ur12 device support

2017-01-03 Thread Michael W. Bombardieri
Hi,

Sending this patch to tech@ in case people have usb
audio devices to test it.

When connecting yamaha ur12 usb audio interface I was getting
USBD_INVAL because of the aclen check. netbsd previously removed
the check for aclen here:
http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/dev/usb/uaudio.c.diff?r1=1.119=1.120=h=u

So this patch is a copy, without the Roland SD-90 stuff.
I originally applied this to uaudio.c r1.116 and it allowed
ur12 device to progress further. usb device attach
then failed later related to unexpected
format type or other sample encoding details. That would need
to be addressed later in uaudio_process_as().


- Michael


Index: uaudio.c
===
RCS file: /cvs/src/sys/dev/usb/uaudio.c,v
retrieving revision 1.122
diff -u -p -u -r1.122 uaudio.c
--- uaudio.c3 Jan 2017 06:45:58 -   1.122
+++ uaudio.c3 Jan 2017 08:14:27 -
@@ -1788,7 +1788,7 @@ uaudio_identify_ac(struct uaudio_softc *
const struct usb_audio_output_terminal *pot;
struct terminal_list *tml;
const char *buf, *ibuf, *ibufend;
-   int size, offs, aclen, ndps, i, j;
+   int size, offs, ndps, i, j;
 
size = UGETW(cdesc->wTotalLength);
buf = (char *)cdesc;
@@ -1807,26 +1807,23 @@ uaudio_identify_ac(struct uaudio_softc *
 
/* A class-specific AC interface header should follow. */
ibuf = buf + offs;
+   ibufend = buf + size;
acdp = (const struct usb_audio_control_descriptor *)ibuf;
if (acdp->bDescriptorType != UDESC_CS_INTERFACE ||
acdp->bDescriptorSubtype != UDESCSUB_AC_HEADER)
return (USBD_INVAL);
-   aclen = UGETW(acdp->wTotalLength);
-   if (offs + aclen > size)
-   return (USBD_INVAL);
 
if (!(sc->sc_quirks & UAUDIO_FLAG_BAD_ADC) &&
 UGETW(acdp->bcdADC) != UAUDIO_VERSION)
return (USBD_INVAL);
 
sc->sc_audio_rev = UGETW(acdp->bcdADC);
-   DPRINTFN(2,("%s: found AC header, vers=%03x, len=%d\n",
-__func__, sc->sc_audio_rev, aclen));
+   DPRINTFN(2,("%s: found AC header, vers=%03x\n",
+__func__, sc->sc_audio_rev));
 
sc->sc_nullalt = -1;
 
/* Scan through all the AC specific descriptors */
-   ibufend = ibuf + aclen;
dp = (const usb_descriptor_t *)ibuf;
ndps = 0;
iot = malloc(256 * sizeof(struct io_terminal),
@@ -1844,11 +1841,8 @@ uaudio_identify_ac(struct uaudio_softc *
free(iot, M_TEMP, 0);
return (USBD_INVAL);
}
-   if (dp->bDescriptorType != UDESC_CS_INTERFACE) {
-   printf("%s: skip desc type=0x%02x\n",
-  __func__, dp->bDescriptorType);
-   continue;
-   }
+   if (dp->bDescriptorType != UDESC_CS_INTERFACE)
+   break;
i = ((const struct usb_audio_input_terminal *)dp)->bTerminalId;
iot[i].d.desc = dp;
if (i > ndps)