date:20190219

Re: Executing rc.d on rdomain != 0

2019-02-19 Thread YASUOKA Masahiko

On Tue, 19 Feb 2019 22:33:53 -0700
"Theo de Raadt"  wrote:
> I think that's really gross.
> 
> route domains are a concept usable by some people, not everyone should
> need to see this.

Ah, may be yes.  I am using sshd on routing domain other than 0, but
actually I'll add "RDomain 0" to sshd_config for keeping rdomain 0 for
shells logged in, to avoid this kind of confusion.


>> I think rc.d should specify the routing domain explicitly when it
>> executes the daemon program even if the daemon's rtable is configured
>> 0 since the executed routing domain may not be 0.
>> 
>> Exmaple:
>> 
>>   (run sshd on rtable 100)
>>   $ doas ifconfig lo100 rdomain 100 127.0.0.1/8
>>   $ doas ln -s sshd /etc/rc.d/sshd100 
>>   $ doas rcctl enable sshd100
>>   $ doas rcctl set sshd100 rtable 100
>>   $ doas rcctl start sshd100
>> 
>>   (ssh login from rdomain 100)
>>   $ route -T100 exec ssh 127.0.0.1
>> 
>>   (logged in, default routing domain becomes 100)
>>   $ doas rcctl get ntpd rtable
>>   0
>>   $ doas rcctl restart ntpd
>>   ntpd(ok)
>>   ntpd(ok)
>> 
>>   $ doas /etc/rc.d/ntpd check
>>   ntpd(failed)
>>   $ ps ax -o 'pid comm rtable' | grep ntpd
>>   26036 ntpd100
>>2924 ntpd100
>>   78901 ntpd100
>>   $
>> 
>> "check" fails because /var/run/rc.d/ntpd rtable is 0, but it is
>> actually running on 100.
>> 
>> ok?
>> 
>> Execute the daemon program on the configured routing table always even
>> if its rtable is configured 0 and rc.d is executed on a routing domain
>> other than 0.
>> 
>> Index: etc/rc.d/rc.subr
>> ===
>> RCS file: /cvs/src/etc/rc.d/rc.subr,v
>> retrieving revision 1.130
>> diff -u -p -r1.130 rc.subr
>> --- etc/rc.d/rc.subr 20 Jan 2019 04:52:07 -  1.130
>> +++ etc/rc.d/rc.subr 20 Feb 2019 03:57:37 -
>> @@ -320,5 +320,4 @@ unset _rcflags _rcrtable _rcuser _rctime
>>  # make sure pexp matches the process (i.e. doesn't include the quotes)
>>  pexp="$(eval echo ${daemon}${daemon_flags:+ ${daemon_flags}})"
>>  rcexec="su -l -c ${daemon_class} -s /bin/sh ${daemon_user} -c"
>> -[ "${daemon_rtable}" -eq 0 ] ||
>> -rcexec="route -T ${daemon_rtable} exec ${rcexec}"
>> +rcexec="route -T ${daemon_rtable} exec ${rcexec}"
>>

Re: Executing rc.d on rdomain != 0

2019-02-19 Thread Theo de Raadt

I think that's really gross.

route domains are a concept usable by some people, not everyone should
need to see this.

> I think rc.d should specify the routing domain explicitly when it
> executes the daemon program even if the daemon's rtable is configured
> 0 since the executed routing domain may not be 0.
> 
> Exmaple:
> 
>   (run sshd on rtable 100)
>   $ doas ifconfig lo100 rdomain 100 127.0.0.1/8
>   $ doas ln -s sshd /etc/rc.d/sshd100 
>   $ doas rcctl enable sshd100
>   $ doas rcctl set sshd100 rtable 100
>   $ doas rcctl start sshd100
> 
>   (ssh login from rdomain 100)
>   $ route -T100 exec ssh 127.0.0.1
> 
>   (logged in, default routing domain becomes 100)
>   $ doas rcctl get ntpd rtable
>   0
>   $ doas rcctl restart ntpd
>   ntpd(ok)
>   ntpd(ok)
> 
>   $ doas /etc/rc.d/ntpd check
>   ntpd(failed)
>   $ ps ax -o 'pid comm rtable' | grep ntpd
>   26036 ntpd100
>2924 ntpd100
>   78901 ntpd100
>   $
> 
> "check" fails because /var/run/rc.d/ntpd rtable is 0, but it is
> actually running on 100.
> 
> ok?
> 
> Execute the daemon program on the configured routing table always even
> if its rtable is configured 0 and rc.d is executed on a routing domain
> other than 0.
> 
> Index: etc/rc.d/rc.subr
> ===
> RCS file: /cvs/src/etc/rc.d/rc.subr,v
> retrieving revision 1.130
> diff -u -p -r1.130 rc.subr
> --- etc/rc.d/rc.subr  20 Jan 2019 04:52:07 -  1.130
> +++ etc/rc.d/rc.subr  20 Feb 2019 03:57:37 -
> @@ -320,5 +320,4 @@ unset _rcflags _rcrtable _rcuser _rctime
>  # make sure pexp matches the process (i.e. doesn't include the quotes)
>  pexp="$(eval echo ${daemon}${daemon_flags:+ ${daemon_flags}})"
>  rcexec="su -l -c ${daemon_class} -s /bin/sh ${daemon_user} -c"
> -[ "${daemon_rtable}" -eq 0 ] ||
> - rcexec="route -T ${daemon_rtable} exec ${rcexec}"
> +rcexec="route -T ${daemon_rtable} exec ${rcexec}"
>

Executing rc.d on rdomain != 0

2019-02-19 Thread YASUOKA Masahiko

Hi!

I think rc.d should specify the routing domain explicitly when it
executes the daemon program even if the daemon's rtable is configured
0 since the executed routing domain may not be 0.

Exmaple:

  (run sshd on rtable 100)
  $ doas ifconfig lo100 rdomain 100 127.0.0.1/8
  $ doas ln -s sshd /etc/rc.d/sshd100 
  $ doas rcctl enable sshd100
  $ doas rcctl set sshd100 rtable 100
  $ doas rcctl start sshd100

  (ssh login from rdomain 100)
  $ route -T100 exec ssh 127.0.0.1

  (logged in, default routing domain becomes 100)
  $ doas rcctl get ntpd rtable
  0
  $ doas rcctl restart ntpd
  ntpd(ok)
  ntpd(ok)

  $ doas /etc/rc.d/ntpd check
  ntpd(failed)
  $ ps ax -o 'pid comm rtable' | grep ntpd
  26036 ntpd100
   2924 ntpd100
  78901 ntpd100
  $

"check" fails because /var/run/rc.d/ntpd rtable is 0, but it is
actually running on 100.

ok?

Execute the daemon program on the configured routing table always even
if its rtable is configured 0 and rc.d is executed on a routing domain
other than 0.

Index: etc/rc.d/rc.subr
===
RCS file: /cvs/src/etc/rc.d/rc.subr,v
retrieving revision 1.130
diff -u -p -r1.130 rc.subr
--- etc/rc.d/rc.subr20 Jan 2019 04:52:07 -  1.130
+++ etc/rc.d/rc.subr20 Feb 2019 03:57:37 -
@@ -320,5 +320,4 @@ unset _rcflags _rcrtable _rcuser _rctime
 # make sure pexp matches the process (i.e. doesn't include the quotes)
 pexp="$(eval echo ${daemon}${daemon_flags:+ ${daemon_flags}})"
 rcexec="su -l -c ${daemon_class} -s /bin/sh ${daemon_user} -c"
-[ "${daemon_rtable}" -eq 0 ] ||
-   rcexec="route -T ${daemon_rtable} exec ${rcexec}"
+rcexec="route -T ${daemon_rtable} exec ${rcexec}"

Re: ioctls for MPLS pseudowire interface config

2019-02-19 Thread David Gwynne

jsg@ pointed out that stsp sniped the ioctl numbers i was using.

this diff moves them into 220-212.

On Wed, Feb 20, 2019 at 01:33:00PM +1000, David Gwynne wrote:
> This splits up the mpw config ioctl so the same functionality is
> implemented in a bunch of smaller and more specific ioctls. This
> simplifies configuration of an interface cos you can incrementally
> configure it instead of having to line up all the bits correctly for the
> jumbo ioctl.
> 
> It also allows extra functionality to be added incrementally in the
> future. For example, this adds the ability to configure Flow-Aware
> Transport for mpw via the SIOCSPWE3FAT and SIOCGPWE3FAT ioctls.
> 
> Another benefit is that this shrinks ifconfig output. Currently ifconfig
> mpw0 looks like this:
> 
> mpw0: flags=8843 mtu 1500
> lladdr fe:e1:ba:d0:93:1a
> index 10 priority 0 llprio 3
> encapsulation-type ethernet, control-word
> mpls label: local 16 remote 16
> neighbor: 192.168.0.27
> groups: mpw
> inet 100.64.100.2 netmask 0xff00 broadcast 100.64.100.255
> 
> After this I can make it look like this:
> 
> mpw0: flags=8843 mtu 1500
> lladdr fe:e1:ba:d0:93:1a
> index 10 priority 0 llprio 3
> mpls: label 16 pwe3 remote label 16 on 192.168.0.27 cw nofat
> groups: mpw
> inet 100.64.100.2 netmask 0xff00 broadcast 100.64.100.255
> 
> The ifconfig bits aren't built when SMALL, so this doesn't impact
> install media.
> 
> Lastly, this let's the PWE3 ioctls run without locks. Gotta start
> somewhere right?
> 
> As discussed with claudio@ at a2k19, I have written a driver for an IP
> pseudowire interface called mpip(4). It uses these same ioctls for it's
> configuration.
> 
> ok?

Index: sys/sys/sockio.h
===
RCS file: /cvs/src/sys/sys/sockio.h,v
retrieving revision 1.79
diff -u -p -r1.79 sockio.h
--- sys/sys/sockio.h23 Jan 2019 08:23:18 -  1.79
+++ sys/sys/sockio.h20 Feb 2019 04:35:42 -
@@ -143,6 +143,7 @@
 #defineSIOCSSARAMS  _IOW('i', 147, struct ifreq)   /* set pppoe 
params */
 #defineSIOCGSARAMS _IOWR('i', 148, struct ifreq)   /* get pppoe 
params */
 
+#define SIOCDELLABEL_IOW('i', 151, struct ifreq)   /* del MPLS label */
 #define SIOCGPWE3   _IOWR('i', 152, struct ifreq)  /* get MPLS PWE3 cap */
 #define SIOCSETLABEL_IOW('i', 153, struct ifreq)   /* set MPLS label */
 #define SIOCGETLABEL_IOW('i', 154, struct ifreq)   /* get MPLS label */
@@ -204,6 +205,14 @@
 
 #defineSIOCSLIFPHYECN  _IOW('i', 199, struct ifreq)/* set ecn 
copying */
 #defineSIOCGLIFPHYECN  _IOWR('i', 200, struct ifreq)   /* get ecn 
copying */
+
+#define SIOCSPWE3CTRLWORD  _IOW('i', 220, struct ifreq)
+#define SIOCGPWE3CTRLWORD  _IOWR('i',  220, struct ifreq)
+#define SIOCSPWE3FAT   _IOW('i', 221, struct ifreq)
+#define SIOCGPWE3FAT   _IOWR('i', 221, struct ifreq)
+#define SIOCSPWE3NEIGHBOR  _IOW('i', 222, struct if_laddrreq)
+#define SIOCGPWE3NEIGHBOR  _IOWR('i', 222, struct if_laddrreq)
+#define SIOCDPWE3NEIGHBOR  _IOW('i', 222, struct ifreq)
 
 #defineSIOCSVH _IOWR('i', 245, struct ifreq)   /* set carp 
param */
 #defineSIOCGVH _IOWR('i', 246, struct ifreq)   /* get carp 
param */
Index: sys/net/if.c
===
RCS file: /cvs/src/sys/net/if.c,v
retrieving revision 1.571
diff -u -p -r1.571 if.c
--- sys/net/if.c9 Jan 2019 01:14:21 -   1.571
+++ sys/net/if.c20 Feb 2019 04:35:42 -
@@ -2143,6 +2143,25 @@ ifioctl(struct socket *so, u_long cmd, c
NET_UNLOCK();
break;
 
+   case SIOCSETMPWCFG:
+   case SIOCSPWE3CTRLWORD:
+   case SIOCSPWE3FAT:
+   case SIOCSPWE3NEIGHBOR:
+   case SIOCDPWE3NEIGHBOR:
+   if ((error = suser(p)) != 0)
+   break;
+   /* FALLTHROUGH */
+   case SIOCGETMPWCFG:
+   case SIOCGPWE3CTRLWORD:
+   case SIOCGPWE3FAT:
+   case SIOCGPWE3NEIGHBOR:
+   if_ref(ifp);
+   KERNEL_UNLOCK();
+   error = ((*ifp->if_ioctl)(ifp, cmd, data));
+   KERNEL_LOCK();
+   if_put(ifp);
+   break;
+
case SIOCSETKALIVE:
case SIOCDIFPHYADDR:
case SIOCSLIFPHYADDR:
Index: sys/net/if_mpw.c
===
RCS file: /cvs/src/sys/net/if_mpw.c,v
retrieving revision 1.44
diff -u -p -r1.44 if_mpw.c
--- sys/net/if_mpw.c20 Feb 2019 01:04:53 -  1.44
+++ sys/net/if_mpw.c20 Feb 2019 04:35:42 -
@@ -44,6 +44,11 @@
 #include 
 #endif
 
+struct mpw_neighbor {
+   struct shim_hdr n_rshim;
+   struct sockaddr_storage n_nexthop;
+};
+
 struct mpw_softc {
struct arpcom   sc_ac;
 #define sc_if

ioctls for MPLS pseudowire interface config

2019-02-19 Thread David Gwynne

This splits up the mpw config ioctl so the same functionality is
implemented in a bunch of smaller and more specific ioctls. This
simplifies configuration of an interface cos you can incrementally
configure it instead of having to line up all the bits correctly for the
jumbo ioctl.

It also allows extra functionality to be added incrementally in the
future. For example, this adds the ability to configure Flow-Aware
Transport for mpw via the SIOCSPWE3FAT and SIOCGPWE3FAT ioctls.

Another benefit is that this shrinks ifconfig output. Currently ifconfig
mpw0 looks like this:

mpw0: flags=8843 mtu 1500
lladdr fe:e1:ba:d0:93:1a
index 10 priority 0 llprio 3
encapsulation-type ethernet, control-word
mpls label: local 16 remote 16
neighbor: 192.168.0.27
groups: mpw
inet 100.64.100.2 netmask 0xff00 broadcast 100.64.100.255

After this I can make it look like this:

mpw0: flags=8843 mtu 1500
lladdr fe:e1:ba:d0:93:1a
index 10 priority 0 llprio 3
mpls: label 16 pwe3 remote label 16 on 192.168.0.27 cw nofat
groups: mpw
inet 100.64.100.2 netmask 0xff00 broadcast 100.64.100.255

The ifconfig bits aren't built when SMALL, so this doesn't impact
install media.

Lastly, this let's the PWE3 ioctls run without locks. Gotta start
somewhere right?

As discussed with claudio@ at a2k19, I have written a driver for an IP
pseudowire interface called mpip(4). It uses these same ioctls for it's
configuration.

ok?

Index: sys/sys/sockio.h
===
RCS file: /cvs/src/sys/sys/sockio.h,v
retrieving revision 1.79
diff -u -p -r1.79 sockio.h
--- sys/sys/sockio.h23 Jan 2019 08:23:18 -  1.79
+++ sys/sys/sockio.h20 Feb 2019 03:29:05 -
@@ -143,6 +143,7 @@
 #defineSIOCSSARAMS  _IOW('i', 147, struct ifreq)   /* set pppoe 
params */
 #defineSIOCGSARAMS _IOWR('i', 148, struct ifreq)   /* get pppoe 
params */
 
+#define SIOCDELLABEL_IOW('i', 151, struct ifreq)   /* del MPLS label */
 #define SIOCGPWE3   _IOWR('i', 152, struct ifreq)  /* get MPLS PWE3 cap */
 #define SIOCSETLABEL_IOW('i', 153, struct ifreq)   /* set MPLS label */
 #define SIOCGETLABEL_IOW('i', 154, struct ifreq)   /* get MPLS label */
@@ -204,6 +205,14 @@
 
 #defineSIOCSLIFPHYECN  _IOW('i', 199, struct ifreq)/* set ecn 
copying */
 #defineSIOCGLIFPHYECN  _IOWR('i', 200, struct ifreq)   /* get ecn 
copying */
+
+#define SIOCSPWE3CTRLWORD  _IOW('i', 210, struct ifreq)
+#define SIOCGPWE3CTRLWORD  _IOWR('i', 210, struct ifreq)
+#define SIOCSPWE3FAT   _IOW('i', 211, struct ifreq)
+#define SIOCGPWE3FAT   _IOWR('i', 211, struct ifreq)
+#define SIOCSPWE3NEIGHBOR  _IOW('i', 212, struct if_laddrreq)
+#define SIOCGPWE3NEIGHBOR  _IOWR('i', 212, struct if_laddrreq)
+#define SIOCDPWE3NEIGHBOR  _IOW('i', 212, struct ifreq)
 
 #defineSIOCSVH _IOWR('i', 245, struct ifreq)   /* set carp 
param */
 #defineSIOCGVH _IOWR('i', 246, struct ifreq)   /* get carp 
param */
Index: sys/net/if.c
===
RCS file: /cvs/src/sys/net/if.c,v
retrieving revision 1.571
diff -u -p -r1.571 if.c
--- sys/net/if.c9 Jan 2019 01:14:21 -   1.571
+++ sys/net/if.c20 Feb 2019 03:29:05 -
@@ -2143,6 +2143,25 @@ ifioctl(struct socket *so, u_long cmd, c
NET_UNLOCK();
break;
 
+   case SIOCSETMPWCFG:
+   case SIOCSPWE3CTRLWORD:
+   case SIOCSPWE3FAT:
+   case SIOCSPWE3NEIGHBOR:
+   case SIOCDPWE3NEIGHBOR:
+   if ((error = suser(p)) != 0)
+   break;
+   /* FALLTHROUGH */
+   case SIOCGETMPWCFG:
+   case SIOCGPWE3CTRLWORD:
+   case SIOCGPWE3FAT:
+   case SIOCGPWE3NEIGHBOR:
+   if_ref(ifp);
+   KERNEL_UNLOCK();
+   error = ((*ifp->if_ioctl)(ifp, cmd, data));
+   KERNEL_LOCK();
+   if_put(ifp);
+   break;
+
case SIOCSETKALIVE:
case SIOCDIFPHYADDR:
case SIOCSLIFPHYADDR:
Index: sys/net/if_mpw.c
===
RCS file: /cvs/src/sys/net/if_mpw.c,v
retrieving revision 1.44
diff -u -p -r1.44 if_mpw.c
--- sys/net/if_mpw.c20 Feb 2019 01:04:53 -  1.44
+++ sys/net/if_mpw.c20 Feb 2019 03:29:05 -
@@ -44,6 +44,11 @@
 #include 
 #endif
 
+struct mpw_neighbor {
+   struct shim_hdr n_rshim;
+   struct sockaddr_storage n_nexthop;
+};
+
 struct mpw_softc {
struct arpcom   sc_ac;
 #define sc_if  sc_ac.ac_if
@@ -56,8 +61,7 @@ struct mpw_softc {
unsigned intsc_fword;
uint32_tsc_flow;
uint32_tsc_type;
-   struct shim_hdr sc_rshim;
-   struct sockaddr_storage

Re: strptime: %e and leading space

2019-02-19 Thread Klemens Nanni

On Sun, Feb 17, 2019 at 08:45:18PM -0500, Ted Unangst wrote:
> However, later it adds:
> Several "equivalent to" formats and the special processing of white-space
> characters are provided in order to ease the use of identical format strings
> for strftime() and strptime().
Well, that sounds like just enough to support what I'm heading for.

> I think this sounds like a reasonable change, but austin bugs may be another
> place to bring it up. They maybe intended for %e to consume a space, but my
> reading of the text is that they forgot to actually say so.
I'm not that familiar with standards compliance; if appropiate, maybe
someone with an account on http://austingroupbugs.net/main_page.php can
help me here?

> I do believe it should be possible to round trip data through these functions
> with the same format string.
Agreed.

Looking at postfix's source to see how the string net/isync consumes is
generated, the following seems to justify my diff even further:

$ grep -FC5 MISSING_STRFTIME_E postfix-3.3.2/global/mail_date.c
/*
 * First, format the date and wall-clock time. XXX The %e format 
(day of
 * month, leading zero replaced by blank) isn't in my POSIX book, 
but
 * many vendors seem to support it.
 */
#ifdef MISSING_STRFTIME_E
#define STRFTIME_FMT "%a, %d %b %Y %H:%M:%S "
#else
#define STRFTIME_FMT "%a, %e %b %Y %H:%M:%S "
#endif

Given this feedback and the fact that the majority of implementations
already behave that way:  any OKs or objections for my diff?

Re: bgpd use long long instead of int64_t

2019-02-19 Thread Otto Moerbeek

On Tue, Feb 19, 2019 at 09:28:36AM +0100, Claudio Jeker wrote:

> On Tue, Feb 19, 2019 at 12:10:25AM +0100, Andreas Kusalananda Kähäri wrote:
> > On Mon, Feb 18, 2019 at 10:11:03PM +0100, Mark Kettenis wrote:
> > > > Date: Mon, 18 Feb 2019 21:59:38 +0100
> > > > From: Claudio Jeker 
> > > > 
> > > > In some places bgpd just wants something bigger then a 32bit int.
> > > > Instead of using int64_t or u_int64_t use (unsigned) long long which is 
> > > > at
> > > > least 64bit and therefor good enough. Makes the mess with type 
> > > > definition
> > > > of int64_t on various systems go away (including a bunch of type casts).
> > > > While there also apply the endian.h cleanup done in bgpd a few days ago.
> > > > 
> > > > OK?
> > > 
> > > You could use  and uint64_t instead.  That should be
> > > portable.  But you'd still need to be careful about printf statements
> > > since (u)int64_t might be (unsigned) long on some systems.
> > 
> > printf should be no issue if you use the correct PRI*64 (PRIu64 or
> > PRId64) macro from .  Both  and  are
> > C99.
> > 
> > E.g.
> > 
> > uint64_t thing;
> > 
> > /* ... */
> > 
> > printf("The value is %" PRIu64 "\n", thing);
> > 
> > 
> > ... but I'm really not qualified to say anything about what you guys should 
> > do.
> > 
> 
> While true I have to say that the PRI constructs are even worse than doing
> casts. Chopping up the format string like this is just ugly and unreadable
> for complex format strings.

Yes, and the only other alternative I can think of: (u)intmax_t and
%jd or %ju is not very attractive either.

-Otto

ix transmit code doesn't need atomic ops

2019-02-19 Thread David Gwynne

mpi's recent post about vlan performance which happened to use ix
reminded me that i had some diffz for ix that may be relevant to
the discussion.

this uses the loads and stores of the produce and consumer indexes
to calculate free space in the start path and for figuring out how
much space to reclaim in txeof. this is instead coordining with an
actual "available slots" counter using atomic ops.

it also avoids doing a bunch of work in the txeof path. instead of
putting the mbuf on the last descriptor for a packet, we leave it on the
first and use the index to the last to poll for packet completion. this
means we can leave the mbuf and dmamap in the first slot, which
simplifies the encap code. by only reading the last descriptor from the
ring, we are no longer scrubbing entries like we used to, but this
doesnt seem be a problem in practice.

anyway, i think the big cost when transmitting is writing to the
register at the end of the loop. we effectively call start for every
packet, which means we post each packet to the chip. this is why
tx mitigation helps; it reduces the number of register writes.

dlg

Index: if_ix.c
===
RCS file: /cvs/src/sys/dev/pci/if_ix.c,v
retrieving revision 1.152
diff -u -p -r1.152 if_ix.c
--- if_ix.c 22 Jun 2017 02:44:37 -  1.152
+++ if_ix.c 19 Feb 2019 11:36:43 -
@@ -385,6 +385,7 @@ ixgbe_start(struct ifqueue *ifq)
struct ix_softc *sc = ifp->if_softc;
struct tx_ring  *txr = sc->tx_rings;
struct mbuf *m_head;
+   unsigned int head, free, used;
int  post = 0;
 
if (!(ifp->if_flags & IFF_RUNNING) || ifq_is_oactive(ifq))
@@ -392,13 +393,21 @@ ixgbe_start(struct ifqueue *ifq)
if (!sc->link_up)
return;
 
-   bus_dmamap_sync(txr->txdma.dma_tag, txr->txdma.dma_map, 0,
-   txr->txdma.dma_map->dm_mapsize,
-   BUS_DMASYNC_POSTREAD | BUS_DMASYNC_POSTWRITE);
+   head = txr->next_avail_desc;
+   free = txr->next_to_clean;
+   if (free <= head)
+   free += sc->num_tx_desc;
+   free -= head;
+
+   membar_consumer();
+
+   bus_dmamap_sync(txr->txdma.dma_tag, txr->txdma.dma_map,
+   0, txr->txdma.dma_map->dm_mapsize,
+   BUS_DMASYNC_POSTWRITE);
 
for (;;) {
/* Check that we have the minimal number of TX descriptors. */
-   if (txr->tx_avail <= IXGBE_TX_OP_THRESHOLD) {
+   if (free <= IXGBE_TX_OP_THRESHOLD) {
ifq_set_oactive(ifq);
break;
}
@@ -407,11 +416,14 @@ ixgbe_start(struct ifqueue *ifq)
if (m_head == NULL)
break;
 
-   if (ixgbe_encap(txr, m_head)) {
+   used = ixgbe_encap(txr, m_head);
+   if (used == 0) {
m_freem(m_head);
continue;
}
 
+   free -= used;
+
 #if NBPFILTER > 0
if (ifp->if_bpf)
bpf_mtap_ether(ifp->if_bpf, m_head, BPF_DIRECTION_OUT);
@@ -426,7 +438,7 @@ ixgbe_start(struct ifqueue *ifq)
 
bus_dmamap_sync(txr->txdma.dma_tag, txr->txdma.dma_map,
0, txr->txdma.dma_map->dm_mapsize,
-   BUS_DMASYNC_PREREAD | BUS_DMASYNC_PREWRITE);
+   BUS_DMASYNC_PREWRITE);
 
/*
 * Advance the Transmit Descriptor Tail (Tdt), this tells the
@@ -579,8 +591,8 @@ ixgbe_watchdog(struct ifnet * ifp)
printf("%s: Queue(%d) tdh = %d, hw tdt = %d\n", ifp->if_xname, 
i,
IXGBE_READ_REG(hw, IXGBE_TDH(i)),
IXGBE_READ_REG(hw, IXGBE_TDT(i)));
-   printf("%s: TX(%d) desc avail = %d, Next TX to Clean = %d\n", 
ifp->if_xname,
-   i, txr->tx_avail, txr->next_to_clean);
+   printf("%s: TX(%d) Next TX to Clean = %d\n", ifp->if_xname,
+   i, txr->next_to_clean);
}
ifp->if_flags &= ~IFF_RUNNING;
sc->watchdog_events++;
@@ -1150,7 +1162,7 @@ ixgbe_encap(struct tx_ring *txr, struct 
 {
struct ix_softc *sc = txr->sc;
uint32_tolinfo_status = 0, cmd_type_len;
-   int i, j, error;
+   int i, j, ntxc;
int first, last = 0;
bus_dmamap_tmap;
struct ixgbe_tx_buf *txbuf;
@@ -1177,36 +1189,34 @@ ixgbe_encap(struct tx_ring *txr, struct 
/*
 * Map the packet for DMA.
 */
-   error = bus_dmamap_load_mbuf(txr->txdma.dma_tag, map, m_head,
-   BUS_DMA_NOWAIT);
-   switch (error) {
+   switch (bus_dmamap_load_mbuf(txr->txdma.dma_tag, map,
+   m_head, BUS_DMA_NOWAIT)) {
case 0:
break;
case EFBIG:
if (m_defrag(m_head, M_NOWAIT) == 0 &&
-   (error =

Re: httpd(8): add support for FastCGI parameters

2019-02-19 Thread Paul Irofti

On Mon, Feb 18, 2019 at 08:05:14PM +0100, Florian Obser wrote:
> On Mon, Feb 18, 2019 at 12:17:31PM +0200, Paul Irofti wrote:
> > On Sun, Feb 17, 2019 at 11:57:20AM +0100, Florian Obser wrote:
> > > On Tue, Feb 12, 2019 at 05:02:47PM +0200, Paul Irofti wrote:
> > > > Hi,
> > > > 
> > > > This patch adds support for FastCGI parameters.
> > > > Grammar change is very simple.
> > > > 
> > > >   fastcgi param NAME VALUE
> > > > 
> > > > Example:
> > > > %--
> > > > server "default" {
> > > > listen on $ext_addr port 80
> > > > 
> > > > location "/cgi-bin/*" {
> > > > fastcgi socket "/run/slowcgi.sock"
> > > > fastcgi param TEST1 hello
> > > > fastcgi param TEST2 world
> > > > 
> > > > # The /cgi-bin directory is outside of the document root
> > > > root "/"
> > > > }
> > > > }
> > > > %--
> > > > 
> > > > Output:
> > > > %--
> > > > CGI/1.1 test script report:
> > > > 
> > > > GATEWAY_INTERFACE = CGI/1.1
> > > > SERVER_SOFTWARE = OpenBSD httpd
> > > > SERVER_PROTOCOL = HTTP/1.1
> > > > SERVER_NAME = default
> > > > SERVER_ADDR = 127.0.0.1
> > > > SERVER_PORT = 80
> > > > REQUEST_METHOD = GET
> > > > HTTP_ACCEPT =
> > > > text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8
> > > > SCRIPT_NAME = /cgi-bin/testcgi
> > > > REQUEST_URI = /cgi-bin/testcgi
> > > > PATH_INFO = 
> > > > QUERY_STRING = 
> > > > REMOTE_ADDR = 127.0.0.1
> > > > REMOTE_PORT = 28054
> > > > CONTENT_TYPE = 
> > > > CONTENT_LENGTH = 
> > > > TEST1 = hello
> > > > TEST2 = world
> > > > PATH = 
> > > > %--
> > > > 
> > > > Initially discussed with florian@.
> > > > Thoughts? Silly bike-shedding about the grammar? OKs?
> > > > 
> > > > Manual page changes after grammar is OK'ed.
> > > 
> > > I'm mostly OK with it, config_getserver_fcgiparams() needs a bit of
> > > polishing, see inline.
> > 
> > Like this? I did the message length check in two steps as I don't know
> > how long it will be until I read how many items were sent.
> 
> kinda, except you can't do it like this, see inline.

Heh, silly me. Thanks for catching that!

I also added the manual bits in my commit. If you dislike them let me
know and I will change them or go ahead and modify them.

Thanks again for your review!

> 
> > 
> > 
> > Index: config.c
> > ===
> > RCS file: /cvs/src/usr.sbin/httpd/config.c,v
> > retrieving revision 1.55
> > diff -u -p -u -p -r1.55 config.c
> > --- config.c20 Jun 2018 16:43:05 -  1.55
> > +++ config.c18 Feb 2019 10:15:22 -
> > @@ -231,6 +231,9 @@ config_setserver(struct httpd *env, stru
> > __func__, srv->srv_conf.name);
> > return (-1);
> > }
> > +
> > +   /* Configure FCGI parmeters if necessary. */
> > +   config_setserver_fcgiparams(env, srv);
> > }
> > }
> >  
> > @@ -289,6 +292,102 @@ config_settls(struct httpd *env, struct 
> > tls.tls_chunk_offset += tls.tls_chunk_len;
> > data += tls.tls_chunk_len;
> > len -= tls.tls_chunk_len;
> > +   }
> > +
> > +   return (0);
> > +}
> > +
> > +int
> > +config_getserver_fcgiparams(struct httpd *env, struct imsg *imsg)
> > +{
> > +   struct server   *srv;
> > +   struct server_config*srv_conf, *iconf;
> > +   struct fastcgi_param*fp;
> > +   uint32_t id;
> > +   size_t   c, nc, len;
> > +   uint8_t *p = imsg->data;
> > +
> > +   len = sizeof(nc) + sizeof(id);
> > +   if ((IMSG_DATA_SIZE(imsg) - len) < 0) {
> 
> these are all unsigned data types, this is always false
> 
> please write it like this:
>   if (IMSG_DATA_SIZE(imsg) < len) {
> 
> > +   log_debug("%s: invalid message length", __func__);
> > +   return (-1);
> > +   }
> > +
> > +   memcpy(, p, sizeof(nc)); /* number of params */
> > +   p += sizeof(nc);
> > +
> > +   memcpy(, p, sizeof(id)); /* server conf id */
> > +   srv_conf = serverconfig_byid(id);
> > +   p += sizeof(id);
> > +
> > +   len += nc*sizeof(*fp);
> > +   if ((IMSG_DATA_SIZE(imsg) - len) < 0) {
> 
> and here.
> With that fixed OK florian@
> 
> > +   log_debug("%s: invalid message length", __func__);
> > +   return (-1);
> > +   }
> > +
> > +   /* Find associated server config */
> > +   TAILQ_FOREACH(srv, env->sc_servers, srv_entry) {
> > +   if (srv->srv_conf.id == id) {
> > +   srv_conf = >srv_conf;
> > +   break;
> > +   }
> > +

security.html -> patch

2019-02-19 Thread Oleg Pahl


Hi @all,


in an attachment you can find one more patch for *security.html page.

Link:

https://www.openbsd.org/security.html

please confirm.


-Oleg Pahl

Index: security.html
===
RCS file: /cvs/www/security.html,v
retrieving revision 1.438
diff -u -r1.438 security.html
--- security.html    19 Feb 2019 10:17:31 -    1.438
+++ security.html    19 Feb 2019 10:50:37 -
@@ -136,7 +136,7 @@
 have fixed many simple and obvious careless programming errors in code
 and only months later discovered that the problems were in fact
 exploitable.  (Or, more likely someone on
-http://online.securityfocus.com/archive/1;>BUGTRAQ
+https://www.securityfocus.com/archive/1;>BUGTRAQ
 would report that other operating systems were vulnerable to a `newly
 discovered problem', and then it would be discovered that OpenBSD had
 been fixed in a previous release).  In other cases we have been saved
@@ -178,7 +178,7 @@
 Our proactive auditing process has really paid off.  Statements like
 ``This problem was fixed in OpenBSD about 6 months ago'' have become
 commonplace in security forums like
-http://online.securityfocus.com/archive/1;>BUGTRAQ.
+https://www.securityfocus.com/archive/1;>BUGTRAQ.

 The most intense part of our security auditing happened immediately
 before the OpenBSD 2.0 release and during the 2.0-2.1 transition,

Index: security.html
===
RCS file: /cvs/www/security.html,v
retrieving revision 1.438
diff -u -r1.438 security.html
--- security.html   19 Feb 2019 10:17:31 -  1.438
+++ security.html   19 Feb 2019 10:50:37 -
@@ -136,7 +136,7 @@
 have fixed many simple and obvious careless programming errors in code
 and only months later discovered that the problems were in fact
 exploitable.  (Or, more likely someone on
-http://online.securityfocus.com/archive/1;>BUGTRAQ
+https://www.securityfocus.com/archive/1;>BUGTRAQ
 would report that other operating systems were vulnerable to a `newly
 discovered problem', and then it would be discovered that OpenBSD had
 been fixed in a previous release).  In other cases we have been saved
@@ -178,7 +178,7 @@
 Our proactive auditing process has really paid off.  Statements like
 ``This problem was fixed in OpenBSD about 6 months ago'' have become
 commonplace in security forums like
-http://online.securityfocus.com/archive/1;>BUGTRAQ.
+https://www.securityfocus.com/archive/1;>BUGTRAQ.
 
 The most intense part of our security auditing happened immediately
 before the OpenBSD 2.0 release and during the 2.0-2.1 transition,

athn(4): explicit timing of control frames

2019-02-19 Thread Stefan Sperling

Our athn(4) driver currently doesn't configure timing of control
frames generated in hardware. It keeps using whatever magic numbers our
init vals arrays are setting up. With this diff we update the chip with
the same values as used by Linux when configuration changes occur.

I don't notice any difference in my testing. Please run this diff with
PCI and USB devices, watch for regressions, and let me know your results.

diff bb1f4f10a1f3306630a2ce77de0832219fb53582 /usr/src
blob - af5296bfd5ef783a552ca16f283c8b43ea1ff15d
file + sys/dev/ic/athn.c
--- sys/dev/ic/athn.c
+++ sys/dev/ic/athn.c
@@ -136,6 +136,14 @@ intathn_newstate(struct ieee80211com *, 
enum ieee802
int);
 void   athn_updateedca(struct ieee80211com *);
 intathn_clock_rate(struct athn_softc *);
+intathn_chan_sifs(struct ieee80211_channel *);
+void   athn_setsifs(struct athn_softc *);
+intathn_acktimeout(struct ieee80211_channel *, int);
+void   athn_setacktimeout(struct athn_softc *,
+   struct ieee80211_channel *, int);
+void   athn_setctstimeout(struct athn_softc *,
+   struct ieee80211_channel *, int);
+void   athn_setclockrate(struct athn_softc *);
 void   athn_updateslot(struct ieee80211com *);
 void   athn_start(struct ifnet *);
 void   athn_watchdog(struct ifnet *);
@@ -2403,6 +2411,9 @@ athn_hw_reset(struct athn_softc *sc, struct ieee80211_
 
AR_SETBITS(sc, AR_PCU_MISC, AR_PCU_MIC_NEW_LOC_ENA);
 
+   athn_setsifs(sc);
+   athn_updateslot(ic);
+   athn_setclockrate(sc);
if (AR_SREV_9287_13_OR_LATER(sc) && !AR_SREV_9380_10_OR_LATER(sc))
ar9287_1_3_setup_async_fifo(sc);
 
@@ -2713,7 +2724,13 @@ athn_clock_rate(struct athn_softc *sc)
struct ieee80211com *ic = >sc_ic;
int clockrate;  /* MHz. */
 
-   if (ic->ic_bss->ni_chan != IEEE80211_CHAN_ANYC &&
+   /*
+* AR9287 v1.3+ MAC runs at 117MHz (instead of 88/44MHz) when
+* ASYNC FIFO is enabled.
+*/
+   if (AR_SREV_9287_13_OR_LATER(sc) && !AR_SREV_9380_10_OR_LATER(sc))
+   clockrate = 117;
+   else if (ic->ic_bss->ni_chan != IEEE80211_CHAN_ANYC &&
IEEE80211_IS_CHAN_5GHZ(ic->ic_bss->ni_chan)) {
if (sc->flags & ATHN_FLAG_FAST_PLL_CLOCK)
clockrate = AR_CLOCK_RATE_FAST_5GHZ_OFDM;
@@ -2729,7 +2746,70 @@ athn_clock_rate(struct athn_softc *sc)
return (clockrate);
 }
 
+int
+athn_chan_sifs(struct ieee80211_channel *c)
+{
+   return IEEE80211_IS_CHAN_2GHZ(c) ? IEEE80211_DUR_DS_SIFS : 16;
+}
+
 void
+athn_setsifs(struct athn_softc *sc)
+{
+   int sifs = athn_chan_sifs(sc->sc_ic.ic_bss->ni_chan);
+   AR_WRITE(sc, AR_D_GBL_IFS_SIFS, (sifs - 2) * athn_clock_rate(sc));
+   AR_WRITE_BARRIER(sc);
+}
+
+int
+athn_acktimeout(struct ieee80211_channel *c, int slot)
+{
+   int sifs = athn_chan_sifs(c);
+   int ackto = sifs + slot;
+
+   /* Workaround for early ACK timeouts. */
+   if (IEEE80211_IS_CHAN_2GHZ(c))
+   ackto += 64 - sifs - slot;
+
+   return ackto;
+}
+
+void
+athn_setacktimeout(struct athn_softc *sc, struct ieee80211_channel *c, int 
slot)
+{
+   int ackto = athn_acktimeout(c, slot);
+   uint32_t reg = AR_READ(sc, AR_TIME_OUT);
+   reg = RW(reg, AR_TIME_OUT_ACK, ackto * athn_clock_rate(sc));
+   AR_WRITE(sc, AR_TIME_OUT, reg);
+   AR_WRITE_BARRIER(sc);
+}
+
+void
+athn_setctstimeout(struct athn_softc *sc, struct ieee80211_channel *c, int 
slot)
+{
+   int ctsto = athn_acktimeout(c, slot);
+   int sifs = athn_chan_sifs(c);
+   uint32_t reg = AR_READ(sc, AR_TIME_OUT);
+
+   /* Workaround for early CTS timeouts. */
+   if (IEEE80211_IS_CHAN_2GHZ(c))
+   ctsto += 48 - sifs - slot;
+
+   reg = RW(reg, AR_TIME_OUT_CTS, ctsto * athn_clock_rate(sc));
+   AR_WRITE(sc, AR_TIME_OUT, reg);
+   AR_WRITE_BARRIER(sc);
+}
+
+void
+athn_setclockrate(struct athn_softc *sc)
+{
+   int clockrate = athn_clock_rate(sc);
+   uint32_t reg = AR_READ(sc, AR_USEC);
+   reg = RW(reg, AR_USEC_USEC, clockrate - 1);
+   AR_WRITE(sc, AR_USEC, reg);
+   AR_WRITE_BARRIER(sc);
+}
+
+void
 athn_updateslot(struct ieee80211com *ic)
 {
struct athn_softc *sc = ic->ic_softc;
@@ -2739,6 +2819,9 @@ athn_updateslot(struct ieee80211com *ic)
IEEE80211_DUR_DS_SHSLOT : IEEE80211_DUR_DS_SLOT;
AR_WRITE(sc, AR_D_GBL_IFS_SLOT, slot * athn_clock_rate(sc));
AR_WRITE_BARRIER(sc);
+
+   athn_setacktimeout(sc, ic->ic_bss->ni_chan, slot);
+   athn_setctstimeout(sc, ic->ic_bss->ni_chan, slot);
 }
 
 void

Re: athn(4) bpf tap short-preamble fix

2019-02-19 Thread Stefan Sperling

On Fri, Feb 01, 2019 at 03:22:41PM +0100, Stefan Sperling wrote:
> This fixes a cosmetic issue:
> 
> tcpdump -n -i athn0 -y IEEE802_11_RADIO shows a SHORTPRE flag on most frames
> sent from athn0. Even for OFDM frames. Which is bogus because short preamble
> only applies to non-OFDM frames with Tx rates 2, 5.5, and 11 MBit/s.
> 
> This is handled correctly when Tx configuration is provided to hardware
> where we check Tx rate _and_ PHY type. But the PHY type check is missing
> from the bpf tap code path, so add it there as well.

I've just committed this fix.

> Index: ar5008.c
> ===
> RCS file: /cvs/src/sys/dev/ic/ar5008.c,v
> retrieving revision 1.46
> diff -u -p -r1.46 ar5008.c
> --- ar5008.c  28 Nov 2017 04:35:39 -  1.46
> +++ ar5008.c  1 Feb 2019 13:52:55 -
> @@ -1393,7 +1393,8 @@ ar5008_tx(struct athn_softc *sc, struct 
>   tap->wt_chan_freq = htole16(ic->ic_bss->ni_chan->ic_freq);
>   tap->wt_chan_flags = htole16(ic->ic_bss->ni_chan->ic_flags);
>   tap->wt_hwqueue = qid;
> - if (ridx[0] != ATHN_RIDX_CCK1 &&
> + if (athn_rates[ridx[0]].phy == IEEE80211_T_DS &&
> + ridx[0] != ATHN_RIDX_CCK1 &&
>   (ic->ic_flags & IEEE80211_F_SHPREAMBLE))
>   tap->wt_flags |= IEEE80211_RADIOTAP_F_SHORTPRE;
>   mb.m_data = (caddr_t)tap;
> Index: ar9003.c
> ===
> RCS file: /cvs/src/sys/dev/ic/ar9003.c,v
> retrieving revision 1.46
> diff -u -p -r1.46 ar9003.c
> --- ar9003.c  19 May 2017 11:42:48 -  1.46
> +++ ar9003.c  1 Feb 2019 13:54:04 -
> @@ -1482,7 +1482,8 @@ ar9003_tx(struct athn_softc *sc, struct 
>   tap->wt_chan_freq = htole16(ic->ic_bss->ni_chan->ic_freq);
>   tap->wt_chan_flags = htole16(ic->ic_bss->ni_chan->ic_flags);
>   tap->wt_hwqueue = qid;
> - if (ridx[0] != ATHN_RIDX_CCK1 &&
> + if (athn_rates[ridx[0]].phy == IEEE80211_T_DS &&
> + ridx[0] != ATHN_RIDX_CCK1 &&
>   (ic->ic_flags & IEEE80211_F_SHPREAMBLE))
>   tap->wt_flags |= IEEE80211_RADIOTAP_F_SHORTPRE;
>   mb.m_data = (caddr_t)tap;
>

Re: security.html -> broken link

2019-02-19 Thread Raf Czlonka

On Tue, Feb 19, 2019 at 09:49:15AM GMT, Oleg Pahl wrote:
> Hi @all,
> 
> On https://www.openbsd.org/security.html there is a broken link.
> 
> 
>  --->
> 
> 
>  Full Disclosure
> 
> Like many readers of theBUGTRAQ mailing list
> , we believe in full disclosure
> of security problems.
> 
> * http://online.securityfocus.com/archive/1
> 
> <---
> 
> Please check!
> 
> BR,
> 
> Oleg Pahl
> 

Hi Oleg,

You "forgot" the diff ;^)

Cheers,

Raf

Index: security.html
===
RCS file: /cvs/www/security.html,v
retrieving revision 1.437
diff -u -p -r1.437 security.html
--- security.html   18 Oct 2018 12:29:23 -  1.437
+++ security.html   19 Feb 2019 10:13:10 -
@@ -89,7 +89,7 @@ fixing security problems.
 Full Disclosure
 
 Like many readers of the
-http://online.securityfocus.com/archive/1;>
+https://www.securityfocus.com/archive/1;>
 BUGTRAQ mailing list,
 we believe in full disclosure of security problems.  In the
 operating system arena, we were probably the first to embrace

Re: add getrun for rcctl(8)

2019-02-19 Thread YASUOKA Masahiko

Hi,

On Mon, 18 Feb 2019 10:24:51 +
Stuart Henderson  wrote:
> There's a safer way, you can obtain reliable current information about
> the rtable for a process from ps.

Yes.

But what I wanted to do is applying rtable changes by rc.conf to the
daemon if needed.  Running daemon's rtable may be configured by it's
configuration file as well.  For example, if ntpd.conf has "Listen on
* rtable 1" and rc.conf.local doesn't have "ntpd_rtable",

   curr=$(rcctl get ntpd rtable)
   running=$(get rtable from ps)
   if [[ $curr != $running ]]; then
  /etc/rc.d/ntpd restart
   fi

will restart ntpd always.

On this use case, the script needs to know not the actual running
daemon's configuration but the last configuration applied by rcctl(or
rc.d).  I thought that kind of information should be provided through
rcctl(8).

Anyway, I admit the use case is minor and the diff looks too much.
Let me withdraw the diff unless another user appears.

> On 18 February 2019 09:55:55 Antoine Jacoutot 
> wrote:
> 
>> On Mon, Feb 18, 2019 at 11:21:38AM +0900, YASUOKA Masahiko wrote:
>>> Hi,
>>>
>>> On Sun, 17 Feb 2019 10:55:11 +0100
>>> Antoine Jacoutot  wrote:
>>> > On Fri, Feb 15, 2019 at 02:50:22PM +0900, YASUOKA Masahiko wrote:
>>> >> On Fri, 15 Feb 2019 14:45:14 +0900 (JST)
>>> >> YASUOKA Masahiko  wrote:
>>> >> > The diff adds "getrun" command for rcctl(8) which shows the daemon
>>> >> > variables from the running daemon.
>>> >> >
>>> >> > ok? comment?
>>> >>
>>> >> Sorry, previous diff is broken.  It could not get any value other than
>>> >> daemon_pexp.  Let me update the diff.
>>> >
>>> > That's a lot of chunk of code for an enhanced 'cat /var/run/rc.d/foo'.
>>> > What is your usage for this?
>>>
>>> My actual usage is to know whether current "rtable" or "user" is
>>> changed from the values of the running daemon.  If either is changed,
>>> we need to restart the daemon apply that change.
>>>
>>> For example,
>>>
>>>   curr=$(rcctl get ntpd rtable)
>>>   running=$(rcctl getrun ntpd rtable)
>>>   if [[ $curr != $running ]]; then
>>>  /etc/rc.d/ntpd restart
>>>   fi
>>
>> You better of using this I think:
>> running=$(sed -n 's/^daemon_rtable=*//p' /var/run/rc.d/ntpd)
>>
>> What's under /var/run/rc.d/ is only a "hint".
>> If ntpd is manually killed (outside of the rc.d system), the
>> information is not
>> removed from there.
>> That's why I'd like to avoid relying on it too much in rcctl.
>>
>>
>>> >> Index: usr.sbin/rcctl/rcctl.8
>>> >> ===
>>> >> RCS file: /cvs/src/usr.sbin/rcctl/rcctl.8,v
>>> >> retrieving revision 1.35
>>> >> diff -u -p -r1.35 rcctl.8
>>> >> --- usr.sbin/rcctl/rcctl.8   20 Sep 2018 12:24:14 -  1.35
>>> >> +++ usr.sbin/rcctl/rcctl.8   15 Feb 2019 05:48:16 -
>>> >> @@ -22,7 +22,7 @@
>>> >>  .Nd configure and control daemons and services
>>> >>  .Sh SYNOPSIS
>>> >>  .Nm rcctl
>>> >> -.Cm get Ns | Ns Cm getdef Ns | Ns Cm set
>>> >> +.Cm get Ns | Ns Cm getdef Ns | Ns Cm getrun Ns | Ns Cm set
>>> >>  .Ar service | daemon Op Ar variable Op Ar arguments
>>> >>  .Nm rcctl
>>> >>  .Op Fl df
>>> >> @@ -103,6 +103,10 @@ will display all services and daemons va
>>> >>  Like
>>> >>  .Cm get
>>> >>  but returns the default values.
>>> >> +.It Cm getrun Ar service | daemon Op Ar variable
>>> >> +Like
>>> >> +.Cm get
>>> >> +but returns the values of the running daemon.
>>> >>  .It Cm ls Ar lsarg
>>> >>  Display a list of services and daemons matching
>>> >>  .Ar lsarg ,
>>> >> @@ -180,6 +184,9 @@ exits with 0 if the daemon or service is
>>> >>  .Nm Cm getdef Ar daemon | service Op Cm status
>>> >>  exits with 0 if the daemon or service is enabled by default
>>> >>  and 1 if it is not.
>>> >> +.Nm Cm getrun Ar daemon | service
>>> >> +exits with 0 if the values of the running daemon exists
>>> >> +and 1 if it doesn't.
>>> >>  .Nm Cm ls failed
>>> >>  exits with 1 if an enabled daemon is not running.
>>> >>  Otherwise, the
>>> >> Index: usr.sbin/rcctl/rcctl.sh
>>> >> ===
>>> >> RCS file: /cvs/src/usr.sbin/rcctl/rcctl.sh,v
>>> >> retrieving revision 1.107
>>> >> diff -u -p -r1.107 rcctl.sh
>>> >> --- usr.sbin/rcctl/rcctl.sh  21 Oct 2018 21:20:40 -  1.107
>>> >> +++ usr.sbin/rcctl/rcctl.sh  15 Feb 2019 05:48:16 -
>>> >> @@ -21,6 +21,7 @@ _special_svcs="accounting check_quotas i
>>> >> spamd_black"
>>> >>  readonly _special_svcs
>>> >>
>>> >> +_RC_RUNDIR=/var/run/rc.d
>>> >>  # get local functions from rc.subr(8)
>>> >>  FUNCS_ONLY=1
>>> >>  . /etc/rc.d/rc.subr
>>> >> @@ -32,7 +33,7 @@ usage()
>>> >>  for _i in ${_rc_actions}; do _a="$(echo -n 
>>> >> ${_i}${_a:+|${_a}})"; done
>>> >>
>>> >>  _rc_err \
>>> >> -"usage: rcctl get|getdef|set service | daemon [variable 
>>> >> [arguments]]
>>> >> + "usage: rcctl get|getdef|getrun|set service | daemon [variable
>>> >> [arguments]]
>>> >>  rcctl [-df]

security.html -> broken link

2019-02-19 Thread Oleg Pahl


Hi @all,

On https://www.openbsd.org/security.html there is a broken link.


 --->


 Full Disclosure

Like many readers of theBUGTRAQ mailing list 
, we believe in full 
disclosure of security problems.


* http://online.securityfocus.com/archive/1

<---

Please check!

BR,

Oleg Pahl

Re: bgpd use long long instead of int64_t

2019-02-19 Thread Claudio Jeker

On Tue, Feb 19, 2019 at 12:10:25AM +0100, Andreas Kusalananda Kähäri wrote:
> On Mon, Feb 18, 2019 at 10:11:03PM +0100, Mark Kettenis wrote:
> > > Date: Mon, 18 Feb 2019 21:59:38 +0100
> > > From: Claudio Jeker 
> > > 
> > > In some places bgpd just wants something bigger then a 32bit int.
> > > Instead of using int64_t or u_int64_t use (unsigned) long long which is at
> > > least 64bit and therefor good enough. Makes the mess with type definition
> > > of int64_t on various systems go away (including a bunch of type casts).
> > > While there also apply the endian.h cleanup done in bgpd a few days ago.
> > > 
> > > OK?
> > 
> > You could use  and uint64_t instead.  That should be
> > portable.  But you'd still need to be careful about printf statements
> > since (u)int64_t might be (unsigned) long on some systems.
> 
> printf should be no issue if you use the correct PRI*64 (PRIu64 or
> PRId64) macro from .  Both  and  are
> C99.
> 
> E.g.
> 
> uint64_t thing;
> 
> /* ... */
> 
> printf("The value is %" PRIu64 "\n", thing);
> 
> 
> ... but I'm really not qualified to say anything about what you guys should 
> do.
> 

While true I have to say that the PRI constructs are even worse than doing
casts. Chopping up the format string like this is just ugly and unreadable
for complex format strings.

-- 
:wq Claudio

Re: Executing rc.d on rdomain != 0

Re: Executing rc.d on rdomain != 0

Executing rc.d on rdomain != 0

Re: ioctls for MPLS pseudowire interface config

ioctls for MPLS pseudowire interface config

Re: strptime: %e and leading space

Re: bgpd use long long instead of int64_t

ix transmit code doesn't need atomic ops

Re: httpd(8): add support for FastCGI parameters

security.html -> patch

athn(4): explicit timing of control frames

Re: athn(4) bpf tap short-preamble fix

Re: security.html -> broken link

Re: add getrun for rcctl(8)

security.html -> broken link

Re: bgpd use long long instead of int64_t

16 matches

Site Navigation

Mail list logo

Footer information