Re: [Patch] Driver for Keyspan USA-19HS

2019-06-03 Thread Cody Cutler
Hi jcs and tech, the following is a patch which implements jcs's feedback and
adds a man page.

Note that one must execute `make -C sys/dev/usb' after applying to build.

Thanks!

diff --git share/man/man4/Makefile share/man/man4/Makefile
index 7d470b6ca47..999621c7889 100644
--- share/man/man4/Makefile
+++ share/man/man4/Makefile
@@ -71,7 +71,7 @@ MAN=  aac.4 abcrtc.4 ac97.4 acphy.4 acrtc.4 \
tlphy.4 thmc.4 tpm.4 tqphy.4 trm.4 trunk.4 tsl.4 tty.4 tun.4 tap.4 \
twe.4 \
txp.4 txphy.4 uaudio.4 uark.4 uath.4 ubcmtp.4 uberry.4 ubsa.4 \
-   ubsec.4 ucom.4 uchcom.4 ucrcom.4 ucycom.4 uslhcom.4 \
+   ubsec.4 ucom.4 uchcom.4 ucrcom.4 ucycom.4 ukspan.4 uslhcom.4 \
udav.4 udcf.4 udl.4 udp.4 udsbr.4 \
uftdi.4 ugen.4 ugl.4 ugold.4 uguru.4 uhci.4 uhid.4 uhidev.4 uipaq.4 \
uk.4 ukbd.4 \
diff --git share/man/man4/ucom.4 share/man/man4/ucom.4
index e14df75675b..bde53a2c5e1 100644
--- share/man/man4/ucom.4
+++ share/man/man4/ucom.4
@@ -42,6 +42,7 @@
 .Cd "ucom* at ucycom?" # Cypress
 .Cd "ucom* at uftdi?"  # FTDI
 .Cd "ucom* at uipaq?"  # iPAQ
+.Cd "ucom* at ukspan?" # Keyspan
 .Cd "ucom* at umcs?"   # MosChip Semiconductor multiport
 .Cd "ucom* at umct?"   # MCT
 .Cd "ucom* at umodem?" # Standardized umodem
diff --git share/man/man4/ukspan.4 share/man/man4/ukspan.4
new file mode 100644
index 000..2b98f1efcb5
--- /dev/null
+++ share/man/man4/ukspan.4
@@ -0,0 +1,39 @@
+.\" Copyright (c) 2019 Cody Cutler 
+.\"
+.\" Permission to use, copy, modify, and distribute this software for any
+.\" purpose with or without fee is hereby granted, provided that the above
+.\" copyright notice and this permission notice appear in all copies.
+.\"
+.\" THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
+.\" WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
+.\" MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
+.\" ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
+.\" WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
+.\" ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
+.\" OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
+.\"
+.Dd $Mdocdate$
+.Dt UKSPAN 4
+.Os
+.Sh NAME
+.Nm ukspan
+.Nd Keyspan USB serial adapter
+.Sh SYNOPSIS
+.Cd "ukspan* at uhub?"
+.Cd "ucom*   at ukspan?"
+.Sh DESCRIPTION
+The
+.Nm
+driver supports the TrippLite Keyspan USA-19HS serial adapter, which is made
+accessible through
+.Xr ucom 4 .
+.Sh SEE ALSO
+.Xr tty 4 ,
+.Xr ucom 4 ,
+.Xr uhub 4 ,
+.Xr usb 4
+.Sh AUTHORS
+The
+.Nm
+driver was written by
+.An Cody Cutler Aq Mt ccut...@csail.mit.edu .
diff --git share/man/man4/usb.4 share/man/man4/usb.4
index 520d513f5b1..81a4abd8c70 100644
--- share/man/man4/usb.4
+++ share/man/man4/usb.4
@@ -188,6 +188,8 @@ FTDI USB serial adapter
 iPAQ USB units
 .It Xr ulpt 4
 USB printer support
+.It Xr ukspan 4
+Keyspan serial adapter
 .It Xr umcs 4
 MosChip Semiconductor based USB multiport serial adapter
 .It Xr umct 4
diff --git sys/arch/amd64/conf/GENERIC sys/arch/amd64/conf/GENERIC
index ad192f4ea1d..5b5d37c24e2 100644
--- sys/arch/amd64/conf/GENERIC
+++ sys/arch/amd64/conf/GENERIC
@@ -224,6 +224,8 @@ uvscom* at uhub?# SUNTAC Slipper U 
VS-10U serial
 ucom*  at uvscom?
 ubsa*  at uhub?# Belkin serial adapter
 ucom*  at ubsa?
+ukspan* at uhub?   # Keyspan USA19HS serial adapter
+ucom*  at ukspan?
 uftdi* at uhub?# FTDI FT8U100AX serial adapter
 ucom*  at uftdi?
 uplcom* at uhub?   # I/O DATA USB-RSAQ2 serial adapter
diff --git sys/dev/usb/files.usb sys/dev/usb/files.usb
index 1036cf36232..29bc1205540 100644
--- sys/dev/usb/files.usb
+++ sys/dev/usb/files.usb
@@ -317,6 +317,11 @@ device ubsa: ucombus
 attach ubsa at uhub
 file   dev/usb/ubsa.c  ubsa
 
+# Keyspan USA19HS serial
+device ukspan: ucombus
+attach ukspan at uhub
+file   dev/usb/ukspan.cukspan
+
 # Silicon Laboratories CP210x serial
 device uslcom: ucombus
 attach uslcom at uhub
diff --git sys/dev/usb/ukspan.c sys/dev/usb/ukspan.c
new file mode 100644
index 000..5f5e9583641
--- /dev/null
+++ sys/dev/usb/ukspan.c
@@ -0,0 +1,594 @@
+/*
+ * Copyright (c) 2019 Cody Cutler 
+ *
+ * Permission to use, copy, modify, and distribute this software for any
+ * purpose with or without fee is hereby granted, provided that the above
+ * copyright notice and this permission notice appear in all copies.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
+ * WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
+ * MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
+ * ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
+ * WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
+ * ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
+ * OR IN CONNECTION 

pfsync_sendout() requires PF_LOCK()

2019-06-03 Thread Alexandr Nedvedicky
Hello,

this is yet another fall out from my experiments.  It has turned out my initial
change introduced some time ago [1] omits pfsyncintr() and pfsync_sendout().
Both functions call pfsync_sendout(), which currently requires protection
of PF_LOCK(). Without change below the test box was dying on ASSERT()
in pf_state_uref() at line 7529.

7520 pf_state_unref(struct pf_state *s)
7521 {
7522 if ((s != NULL) && PF_REF_RELE(s->refcnt)) {
7523 /* never inserted or removed */
7524 #if NPFSYNC > 0
7525 KASSERT((TAILQ_NEXT(s, sync_list) == NULL) ||
7526 ((TAILQ_NEXT(s, sync_list) == _Q_INVALID) &&
7527 (s->sync_state == PFSYNC_S_NONE)));
7528 #endif  /* NPFSYNC */
7529 KASSERT((TAILQ_NEXT(s, entry_list) == NULL) ||
7530 (TAILQ_NEXT(s, entry_list) == _Q_INVALID));
7531 KASSERT((s->key[PF_SK_WIRE] == NULL) &&
7532 (s->key[PF_SK_STACK] == NULL));
7533 
7534 pool_put(_state_pl, s);
7535 }
7536 }

The assert was being triggered from various code paths. Most frequently
from pfsync_update_state(). Occurrence of pf_state_unref() at pf_test()
or timer thread were very rare.

OK?

thanks and
regards
sashan

[1] 
https://github.com/openbsd/src/commit/ddb22b9530d7ad1b4698803d7b6dcb21c96a3f7d#diff-9517dfce4e8db974781a4536fd38cfc1

8<---8<---8<--8<
diff --git a/sys/net/if_pfsync.c b/sys/net/if_pfsync.c
index 20a0136e838..e891832b3ab 100644
--- a/sys/net/if_pfsync.c
+++ b/sys/net/if_pfsync.c
@@ -1581,6 +1581,8 @@ pfsync_sendout(void)
int offset;
int q, count = 0;
 
+   PF_ASSERT_LOCKED();
+
if (sc == NULL || sc->sc_len == PFSYNC_MINPKT)
return;
 
@@ -2472,7 +2474,9 @@ void
 pfsync_timeout(void *arg)
 {
NET_LOCK();
+   PF_LOCK();
pfsync_sendout();
+   PF_UNLOCK();
NET_UNLOCK();
 }
 
@@ -2480,7 +2484,9 @@ pfsync_timeout(void *arg)
 void
 pfsyncintr(void)
 {
+   PF_LOCK();
pfsync_sendout();
+   PF_UNLOCK();
 }
 
 int



pf_state_key_link_reverse() needs atomic ops

2019-06-03 Thread Alexandr Nedvedicky
Hello,

I've managed to get pf_test() running in parallel on forwarding path in my
experimental tree. And there was some fall out. PF died on ASSERT() in
pf_state_key_link_reverse() at line 7371:

7368 pf_state_key_link_reverse(struct pf_state_key *sk, ...)
7369 {
7370 /* Note that sk and skrev may be equal, then we ... */
7371 KASSERT(sk->reverse == NULL);
7372 KASSERT(skrev->reverse == NULL);
7373 sk->reverse = pf_state_key_ref(skrev);
7374 skrev->reverse = pf_state_key_ref(sk);
7375 }


pf_state_key_link_reverse() function is being called from pf_find_state() here:

1074 if (sk == NULL) {
1075 if ((sk = RB_FIND(pf_state_tree, _statetbl,
1076 (struct pf_state_key *)key)) == NULL)
1077 return (PF_DROP);
1078 if (pd->dir == PF_OUT && pkt_sk &&
1079 pf_compare_state_keys(pkt_sk, sk, ...) == 0)
1080 pf_state_key_link_reverse(sk, pkt_sk);
1081 else if (pd->dir == PF_OUT && pd->m->m_pkthdr.pf.inp &&
1082 !pd->m->m_pkthdr.pf.inp->inp_pf_sk && !sk->inp)
1083 pf_state_key_link_inpcb(sk, pd->m->m_pkt...);
1084 }

the pf_find_state() performs a look up to PF state table and as such it runs
under PF_STATE_ENTER_READ() lock. So there might be actually more threads
running at pf_state_key_link_reverse() function. The thread, which currently
loses the race trips the assert in 7371. Patch below uses atomic ops
to handle the race properly.

OK?

thanks and
regards
sashan

8<---8<---8<--8<
diff --git a/sys/net/pf.c b/sys/net/pf.c
index 9e454e5c941..6e2ec19faaa 100644
--- a/sys/net/pf.c
+++ b/sys/net/pf.c
@@ -7367,11 +7367,20 @@ pf_inp_unlink(struct inpcb *inp)
 void
 pf_state_key_link_reverse(struct pf_state_key *sk, struct pf_state_key *skrev)
 {
-   /* Note that sk and skrev may be equal, then we refcount twice. */
-   KASSERT(sk->reverse == NULL);
-   KASSERT(skrev->reverse == NULL);
-   sk->reverse = pf_state_key_ref(skrev);
-   skrev->reverse = pf_state_key_ref(sk);
+   struct pf_state_key *old_reverse;
+
+   old_reverse = atomic_cas_ptr(>reverse, NULL, skrev);
+   if (old_reverse != NULL)
+   KASSERT(old_reverse == skrev);
+   else
+   pf_state_key_ref(skrev);
+
+
+   old_reverse = atomic_cas_ptr(>reverse, NULL, sk);
+   if (old_reverse != NULL)
+   KASSERT(old_reverse == sk);
+   else
+   pf_state_key_ref(sk);
 }
 
 #if NPFLOG > 0



if_netisr(): trade NET_LOCK() for NET_RLOCK()

2019-06-03 Thread Alexandr Nedvedicky
Hello,

diff below is just cosmetic change, which has no impact on current
functionality, because there is just single network task to deliver packets to
IP stack. I just want to push this small change to tree to minimize delta
between current and my experimental branch.

OK?

thanks and
regards
sashan

8<---8<---8<--8<
diff --git a/sys/net/if.c b/sys/net/if.c
index e355f44e80d..15b5f94f188 100644
--- a/sys/net/if.c
+++ b/sys/net/if.c
@@ -976,14 +976,14 @@ if_netisr(void *unused)
 {
int n, t = 0;
 
-   NET_LOCK();
+   NET_RLOCK();
 
while ((n = netisr) != 0) {
/* Like sched_pause() but with a rwlock dance. */
if (curcpu()->ci_schedstate.spc_schedflags & SPCF_SHOULDYIELD) {
-   NET_UNLOCK();
+   NET_RUNLOCK();
yield();
-   NET_LOCK();
+   NET_RLOCK();
}
 
atomic_clearbits_int(, n);
@@ -1044,7 +1044,7 @@ if_netisr(void *unused)
}
 #endif
 
-   NET_UNLOCK();
+   NET_RUNLOCK();
 }
 
 void



[patch] rsync: fix free() on uninitialized pointer with -rx and same device

2019-06-03 Thread Hiltjo Posthuma
Hi,

I noticed a free() issue on an uninitialized pointer on a certain condition.

To reproduce:

mkdir -p /tmp/test /tmp/plop
openrsync -rx /tmp/test/ /tmp/plop/

Result:

openrsync(3470) in free(): bogus pointer (double free?) 0x7f7dcdc8
Abort trap (core dumped)

The check does not match the condition checked before free(xdev);

if (sess->opts->one_file_system &&
ent->fts_statp->st_dev != st.st_dev) {


The patch below fixes it and simplifies the logic:


diff --git usr.bin/rsync/flist.c usr.bin/rsync/flist.c
index e1f41b1a108..1b3f9e40f62 100644
--- usr.bin/rsync/flist.c
+++ usr.bin/rsync/flist.c
@@ -808,7 +808,7 @@ flist_gen_dirent(struct sess *sess, char *root, struct 
flist **fl, size_t *sz,
FTSENT  *ent;
struct flist*f;
size_t   flsz = 0, stripdir;
-   dev_t   *xdev;
+   dev_t   *xdev = NULL;
struct stat  st;
 
cargv[0] = root;
@@ -1008,8 +1008,7 @@ flist_gen_dirent(struct sess *sess, char *root, struct 
flist **fl, size_t *sz,
rc = 1;
 out:
fts_close(fts);
-   if (sess->opts->one_file_system)
-   free(xdev);
+   free(xdev);
return rc;
 }
 

-- 
Kind regards,
Hiltjo



Re: [patch] rsync: fix another double close socket descriptor

2019-06-03 Thread Christian Weisgerber
On 2019-06-02, Hiltjo Posthuma  wrote:

> I noticed when using openrsync with a remote and a ssh_prog set (-e option) 
> the
> socket is closed twice also.

Yes, we need to decide whether rsync_socket() should close the
socket itself or not.  Since rsync_socket() doesn't open the socket,
I guess it shouldn't close it either.  Matches rsync_client().

ok?

Index: main.c
===
RCS file: /cvs/src/usr.bin/rsync/main.c,v
retrieving revision 1.46
diff -u -p -r1.46 main.c
--- main.c  28 May 2019 18:20:30 -  1.46
+++ main.c  3 Jun 2019 14:30:06 -
@@ -428,8 +428,10 @@ main(int argc, char *argv[])
 
if (fargs->remote && opts.ssh_prog == NULL) {
assert(fargs->mode == FARGS_RECEIVER);
-   if ((rc = rsync_connect(, , fargs)) == 0)
+   if ((rc = rsync_connect(, , fargs)) == 0) {
rc = rsync_socket(, sd, fargs);
+   close(sd);
+   }
exit(rc);
}
 
@@ -484,14 +486,7 @@ main(int argc, char *argv[])
break;
}
 
-   /*
-* If the client has an error and exits, the server may be
-* sitting around waiting to get data while we waitpid().
-* So close the connection here so that they don't hang.
-*/
-
-   if (rc)
-   close(fds[0]);
+   close(fds[0]);
 
if (waitpid(child, , 0) == -1)
err(1, "waitpid");
Index: socket.c
===
RCS file: /cvs/src/usr.bin/rsync/socket.c,v
retrieving revision 1.24
diff -u -p -r1.24 socket.c
--- socket.c8 May 2019 21:30:11 -   1.24
+++ socket.c3 Jun 2019 14:26:44 -
@@ -455,6 +455,5 @@ rsync_socket(const struct opts *opts, in
rc = 0;
 out:
free(args);
-   close(sd);
return rc;
 }
-- 
Christian "naddy" Weisgerber  na...@mips.inka.de



bfd: respond to poll sequence from peer

2019-06-03 Thread Mitchell Krome
Hi,

Testing bfd against frr on linux, their bfd implementation sends polls
as soon as the session is up even if the session timers haven't
changed from what it was advertising while it was in the down state.
Currently openbsd bfd doesn't respond to polls, so this diff adds that
support. tcpdump output during session setup (.9 is openbsd):

14:56:31.225339 10.10.20.9.58974 > 10.10.20.10.bfd-control: [udp sum ok] BFD v1 
length 24 state down flags [] diag none my-discrim 3396727743 your-discrim 0 
mintx 100 minrx 100 minecho 0 multiplier 3 [to s 0xc0] (ttl 255, id 
48014, len 52)
14:56:31.533645 10.10.20.10.49143 > 10.10.20.9.bfd-control: [udp sum ok] BFD v1 
length 24 state init flags [] diag neighbor-down my-discrim 2 your-discrim 
3396727743 mintx 150 minrx 150 minecho 5 mul tiplier 3 (DF) [tos 
0xc0] (ttl 255, id 36838, len 52)
14:56:32.022601 10.10.20.9.58974 > 10.10.20.10.bfd-control: [udp sum ok] BFD v1 
length 24 state up flags [] diag none my-discrim 3396727743 your-discrim 2 
mintx 100 minrx 150 minecho 0 multiplier 3 [tos 0xc0] (ttl 255, id 
21474, len 52)
14:56:32.023134 10.10.20.10.49143 > 10.10.20.9.bfd-control: [udp sum ok] BFD v1 
length 24 state up flags [P] diag none my-discrim 2 your-discrim 3396727743 
mintx 150 minrx 150 minecho 5 multiplier 3 (DF) [tos 0xc0] (ttl 
255, id 36952, len 52)
14:56:32.023207 10.10.20.9.58974 > 10.10.20.10.bfd-control: [udp sum ok] BFD v1 
length 24 state up flags [F] diag none my-discrim 3396727743 your-discrim 2 
mintx 150 minrx 150 minecho 0 multiplier 3 [tos 0xc0] (ttl 255, id 
23805, len 52)
14:56:32.997091 10.10.20.10.49143 > 10.10.20.9.bfd-control: [udp sum ok] BFD v1 
length 24 state up flags [] diag none my-discrim 2 your-discrim 3396727743 
mintx 150 minrx 150 minecho 5 multiplier 3 ( DF) [tos 0xc0] (ttl 
255, id 36991, len 52)

I also added some handling for generating polls and receiving finals while
in there, but there isn't any code to actually start our own poll
sequence just yet.

I only have frr and openbsd peers to test with - if anybody has
something else hooked up would be good to check what they do.

Mitchell


diff --git sys/net/bfd.c sys/net/bfd.c
index 42995531a8a..2ae287a15bb 100644
--- sys/net/bfd.c
+++ sys/net/bfd.c
@@ -741,6 +741,8 @@ bfd_reset(struct bfd_config *bfd)
 
bfd->bc_mode = BFD_MODE_ASYNC;
bfd->bc_state = BFD_STATE_DOWN;
+   bfd->bc_poll_seq = 0;
+   bfd->bc_poll_rcvd = 0;
 
/* rfc5880 6.8.18 */
bfd->bc_neighbor->bn_lstate = BFD_STATE_DOWN;
@@ -825,7 +827,10 @@ bfd_input(struct bfd_config *bfd, struct mbuf *m)
bfd->bc_neighbor->bn_rdiscr = ntohl(peer->bfd_my_discriminator);
bfd->bc_neighbor->bn_rstate = state;
bfd->bc_neighbor->bn_rdemand = (flags & BFD_FLAG_D);
-   bfd->bc_poll = (flags & BFD_FLAG_F);
+
+   if (flags & BFD_FLAG_F && bfd->bc_poll_seq) {
+   bfd->bc_poll_seq = 0;
+   }
 
/* Local change to the algorithm, we don't accept below 50ms */
if (ntohl(peer->bfd_required_min_rx_interval) < BFD_MINIMUM)
@@ -891,6 +896,12 @@ bfd_input(struct bfd_config *bfd, struct mbuf *m)
 
bfd->bc_error = 0;
 
+   /* Reply to poll if we aren't down */
+   if (flags & BFD_FLAG_P && bfd->bc_state > BFD_STATE_DOWN) {
+   bfd->bc_poll_rcvd = 1;
+   bfd_send_control(bfd);
+   }
+
  discard:
bfd->bc_neighbor->bn_rdiag = diag;
m_free(m);
@@ -979,6 +990,13 @@ bfd_send_control(void *x)
 
h->bfd_ver_diag = ((BFD_VERSION << 5) | (bfd->bc_neighbor->bn_ldiag));
h->bfd_sta_flags = (bfd->bc_state << 6);
+   /* Can't send a poll and a final in the same packet. */
+   if (bfd->bc_poll_rcvd) {
+   h->bfd_sta_flags |= BFD_FLAG_F;
+   bfd->bc_poll_rcvd = 0;
+   } else if (bfd->bc_poll_seq) {
+   h->bfd_sta_flags |= BFD_FLAG_P;
+   }
h->bfd_detect_multi = bfd->bc_neighbor->bn_mult;
h->bfd_length = BFD_HDRLEN;
h->bfd_my_discriminator = htonl(bfd->bc_neighbor->bn_ldiscr);
diff --git sys/net/bfd.h sys/net/bfd.h
index 3e8da45086f..8ee372faa5d 100644
--- sys/net/bfd.h
+++ sys/net/bfd.h
@@ -143,7 +143,8 @@ struct bfd_config {
time_t   bc_lastuptime;
unsigned int bc_laststate;
unsigned int bc_state;
-   unsigned int bc_poll;
+   unsigned int bc_poll_seq;
+   unsigned int bc_poll_rcvd;
unsigned int bc_error;
uint32_t bc_minrx;
uint32_t bc_mintx;



Re: [patch] use acme-client to sign certificated with ecdsa keys

2019-06-03 Thread Renaud Allard



On 6/3/19 11:18 AM, Renaud Allard wrote:



On 5/29/19 10:19 AM, Renaud Allard wrote:



On 5/29/19 9:58 AM, Florian Obser wrote:

On Wed, May 22, 2019 at 01:33:11PM +0200, Renaud Allard wrote:

The key needs to be generated manually
i.e.: openssl ecparam -genkey -name secp384r1 -out privkey.pem


why not let acme-client generate the key?




Here is a more complete diff where you can use the -D switch to generate 
a ECDSA key instead of the RSA one.



I obviously meant -E switch :)



smime.p7s
Description: S/MIME Cryptographic Signature


Re: Pump my sched: fewer SCHED_LOCK() & kill p_priority

2019-06-03 Thread Solene Rapenne
On Sat, Jun 01, 2019 at 06:55:20PM -0300, Martin Pieuchot wrote:
> Diff below exists mainly for documentation and test purposes.  If
> you're not interested about how to break the scheduler internals in
> pieces, don't read further and go straight to testing!

I'm running it since a few hours.

- games/gzdoom feels smoother with this patch (stuttering was certainly
  related to audio)
- mpd playback doesn't seem interrupted under heavy load as it
  occasionnaly did

this may be coincidences or placebo effect.



Re: [patch] use acme-client to sign certificated with ecdsa keys

2019-06-03 Thread Renaud Allard



On 5/29/19 10:19 AM, Renaud Allard wrote:



On 5/29/19 9:58 AM, Florian Obser wrote:

On Wed, May 22, 2019 at 01:33:11PM +0200, Renaud Allard wrote:

The key needs to be generated manually
i.e.: openssl ecparam -genkey -name secp384r1 -out privkey.pem


why not let acme-client generate the key?




Here is a more complete diff where you can use the -D switch to generate 
a ECDSA key instead of the RSA one.




Index: acme-client.1
===
RCS file: /cvs/src/usr.sbin/acme-client/acme-client.1,v
retrieving revision 1.29
diff -u -p -r1.29 acme-client.1
--- acme-client.1	3 Feb 2019 20:39:35 -	1.29
+++ acme-client.1	3 Jun 2019 09:13:54 -
@@ -79,7 +79,9 @@ The options are as follows:
 .It Fl A
 Create a new RSA account key if one does not already exist.
 .It Fl D
-Create a new RSA domain key if one does not already exist.
+Create a new (RSA) domain key if one does not already exist.
+.It Fl E
+Switch the new domain key algorithm to ECDSA instead of RSA.
 .It Fl F
 Force certificate renewal, even if it's too soon.
 .It Fl f Ar configfile
Index: ecdsa.h
===
RCS file: ecdsa.h
diff -N ecdsa.h
--- /dev/null	1 Jan 1970 00:00:00 -
+++ ecdsa.h	3 Jun 2019 09:13:54 -
@@ -0,0 +1,22 @@
+/*	$Id: rsa.h,v 1.1 2016/08/31 22:01:42 florian Exp $ */
+/*
+ * Copyright (c) 2019 Renaud Allard 
+ *
+ * Permission to use, copy, modify, and distribute this software for any
+ * purpose with or without fee is hereby granted, provided that the above
+ * copyright notice and this permission notice appear in all copies.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHORS DISCLAIM ALL WARRANTIES
+ * WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
+ * MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHORS BE LIABLE FOR
+ * ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
+ * WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
+ * ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
+ * OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
+ */
+#ifndef ECDSA_H
+#define ECDSA_H
+
+EVP_PKEY	*ec_key_create(FILE *, const char *);
+
+#endif /* ! ECDSA_H */
Index: extern.h
===
RCS file: /cvs/src/usr.sbin/acme-client/extern.h,v
retrieving revision 1.10
diff -u -p -r1.10 extern.h
--- extern.h	31 Jan 2019 15:55:48 -	1.10
+++ extern.h	3 Jun 2019 09:13:54 -
@@ -18,6 +18,7 @@
 #define EXTERN_H
 
 #include "parse.h"
+#include "stdbool.h"
 
 #define MAX_SERVERS_DNS 8
 
@@ -252,6 +253,11 @@ char		*json_fmt_signed(const char *,
  * Should we print debugging messages?
  */
 int		 verbose;
+
+/*
+ * Should we switch to ecdsa?
+ */
+bool		 ecdsa;
 
 /*
  * What component is the process within (COMP__MAX for none)?
Index: keyproc.c
===
RCS file: /cvs/src/usr.sbin/acme-client/keyproc.c,v
retrieving revision 1.11
diff -u -p -r1.11 keyproc.c
--- keyproc.c	29 Jul 2018 20:22:02 -	1.11
+++ keyproc.c	3 Jun 2019 09:13:55 -
@@ -31,6 +31,7 @@
 
 #include "extern.h"
 #include "rsa.h"
+#include "ecdsa.h"
 
 /*
  * This was lifted more or less directly from demos/x509/mkreq.c of the
@@ -114,9 +115,15 @@ keyproc(int netsock, const char *keyfile
 	}
 
 	if (newkey) {
-		if ((pkey = rsa_key_create(f, keyfile)) == NULL)
-			goto out;
-		dodbg("%s: generated RSA domain key", keyfile);
+		if (ecdsa) {
+			if ((pkey = ec_key_create(f, keyfile)) == NULL)
+goto out;
+			dodbg("%s: generated ECDSA domain key", keyfile);
+		} else {
+			if ((pkey = rsa_key_create(f, keyfile)) == NULL)
+goto out;
+			dodbg("%s: generated RSA domain key", keyfile);
+		}
 	} else {
 		if ((pkey = rsa_key_load(f, keyfile)) == NULL)
 			goto out;
Index: main.c
===
RCS file: /cvs/src/usr.sbin/acme-client/main.c,v
retrieving revision 1.45
diff -u -p -r1.45 main.c
--- main.c	9 Mar 2019 18:07:40 -	1.45
+++ main.c	3 Jun 2019 09:13:55 -
@@ -49,6 +49,7 @@ main(int argc, char *argv[])
 	int		  popts = 0;
 	pid_t		  pids[COMP__MAX];
 	extern int	  verbose;
+	extern bool	  ecdsa;
 	extern enum comp  proccomp;
 	size_t		  i, altsz, ne;
 
@@ -57,7 +58,7 @@ main(int argc, char *argv[])
 	struct domain_c		*domain = NULL;
 	struct altname_c	*ac;
 
-	while ((c = getopt(argc, argv, "ADFnrvf:")) != -1)
+	while ((c = getopt(argc, argv, "ADEFnrvf:")) != -1)
 		switch (c) {
 		case 'A':
 			popts |= ACME_OPT_NEWACCT;
@@ -65,6 +66,10 @@ main(int argc, char *argv[])
 		case 'D':
 			popts |= ACME_OPT_NEWDKEY;
 			break;
+		case 'E':
+			ecdsa = true;
+			popts |= ACME_OPT_DKEYEC;
+			break;
 		case 'F':
 			force = 1;
 			break;
@@ -180,6 +185,10 @@ main(int argc, char *argv[])
 	!= -1) {
 		dodbg("%s: domain key exists (not creating)", domain->key);
 		popts &= 

Re: Pump my sched: fewer SCHED_LOCK() & kill p_priority

2019-06-03 Thread Amit Kulkarni
Hi,

This is pretty cool diff in splitting the sleep prio and the run prio!

In a few places, the documentation comment could be changed from process to 
proc, tried to find it below and mark. It leaves reader confused for a moment.

thanks

> > - `spc_curpriority' is now updated at every context-switch.  That means
> >need_resched() won't be called after comparing an out-of-date value.
> >At the same time, `p_usrpri' is initialized to the highest possible
> >value for idle threads.
> > - resched_proc() was calling need_resched() in the following conditions:
> >- If the SONPROC thread has a higher priority that the current
> >  running thread (itself).
> >- Twice in setrunnable() when we know that p_priority <= p_usrpri.
> >- If schedcpu() considered that a thread, after updating its prio,
> >  should preempt the one running on the CPU pointed by `p_cpu'. 
> > 
> >   The diff below simplify all of that by calling need_resched() when:
> >- A thread is inserted in a CPU runqueue at a higher priority than
> >  the one SONPROC.
> >- schedcpu() decides that a thread in SRUN state should preempt the
> >  one SONPROC.

Just FYI, this should fix a serious bug, the resched_proc() call was very wrong 
in comparing stale priority in deciding what to schedule, and it made a pretty 
bad decision consistently!

> > - `p_estcpu' `p_usrpri' and `p_slptime' which represent the "priority"
> >   of a thread are now updated while holding a per-thread mutex.  As a
> >   result schedclock() and donice() no longer takes the SCHED_LOCK(),
> >   and schedcpu() almost never take it.

You forgot to add resetpriority() which is also moved from SCHED_LOCK!

> > 
> > - With this diff top(1) and ps(1) will report the "real" `p_usrpi' value
> >   when displaying priorities.  This is helpful to understand what's
> >   happening:
> > 
> > load averages:  0.99,  0.56,  0.25   two.lab.grenadille.net 
> > 23:42:10
> > 70 threads: 68 idle, 2 on processorup  
> > 0:09
> > CPU0:  0.0% user,  0.0% nice, 51.0% sys,  2.0% spin,  0.0% intr, 47.1% idle
> > CPU1:  2.0% user,  0.0% nice, 51.0% sys,  3.9% spin,  0.0% intr, 43.1% idle
> > Memory: Real: 47M/1005M act/tot Free: 2937M Cache: 812M Swap: 0K/4323M
> > 
> >   PID  TID PRI NICE  SIZE   RES STATE WAIT  TIMECPU COMMAND
> > 81000   145101  7200K 1664K sleep/1   bored 1:15 36.96% softnet
> > 47133   244097  730 2984K 4408K sleep/1   netio 1:06 35.06% cvs 
> > 64749   522184  660  176K  148K onproc/1  - 0:55 28.81% nfsd
> > 21615   602473 12700K 1664K sleep/0   - 7:22  0.00% idle0  
> > 12413   606242 12700K 1664K sleep/1   - 7:08  0.00% idle1
> > 85778   338258  500 4936K 7308K idle  select0:10  0.00% ssh  
> > 22771   575513  500  176K  148K sleep/0   nfsd  0:02  0.00% nfsd 
> > 
> > 
> > 
> > - The removal of `p_priority' and the change that makes mi_switch()
> >   always update `spc_curpriority' might introduce some changes in
> >   behavior, especially with kernel threads that were not going through
> >   tsleep(9).  We currently have some situations where the priority of
> >   the running thread isn't correctly reflected.  This diff changes that
> >   which means we should be able to better understand where the problems
> >   are.
> > 
> > I'd be interested in comments/tests/reviews before continuing in this
> > direction.  Note that at least part of this diff are required to split
> > the accounting apart from the SCHED_LOCK() as well.
> > 
> > I'll also work on exporting scheduler statistics unless somebody wants
> > to beat me :)
> 
> Updated diff to use IPL_SCHED and rebased to apply on top of -current :) 
> 
> Index: arch/amd64/amd64/genassym.cf
> ===
> RCS file: /cvs/src/sys/arch/amd64/amd64/genassym.cf,v
> retrieving revision 1.40
> diff -u -p -r1.40 genassym.cf
> --- arch/amd64/amd64/genassym.cf  17 May 2019 19:07:15 -  1.40
> +++ arch/amd64/amd64/genassym.cf  1 Jun 2019 16:27:46 -
> @@ -32,7 +32,6 @@ export  VM_MIN_KERNEL_ADDRESS
>  
>  struct   proc
>  member   p_addr
> -member   p_priority
>  member   p_stat
>  member   p_wchan
>  member   P_MD_REGS   p_md.md_regs
> Index: arch/hppa/hppa/genassym.cf
> ===
> RCS file: /cvs/src/sys/arch/hppa/hppa/genassym.cf,v
> retrieving revision 1.47
> diff -u -p -r1.47 genassym.cf
> --- arch/hppa/hppa/genassym.cf9 Feb 2015 08:20:13 -   1.47
> +++ arch/hppa/hppa/genassym.cf1 Jun 2019 17:21:44 -
> @@ -130,7 +130,6 @@ membertf_cr30
>  # proc fields and values
>  struct   proc
>  member   p_addr
> -member   p_priority
>  member   p_stat
>  member   p_wchan
>  member   p_md
> Index: arch/i386/i386/esm.c
>