Re: another go at bypass support for sparc64 iommu and BUS_DMA_64BIT

[Theo de Raadt]

David Gwynne  wrote:

> this is a reposting of the diff i sent out a while back. it lets sparc64
> enable iommu bypass, and then uses that bypass support for BUS_DMA_64BIT
> dmamaps.

BTW, this is in snapshots and I'd urge everyone running sparc64 to give it
a try.

Re: bgpd: pimp imsg pipes

[Theo de Raadt]

Not without further measurement of all applications.

Imagine if this gets commited, and causes kernel memory shortage
and deadlock.

Shall we all then point fingers at you for experimenting live?
I know I will.

Claudio Jeker  wrote:

> I noticed that by default the send and recv socket buffers for
> socketpair(2) is rather low (4k IIRC). The result is a fairly inefficent
> write/read behaviour on the imsg sockets. Increasing SO_SNDBUF and
> SO_RCVBUF seems to help increase the data sent and received per syscall.
> 
> Another option would be to make the default socketbuffer watermarks for
> socketpair(2) a bit less limited. Then all imsg users would benefit at the
> same time.
> -- 
> :wq Claudio
> 
> Index: bgpd.c
> ===
> RCS file: /cvs/src/usr.sbin/bgpd/bgpd.c,v
> retrieving revision 1.219
> diff -u -p -r1.219 bgpd.c
> --- bgpd.c29 May 2019 08:48:00 -  1.219
> +++ bgpd.c4 Jun 2019 09:47:18 -
> @@ -46,6 +46,7 @@ int send_filterset(struct imsgbuf *, st
>  int  reconfigure(char *, struct bgpd_config *);
>  int  dispatch_imsg(struct imsgbuf *, int, struct bgpd_config *);
>  int  control_setup(struct bgpd_config *);
> +static void  getsockpair(int [2]);
>  int  imsg_send_sockets(struct imsgbuf *, struct imsgbuf *);
>  
>  int   cflags;
> @@ -203,12 +204,8 @@ main(int argc, char *argv[])
>  
>   log_info("startup");
>  
> - if (socketpair(AF_UNIX, SOCK_STREAM | SOCK_CLOEXEC | SOCK_NONBLOCK,
> - PF_UNSPEC, pipe_m2s) == -1)
> - fatal("socketpair");
> - if (socketpair(AF_UNIX, SOCK_STREAM | SOCK_CLOEXEC | SOCK_NONBLOCK,
> - PF_UNSPEC, pipe_m2r) == -1)
> - fatal("socketpair");
> + getsockpair(pipe_m2s);
> + getsockpair(pipe_m2r);
>  
>   /* fork children */
>   rde_pid = start_child(PROC_RDE, saved_argv0, pipe_m2r[1], debug,
> @@ -1073,18 +1070,54 @@ handle_pollfd(struct pollfd *pfd, struct
>   return (0);
>  }
>  
> +static void
> +getsockpair(int pipe[2])
> +{
> + int bsize, i;
> +
> + if (socketpair(AF_UNIX, SOCK_STREAM | SOCK_CLOEXEC | SOCK_NONBLOCK,
> + PF_UNSPEC, pipe) == -1)
> + fatal("socketpair");
> +
> + /* increase socketpair buffers */
> + for (i = 0; i < 2; i++) {
> + for (bsize = MAX_SOCK_BUF; bsize >= 16 * 1024; bsize /= 2) {
> + if (setsockopt(pipe[i], SOL_SOCKET, SO_RCVBUF,
> + &bsize, sizeof(bsize)) == -1) {
> + if (errno != ENOBUFS)
> + fatal("setsockopt(SO_RCVBUF, %d)",
> + bsize);
> + continue;
> + }
> + break;
> + }
> + if (bsize != MAX_SOCK_BUF)
> + log_warn("non optimal SO_RCVBUF size of %d", bsize);
> + }
> + for (i = 0; i < 2; i++) {
> + for (bsize = MAX_SOCK_BUF; bsize >= 16 * 1024; bsize /= 2) {
> + if (setsockopt(pipe[i], SOL_SOCKET, SO_SNDBUF,
> + &bsize, sizeof(bsize)) == -1) {
> + if (errno != ENOBUFS)
> + fatal("setsockopt(SO_SNDBUF, %d)",
> + bsize);
> + continue;
> + }
> + break;
> + }
> + if (bsize != MAX_SOCK_BUF)
> + log_warn("non optimal SO_SNDBUF size of %d", bsize);
> + }
> +}
> +
>  int
>  imsg_send_sockets(struct imsgbuf *se, struct imsgbuf *rde)
>  {
>   int pipe_s2r[2];
>   int pipe_s2r_ctl[2];
>  
> - if (socketpair(AF_UNIX, SOCK_STREAM | SOCK_CLOEXEC | SOCK_NONBLOCK,
> -  PF_UNSPEC, pipe_s2r) == -1)
> - return (-1);
> - if (socketpair(AF_UNIX, SOCK_STREAM | SOCK_CLOEXEC | SOCK_NONBLOCK,
> -  PF_UNSPEC, pipe_s2r_ctl) == -1)
> - return (-1);
> + getsockpair(pipe_s2r);
> + getsockpair(pipe_s2r_ctl);
>  
>   if (imsg_compose(se, IMSG_SOCKET_CONN, 0, 0, pipe_s2r[0],
>   NULL, 0) == -1)
> Index: bgpd.h
> ===
> RCS file: /cvs/src/usr.sbin/bgpd/bgpd.h,v
> retrieving revision 1.386
> diff -u -p -r1.386 bgpd.h
> --- bgpd.h17 Jun 2019 13:35:42 -  1.386
> +++ bgpd.h17 Jun 2019 13:56:15 -
> @@ -49,7 +49,7 @@
>  #define  MIN_HOLDTIME3
>  #define  READ_BUF_SIZE   65535
>  #define  RT_BUF_SIZE 16384
> -#define  MAX_RTSOCK_BUF  (2 * 1024 * 1024)
> +#define  MAX_SOCK_BUF(2 * 1024 * 1024)
>  #define  MAX_COMM_MATCH  3
>  
>  #define  BGPD_OPT_VERBOSE0x0001
> Index: kroute.c
> ===

Re: bgpd: pimp imsg pipes

[Theo de Raadt]

Claudio Jeker  wrote:

> I guess a lot of processes could benefit from increased buffers. For
> example firefox and chrome are heavy users of unix sockets. I remember
> that we already added something in Xorg to bump the buffer size.
> A quick check tells me that most unix sockets have sb_hiwat set to 4096.

OK, so let's crank it to 1G, and see what happens when people run chrome.

NOT.

Re: bgpd: pimp imsg pipes

[Theo de Raadt]

Martin Pieuchot  wrote:

> On 17/06/19(Mon) 21:43, Claudio Jeker wrote:
> > I noticed that by default the send and recv socket buffers for
> > socketpair(2) is rather low (4k IIRC). The result is a fairly inefficent
> > write/read behaviour on the imsg sockets. Increasing SO_SNDBUF and
> > SO_RCVBUF seems to help increase the data sent and received per syscall.
> > 
> > Another option would be to make the default socketbuffer watermarks for
> > socketpair(2) a bit less limited. Then all imsg users would benefit at the
> > same time.
> 
> What's the downside of making the default socketbuffer watermarks
> bigger?

It is kernel memory.

> Wasting resources?

People in the past did assessments to decide what numbers made
reasonable sense for kernel memory availability at the time.  They did
this to avoid the potential of denial of service due to resource
failure, including the worst case of exhaustion, and failure to recover.

Until someone does a new assessment, those should stand.

The alternative is deadlock, for our most heavy users.

Is it unreasonable to prefer low performance over potential of
deadlock or crashing?

> How did you figure out that the socket buffers were too small?

He profiled.

> Is that something we could apply to other daemons?

See a previous point.

Re: bgpd async nexthop update loop

[Claudio Jeker]

On Mon, Jun 17, 2019 at 10:20:57PM +0200, Sebastian Benoit wrote:
> Claudio Jeker(cje...@diehard.n-r-g.com) on 2019.06.17 21:34:30 +0200:
> > Hi,
> > 
> > Now that the community rewrite is in here another diff to make bgpd more
> > awesome. There was one loop left that did not run asynchronous compared to
> > the main event loop. This loop was in nexthop_update() now a route server
> > or a big route reflector would be hit hard by this loop since it will send
> > out many updates when a nexthop becomes valid. I have seen times where the
> > RDE was busy for 15min in nexthop_update().
> > 
> > This diff changes nexthop_update() to do this work asynchronous and
> > therefor returns to the main event loop much more often.
> > Nexthops now have a prefix pointer next_prefix which is used for looping
> > through all prefixes. The for loop is broken up in RDE_RUNNER_ROUNDS steps
> > which should hopefully return quickly.
> > 
> > Additionally prefixes belonging to a RIB that is not evaluated (no
> > decision process running) are no longer linked into this nexthop list
> > which should also shorten the loop a bit (at least Adj-RIB-In and
> > Adj-RIB-Out are now skipped). To make this work correctly the linking and
> > unlinking of prefixes has been adjusted to always work in the right way
> > (nexhop last on link and first on unlink).
> 
> reads ok, one comment.

Fixed.
 
> > When testing please watch out for this message:
> > prefix_updateall: prefix with F_RIB_NOEVALUATE hit
> > This should never happen.
> > 
> > I'm running this on a few routers with good success. Please check if you see
> > a) worse convergence time (updates propagating much slower)
> > b) better responsiveness (to e.g. bgpctl commands)
> 
> i see things much faster, actually too fast, i cant meaningdul test bgpctl
> responsiveness.

You just need around 500 peers which are affected by a big nexthop update :)
 
> > There is some potential for tuning but I would prefer to do this at a
> > later stage.
> 
> sure. one question about that: is the TAILQ_INSERT_TAIL/TAILQ_INSERT_HEAD
> optimal?

The idea is to make this like a ring. Start with the latest arrival
first and then process one after the other. This makes sure that every
entry gets about the same amount of process time. The TAILQ_INSERT_HEAD
in nexthop_update() will reduce initial latency for nexthops with only
few prefixes since they will be done in one nexthop_runner() call.

There is also additional interactions with the other runners
(imsg processing, rib_dump_runner and rde_update_queue_runner) which I
need to profile to understand them better. It looks like
rde_dispatch_imsg_session() is running ahead and produces a lot of work
that can't be absorbed that quickly by the other runners. At least that is
the case in the big route server setup that I'm working with.

> > -- 
> > :wq Claudio
> > 
> > Index: rde.c
> > ===
> > RCS file: /cvs/src/usr.sbin/bgpd/rde.c,v
> > retrieving revision 1.470
> > diff -u -p -r1.470 rde.c
> > --- rde.c   17 Jun 2019 13:35:43 -  1.470
> > +++ rde.c   17 Jun 2019 13:56:16 -
> > @@ -256,9 +256,6 @@ rde_main(int debug, int verbose)
> > set_pollfd(&pfd[PFD_PIPE_SESSION], ibuf_se);
> > set_pollfd(&pfd[PFD_PIPE_SESSION_CTL], ibuf_se_ctl);
> >  
> > -   if (rib_dump_pending() || rde_update_queue_pending())
> > -   timeout = 0;
> > -
> > i = PFD_PIPE_COUNT;
> > for (mctx = LIST_FIRST(&rde_mrts); mctx != 0; mctx = xmctx) {
> > xmctx = LIST_NEXT(mctx, entry);
> > @@ -275,6 +272,10 @@ rde_main(int debug, int verbose)
> > }
> > }
> >  
> > +   if (rib_dump_pending() || rde_update_queue_pending() ||
> > +   nexthop_pending())
> > +   timeout = 0;
> > +
> > if (poll(pfd, i, timeout) == -1) {
> > if (errno != EINTR)
> > fatal("poll error");
> > @@ -311,12 +312,13 @@ rde_main(int debug, int verbose)
> > mctx = LIST_NEXT(mctx, entry);
> > }
> >  
> > +   rib_dump_runner();
> > +   nexthop_runner();
> > if (ibuf_se && ibuf_se->w.queued < SESS_MSG_HIGH_MARK) {
> > rde_update_queue_runner();
> > for (aid = AID_INET6; aid < AID_MAX; aid++)
> > rde_update6_queue_runner(aid);
> > }
> > -   rib_dump_runner();
> > }
> >  
> > /* do not clean up on shutdown on production, it takes ages. */
> > Index: rde.h
> > ===
> > RCS file: /cvs/src/usr.sbin/bgpd/rde.h,v
> > retrieving revision 1.214
> > diff -u -p -r1.214 rde.h
> > --- rde.h   17 Jun 2019 13:35:43 -  1.214
> > +++ rde.h   17 Jun 2019 13:56:16 -
> > @@ -228,12 +228,15 @@ struct rde_aspath {
> >  enum nexthop

Re: bgpd: pimp imsg pipes

[Sebastian Benoit]

Claudio Jeker(cje...@diehard.n-r-g.com) on 2019.06.17 22:38:00 +0200:
> On Mon, Jun 17, 2019 at 05:00:32PM -0300, Martin Pieuchot wrote:
> > On 17/06/19(Mon) 21:43, Claudio Jeker wrote:
> > > I noticed that by default the send and recv socket buffers for
> > > socketpair(2) is rather low (4k IIRC). The result is a fairly inefficent
> > > write/read behaviour on the imsg sockets. Increasing SO_SNDBUF and
> > > SO_RCVBUF seems to help increase the data sent and received per syscall.
> > > 
> > > Another option would be to make the default socketbuffer watermarks for
> > > socketpair(2) a bit less limited. Then all imsg users would benefit at the
> > > same time.
> > 
> > What's the downside of making the default socketbuffer watermarks
> > bigger?  Wasting resources?  How did you figure out that the socket
> > buffers were too small?  Is that something we could apply to other
> > daemons?
> > 
> 
> First about the how I found it. Looking at ktrace output and noticing that
> write is only pushing 4k of data and read is also only pulling 4k data.
> Afterwards I used netstat -vP to verify the socketbuffer limits.
> 
> Bigger watermarks could cause higher pressure on the mbuf/mcluster pools.
> Now as long as the receiver is processing the data there should not be a
> problem but once the reader stops more data queues up in the socketbuffer.
> It would make sense to use something similar to pipe(2)'s method of big
> and small buffers for socketpair(2). It would also be possible to auto
> scale the buffers but that is a fair bit harder to implement.
> 
> I guess a lot of processes could benefit from increased buffers. For
> example firefox and chrome are heavy users of unix sockets. I remember
> that we already added something in Xorg to bump the buffer size.
> A quick check tells me that most unix sockets have sb_hiwat set to 4096.
> 
> Makes me wonder what the other BSD use for buffer sizes for the different
> UNIX socket types.

FreeBSD: sysctl
net.local.stream.recvspace: 8192
net.local.dgram.recvspace: 4096
net.local.seqpacket.recvspace: 8192
net.local.stream.sendspace: 8192

Linux: 212992 (/proc/sys/net/core/[rw]mem_default)


> -- 
> :wq Claudio
> 

Re: bgpd: pimp imsg pipes

[Claudio Jeker]

On Mon, Jun 17, 2019 at 05:00:32PM -0300, Martin Pieuchot wrote:
> On 17/06/19(Mon) 21:43, Claudio Jeker wrote:
> > I noticed that by default the send and recv socket buffers for
> > socketpair(2) is rather low (4k IIRC). The result is a fairly inefficent
> > write/read behaviour on the imsg sockets. Increasing SO_SNDBUF and
> > SO_RCVBUF seems to help increase the data sent and received per syscall.
> > 
> > Another option would be to make the default socketbuffer watermarks for
> > socketpair(2) a bit less limited. Then all imsg users would benefit at the
> > same time.
> 
> What's the downside of making the default socketbuffer watermarks
> bigger?  Wasting resources?  How did you figure out that the socket
> buffers were too small?  Is that something we could apply to other
> daemons?
> 

First about the how I found it. Looking at ktrace output and noticing that
write is only pushing 4k of data and read is also only pulling 4k data.
Afterwards I used netstat -vP to verify the socketbuffer limits.

Bigger watermarks could cause higher pressure on the mbuf/mcluster pools.
Now as long as the receiver is processing the data there should not be a
problem but once the reader stops more data queues up in the socketbuffer.
It would make sense to use something similar to pipe(2)'s method of big
and small buffers for socketpair(2). It would also be possible to auto
scale the buffers but that is a fair bit harder to implement.

I guess a lot of processes could benefit from increased buffers. For
example firefox and chrome are heavy users of unix sockets. I remember
that we already added something in Xorg to bump the buffer size.
A quick check tells me that most unix sockets have sb_hiwat set to 4096.

Makes me wonder what the other BSD use for buffer sizes for the different
UNIX socket types.
-- 
:wq Claudio

Re: bgpd async nexthop update loop

[Sebastian Benoit]

Claudio Jeker(cje...@diehard.n-r-g.com) on 2019.06.17 21:34:30 +0200:
> Hi,
> 
> Now that the community rewrite is in here another diff to make bgpd more
> awesome. There was one loop left that did not run asynchronous compared to
> the main event loop. This loop was in nexthop_update() now a route server
> or a big route reflector would be hit hard by this loop since it will send
> out many updates when a nexthop becomes valid. I have seen times where the
> RDE was busy for 15min in nexthop_update().
> 
> This diff changes nexthop_update() to do this work asynchronous and
> therefor returns to the main event loop much more often.
> Nexthops now have a prefix pointer next_prefix which is used for looping
> through all prefixes. The for loop is broken up in RDE_RUNNER_ROUNDS steps
> which should hopefully return quickly.
> 
> Additionally prefixes belonging to a RIB that is not evaluated (no
> decision process running) are no longer linked into this nexthop list
> which should also shorten the loop a bit (at least Adj-RIB-In and
> Adj-RIB-Out are now skipped). To make this work correctly the linking and
> unlinking of prefixes has been adjusted to always work in the right way
> (nexhop last on link and first on unlink).

reads ok, one comment.

> When testing please watch out for this message:
> prefix_updateall: prefix with F_RIB_NOEVALUATE hit
> This should never happen.
> 
> I'm running this on a few routers with good success. Please check if you see
> a) worse convergence time (updates propagating much slower)
> b) better responsiveness (to e.g. bgpctl commands)

i see things much faster, actually too fast, i cant meaningdul test bgpctl
responsiveness.

> There is some potential for tuning but I would prefer to do this at a
> later stage.

sure. one question about that: is the TAILQ_INSERT_TAIL/TAILQ_INSERT_HEAD
optimal?

> -- 
> :wq Claudio
> 
> Index: rde.c
> ===
> RCS file: /cvs/src/usr.sbin/bgpd/rde.c,v
> retrieving revision 1.470
> diff -u -p -r1.470 rde.c
> --- rde.c 17 Jun 2019 13:35:43 -  1.470
> +++ rde.c 17 Jun 2019 13:56:16 -
> @@ -256,9 +256,6 @@ rde_main(int debug, int verbose)
>   set_pollfd(&pfd[PFD_PIPE_SESSION], ibuf_se);
>   set_pollfd(&pfd[PFD_PIPE_SESSION_CTL], ibuf_se_ctl);
>  
> - if (rib_dump_pending() || rde_update_queue_pending())
> - timeout = 0;
> -
>   i = PFD_PIPE_COUNT;
>   for (mctx = LIST_FIRST(&rde_mrts); mctx != 0; mctx = xmctx) {
>   xmctx = LIST_NEXT(mctx, entry);
> @@ -275,6 +272,10 @@ rde_main(int debug, int verbose)
>   }
>   }
>  
> + if (rib_dump_pending() || rde_update_queue_pending() ||
> + nexthop_pending())
> + timeout = 0;
> +
>   if (poll(pfd, i, timeout) == -1) {
>   if (errno != EINTR)
>   fatal("poll error");
> @@ -311,12 +312,13 @@ rde_main(int debug, int verbose)
>   mctx = LIST_NEXT(mctx, entry);
>   }
>  
> + rib_dump_runner();
> + nexthop_runner();
>   if (ibuf_se && ibuf_se->w.queued < SESS_MSG_HIGH_MARK) {
>   rde_update_queue_runner();
>   for (aid = AID_INET6; aid < AID_MAX; aid++)
>   rde_update6_queue_runner(aid);
>   }
> - rib_dump_runner();
>   }
>  
>   /* do not clean up on shutdown on production, it takes ages. */
> Index: rde.h
> ===
> RCS file: /cvs/src/usr.sbin/bgpd/rde.h,v
> retrieving revision 1.214
> diff -u -p -r1.214 rde.h
> --- rde.h 17 Jun 2019 13:35:43 -  1.214
> +++ rde.h 17 Jun 2019 13:56:16 -
> @@ -228,12 +228,15 @@ struct rde_aspath {
>  enum nexthop_state {
>   NEXTHOP_LOOKUP,
>   NEXTHOP_UNREACH,
> - NEXTHOP_REACH
> + NEXTHOP_REACH,
> + NEXTHOP_FLAPPED
>  };
>  
>  struct nexthop {
>   LIST_ENTRY(nexthop) nexthop_l;
> + TAILQ_ENTRY(nexthop)runner_l;
>   struct prefix_list  prefix_h;
> + struct prefix   *next_prefix;
>   struct bgpd_addrexit_nexthop;
>   struct bgpd_addrtrue_nexthop;
>   struct bgpd_addrnexthop_net;
> @@ -246,6 +249,7 @@ struct nexthop {
>  #endif
>   int refcnt;
>   enum nexthop_state  state;
> + enum nexthop_state  oldstate;
>   u_int8_tnexthop_netlen;
>   u_int8_tflags;
>  #define NEXTHOP_CONNECTED0x01
> @@ -593,6 +597,8 @@ prefix_vstate(struct prefix *p)
>  
>  void  nexthop_init(u_int32_t);
>  void  nexthop_shutdown(void);
> +int   nexthop_pending(void);
> +void  nexthop_runner(void);
>  void  nexthop_modify(struct nexthop *

Re: bgpd: pimp imsg pipes

[Martin Pieuchot]

On 17/06/19(Mon) 21:43, Claudio Jeker wrote:
> I noticed that by default the send and recv socket buffers for
> socketpair(2) is rather low (4k IIRC). The result is a fairly inefficent
> write/read behaviour on the imsg sockets. Increasing SO_SNDBUF and
> SO_RCVBUF seems to help increase the data sent and received per syscall.
> 
> Another option would be to make the default socketbuffer watermarks for
> socketpair(2) a bit less limited. Then all imsg users would benefit at the
> same time.

What's the downside of making the default socketbuffer watermarks
bigger?  Wasting resources?  How did you figure out that the socket
buffers were too small?  Is that something we could apply to other
daemons?

bgpd: pimp imsg pipes

[Claudio Jeker]

I noticed that by default the send and recv socket buffers for
socketpair(2) is rather low (4k IIRC). The result is a fairly inefficent
write/read behaviour on the imsg sockets. Increasing SO_SNDBUF and
SO_RCVBUF seems to help increase the data sent and received per syscall.

Another option would be to make the default socketbuffer watermarks for
socketpair(2) a bit less limited. Then all imsg users would benefit at the
same time.
-- 
:wq Claudio

Index: bgpd.c
===
RCS file: /cvs/src/usr.sbin/bgpd/bgpd.c,v
retrieving revision 1.219
diff -u -p -r1.219 bgpd.c
--- bgpd.c  29 May 2019 08:48:00 -  1.219
+++ bgpd.c  4 Jun 2019 09:47:18 -
@@ -46,6 +46,7 @@ int   send_filterset(struct imsgbuf *, st
 intreconfigure(char *, struct bgpd_config *);
 intdispatch_imsg(struct imsgbuf *, int, struct bgpd_config *);
 intcontrol_setup(struct bgpd_config *);
+static voidgetsockpair(int [2]);
 intimsg_send_sockets(struct imsgbuf *, struct imsgbuf *);
 
 int cflags;
@@ -203,12 +204,8 @@ main(int argc, char *argv[])
 
log_info("startup");
 
-   if (socketpair(AF_UNIX, SOCK_STREAM | SOCK_CLOEXEC | SOCK_NONBLOCK,
-   PF_UNSPEC, pipe_m2s) == -1)
-   fatal("socketpair");
-   if (socketpair(AF_UNIX, SOCK_STREAM | SOCK_CLOEXEC | SOCK_NONBLOCK,
-   PF_UNSPEC, pipe_m2r) == -1)
-   fatal("socketpair");
+   getsockpair(pipe_m2s);
+   getsockpair(pipe_m2r);
 
/* fork children */
rde_pid = start_child(PROC_RDE, saved_argv0, pipe_m2r[1], debug,
@@ -1073,18 +1070,54 @@ handle_pollfd(struct pollfd *pfd, struct
return (0);
 }
 
+static void
+getsockpair(int pipe[2])
+{
+   int bsize, i;
+
+   if (socketpair(AF_UNIX, SOCK_STREAM | SOCK_CLOEXEC | SOCK_NONBLOCK,
+   PF_UNSPEC, pipe) == -1)
+   fatal("socketpair");
+
+   /* increase socketpair buffers */
+   for (i = 0; i < 2; i++) {
+   for (bsize = MAX_SOCK_BUF; bsize >= 16 * 1024; bsize /= 2) {
+   if (setsockopt(pipe[i], SOL_SOCKET, SO_RCVBUF,
+   &bsize, sizeof(bsize)) == -1) {
+   if (errno != ENOBUFS)
+   fatal("setsockopt(SO_RCVBUF, %d)",
+   bsize);
+   continue;
+   }
+   break;
+   }
+   if (bsize != MAX_SOCK_BUF)
+   log_warn("non optimal SO_RCVBUF size of %d", bsize);
+   }
+   for (i = 0; i < 2; i++) {
+   for (bsize = MAX_SOCK_BUF; bsize >= 16 * 1024; bsize /= 2) {
+   if (setsockopt(pipe[i], SOL_SOCKET, SO_SNDBUF,
+   &bsize, sizeof(bsize)) == -1) {
+   if (errno != ENOBUFS)
+   fatal("setsockopt(SO_SNDBUF, %d)",
+   bsize);
+   continue;
+   }
+   break;
+   }
+   if (bsize != MAX_SOCK_BUF)
+   log_warn("non optimal SO_SNDBUF size of %d", bsize);
+   }
+}
+
 int
 imsg_send_sockets(struct imsgbuf *se, struct imsgbuf *rde)
 {
int pipe_s2r[2];
int pipe_s2r_ctl[2];
 
-   if (socketpair(AF_UNIX, SOCK_STREAM | SOCK_CLOEXEC | SOCK_NONBLOCK,
-PF_UNSPEC, pipe_s2r) == -1)
-   return (-1);
-   if (socketpair(AF_UNIX, SOCK_STREAM | SOCK_CLOEXEC | SOCK_NONBLOCK,
-PF_UNSPEC, pipe_s2r_ctl) == -1)
-   return (-1);
+   getsockpair(pipe_s2r);
+   getsockpair(pipe_s2r_ctl);
 
if (imsg_compose(se, IMSG_SOCKET_CONN, 0, 0, pipe_s2r[0],
NULL, 0) == -1)
Index: bgpd.h
===
RCS file: /cvs/src/usr.sbin/bgpd/bgpd.h,v
retrieving revision 1.386
diff -u -p -r1.386 bgpd.h
--- bgpd.h  17 Jun 2019 13:35:42 -  1.386
+++ bgpd.h  17 Jun 2019 13:56:15 -
@@ -49,7 +49,7 @@
 #defineMIN_HOLDTIME3
 #defineREAD_BUF_SIZE   65535
 #defineRT_BUF_SIZE 16384
-#defineMAX_RTSOCK_BUF  (2 * 1024 * 1024)
+#defineMAX_SOCK_BUF(2 * 1024 * 1024)
 #defineMAX_COMM_MATCH  3
 
 #defineBGPD_OPT_VERBOSE0x0001
Index: kroute.c
===
RCS file: /cvs/src/usr.sbin/bgpd/kroute.c,v
retrieving revision 1.236
diff -u -p -r1.236 kroute.c
--- kroute.c6 May 2019 09:49:26 -   1.236
+++ kroute.c3 Jun 2019 20:16:59 -
@@ -236,7 +236,7 @@ kr_init(void)
&default_rcvbuf, &optlen) == -1)

bgpd async nexthop update loop

[Claudio Jeker]

Hi,

Now that the community rewrite is in here another diff to make bgpd more
awesome. There was one loop left that did not run asynchronous compared to
the main event loop. This loop was in nexthop_update() now a route server
or a big route reflector would be hit hard by this loop since it will send
out many updates when a nexthop becomes valid. I have seen times where the
RDE was busy for 15min in nexthop_update().

This diff changes nexthop_update() to do this work asynchronous and
therefor returns to the main event loop much more often.
Nexthops now have a prefix pointer next_prefix which is used for looping
through all prefixes. The for loop is broken up in RDE_RUNNER_ROUNDS steps
which should hopefully return quickly.

Additionally prefixes belonging to a RIB that is not evaluated (no
decision process running) are no longer linked into this nexthop list
which should also shorten the loop a bit (at least Adj-RIB-In and
Adj-RIB-Out are now skipped). To make this work correctly the linking and
unlinking of prefixes has been adjusted to always work in the right way
(nexhop last on link and first on unlink).

When testing please watch out for this message:
prefix_updateall: prefix with F_RIB_NOEVALUATE hit
This should never happen.

I'm running this on a few routers with good success. Please check if you see
a) worse convergence time (updates propagating much slower)
b) better responsiveness (to e.g. bgpctl commands)

There is some potential for tuning but I would prefer to do this at a
later stage.
-- 
:wq Claudio

Index: rde.c
===
RCS file: /cvs/src/usr.sbin/bgpd/rde.c,v
retrieving revision 1.470
diff -u -p -r1.470 rde.c
--- rde.c   17 Jun 2019 13:35:43 -  1.470
+++ rde.c   17 Jun 2019 13:56:16 -
@@ -256,9 +256,6 @@ rde_main(int debug, int verbose)
set_pollfd(&pfd[PFD_PIPE_SESSION], ibuf_se);
set_pollfd(&pfd[PFD_PIPE_SESSION_CTL], ibuf_se_ctl);
 
-   if (rib_dump_pending() || rde_update_queue_pending())
-   timeout = 0;
-
i = PFD_PIPE_COUNT;
for (mctx = LIST_FIRST(&rde_mrts); mctx != 0; mctx = xmctx) {
xmctx = LIST_NEXT(mctx, entry);
@@ -275,6 +272,10 @@ rde_main(int debug, int verbose)
}
}
 
+   if (rib_dump_pending() || rde_update_queue_pending() ||
+   nexthop_pending())
+   timeout = 0;
+
if (poll(pfd, i, timeout) == -1) {
if (errno != EINTR)
fatal("poll error");
@@ -311,12 +312,13 @@ rde_main(int debug, int verbose)
mctx = LIST_NEXT(mctx, entry);
}
 
+   rib_dump_runner();
+   nexthop_runner();
if (ibuf_se && ibuf_se->w.queued < SESS_MSG_HIGH_MARK) {
rde_update_queue_runner();
for (aid = AID_INET6; aid < AID_MAX; aid++)
rde_update6_queue_runner(aid);
}
-   rib_dump_runner();
}
 
/* do not clean up on shutdown on production, it takes ages. */
Index: rde.h
===
RCS file: /cvs/src/usr.sbin/bgpd/rde.h,v
retrieving revision 1.214
diff -u -p -r1.214 rde.h
--- rde.h   17 Jun 2019 13:35:43 -  1.214
+++ rde.h   17 Jun 2019 13:56:16 -
@@ -228,12 +228,15 @@ struct rde_aspath {
 enum nexthop_state {
NEXTHOP_LOOKUP,
NEXTHOP_UNREACH,
-   NEXTHOP_REACH
+   NEXTHOP_REACH,
+   NEXTHOP_FLAPPED
 };
 
 struct nexthop {
LIST_ENTRY(nexthop) nexthop_l;
+   TAILQ_ENTRY(nexthop)runner_l;
struct prefix_list  prefix_h;
+   struct prefix   *next_prefix;
struct bgpd_addrexit_nexthop;
struct bgpd_addrtrue_nexthop;
struct bgpd_addrnexthop_net;
@@ -246,6 +249,7 @@ struct nexthop {
 #endif
int refcnt;
enum nexthop_state  state;
+   enum nexthop_state  oldstate;
u_int8_tnexthop_netlen;
u_int8_tflags;
 #define NEXTHOP_CONNECTED  0x01
@@ -593,6 +597,8 @@ prefix_vstate(struct prefix *p)
 
 voidnexthop_init(u_int32_t);
 voidnexthop_shutdown(void);
+int nexthop_pending(void);
+voidnexthop_runner(void);
 voidnexthop_modify(struct nexthop *, enum action_types, u_int8_t,
struct nexthop **, u_int8_t *);
 voidnexthop_link(struct prefix *);
Index: rde_rib.c
===
RCS file: /cvs/src/usr.sbin/bgpd/rde_rib.c,v
retrieving revision 1.191
diff -u -p -r1.191 rde_rib.c
--- rde_rib.c   17 Jun 2019 11:02:20 -  1.191
+++ rde_rib.c   17 Jun 

Re: acme-client(1): allocate EC_KEY only once

[Sebastian Benoit]

Florian Obser(flor...@openbsd.org) on 2019.06.17 17:36:28 +0200:
> OK?

after reading the manpage, it seems to be ok.
 
> diff --git key.c key.c
> index 02c04a03419..b701cf85467 100644
> --- key.c
> +++ key.c
> @@ -81,11 +81,8 @@ ec_key_create(FILE *f, const char *fname)
>   EC_KEY  *eckey = NULL;
>   EVP_PKEY*pkey = NULL;
>  
> - if ((eckey = EC_KEY_new()) == NULL ) {
> - warnx("EC_KEY_new");
> - goto err;
> - } else if ((eckey = EC_KEY_new_by_curve_name(ECCTYPE)) == NULL ) {
> - warnx("EC_GROUP_new_by_curve_name");
> + if ((eckey = EC_KEY_new_by_curve_name(ECCTYPE)) == NULL ) {
> + warnx("EC_KEY_new_by_curve_name");
>   goto err;
>   }
>  
> 
> 
> -- 
> I'm not entirely sure you are real.
> 

doas fix PATH inheritance

[Ted Unangst]

espie found a bug. we reset PATH in the parent too soon, and then it's not
possible to change it back via setenv. 

instead of trying to move code around, save a copy of the path before we mess
with it and make it available later. this lets setenv { PATH=$PATH } work.


Index: doas.c
===
RCS file: /cvs/src/usr.bin/doas/doas.c,v
retrieving revision 1.77
diff -u -p -r1.77 doas.c
--- doas.c  16 Jun 2019 18:16:34 -  1.77
+++ doas.c  17 Jun 2019 19:06:14 -
@@ -286,6 +286,7 @@ main(int argc, char **argv)
const char *confpath = NULL;
char *shargv[] = { NULL, NULL };
char *sh;
+   const char *p;
const char *cmd;
char cmdline[LINE_MAX];
char mypwbuf[_PW_BUF_LEN], targpwbuf[_PW_BUF_LEN];
@@ -401,6 +402,11 @@ main(int argc, char **argv)
 
authuser(mypw->pw_name, login_style, rule->options & PERSIST);
}
+
+   if ((p = getenv("PATH")) != NULL)
+   formerpath = strdup(p);
+   if (formerpath == NULL)
+   formerpath = "";
 
if (unveil(_PATH_LOGIN_CONF, "r") == -1)
err(1, "unveil");
Index: doas.h
===
RCS file: /cvs/src/usr.bin/doas/doas.h,v
retrieving revision 1.14
diff -u -p -r1.14 doas.h
--- doas.h  16 Jun 2019 18:16:34 -  1.14
+++ doas.h  17 Jun 2019 19:06:14 -
@@ -29,6 +29,8 @@ extern struct rule **rules;
 extern int nrules;
 extern int parse_errors;
 
+extern const char *formerpath;
+
 struct passwd;
 
 char **prepenv(const struct rule *, const struct passwd *,
Index: env.c
===
RCS file: /cvs/src/usr.bin/doas/env.c,v
retrieving revision 1.8
diff -u -p -r1.8 env.c
--- env.c   17 Jun 2019 16:01:26 -  1.8
+++ env.c   17 Jun 2019 19:06:14 -
@@ -28,6 +28,8 @@
 
 #include "doas.h"
 
+const char *formerpath;
+
 struct envnode {
RB_ENTRY(envnode) node;
const char *key;
@@ -198,8 +200,12 @@ fillenv(struct env *env, const char **en
/* assign value or inherit from environ */
if (eq) {
val = eq + 1;
-   if (*val == '$')
-   val = getenv(val + 1);
+   if (*val == '$') {
+   if (strcmp(val + 1, "PATH") == 0)
+   val = formerpath;
+   else
+   val = getenv(val + 1);
+   }
} else {
val = getenv(name);
}

missing trap.c code for m88k

[Miod Vallat]

Exception handling code on superH and m88k does not check for a valid
stack pointer, like other platforms do.

The following (mechanical) diff addresses the m88k case, and has been
tested to work on 88100 and 88110 processors.

Index: sys/arch/m88k/m88k/trap.c
===
RCS file: /OpenBSD/src/sys/arch/m88k/m88k/trap.c,v
retrieving revision 1.107
diff -u -p -u -p -r1.107 trap.c
--- sys/arch/m88k/m88k/trap.c   8 Sep 2017 05:36:52 -   1.107
+++ sys/arch/m88k/m88k/trap.c   17 Jun 2019 17:54:48 -
@@ -239,6 +239,9 @@ m88100_trap(u_int type, struct trapframe
type += T_USER;
p->p_md.md_tf = frame;  /* for ptrace/signals */
refreshcreds(p);
+   if (!uvm_map_inentry(p, &p->p_spinentry, PROC_STACK(p), "sp",
+   uvm_map_inentry_sp, p->p_vmspace->vm_map.sserial))
+   return;
}
fault_type = SI_NOINFO;
fault_code = 0;
@@ -679,6 +682,9 @@ m88110_trap(u_int type, struct trapframe
type += T_USER;
p->p_md.md_tf = frame;  /* for ptrace/signals */
refreshcreds(p);
+   if (!uvm_map_inentry(p, &p->p_spinentry, PROC_STACK(p), "sp",
+   uvm_map_inentry_sp, p->p_vmspace->vm_map.sserial))
+   return;
}
 
if (sig != 0)

Re: apollo lake gpio

[Patrick Wildt]

Committed, thanks!

On Mon, Jun 17, 2019 at 07:53:50PM +0200, Mark Kettenis wrote:
> > From: James Hastings 
> > Date: Mon, 17 Jun 2019 13:24:36 -0400 (EDT)
> 
> This diff is ok kettenis@
> 
> It might take a few days for me to commit this.  If anybody else wants
> to do it based on my ok, go ahead.
> 
> 
> > Index: share/man/man4/Makefile
> > ===
> > RCS file: /cvs/src/share/man/man4/Makefile,v
> > retrieving revision 1.713
> > diff -u -p -u -r1.713 Makefile
> > --- share/man/man4/Makefile 7 Jun 2019 16:06:59 -   1.713
> > +++ share/man/man4/Makefile 17 Jun 2019 16:18:15 -
> > @@ -10,7 +10,7 @@ MAN=  aac.4 abcrtc.4 ac97.4 acphy.4 acrtc
> > admtm.4 admtmp.4 admtt.4 adt.4 adtfsm.4 adv.4 age.4 alc.4 ale.4 agp.4 \
> > ahc.4 ahci.4 ahd.4 aibs.4 aic.4 \
> > akbd.4 alipm.4 amas.4 amdiic.4 amdpm.4 ami.4 amphy.4 \
> > -   ams.4 an.4 andl.4 aps.4 arc.4 arcofi.4 \
> > +   ams.4 an.4 andl.4 aplgpio.4 aps.4 arc.4 arcofi.4 \
> > asbtm.4 asmc.4 ast.4 atapiscsi.4 atphy.4 ath.4 athn.4 atu.4 atw.4 \
> > auacer.4 audio.4 aue.4 auglx.4 auich.4 auixp.4 autri.4 auvia.4 \
> > axe.4 axen.4 axppmic.4 azalia.4 \
> > Index: share/man/man4/acpi.4
> > ===
> > RCS file: /cvs/src/share/man/man4/acpi.4,v
> > retrieving revision 1.57
> > diff -u -p -u -r1.57 acpi.4
> > --- share/man/man4/acpi.4   23 Apr 2019 20:23:36 -  1.57
> > +++ share/man/man4/acpi.4   17 Jun 2019 16:18:15 -
> > @@ -90,6 +90,8 @@ ACPI video
> >  ACPI video output
> >  .It Xr aibs 4
> >  ASUSTeK AI Booster ACPI ATK0110 temperature, voltage, and fan sensor
> > +.It Xr aplgpio 4
> > +Intel Apollo Lake GPIO controller
> >  .It Xr bytgpio 4
> >  Intel Bay Trail GPIO controller
> >  .It Xr ccp 4
> > Index: share/man/man4/aplgpio.4
> > ===
> > RCS file: share/man/man4/aplgpio.4
> > diff -N share/man/man4/aplgpio.4
> > --- /dev/null   1 Jan 1970 00:00:00 -
> > +++ share/man/man4/aplgpio.417 Jun 2019 16:18:15 -
> > @@ -0,0 +1,50 @@
> > +.\"$OpenBSD$
> > +.\"
> > +.\" Copyright (c) 2019 James Hastings
> > +.\"
> > +.\" 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 APLGPIO 4
> > +.Os
> > +.Sh NAME
> > +.Nm aplgpio
> > +.Nd Intel Apollo Lake GPIO controller
> > +.Sh SYNOPSIS
> > +.Cd "aplgpio* at acpi?"
> > +.Sh DESCRIPTION
> > +The
> > +.Nm
> > +driver provides support for the GPIO controllers found on Intel's Apollo 
> > +Lake SoC.
> > +It does not provide direct device driver entry points but makes its
> > +functions available to
> > +.Xr acpi 4 .
> > +.Sh SEE ALSO
> > +.Xr acpi 4 ,
> > +.Xr intro 4
> > +.Sh HISTORY
> > +The
> > +.Nm
> > +driver first appeared in
> > +.Ox 6.6 .
> > +.Sh AUTHORS
> > +.An -nosplit
> > +The
> > +.Nm
> > +driver was written by
> > +.An James Hastings
> > +based on the
> > +.Xr bytgpio 4
> > +driver by
> > +.An Mark Kettenis Aq Mt kette...@openbsd.org .
> > Index: sys/arch/amd64/conf/GENERIC
> > ===
> > RCS file: /cvs/src/sys/arch/amd64/conf/GENERIC,v
> > retrieving revision 1.473
> > diff -u -p -u -r1.473 GENERIC
> > --- sys/arch/amd64/conf/GENERIC 7 Jun 2019 16:06:59 -   1.473
> > +++ sys/arch/amd64/conf/GENERIC 17 Jun 2019 16:18:16 -
> > @@ -61,6 +61,7 @@ acpivideo*at acpi?
> >  acpivout*  at acpivideo?
> >  acpipwrres*at acpi?
> >  aibs*  at acpi?
> > +aplgpio*   at acpi?
> >  bytgpio*   at acpi?
> >  chvgpio*   at acpi?
> >  sdhc*  at acpi?
> > Index: sys/arch/amd64/conf/RAMDISK_CD
> > ===
> > RCS file: /cvs/src/sys/arch/amd64/conf/RAMDISK_CD,v
> > retrieving revision 1.179
> > diff -u -p -u -r1.179 RAMDISK_CD
> > --- sys/arch/amd64/conf/RAMDISK_CD  4 May 2019 17:59:40 -   1.179
> > +++ sys/arch/amd64/conf/RAMDISK_CD  17 Jun 2019 16:18:16 -
> > @@ -42,6 +42,7 @@ acpiec*   at acpi?
> >  acpiprt*   at acpi?
> >  acpimadt0  at acpi?
> >  #acpitz*   at acpi?
> > +aplgpio*   at acpi?
> >  bytgpio*   at acpi?
> >

Re: apollo lake gpio

[Mark Kettenis]

> From: James Hastings 
> Date: Mon, 17 Jun 2019 13:24:36 -0400 (EDT)

This diff is ok kettenis@

It might take a few days for me to commit this.  If anybody else wants
to do it based on my ok, go ahead.


> Index: share/man/man4/Makefile
> ===
> RCS file: /cvs/src/share/man/man4/Makefile,v
> retrieving revision 1.713
> diff -u -p -u -r1.713 Makefile
> --- share/man/man4/Makefile   7 Jun 2019 16:06:59 -   1.713
> +++ share/man/man4/Makefile   17 Jun 2019 16:18:15 -
> @@ -10,7 +10,7 @@ MAN=aac.4 abcrtc.4 ac97.4 acphy.4 acrtc
>   admtm.4 admtmp.4 admtt.4 adt.4 adtfsm.4 adv.4 age.4 alc.4 ale.4 agp.4 \
>   ahc.4 ahci.4 ahd.4 aibs.4 aic.4 \
>   akbd.4 alipm.4 amas.4 amdiic.4 amdpm.4 ami.4 amphy.4 \
> - ams.4 an.4 andl.4 aps.4 arc.4 arcofi.4 \
> + ams.4 an.4 andl.4 aplgpio.4 aps.4 arc.4 arcofi.4 \
>   asbtm.4 asmc.4 ast.4 atapiscsi.4 atphy.4 ath.4 athn.4 atu.4 atw.4 \
>   auacer.4 audio.4 aue.4 auglx.4 auich.4 auixp.4 autri.4 auvia.4 \
>   axe.4 axen.4 axppmic.4 azalia.4 \
> Index: share/man/man4/acpi.4
> ===
> RCS file: /cvs/src/share/man/man4/acpi.4,v
> retrieving revision 1.57
> diff -u -p -u -r1.57 acpi.4
> --- share/man/man4/acpi.4 23 Apr 2019 20:23:36 -  1.57
> +++ share/man/man4/acpi.4 17 Jun 2019 16:18:15 -
> @@ -90,6 +90,8 @@ ACPI video
>  ACPI video output
>  .It Xr aibs 4
>  ASUSTeK AI Booster ACPI ATK0110 temperature, voltage, and fan sensor
> +.It Xr aplgpio 4
> +Intel Apollo Lake GPIO controller
>  .It Xr bytgpio 4
>  Intel Bay Trail GPIO controller
>  .It Xr ccp 4
> Index: share/man/man4/aplgpio.4
> ===
> RCS file: share/man/man4/aplgpio.4
> diff -N share/man/man4/aplgpio.4
> --- /dev/null 1 Jan 1970 00:00:00 -
> +++ share/man/man4/aplgpio.4  17 Jun 2019 16:18:15 -
> @@ -0,0 +1,50 @@
> +.\"  $OpenBSD$
> +.\"
> +.\" Copyright (c) 2019 James Hastings
> +.\"
> +.\" 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 APLGPIO 4
> +.Os
> +.Sh NAME
> +.Nm aplgpio
> +.Nd Intel Apollo Lake GPIO controller
> +.Sh SYNOPSIS
> +.Cd "aplgpio* at acpi?"
> +.Sh DESCRIPTION
> +The
> +.Nm
> +driver provides support for the GPIO controllers found on Intel's Apollo 
> +Lake SoC.
> +It does not provide direct device driver entry points but makes its
> +functions available to
> +.Xr acpi 4 .
> +.Sh SEE ALSO
> +.Xr acpi 4 ,
> +.Xr intro 4
> +.Sh HISTORY
> +The
> +.Nm
> +driver first appeared in
> +.Ox 6.6 .
> +.Sh AUTHORS
> +.An -nosplit
> +The
> +.Nm
> +driver was written by
> +.An James Hastings
> +based on the
> +.Xr bytgpio 4
> +driver by
> +.An Mark Kettenis Aq Mt kette...@openbsd.org .
> Index: sys/arch/amd64/conf/GENERIC
> ===
> RCS file: /cvs/src/sys/arch/amd64/conf/GENERIC,v
> retrieving revision 1.473
> diff -u -p -u -r1.473 GENERIC
> --- sys/arch/amd64/conf/GENERIC   7 Jun 2019 16:06:59 -   1.473
> +++ sys/arch/amd64/conf/GENERIC   17 Jun 2019 16:18:16 -
> @@ -61,6 +61,7 @@ acpivideo*  at acpi?
>  acpivout*at acpivideo?
>  acpipwrres*  at acpi?
>  aibs*at acpi?
> +aplgpio* at acpi?
>  bytgpio* at acpi?
>  chvgpio* at acpi?
>  sdhc*at acpi?
> Index: sys/arch/amd64/conf/RAMDISK_CD
> ===
> RCS file: /cvs/src/sys/arch/amd64/conf/RAMDISK_CD,v
> retrieving revision 1.179
> diff -u -p -u -r1.179 RAMDISK_CD
> --- sys/arch/amd64/conf/RAMDISK_CD4 May 2019 17:59:40 -   1.179
> +++ sys/arch/amd64/conf/RAMDISK_CD17 Jun 2019 16:18:16 -
> @@ -42,6 +42,7 @@ acpiec* at acpi?
>  acpiprt* at acpi?
>  acpimadt0at acpi?
>  #acpitz* at acpi?
> +aplgpio* at acpi?
>  bytgpio* at acpi?
>  sdhc*at acpi?
>  acpihve* at acpi?
> Index: sys/dev/acpi/aplgpio.c
> ===
> RCS file: sys/dev/acpi/aplgpio.c
> diff -N sys/dev/acpi/aplgpio.c
> --- /dev/null 1 Jan 1970 00:00:00 -
> +++ sys/dev/acpi/aplgpio.c17 Jun 2019 1

apollo lake gpio

[James Hastings]

Index: share/man/man4/Makefile
===
RCS file: /cvs/src/share/man/man4/Makefile,v
retrieving revision 1.713
diff -u -p -u -r1.713 Makefile
--- share/man/man4/Makefile 7 Jun 2019 16:06:59 -   1.713
+++ share/man/man4/Makefile 17 Jun 2019 16:18:15 -
@@ -10,7 +10,7 @@ MAN=  aac.4 abcrtc.4 ac97.4 acphy.4 acrtc
admtm.4 admtmp.4 admtt.4 adt.4 adtfsm.4 adv.4 age.4 alc.4 ale.4 agp.4 \
ahc.4 ahci.4 ahd.4 aibs.4 aic.4 \
akbd.4 alipm.4 amas.4 amdiic.4 amdpm.4 ami.4 amphy.4 \
-   ams.4 an.4 andl.4 aps.4 arc.4 arcofi.4 \
+   ams.4 an.4 andl.4 aplgpio.4 aps.4 arc.4 arcofi.4 \
asbtm.4 asmc.4 ast.4 atapiscsi.4 atphy.4 ath.4 athn.4 atu.4 atw.4 \
auacer.4 audio.4 aue.4 auglx.4 auich.4 auixp.4 autri.4 auvia.4 \
axe.4 axen.4 axppmic.4 azalia.4 \
Index: share/man/man4/acpi.4
===
RCS file: /cvs/src/share/man/man4/acpi.4,v
retrieving revision 1.57
diff -u -p -u -r1.57 acpi.4
--- share/man/man4/acpi.4   23 Apr 2019 20:23:36 -  1.57
+++ share/man/man4/acpi.4   17 Jun 2019 16:18:15 -
@@ -90,6 +90,8 @@ ACPI video
 ACPI video output
 .It Xr aibs 4
 ASUSTeK AI Booster ACPI ATK0110 temperature, voltage, and fan sensor
+.It Xr aplgpio 4
+Intel Apollo Lake GPIO controller
 .It Xr bytgpio 4
 Intel Bay Trail GPIO controller
 .It Xr ccp 4
Index: share/man/man4/aplgpio.4
===
RCS file: share/man/man4/aplgpio.4
diff -N share/man/man4/aplgpio.4
--- /dev/null   1 Jan 1970 00:00:00 -
+++ share/man/man4/aplgpio.417 Jun 2019 16:18:15 -
@@ -0,0 +1,50 @@
+.\"$OpenBSD$
+.\"
+.\" Copyright (c) 2019 James Hastings
+.\"
+.\" 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 APLGPIO 4
+.Os
+.Sh NAME
+.Nm aplgpio
+.Nd Intel Apollo Lake GPIO controller
+.Sh SYNOPSIS
+.Cd "aplgpio* at acpi?"
+.Sh DESCRIPTION
+The
+.Nm
+driver provides support for the GPIO controllers found on Intel's Apollo 
+Lake SoC.
+It does not provide direct device driver entry points but makes its
+functions available to
+.Xr acpi 4 .
+.Sh SEE ALSO
+.Xr acpi 4 ,
+.Xr intro 4
+.Sh HISTORY
+The
+.Nm
+driver first appeared in
+.Ox 6.6 .
+.Sh AUTHORS
+.An -nosplit
+The
+.Nm
+driver was written by
+.An James Hastings
+based on the
+.Xr bytgpio 4
+driver by
+.An Mark Kettenis Aq Mt kette...@openbsd.org .
Index: sys/arch/amd64/conf/GENERIC
===
RCS file: /cvs/src/sys/arch/amd64/conf/GENERIC,v
retrieving revision 1.473
diff -u -p -u -r1.473 GENERIC
--- sys/arch/amd64/conf/GENERIC 7 Jun 2019 16:06:59 -   1.473
+++ sys/arch/amd64/conf/GENERIC 17 Jun 2019 16:18:16 -
@@ -61,6 +61,7 @@ acpivideo*at acpi?
 acpivout*  at acpivideo?
 acpipwrres*at acpi?
 aibs*  at acpi?
+aplgpio*   at acpi?
 bytgpio*   at acpi?
 chvgpio*   at acpi?
 sdhc*  at acpi?
Index: sys/arch/amd64/conf/RAMDISK_CD
===
RCS file: /cvs/src/sys/arch/amd64/conf/RAMDISK_CD,v
retrieving revision 1.179
diff -u -p -u -r1.179 RAMDISK_CD
--- sys/arch/amd64/conf/RAMDISK_CD  4 May 2019 17:59:40 -   1.179
+++ sys/arch/amd64/conf/RAMDISK_CD  17 Jun 2019 16:18:16 -
@@ -42,6 +42,7 @@ acpiec*   at acpi?
 acpiprt*   at acpi?
 acpimadt0  at acpi?
 #acpitz*   at acpi?
+aplgpio*   at acpi?
 bytgpio*   at acpi?
 sdhc*  at acpi?
 acpihve*   at acpi?
Index: sys/dev/acpi/aplgpio.c
===
RCS file: sys/dev/acpi/aplgpio.c
diff -N sys/dev/acpi/aplgpio.c
--- /dev/null   1 Jan 1970 00:00:00 -
+++ sys/dev/acpi/aplgpio.c  17 Jun 2019 16:18:16 -
@@ -0,0 +1,304 @@
+/* $OpenBSD$   */
+/*
+ * Copyright (c) 2016 Mark Kettenis
+ * Copyright (c) 2019 James Hastings
+ *
+ * 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 A

Re: new env defaults for doas

[Todd C . Miller]

On Mon, 17 Jun 2019 13:17:15 -0400, "Ted Unangst" wrote:

> Not sure what you mean. This diff does put it before the options.
>
> same place as su, although su has other problems. fortunately, we don't have
> the same combination of possibilities as su.

Sorry, I misread the diff.  The placement in that diff is fine.

 - todd

Re: new env defaults for doas

[Ted Unangst]

Todd C. Miller wrote:
> On Mon, 17 Jun 2019 12:58:00 -0400, "Ted Unangst" wrote:
> 
> > Committed this. I'm not entirely happy with the wording. I think hiding them
> > under an option in the config man page is the wrong place. The default
> > behavior should be documented in a more default place.
> 
> I would just place that bit either before the options are described
> or after the options in an "Execution environment" sub-section.

Not sure what you mean. This diff does put it before the options.

same place as su, although su has other problems. fortunately, we don't have
the same combination of possibilities as su.

Re: new env defaults for doas

[Todd C . Miller]

On Mon, 17 Jun 2019 12:58:00 -0400, "Ted Unangst" wrote:

> Committed this. I'm not entirely happy with the wording. I think hiding them
> under an option in the config man page is the wrong place. The default
> behavior should be documented in a more default place.

I would just place that bit either before the options are described
or after the options in an "Execution environment" sub-section.

 - todd

Re: new env defaults for doas

[Ted Unangst]

Ted Unangst wrote:
> Yes, I think it's better to always reset these things. Here's a diff.
> 
> 1. Always set HOME, PATH, SHELL etc to the target.

Committed this. I'm not entirely happy with the wording. I think hiding them
under an option in the config man page is the wrong place. The default
behavior should be documented in a more default place.

Also mention working directory is not changed.


Index: doas.1
===
RCS file: /cvs/src/usr.bin/doas/doas.1,v
retrieving revision 1.19
diff -u -p -r1.19 doas.1
--- doas.1  4 Sep 2016 15:20:37 -   1.19
+++ doas.1  17 Jun 2019 16:57:26 -
@@ -40,6 +40,23 @@ or
 .Fl s
 is specified.
 .Pp
+By default, the environment is reset.
+The variables
+.Ev HOME ,
+.Ev LOGNAME ,
+.Ev PATH ,
+.Ev SHELL ,
+and
+.Ev USER
+are set to values appropriate for the target user.
+The variables
+.Ev DISPLAY
+and
+.Ev TERM
+are inherited from the current environment.
+This behavior may be modified by the config file.
+The working directory is not changed.
+.Pp
 The options are as follows:
 .Bl -tag -width tenletters
 .It Fl a Ar style

Re: sftp(1) manual diff

[Jason McIntyre]

On Mon, Jun 17, 2019 at 05:31:16PM +0200, Tim van der Molen wrote:
> Jason McIntyre (2019-06-17 15:02 +0200):
> > On Mon, Jun 17, 2019 at 02:47:09PM +0200, Tim van der Molen wrote:
> > > sftp(1) has this:
> > > 
> > >  reput [-Ppr] [local-path] remote-path
> > >  Resume upload of [local-path].  Equivalent to put with the -a
> > >  flag set.
> > > 
> > > remote-path should be marked optional, not local-path. Probably a pasto
> > > from reget.
> > > 
> > > OK?
> > > 
> > 
> > hi.
> > 
> > ok by me, but i have another question - shouldn;t the usage for reput
> > and reget show the -f flag too? i know it's unrelated to your diff, but
> > two birds and all that.
> 
> Yes, you're right.
> 
> I see there's also a -R flag (equivalent to -r), so I added that one as
> well (it's also listed in sftp's help command).
> 

ok, please wait for a bit of feedback. i suspect -R is deliberately
undocumented (maybe to mirror cp).

> And then I noticed the help command also has the original issue. While
> there I might as well restore alphabetical order.
> 
> (It's not two birds, but a can of worms!)
> 

it's always a can of worms.

jmc

> Index: sftp.1
> ===
> RCS file: /cvs/src/usr.bin/ssh/sftp.1,v
> retrieving revision 1.125
> diff -p -u -r1.125 sftp.1
> --- sftp.122 Jan 2019 06:58:31 -  1.125
> +++ sftp.117 Jun 2019 15:27:11 -
> @@ -404,7 +404,7 @@ extension.
>  Quit
>  .Nm sftp .
>  .It Xo Ic get
> -.Op Fl afPpr
> +.Op Fl afPpRr
>  .Ar remote-path
>  .Op Ar local-path
>  .Xc
> @@ -446,9 +446,11 @@ or
>  flag is specified, then full file permissions and access times are
>  copied too.
>  .Pp
> -If the
> +If either the
> +.Fl R
> +or
>  .Fl r
> -flag is specified then directories will be copied recursively.
> +flag is specified, then directories will be copied recursively.
>  Note that
>  .Nm
>  does not follow symbolic links when performing recursive transfers.
> @@ -545,7 +547,7 @@ Create remote directory specified by
>  .It Ic progress
>  Toggle display of progress meter.
>  .It Xo Ic put
> -.Op Fl afPpr
> +.Op Fl afPpRr
>  .Ar local-path
>  .Op Ar remote-path
>  .Xc
> @@ -588,9 +590,11 @@ or
>  flag is specified, then full file permissions and access times are
>  copied too.
>  .Pp
> -If the
> +If either the
> +.Fl R
> +or
>  .Fl r
> -flag is specified then directories will be copied recursively.
> +flag is specified, then directories will be copied recursively.
>  Note that
>  .Nm
>  does not follow symbolic links when performing recursive transfers.
> @@ -600,7 +604,7 @@ Display remote working directory.
>  Quit
>  .Nm sftp .
>  .It Xo Ic reget
> -.Op Fl Ppr
> +.Op Fl fPpRr
>  .Ar remote-path
>  .Op Ar local-path
>  .Xc
> @@ -612,12 +616,12 @@ with the
>  .Fl a
>  flag set.
>  .It Xo Ic reput
> -.Op Fl Ppr
> -.Op Ar local-path
> -.Ar remote-path
> +.Op Fl fPpRr
> +.Ar local-path
> +.Op Ar remote-path
>  .Xc
>  Resume upload of
> -.Op Ar local-path .
> +.Ar local-path .
>  Equivalent to
>  .Ic put
>  with the
> Index: sftp.c
> ===
> RCS file: /cvs/src/usr.bin/ssh/sftp.c,v
> retrieving revision 1.192
> diff -p -u -r1.192 sftp.c
> --- sftp.c7 Jun 2019 03:47:12 -   1.192
> +++ sftp.c17 Jun 2019 15:27:11 -
> @@ -263,8 +263,6 @@ help(void)
>   "   filesystem containing 'path'\n"
>   "exit   Quit sftp\n"
>   "get [-afPpRr] remote [local]   Download file\n"
> - "reget [-fPpRr] remote [local]  Resume download file\n"
> - "reput [-fPpRr] [local] remote  Resume upload file\n"
>   "help   Display this help text\n"
>   "lcd path   Change local directory to 
> 'path'\n"
>   "lls [ls-options [path]]Display local directory 
> listing\n"
> @@ -278,6 +276,8 @@ help(void)
>   "put [-afPpRr] local [remote]   Upload file\n"
>   "pwdDisplay remote working 
> directory\n"
>   "quit   Quit sftp\n"
> + "reget [-fPpRr] remote [local]  Resume download file\n"
> + "reput [-fPpRr] local [remote]  Resume upload file\n"
>   "rename oldpath newpath Rename remote file\n"
>   "rm pathDelete remote file\n"
>   "rmdir path Remove remote directory\n"
> 

acme-client(1): allocate EC_KEY only once

[Florian Obser]

OK?

diff --git key.c key.c
index 02c04a03419..b701cf85467 100644
--- key.c
+++ key.c
@@ -81,11 +81,8 @@ ec_key_create(FILE *f, const char *fname)
EC_KEY  *eckey = NULL;
EVP_PKEY*pkey = NULL;
 
-   if ((eckey = EC_KEY_new()) == NULL ) {
-   warnx("EC_KEY_new");
-   goto err;
-   } else if ((eckey = EC_KEY_new_by_curve_name(ECCTYPE)) == NULL ) {
-   warnx("EC_GROUP_new_by_curve_name");
+   if ((eckey = EC_KEY_new_by_curve_name(ECCTYPE)) == NULL ) {
+   warnx("EC_KEY_new_by_curve_name");
goto err;
}
 


-- 
I'm not entirely sure you are real.

Re: sftp(1) manual diff

[Tim van der Molen]

Jason McIntyre (2019-06-17 15:02 +0200):
> On Mon, Jun 17, 2019 at 02:47:09PM +0200, Tim van der Molen wrote:
> > sftp(1) has this:
> > 
> >  reput [-Ppr] [local-path] remote-path
> >  Resume upload of [local-path].  Equivalent to put with the -a
> >  flag set.
> > 
> > remote-path should be marked optional, not local-path. Probably a pasto
> > from reget.
> > 
> > OK?
> > 
> 
> hi.
> 
> ok by me, but i have another question - shouldn;t the usage for reput
> and reget show the -f flag too? i know it's unrelated to your diff, but
> two birds and all that.

Yes, you're right.

I see there's also a -R flag (equivalent to -r), so I added that one as
well (it's also listed in sftp's help command).

And then I noticed the help command also has the original issue. While
there I might as well restore alphabetical order.

(It's not two birds, but a can of worms!)

Index: sftp.1
===
RCS file: /cvs/src/usr.bin/ssh/sftp.1,v
retrieving revision 1.125
diff -p -u -r1.125 sftp.1
--- sftp.1  22 Jan 2019 06:58:31 -  1.125
+++ sftp.1  17 Jun 2019 15:27:11 -
@@ -404,7 +404,7 @@ extension.
 Quit
 .Nm sftp .
 .It Xo Ic get
-.Op Fl afPpr
+.Op Fl afPpRr
 .Ar remote-path
 .Op Ar local-path
 .Xc
@@ -446,9 +446,11 @@ or
 flag is specified, then full file permissions and access times are
 copied too.
 .Pp
-If the
+If either the
+.Fl R
+or
 .Fl r
-flag is specified then directories will be copied recursively.
+flag is specified, then directories will be copied recursively.
 Note that
 .Nm
 does not follow symbolic links when performing recursive transfers.
@@ -545,7 +547,7 @@ Create remote directory specified by
 .It Ic progress
 Toggle display of progress meter.
 .It Xo Ic put
-.Op Fl afPpr
+.Op Fl afPpRr
 .Ar local-path
 .Op Ar remote-path
 .Xc
@@ -588,9 +590,11 @@ or
 flag is specified, then full file permissions and access times are
 copied too.
 .Pp
-If the
+If either the
+.Fl R
+or
 .Fl r
-flag is specified then directories will be copied recursively.
+flag is specified, then directories will be copied recursively.
 Note that
 .Nm
 does not follow symbolic links when performing recursive transfers.
@@ -600,7 +604,7 @@ Display remote working directory.
 Quit
 .Nm sftp .
 .It Xo Ic reget
-.Op Fl Ppr
+.Op Fl fPpRr
 .Ar remote-path
 .Op Ar local-path
 .Xc
@@ -612,12 +616,12 @@ with the
 .Fl a
 flag set.
 .It Xo Ic reput
-.Op Fl Ppr
-.Op Ar local-path
-.Ar remote-path
+.Op Fl fPpRr
+.Ar local-path
+.Op Ar remote-path
 .Xc
 Resume upload of
-.Op Ar local-path .
+.Ar local-path .
 Equivalent to
 .Ic put
 with the
Index: sftp.c
===
RCS file: /cvs/src/usr.bin/ssh/sftp.c,v
retrieving revision 1.192
diff -p -u -r1.192 sftp.c
--- sftp.c  7 Jun 2019 03:47:12 -   1.192
+++ sftp.c  17 Jun 2019 15:27:11 -
@@ -263,8 +263,6 @@ help(void)
"   filesystem containing 'path'\n"
"exit   Quit sftp\n"
"get [-afPpRr] remote [local]   Download file\n"
-   "reget [-fPpRr] remote [local]  Resume download file\n"
-   "reput [-fPpRr] [local] remote  Resume upload file\n"
"help   Display this help text\n"
"lcd path   Change local directory to 
'path'\n"
"lls [ls-options [path]]Display local directory 
listing\n"
@@ -278,6 +276,8 @@ help(void)
"put [-afPpRr] local [remote]   Upload file\n"
"pwdDisplay remote working 
directory\n"
"quit   Quit sftp\n"
+   "reget [-fPpRr] remote [local]  Resume download file\n"
+   "reput [-fPpRr] local [remote]  Resume upload file\n"
"rename oldpath newpath Rename remote file\n"
"rm pathDelete remote file\n"
"rmdir path Remove remote directory\n"

Re: new env defaults for doas

[Todd C . Miller]

On Sun, 16 Jun 2019 14:23:24 -0400, "Ted Unangst" wrote:

> Yes, I think it's better to always reset these things. Here's a diff.
>
> 1. Always set HOME, PATH, SHELL etc to the target.
>
> 2. Without keepenv, other environment variables are discarded.
>
> 3. With keepenv, other variables are retained, but the above are still reset.
>
> 4. Possible to override this with setenv.
>
> This is much more consistent and predictable.

That does seem better.  The user can always preserve some or all
of those variables via setenv.  OK millert@

 - todd

Re: acme-client: remove deprecated aliases

[Renaud Allard]

On 6/17/19 3:33 PM, Theo Buehler wrote:

On Mon, Jun 17, 2019 at 01:44:47PM +0200, Renaud Allard wrote:

Hello,

EVP_MD_CTX_create(), EVP_MD_CTX_cleanup(), and EVP_MD_CTX_destroy() are
deprecated aliases for EVP_MD_CTX_new(), EVP_MD_CTX_reset(), and
EVP_MD_CTX_free(). So replace the occurrences to be future proof.

Comments?


I don't think we care about compatibilty with OpenSSL 1.0.2 (which is
EOL by the end of this year), so I think that's fine.

ok with one comment inline


Here it is with the comment taken into account
Index: acctproc.c
===
RCS file: /cvs/src/usr.sbin/acme-client/acctproc.c,v
retrieving revision 1.17
diff -u -p -r1.17 acctproc.c
--- acctproc.c	17 Jun 2019 08:59:33 -	1.17
+++ acctproc.c	17 Jun 2019 13:37:41 -
@@ -124,8 +124,8 @@ op_thumbprint(int fd, EVP_PKEY *pkey)
 	if ((dig = malloc(EVP_MAX_MD_SIZE)) == NULL) {
 		warn("malloc");
 		goto out;
-	} else if ((ctx = EVP_MD_CTX_create()) == NULL) {
-		warnx("EVP_MD_CTX_create");
+	} else if ((ctx = EVP_MD_CTX_new()) == NULL) {
+		warnx("EVP_MD_CTX_new");
 		goto out;
 	} else if (!EVP_DigestInit_ex(ctx, EVP_sha256(), NULL)) {
 		warnx("EVP_SignInit_ex");
@@ -145,7 +145,7 @@ op_thumbprint(int fd, EVP_PKEY *pkey)
 	rc = 1;
 out:
 	if (ctx != NULL)
-		EVP_MD_CTX_destroy(ctx);
+		EVP_MD_CTX_free(ctx);
 
 	free(thumb);
 	free(dig);
@@ -262,8 +262,8 @@ op_sign(int fd, EVP_PKEY *pkey, enum acc
 	 * sign a SHA256 digest of our message.
 	 */
 
-	if ((ctx = EVP_MD_CTX_create()) == NULL) {
-		warnx("EVP_MD_CTX_create");
+	if ((ctx = EVP_MD_CTX_new()) == NULL) {
+		warnx("EVP_MD_CTX_new");
 		goto out;
 	} else if (!EVP_SignInit_ex(ctx, EVP_sha256(), NULL)) {
 		warnx("EVP_SignInit_ex");
@@ -293,9 +293,7 @@ op_sign(int fd, EVP_PKEY *pkey, enum acc
 
 	rc = 1;
 out:
-	if (ctx != NULL)
-		EVP_MD_CTX_destroy(ctx);
-
+	EVP_MD_CTX_free(ctx);
 	free(pay);
 	free(sign);
 	free(pay64);


smime.p7s
Description: S/MIME Cryptographic Signature

Re: acme-client: remove deprecated aliases

[Theo Buehler]

On Mon, Jun 17, 2019 at 01:44:47PM +0200, Renaud Allard wrote:
> Hello,
> 
> EVP_MD_CTX_create(), EVP_MD_CTX_cleanup(), and EVP_MD_CTX_destroy() are
> deprecated aliases for EVP_MD_CTX_new(), EVP_MD_CTX_reset(), and
> EVP_MD_CTX_free(). So replace the occurrences to be future proof.
> 
> Comments?

I don't think we care about compatibilty with OpenSSL 1.0.2 (which is
EOL by the end of this year), so I think that's fine.

ok with one comment inline

> Index: acctproc.c
> ===
> RCS file: /cvs/src/usr.sbin/acme-client/acctproc.c,v
> retrieving revision 1.17
> diff -u -p -r1.17 acctproc.c
> --- acctproc.c17 Jun 2019 08:59:33 -  1.17
> +++ acctproc.c17 Jun 2019 11:42:20 -
> @@ -124,8 +124,8 @@ op_thumbprint(int fd, EVP_PKEY *pkey)
>   if ((dig = malloc(EVP_MAX_MD_SIZE)) == NULL) {
>   warn("malloc");
>   goto out;
> - } else if ((ctx = EVP_MD_CTX_create()) == NULL) {
> - warnx("EVP_MD_CTX_create");
> + } else if ((ctx = EVP_MD_CTX_new()) == NULL) {
> + warnx("EVP_MD_CTX_new");
>   goto out;
>   } else if (!EVP_DigestInit_ex(ctx, EVP_sha256(), NULL)) {
>   warnx("EVP_SignInit_ex");
> @@ -145,7 +145,7 @@ op_thumbprint(int fd, EVP_PKEY *pkey)
>   rc = 1;
>  out:
>   if (ctx != NULL)
> - EVP_MD_CTX_destroy(ctx);
> + EVP_MD_CTX_free(ctx);
>  
>   free(thumb);
>   free(dig);
> @@ -262,8 +262,8 @@ op_sign(int fd, EVP_PKEY *pkey, enum acc
>* sign a SHA256 digest of our message.
>*/
>  
> - if ((ctx = EVP_MD_CTX_create()) == NULL) {
> - warnx("EVP_MD_CTX_create");
> + if ((ctx = EVP_MD_CTX_new()) == NULL) {
> + warnx("EVP_MD_CTX_new");
>   goto out;
>   } else if (!EVP_SignInit_ex(ctx, EVP_sha256(), NULL)) {
>   warnx("EVP_SignInit_ex");
> @@ -294,7 +294,7 @@ op_sign(int fd, EVP_PKEY *pkey, enum acc
>   rc = 1;
>  out:
>   if (ctx != NULL)

This ctx != NULL check is not needed.

> - EVP_MD_CTX_destroy(ctx);
> + EVP_MD_CTX_free(ctx);
>  
>   free(pay);
>   free(sign);

Re: OpenBSD: patch for bridge(4) to fix incoming interface for pf(4)

[Eygene Ryabinkin]

Martin, good day.

Sun, Jun 09, 2019 at 11:44:10AM -0300, Martin Pieuchot wrote:
> On 07/06/19(Fri) 20:50, Eygene Ryabinkin wrote:
> > The attached patch fixes incoming interface for pf(4) processing
> > in the case of bridging of multiple VLAN interfaces which have
> > the same parent iface and unicast packets destined to the bridge
> > member: we can't rely solely on the destination MAC in determining
> > proper incoming interface.
> > 
> > Can it be reviewed and possibly applied?  It was verified in my
> > production environment.
> 
> Are you suggesting that the order in which bridge members are checked
> matters?

Yes.

> In that case would it makes sense to apply the so-called unicast
> check to `ifp', the incoming interface, first?

Right.  Had rewritten the patch to do this explicitely: +1 goto,
-1 (I hope) confusion point about ifp setting.

The bridge with updated patch works as expected already for some hours
in production: will continue to monitor it.
-- 
rea
>From 80808b947d3f1e980a39ae997adb91b142bcc614 Mon Sep 17 00:00:00 2001
From: Eygene Ryabinkin 
Date: Thu, 6 Jun 2019 09:40:06 +0300
Subject: [PATCH] bridge(4): filter locally-destined packets on the proper
 interface

When vlan(4) interfaces are used as the bridge members, they share
the MAC of their parent ifs.  Thus, when multiple VLANs with the
same parent interface are bridged (for filtering), they will all have
the same MAC and MAC-based strategy for indentification
of locally-destined traffic may pick the wrong interface for pf(4)
processing.  Actually, it will use the most recently added interface
with the packet's destination MAC.

As we know the incoming interface for bridge_process(), check
if it has the packet's destination MAC and use it for bridge_input()
when the check succeeds.

Signed-off-by: Eygene Ryabinkin 
---
 sys/net/if_bridge.c | 48 ++---
 1 file changed, 32 insertions(+), 16 deletions(-)

diff --git a/sys/net/if_bridge.c b/sys/net/if_bridge.c
index 882eb9c3283..abffdc4db2f 100644
--- a/sys/net/if_bridge.c
+++ b/sys/net/if_bridge.c
@@ -1116,7 +1116,7 @@ bridge_input(struct ifnet *ifp, struct mbuf *m, void 
*cookie)
 void
 bridge_process(struct ifnet *ifp, struct mbuf *m)
 {
-   struct ifnet *brifp;
+   struct ifnet *brifp, *if0;
struct bridge_softc *sc;
struct bridge_iflist *bif, *bif0;
struct ether_header *eh;
@@ -1198,26 +1198,22 @@ bridge_process(struct ifnet *ifp, struct mbuf *m)
}
 
/*
-* Unicast, make sure it's not for us.
+* Unicast.  Try to consume locally-destined packets.
+*
+* Bridge can have multiple interfaces sharing the same MAC
+* (vlan(4) interfaces are one example of this);
+* so, we first test the incoming interface: it is the most
+* logical entity to process/filter the L2 packets on
+* for such a case.
 */
bif0 = bif;
+   if0 = ifp;
+   if (bridge_ourether(ifp, eh->ether_dhost))
+   goto for_bridge;
SMR_SLIST_FOREACH_LOCKED(bif, &sc->sc_iflist, bif_next) {
if (bridge_ourether(bif->ifp, eh->ether_dhost)) {
-   if (bif0->bif_flags & IFBIF_LEARNING)
-   bridge_rtupdate(sc,
-   (struct ether_addr *)&eh->ether_shost,
-   ifp, 0, IFBAF_DYNAMIC, m);
-   if (bridge_filterrule(&bif0->bif_brlin, eh, m) ==
-   BRL_ACTION_BLOCK) {
-   goto bad;
-   }
-
-   /* Count for the bridge */
-   brifp->if_ipackets++;
-   brifp->if_ibytes += m->m_pkthdr.len;
-
ifp = bif->ifp;
-   goto reenqueue;
+   goto for_bridge;
}
if (bridge_ourether(bif->ifp, eh->ether_shost))
goto bad;
@@ -1227,6 +1223,26 @@ bridge_process(struct ifnet *ifp, struct mbuf *m)
if_put(brifp);
return;
 
+for_bridge:
+   /*
+* The packet is for the bridge member interface on L2.
+*
+* Variables we expect to be set:
+* - if0: incoming interface;
+* - bif0: bridge_iflist that corresponds to if0;
+* - ifp: interface the packet is destined to.
+*/
+   if (bif0->bif_flags & IFBIF_LEARNING)
+   bridge_rtupdate(sc, (struct ether_addr *)&eh->ether_shost,
+   if0, 0, IFBAF_DYNAMIC, m);
+   if (bridge_filterrule(&bif0->bif_brlin, eh, m) == BRL_ACTION_BLOCK)
+   goto bad;
+
+   /* Count for the bridge */
+   brifp->if_ipackets++;
+   brifp->if_ibytes += m->m_pkthdr.len;
+
+   /* Process on the selected interface */
 reenqueue:
bridge_ifinput(ifp, m);
m = NULL;
-- 
2.21.0

Re: acme-client(1): elliptic curve account key

[Theo Buehler]

> this stores 104 bytes with an NID_secp384r1 key

Yes, this was a pure brainf^Wscrewup on my part, sorry.

> EVP_MAX_MD_SIZE seems to be about digests, not signatures. Did you
> have a different constant in mind or did you get confused by the
> poorly worded variable?

Yes, you're right, I just confused myself.

> What would be the correct calculation for a GF2m field? Should I maybe just
> ignore it? RFC 7518 only lists P-256, P-384 and P-521 (and I think
> Let's Encrypt only supports P-384 anyway), and they are all GFp, no?

Yes, they're all curves over prime fields, so all is well. Just ignore
this comment.

Re: acme-client(1): elliptic curve account key

[Renaud Allard]

On 6/17/19 2:58 PM, Florian Obser wrote:


What would be the correct calculation for a GF2m field? Should I maybe just
ignore it? RFC 7518 only lists P-256, P-384 and P-521 (and I think
Let's Encrypt only supports P-384 anyway), and they are all GFp, no?

Let's Encrypt accepts P-256 and P-384 ECDSA keys for both account keys 
and certificate keys. But there is no point using P-256 when you can do 
P-384.



Maybe it would be best to skip the whole degree calculation and
hardcode bn_len as 48.



That's probably the easiest since we would only support P-384



smime.p7s
Description: S/MIME Cryptographic Signature

Re: sftp(1) manual diff

[Jason McIntyre]

On Mon, Jun 17, 2019 at 02:47:09PM +0200, Tim van der Molen wrote:
> sftp(1) has this:
> 
>  reput [-Ppr] [local-path] remote-path
>  Resume upload of [local-path].  Equivalent to put with the -a
>  flag set.
> 
> remote-path should be marked optional, not local-path. Probably a pasto
> from reget.
> 
> OK?
> 

hi.

ok by me, but i have another question - shouldn;t the usage for reput
and reget show the -f flag too? i know it's unrelated to your diff, but
two birds and all that.

jmc

> Index: sftp.1
> ===
> RCS file: /cvs/src/usr.bin/ssh/sftp.1,v
> retrieving revision 1.125
> diff -p -u -r1.125 sftp.1
> --- sftp.122 Jan 2019 06:58:31 -  1.125
> +++ sftp.117 Jun 2019 12:42:05 -
> @@ -613,11 +613,11 @@ with the
>  flag set.
>  .It Xo Ic reput
>  .Op Fl Ppr
> -.Op Ar local-path
> -.Ar remote-path
> +.Ar local-path
> +.Op Ar remote-path
>  .Xc
>  Resume upload of
> -.Op Ar local-path .
> +.Ar local-path .
>  Equivalent to
>  .Ic put
>  with the
> 

Re: acme-client(1): elliptic curve account key

[Florian Obser]

On Sun, Jun 16, 2019 at 08:44:46PM +0200, Theo Buehler wrote:
> On Sun, Jun 16, 2019 at 09:25:45AM +0200, Florian Obser wrote:
> > On Sat, Jun 15, 2019 at 06:20:49PM +0200, Florian Obser wrote:
> > > OK?
> > 
> > update to apply cleanly on -current
> 
> The acctproc.c change looks ok with some minor comments inline.
> I haven't tried to verify the JSON stuff.

that's fine, Benno reviewed that and ignored the crypto stuff :D

I commited it with the get0 change.

Questions inline

[...]

> > @@ -190,14 +267,19 @@ op_sign_rsa(char **prot, EVP_PKEY *pkey, const char 
> > *nonce, const char *url)
> >  static int
> >  op_sign(int fd, EVP_PKEY *pkey, enum acctop op)
> >  {
> > -   char*nonce = NULL, *pay = NULL, *pay64 = NULL;
> > -   char*prot = NULL, *prot64 = NULL;
> > -   char*sign = NULL, *dig64 = NULL, *fin = NULL;
> > -   char*url = NULL, *kid = NULL;
> > -   unsigned char   *dig = NULL;
> > -   EVP_MD_CTX  *ctx = NULL;
> > -   int  cc, rc = 0;
> > -   unsigned int digsz;
> > +   EVP_MD_CTX  *ctx = NULL;
> > +   const EVP_MD*evp_md = NULL;
> > +   EC_KEY  *ec;
> > +   ECDSA_SIG   *ec_sig = NULL;
> > +   const BIGNUM*ec_sig_r = NULL, *ec_sig_s = NULL;
> > +   int  cc, rc = 0;
> > +   unsigned int digsz, bufsz, degree, bn_len, r_len, s_len;
> > +   char*nonce = NULL, *pay = NULL, *pay64 = NULL;
> > +   char*prot = NULL, *prot64 = NULL;
> > +   char*sign = NULL, *dig64 = NULL, *fin = NULL;
> > +   char*url = NULL, *kid = NULL, *alg = NULL;
> > +   unsigned char   *dig = NULL, *buf = NULL;
> 
> To simplify slightly, you could use 
> 
>   unsigned chardig[EVP_MAX_MD_SIZE];
> 
> instead of allocating dig dynamically (EVP_MAX_MD_SIZE is 64).

this doesn't seem to be correct.

} else if (!EVP_SignFinal(ctx, dig, &digsz, pkey)) {

this stores 104 bytes with an NID_secp384r1 key

EVP_MAX_MD_SIZE seems to be about digests, not signatures. Did you
have a different constant in mind or did you get confused by the
poorly worded variable?

[...]

> > +   degree = EC_GROUP_get_degree(EC_KEY_get0_group(ec));
> > +   bn_len = (degree + 7) / 8;
> 
> This calculation is fine if you use curves over a prime field GFp (as
> you currently do), but it will be incorrect if you should ever want to
> use a curve over a binary field GF2m.

I know some of these words!

So this whole song-and-dance is needed because we need to store r and
s with leading zeros, so we need to find out what the maximum
representation length of r and s could be:

/* put r and s in with leading zeros if any */
BN_bn2bin(ec_sig_r, buf + bn_len - r_len);
BN_bn2bin(ec_sig_s, buf + bufsz - s_len);

This is "documented" in RFC7518 Section 3.4.

https://tools.ietf.org/html/rfc7518#section-3.4

But it's kinda documented by example, i.e. it talks about P-256 and
there r and s representations are 32 bytes long. But for P-384 it's 48
bytes. Of course I'm making this all up as I go along.

What would be the correct calculation for a GF2m field? Should I maybe just
ignore it? RFC 7518 only lists P-256, P-384 and P-521 (and I think
Let's Encrypt only supports P-384 anyway), and they are all GFp, no?

Maybe it would be best to skip the whole degree calculation and
hardcode bn_len as 48.

Thanks for your help!

-- 
I'm not entirely sure you are real.

sftp(1) manual diff

[Tim van der Molen]

sftp(1) has this:

 reput [-Ppr] [local-path] remote-path
 Resume upload of [local-path].  Equivalent to put with the -a
 flag set.

remote-path should be marked optional, not local-path. Probably a pasto
from reget.

OK?

Index: sftp.1
===
RCS file: /cvs/src/usr.bin/ssh/sftp.1,v
retrieving revision 1.125
diff -p -u -r1.125 sftp.1
--- sftp.1  22 Jan 2019 06:58:31 -  1.125
+++ sftp.1  17 Jun 2019 12:42:05 -
@@ -613,11 +613,11 @@ with the
 flag set.
 .It Xo Ic reput
 .Op Fl Ppr
-.Op Ar local-path
-.Ar remote-path
+.Ar local-path
+.Op Ar remote-path
 .Xc
 Resume upload of
-.Op Ar local-path .
+.Ar local-path .
 Equivalent to
 .Ic put
 with the

acme-client: remove deprecated aliases

[Renaud Allard]

Hello,

EVP_MD_CTX_create(), EVP_MD_CTX_cleanup(), and EVP_MD_CTX_destroy() are 
deprecated aliases for EVP_MD_CTX_new(), EVP_MD_CTX_reset(), and 
EVP_MD_CTX_free(). So replace the occurrences to be future proof.


Comments?
Index: acctproc.c
===
RCS file: /cvs/src/usr.sbin/acme-client/acctproc.c,v
retrieving revision 1.17
diff -u -p -r1.17 acctproc.c
--- acctproc.c	17 Jun 2019 08:59:33 -	1.17
+++ acctproc.c	17 Jun 2019 11:42:20 -
@@ -124,8 +124,8 @@ op_thumbprint(int fd, EVP_PKEY *pkey)
 	if ((dig = malloc(EVP_MAX_MD_SIZE)) == NULL) {
 		warn("malloc");
 		goto out;
-	} else if ((ctx = EVP_MD_CTX_create()) == NULL) {
-		warnx("EVP_MD_CTX_create");
+	} else if ((ctx = EVP_MD_CTX_new()) == NULL) {
+		warnx("EVP_MD_CTX_new");
 		goto out;
 	} else if (!EVP_DigestInit_ex(ctx, EVP_sha256(), NULL)) {
 		warnx("EVP_SignInit_ex");
@@ -145,7 +145,7 @@ op_thumbprint(int fd, EVP_PKEY *pkey)
 	rc = 1;
 out:
 	if (ctx != NULL)
-		EVP_MD_CTX_destroy(ctx);
+		EVP_MD_CTX_free(ctx);
 
 	free(thumb);
 	free(dig);
@@ -262,8 +262,8 @@ op_sign(int fd, EVP_PKEY *pkey, enum acc
 	 * sign a SHA256 digest of our message.
 	 */
 
-	if ((ctx = EVP_MD_CTX_create()) == NULL) {
-		warnx("EVP_MD_CTX_create");
+	if ((ctx = EVP_MD_CTX_new()) == NULL) {
+		warnx("EVP_MD_CTX_new");
 		goto out;
 	} else if (!EVP_SignInit_ex(ctx, EVP_sha256(), NULL)) {
 		warnx("EVP_SignInit_ex");
@@ -294,7 +294,7 @@ op_sign(int fd, EVP_PKEY *pkey, enum acc
 	rc = 1;
 out:
 	if (ctx != NULL)
-		EVP_MD_CTX_destroy(ctx);
+		EVP_MD_CTX_free(ctx);
 
 	free(pay);
 	free(sign);


smime.p7s
Description: S/MIME Cryptographic Signature

Re: elf(5): mention the ELF machine type EM_AARCH64

[Kevin Lo]

On Mon, Jun 17, 2019 at 06:15:16PM +1000, Jonathan Gray wrote:
> 
> On Mon, Jun 17, 2019 at 02:45:28PM +0800, Kevin Lo wrote:
> > ok?
> 
> The header also includes EM_PPC64 which isn't documented
> (and EM_X86_64 which should probably be kept not documented).

Documented EM_PPC64, thanks.

Re: apollo lake gpio

[Jason McIntyre]

On Mon, Jun 17, 2019 at 03:22:40AM -0400, James Hastings wrote:
> Index: share/man/man4/Makefile
> ===

morning.

the doc parts looks fine to me. can you add an $OpenBSD$ id to the man
page as well. i guess the .c file added should have one too.

jmc

> RCS file: /cvs/src/share/man/man4/Makefile,v
> retrieving revision 1.713
> diff -u -p -u -r1.713 Makefile
> --- share/man/man4/Makefile   7 Jun 2019 16:06:59 -   1.713
> +++ share/man/man4/Makefile   11 Jun 2019 01:31:02 -
> @@ -10,7 +10,7 @@ MAN=aac.4 abcrtc.4 ac97.4 acphy.4 acrtc
>   admtm.4 admtmp.4 admtt.4 adt.4 adtfsm.4 adv.4 age.4 alc.4 ale.4 agp.4 \
>   ahc.4 ahci.4 ahd.4 aibs.4 aic.4 \
>   akbd.4 alipm.4 amas.4 amdiic.4 amdpm.4 ami.4 amphy.4 \
> - ams.4 an.4 andl.4 aps.4 arc.4 arcofi.4 \
> + ams.4 an.4 andl.4 aplgpio.4 aps.4 arc.4 arcofi.4 \
>   asbtm.4 asmc.4 ast.4 atapiscsi.4 atphy.4 ath.4 athn.4 atu.4 atw.4 \
>   auacer.4 audio.4 aue.4 auglx.4 auich.4 auixp.4 autri.4 auvia.4 \
>   axe.4 axen.4 axppmic.4 azalia.4 \
> Index: share/man/man4/acpi.4
> ===
> RCS file: /cvs/src/share/man/man4/acpi.4,v
> retrieving revision 1.57
> diff -u -p -u -r1.57 acpi.4
> --- share/man/man4/acpi.4 23 Apr 2019 20:23:36 -  1.57
> +++ share/man/man4/acpi.4 11 Jun 2019 01:31:02 -
> @@ -90,6 +90,8 @@ ACPI video
>  ACPI video output
>  .It Xr aibs 4
>  ASUSTeK AI Booster ACPI ATK0110 temperature, voltage, and fan sensor
> +.It Xr aplgpio 4
> +Intel Apollo Lake GPIO controller
>  .It Xr bytgpio 4
>  Intel Bay Trail GPIO controller
>  .It Xr ccp 4
> Index: share/man/man4/aplgpio.4
> ===
> RCS file: share/man/man4/aplgpio.4
> diff -N share/man/man4/aplgpio.4
> --- /dev/null 1 Jan 1970 00:00:00 -
> +++ share/man/man4/aplgpio.4  11 Jun 2019 01:31:02 -
> @@ -0,0 +1,49 @@
> +.\"
> +.\" Copyright (c) 2019 James Hastings
> +.\"
> +.\" 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 APLGPIO 4
> +.Os
> +.Sh NAME
> +.Nm aplgpio
> +.Nd Intel Apollo Lake GPIO controller
> +.Sh SYNOPSIS
> +.Cd "aplgpio* at acpi?"
> +.Sh DESCRIPTION
> +The
> +.Nm
> +driver provides support for the GPIO controllers found on Intel's Apollo 
> +Lake SoC.
> +It does not provide direct device driver entry points but makes its
> +functions available to
> +.Xr acpi 4 .
> +.Sh SEE ALSO
> +.Xr acpi 4 ,
> +.Xr intro 4
> +.Sh HISTORY
> +The
> +.Nm
> +driver first appeared in
> +.Ox 6.6 .
> +.Sh AUTHORS
> +.An -nosplit
> +The
> +.Nm
> +driver was written by
> +.An James Hastings
> +based on the
> +.Xr bytgpio 4
> +driver by
> +.An Mark Kettenis Aq Mt kette...@openbsd.org .
> Index: sys/arch/amd64/conf/GENERIC
> ===
> RCS file: /cvs/src/sys/arch/amd64/conf/GENERIC,v
> retrieving revision 1.473
> diff -u -p -u -r1.473 GENERIC
> --- sys/arch/amd64/conf/GENERIC   7 Jun 2019 16:06:59 -   1.473
> +++ sys/arch/amd64/conf/GENERIC   11 Jun 2019 01:31:02 -
> @@ -61,6 +61,7 @@ acpivideo*  at acpi?
>  acpivout*at acpivideo?
>  acpipwrres*  at acpi?
>  aibs*at acpi?
> +aplgpio* at acpi?
>  bytgpio* at acpi?
>  chvgpio* at acpi?
>  sdhc*at acpi?
> Index: sys/arch/amd64/conf/RAMDISK_CD
> ===
> RCS file: /cvs/src/sys/arch/amd64/conf/RAMDISK_CD,v
> retrieving revision 1.179
> diff -u -p -u -r1.179 RAMDISK_CD
> --- sys/arch/amd64/conf/RAMDISK_CD4 May 2019 17:59:40 -   1.179
> +++ sys/arch/amd64/conf/RAMDISK_CD11 Jun 2019 01:31:02 -
> @@ -42,6 +42,7 @@ acpiec* at acpi?
>  acpiprt* at acpi?
>  acpimadt0at acpi?
>  #acpitz* at acpi?
> +aplgpio* at acpi?
>  bytgpio* at acpi?
>  sdhc*at acpi?
>  acpihve* at acpi?
> Index: sys/dev/acpi/aplgpio.c
> ===
> RCS file: sys/dev/acpi/aplgpio.c
> diff -N sys/dev/acpi/aplgpio.c
> --- /dev/null 1 Jan 1970 00:00:00 -
> +++ sys/dev/acpi/aplgpio.c11 Jun 2019 01:31:03 -00

Re: tls_load_file.3

[alf]

On Mon, Jun 17, 2019 at 10:17:17AM +0200, Gilles Chehade wrote:
> On Mon, Jun 17, 2019 at 10:12:52AM +0200, alf wrote:
> > Hello,
> > 
> > while adding a missing "the" for tls_config_set_cert_file
> > it appeared to me that "file" and "filename" are used
> > inconsistent.  I went with "file" since "filename" to my
> > eyes/ears implies the filename without path, however that
> > maybe wrong.
> > 
> > Alf
> > 
> > Index: lib/libtls/man/tls_load_file.3
> > ===
> > RCS file: /cvs/src/lib/libtls/man/tls_load_file.3,v
> > retrieving revision 1.11
> > diff -u -p -r1.11 tls_load_file.3
> > --- lib/libtls/man/tls_load_file.3  29 Nov 2018 14:24:23 -  1.11
> > +++ lib/libtls/man/tls_load_file.3  17 Jun 2019 08:07:53 -
> > @@ -217,7 +217,7 @@ call, ensuring that the memory contents 
> >  returns the path of the file that contains the default root certificates.
> >  .Pp
> >  .Fn tls_config_set_ca_file
> > -sets the filename used to load a file
> > +sets the file used to load a file
> 
> IMO "set the file used to load a file" reads very weird
> 
> >  containing the root certificates.
> >  .Pp
> >  .Fn tls_config_set_ca_path
> > @@ -228,13 +228,13 @@ certificates.
> >  sets the root certificates directly from memory.
> >  .Pp
> >  .Fn tls_config_set_cert_file
> > -sets file from which the public certificate will be read.
> > +sets the file from which the public certificate will be read.
> 
> I don't see what was wrong here :-/
Imo it misses a "the".

> 
> >  .Pp
> >  .Fn tls_config_set_cert_mem
> >  sets the public certificate directly from memory.
> >  .Pp
> >  .Fn tls_config_set_crl_file
> > -sets the filename used to load a file containing the
> > +sets the file used to load a file containing the
> 
> same
> 
> >  Certificate Revocation List (CRL).
> >  .Pp
> >  .Fn tls_config_set_crl_mem
> > 
> 
> -- 
> Gilles Chehade   @poolpOrg
> 
> https://www.poolp.orgpatreon: https://www.patreon.com/gilles
> 
> 
Ouch, yes. Shouldn't try to fix things with empty stomach, sorry for the noise.

Alf

Re: tls_load_file.3

[Gilles Chehade]

On Mon, Jun 17, 2019 at 10:12:52AM +0200, alf wrote:
> Hello,
> 
> while adding a missing "the" for tls_config_set_cert_file
> it appeared to me that "file" and "filename" are used
> inconsistent.  I went with "file" since "filename" to my
> eyes/ears implies the filename without path, however that
> maybe wrong.
> 
> Alf
> 
> Index: lib/libtls/man/tls_load_file.3
> ===
> RCS file: /cvs/src/lib/libtls/man/tls_load_file.3,v
> retrieving revision 1.11
> diff -u -p -r1.11 tls_load_file.3
> --- lib/libtls/man/tls_load_file.329 Nov 2018 14:24:23 -  1.11
> +++ lib/libtls/man/tls_load_file.317 Jun 2019 08:07:53 -
> @@ -217,7 +217,7 @@ call, ensuring that the memory contents 
>  returns the path of the file that contains the default root certificates.
>  .Pp
>  .Fn tls_config_set_ca_file
> -sets the filename used to load a file
> +sets the file used to load a file

IMO "set the file used to load a file" reads very weird

>  containing the root certificates.
>  .Pp
>  .Fn tls_config_set_ca_path
> @@ -228,13 +228,13 @@ certificates.
>  sets the root certificates directly from memory.
>  .Pp
>  .Fn tls_config_set_cert_file
> -sets file from which the public certificate will be read.
> +sets the file from which the public certificate will be read.

I don't see what was wrong here :-/

>  .Pp
>  .Fn tls_config_set_cert_mem
>  sets the public certificate directly from memory.
>  .Pp
>  .Fn tls_config_set_crl_file
> -sets the filename used to load a file containing the
> +sets the file used to load a file containing the

same

>  Certificate Revocation List (CRL).
>  .Pp
>  .Fn tls_config_set_crl_mem
> 

-- 
Gilles Chehade @poolpOrg

https://www.poolp.orgpatreon: https://www.patreon.com/gilles

Re: elf(5): mention the ELF machine type EM_AARCH64

[Jonathan Gray]

On Mon, Jun 17, 2019 at 02:45:28PM +0800, Kevin Lo wrote:
> ok?

The header also includes EM_PPC64 which isn't documented
(and EM_X86_64 which should probably be kept not documented).

> 
> Index: share/man/man5/elf.5
> ===
> RCS file: /cvs/src/share/man/man5/elf.5,v
> retrieving revision 1.34
> diff -u -p -u -p -r1.34 elf.5
> --- share/man/man5/elf.5  27 Oct 2017 08:36:42 -  1.34
> +++ share/man/man5/elf.5  17 Jun 2019 06:46:19 -
> @@ -325,6 +325,8 @@ Intel IA-64.
>  AMD64.
>  .It Dv EM_VAX
>  DEC Vax.
> +.It Dv EM_AARCH64
> +ARM 64-bit.
>  .It Dv EM_ALPHA_EXP
>  Compaq [DEC] Alpha with enhanced instruction set.
>  .El
> 

tls_load_file.3

[alf]

Hello,

while adding a missing "the" for tls_config_set_cert_file
it appeared to me that "file" and "filename" are used
inconsistent.  I went with "file" since "filename" to my
eyes/ears implies the filename without path, however that
maybe wrong.

Alf

Index: lib/libtls/man/tls_load_file.3
===
RCS file: /cvs/src/lib/libtls/man/tls_load_file.3,v
retrieving revision 1.11
diff -u -p -r1.11 tls_load_file.3
--- lib/libtls/man/tls_load_file.3  29 Nov 2018 14:24:23 -  1.11
+++ lib/libtls/man/tls_load_file.3  17 Jun 2019 08:07:53 -
@@ -217,7 +217,7 @@ call, ensuring that the memory contents 
 returns the path of the file that contains the default root certificates.
 .Pp
 .Fn tls_config_set_ca_file
-sets the filename used to load a file
+sets the file used to load a file
 containing the root certificates.
 .Pp
 .Fn tls_config_set_ca_path
@@ -228,13 +228,13 @@ certificates.
 sets the root certificates directly from memory.
 .Pp
 .Fn tls_config_set_cert_file
-sets file from which the public certificate will be read.
+sets the file from which the public certificate will be read.
 .Pp
 .Fn tls_config_set_cert_mem
 sets the public certificate directly from memory.
 .Pp
 .Fn tls_config_set_crl_file
-sets the filename used to load a file containing the
+sets the file used to load a file containing the
 Certificate Revocation List (CRL).
 .Pp
 .Fn tls_config_set_crl_mem

sdhc_pci: gpio card detect

[James Hastings]

Index: sys/dev/pci/sdhc_pci.c
===
RCS file: /cvs/src/sys/dev/pci/sdhc_pci.c,v
retrieving revision 1.20
diff -u -p -u -r1.20 sdhc_pci.c
--- sys/dev/pci/sdhc_pci.c  30 Apr 2016 11:32:23 -  1.20
+++ sys/dev/pci/sdhc_pci.c  11 Jun 2019 01:31:04 -
@@ -21,6 +21,16 @@
 #include 
 #include 
 
+#include "acpi.h"
+#if NACPI > 0
+#include 
+#include 
+#include 
+#include 
+#include 
+#undef DEVNAME
+#endif
+
 #include 
 #include 
 #include 
@@ -52,6 +62,16 @@ struct sdhc_pci_softc {
pcitag_t sc_tag;
pcireg_t sc_id;
void *sc_ih;
+#if NACPI > 0
+   struct acpi_softc *sc_acpi;
+   struct aml_node *sc_node;
+
+   struct aml_node *sc_gpio_int_node;
+   struct aml_node *sc_gpio_io_node;
+   uint16_t sc_gpio_int_pin;
+   uint16_t sc_gpio_int_flags;
+   uint16_t sc_gpio_io_pin;
+#endif
 };
 
 intsdhc_pci_match(struct device *, void *, void *);
@@ -62,6 +82,17 @@ void sdhc_pci_conf_write(pci_chipset_tag
 void   sdhc_takecontroller(struct pci_attach_args *);
 void   sdhc_ricohfix(struct sdhc_pci_softc *);
 
+#if NACPI > 0
+struct aml_node *acpi_pci_match(struct device *, struct pci_attach_args *);
+intsdhc_pci_card_detect_nonremovable(struct sdhc_softc *);
+intsdhc_pci_card_detect_gpio(struct sdhc_softc *);
+intsdhc_pci_card_detect_intr(void *);
+intsdhc_pci_acpi_parse_resources(int, union acpi_resource *, void *);
+void   sdhc_pci_acpi_get_resources(struct sdhc_pci_softc *);
+void   sdhc_pci_acpi_explore(struct sdhc_pci_softc *);
+void   sdhc_pci_acpi_power_on(struct sdhc_pci_softc *, struct aml_node *);
+#endif
+
 struct cfattach sdhc_pci_ca = {
sizeof(struct sdhc_pci_softc), sdhc_pci_match, sdhc_pci_attach,
NULL, sdhc_pci_activate
@@ -147,6 +178,14 @@ sdhc_pci_attach(struct device *parent, s
}
printf(": %s\n", intrstr);
 
+#if NACPI > 0
+   sc->sc_node = acpi_pci_match(self, pa);
+   if (sc->sc_node != NULL) {
+   sdhc_pci_acpi_get_resources(sc);
+   sdhc_pci_acpi_power_on(sc, sc->sc_node);
+   sdhc_pci_acpi_explore(sc);
+   }
+#endif
/* Enable use of DMA if supported by the interface. */
usedma = PCI_INTERFACE(pa->pa_class) == SDHC_PCI_INTERFACE_DMA;
sc->sc.sc_dmat = pa->pa_dmat;
@@ -257,3 +296,123 @@ sdhc_pci_conf_write(pci_chipset_tag_t pc
tmp |= (val << ((reg & 0x3) * 8));
pci_conf_write(pc, tag, reg & ~0x3, tmp);
 }
+#if NACPI > 0
+int
+sdhc_pci_card_detect_nonremovable(struct sdhc_softc *sc)
+{
+   return 1;
+}
+
+int
+sdhc_pci_card_detect_gpio(struct sdhc_softc *ssc)
+{
+   struct sdhc_pci_softc *sc = (struct sdhc_pci_softc *)ssc;
+   struct acpi_gpio *gpio = sc->sc_gpio_io_node->gpio;
+   uint16_t pin = sc->sc_gpio_io_pin;
+
+   /* Card detect GPIO signal is active-low. */
+   return !gpio->read_pin(gpio->cookie, pin);
+}
+
+int
+sdhc_pci_card_detect_intr(void *arg)
+{
+   struct sdhc_pci_softc *sc = arg;
+
+   sdhc_needs_discover(&sc->sc);
+
+   return 1;
+}
+
+int
+sdhc_pci_acpi_parse_resources(int crsidx, union acpi_resource *crs, void *arg)
+{
+   struct sdhc_pci_softc *sc = arg;
+   int type = AML_CRSTYPE(crs);
+   struct aml_node *node;
+   uint16_t pin;
+
+   switch (type) {
+   case LR_GPIO:
+   node = aml_searchname(sc->sc_node, (char 
*)&crs->pad[crs->lr_gpio.res_off]);
+   pin = *(uint16_t *)&crs->pad[crs->lr_gpio.pin_off];
+   if (crs->lr_gpio.type == LR_GPIO_INT) {
+   sc->sc_gpio_int_node = node;
+   sc->sc_gpio_int_pin = pin;
+   sc->sc_gpio_int_flags = crs->lr_gpio.tflags;
+   } else if (crs->lr_gpio.type == LR_GPIO_IO) {
+   sc->sc_gpio_io_node = node;
+   sc->sc_gpio_io_pin = pin;
+   }
+   }
+
+   return 0;
+}
+
+void
+sdhc_pci_acpi_get_resources(struct sdhc_pci_softc *sc)
+{
+   struct aml_value res;
+
+   aml_evalname(sc->sc_acpi, sc->sc_node, "_CRS", 0, NULL, &res);
+   aml_parse_resource(&res, sdhc_pci_acpi_parse_resources, sc);
+
+   if (sc->sc_gpio_io_node && sc->sc_gpio_io_node->gpio)
+   sc->sc.sc_card_detect = sdhc_pci_card_detect_gpio;
+
+   if (sc->sc_gpio_int_node && sc->sc_gpio_int_node->gpio) {
+   struct acpi_gpio *gpio = sc->sc_gpio_int_node->gpio;
+   gpio->intr_establish(gpio->cookie, sc->sc_gpio_int_pin,
+   sc->sc_gpio_int_flags, sdhc_pci_card_detect_intr, sc);
+   }
+}
+
+void
+sdhc_pci_acpi_power_on(struct sdhc_pci_softc *sc, struct aml_node *node)
+{
+   node = aml_searchname(node, "_PS0");
+   if (node && aml_evalnode(sc->sc_acpi, node, 0, NULL, NULL))
+   printf("%s: _PS0 failed\n", sc->sc.sc_dev.dv_xname);
+}
+
+int
+sdhc_pci_acpi_do_explore(struct aml_node *node, void *a

apollo lake gpio

[James Hastings]

Index: share/man/man4/Makefile
===
RCS file: /cvs/src/share/man/man4/Makefile,v
retrieving revision 1.713
diff -u -p -u -r1.713 Makefile
--- share/man/man4/Makefile 7 Jun 2019 16:06:59 -   1.713
+++ share/man/man4/Makefile 11 Jun 2019 01:31:02 -
@@ -10,7 +10,7 @@ MAN=  aac.4 abcrtc.4 ac97.4 acphy.4 acrtc
admtm.4 admtmp.4 admtt.4 adt.4 adtfsm.4 adv.4 age.4 alc.4 ale.4 agp.4 \
ahc.4 ahci.4 ahd.4 aibs.4 aic.4 \
akbd.4 alipm.4 amas.4 amdiic.4 amdpm.4 ami.4 amphy.4 \
-   ams.4 an.4 andl.4 aps.4 arc.4 arcofi.4 \
+   ams.4 an.4 andl.4 aplgpio.4 aps.4 arc.4 arcofi.4 \
asbtm.4 asmc.4 ast.4 atapiscsi.4 atphy.4 ath.4 athn.4 atu.4 atw.4 \
auacer.4 audio.4 aue.4 auglx.4 auich.4 auixp.4 autri.4 auvia.4 \
axe.4 axen.4 axppmic.4 azalia.4 \
Index: share/man/man4/acpi.4
===
RCS file: /cvs/src/share/man/man4/acpi.4,v
retrieving revision 1.57
diff -u -p -u -r1.57 acpi.4
--- share/man/man4/acpi.4   23 Apr 2019 20:23:36 -  1.57
+++ share/man/man4/acpi.4   11 Jun 2019 01:31:02 -
@@ -90,6 +90,8 @@ ACPI video
 ACPI video output
 .It Xr aibs 4
 ASUSTeK AI Booster ACPI ATK0110 temperature, voltage, and fan sensor
+.It Xr aplgpio 4
+Intel Apollo Lake GPIO controller
 .It Xr bytgpio 4
 Intel Bay Trail GPIO controller
 .It Xr ccp 4
Index: share/man/man4/aplgpio.4
===
RCS file: share/man/man4/aplgpio.4
diff -N share/man/man4/aplgpio.4
--- /dev/null   1 Jan 1970 00:00:00 -
+++ share/man/man4/aplgpio.411 Jun 2019 01:31:02 -
@@ -0,0 +1,49 @@
+.\"
+.\" Copyright (c) 2019 James Hastings
+.\"
+.\" 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 APLGPIO 4
+.Os
+.Sh NAME
+.Nm aplgpio
+.Nd Intel Apollo Lake GPIO controller
+.Sh SYNOPSIS
+.Cd "aplgpio* at acpi?"
+.Sh DESCRIPTION
+The
+.Nm
+driver provides support for the GPIO controllers found on Intel's Apollo 
+Lake SoC.
+It does not provide direct device driver entry points but makes its
+functions available to
+.Xr acpi 4 .
+.Sh SEE ALSO
+.Xr acpi 4 ,
+.Xr intro 4
+.Sh HISTORY
+The
+.Nm
+driver first appeared in
+.Ox 6.6 .
+.Sh AUTHORS
+.An -nosplit
+The
+.Nm
+driver was written by
+.An James Hastings
+based on the
+.Xr bytgpio 4
+driver by
+.An Mark Kettenis Aq Mt kette...@openbsd.org .
Index: sys/arch/amd64/conf/GENERIC
===
RCS file: /cvs/src/sys/arch/amd64/conf/GENERIC,v
retrieving revision 1.473
diff -u -p -u -r1.473 GENERIC
--- sys/arch/amd64/conf/GENERIC 7 Jun 2019 16:06:59 -   1.473
+++ sys/arch/amd64/conf/GENERIC 11 Jun 2019 01:31:02 -
@@ -61,6 +61,7 @@ acpivideo*at acpi?
 acpivout*  at acpivideo?
 acpipwrres*at acpi?
 aibs*  at acpi?
+aplgpio*   at acpi?
 bytgpio*   at acpi?
 chvgpio*   at acpi?
 sdhc*  at acpi?
Index: sys/arch/amd64/conf/RAMDISK_CD
===
RCS file: /cvs/src/sys/arch/amd64/conf/RAMDISK_CD,v
retrieving revision 1.179
diff -u -p -u -r1.179 RAMDISK_CD
--- sys/arch/amd64/conf/RAMDISK_CD  4 May 2019 17:59:40 -   1.179
+++ sys/arch/amd64/conf/RAMDISK_CD  11 Jun 2019 01:31:02 -
@@ -42,6 +42,7 @@ acpiec*   at acpi?
 acpiprt*   at acpi?
 acpimadt0  at acpi?
 #acpitz*   at acpi?
+aplgpio*   at acpi?
 bytgpio*   at acpi?
 sdhc*  at acpi?
 acpihve*   at acpi?
Index: sys/dev/acpi/aplgpio.c
===
RCS file: sys/dev/acpi/aplgpio.c
diff -N sys/dev/acpi/aplgpio.c
--- /dev/null   1 Jan 1970 00:00:00 -
+++ sys/dev/acpi/aplgpio.c  11 Jun 2019 01:31:03 -
@@ -0,0 +1,303 @@
+/*
+ * Copyright (c) 2016 Mark Kettenis
+ * Copyright (c) 2019 James Hastings
+ *
+ * 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 SOFTWAR