Re: regress/bgpd: allow specifying daemon binary

2018-09-18 Thread Theo de Raadt
Wow, suddenly this is about awk? I am going to ask you to do something: Please run the entire regress test on a system. Why not run it twice, without rebooting. Report back, ok? The complexity you wish to embrace so much results in a variety of costs you are about to be introduced to. How we

Re: regress/bgpd: allow specifying daemon binary

2018-09-18 Thread Steffen Nurpmeso
Theo de Raadt wrote in <87985.1537307...@cvs.openbsd.org>: |I honestly think this is a foolishly complicated. Maybe for OpenBSD only software. But i think it is worth the hazzle whenever affordable for certain types of software. |Just install the program, then run regress. Install an older

Re: regress/bgpd: allow specifying daemon binary

2018-09-18 Thread Theo de Raadt
Klemens Nanni wrote: > On Tue, Sep 18, 2018 at 03:44:27PM -0600, Theo de Raadt wrote: > > I honestly think this is a foolishly complicated. > > > > Just install the program, then run regress. Install an older version > > without the broken changes if it doesn't work. > > > > I tire of these

Re: regress/bgpd: allow specifying daemon binary

2018-09-18 Thread Klemens Nanni
On Tue, Sep 18, 2018 at 03:44:27PM -0600, Theo de Raadt wrote: > I honestly think this is a foolishly complicated. > > Just install the program, then run regress. Install an older version > without the broken changes if it doesn't work. > > I tire of these interactions between environment

bgpd: sync host*() changes from pfctl

2018-09-18 Thread Klemens Nanni
This simplifies host() and merges host_v{4,6}() into host_ip() as recently done for pfctl and ntpd. config regress still passes but I don't have a real BGP setup to tinker with so proper testing is highly appreciated. Feedback? OK? Index: config.c

Re: regress/bgpd: allow specifying daemon binary

2018-09-18 Thread Theo de Raadt
I honestly think this is a foolishly complicated. Just install the program, then run regress. Install an older version without the broken changes if it doesn't work. I tire of these interactions between environment variables, base build methods, fork+exec paths in privsep programs, and now

Re: regress/bgpd: allow specifying daemon binary

2018-09-18 Thread Alexander Bluhm
On Tue, Sep 18, 2018 at 11:29:19PM +0200, Klemens Nanni wrote: > Same as in pfctl or route so I can easily test my changes with > > $ make BGPD=/usr/obj/usr.sbin/bgpd/bgpd config > > OK? OK bluhm@ > Index: config/Makefile >

regress/bgpd: allow specifying daemon binary

2018-09-18 Thread Klemens Nanni
Same as in pfctl or route so I can easily test my changes with $ make BGPD=/usr/obj/usr.sbin/bgpd/bgpd config OK? Index: config/Makefile === RCS file: /cvs/src/regress/usr.sbin/bgpd/config/Makefile,v retrieving revision 1.5

Re: timecounter memory barriers

2018-09-18 Thread Mark Kettenis
> Date: Tue, 18 Sep 2018 17:59:21 +0200 > From: Alexander Bluhm > > Hi, > > In timecounter code, generation number and timehands are volatile, > but there are no memory barriers. In general such code is wrong > for SMP as it tells the compiler to care about ordering but ignores > cache

Re: csh: simplify strsave()

2018-09-18 Thread Todd C. Miller
On Tue, 18 Sep 2018 11:51:26 -0600, "Todd C. Miller" wrote: > To use strchr(3) here we either need mask the char value with 0xff > or figure out why asyntax() is calling any() with a char value of > -32768. The -32768 comes from a Char with the QUOTE bit set. This gets sign-extended when cast to

Re: csh: simplify strsave()

2018-09-18 Thread Todd C. Miller
On Sat, 15 Sep 2018 12:42:22 +0200, Martijn van Duren wrote: > While here, should we also remove any in favour of strchr? Only > difference seems to be the return type (bool vs pointer). This turned out to be a problem. There are callers of any() that pass in a value that is not in the range

Re: ix0/1/2/3 at pci8 dev 0 function 0 "Intel X553 SFP+" rev 0x11: msi, address 00:30:18:xxxxxxx

2018-09-18 Thread Hrvoje Popovski
On 18.9.2018. 18:18, sven falempin wrote: > On Tue, Sep 18, 2018 at 4:39 AM Hrvoje Popovski wrote: > >> On 17.9.2018. 22:32, sven falempin wrote: >>> Dear Tech reader, >>> >>> I am recently working on Intel(R) Atom(TM) CPU C3758 intel devices. >>> SFP Intel card are not working in 6.3/current

Re: ix0/1/2/3 at pci8 dev 0 function 0 "Intel X553 SFP+" rev 0x11: msi, address 00:30:18:xxxxxxx

2018-09-18 Thread sven falempin
On Tue, Sep 18, 2018 at 4:39 AM Hrvoje Popovski wrote: > On 17.9.2018. 22:32, sven falempin wrote: > > Dear Tech reader, > > > > I am recently working on Intel(R) Atom(TM) CPU C3758 intel devices. > > SFP Intel card are not working in 6.3/current openBSD base > > > > I did patch intel driver

Re: urndis0: urndis_decap invalid buffer len 1 < minimum header 44

2018-09-18 Thread Artturi Alm
On Sat, Aug 18, 2018 at 11:05:04PM +0300, Artturi Alm wrote: > On Thu, Jan 11, 2018 at 12:41:29AM +0200, Artturi Alm wrote: > > On Wed, Sep 13, 2017 at 05:51:27AM +0300, Artturi Alm wrote: > > > Hi, > > > > > > even after having recently updated the phone to a newer version of > > > android, > >

bgpd: more refactoring for ROA sets

2018-09-18 Thread Claudio Jeker
Since the first bit of ROA sets is in here some refactoring of the code. Split up as_set into a set_table and an as_set. The first is what does the lookup and will now also be used in roa-set tries. The as_set is glue to add the name and dirty flag. Add an accessor to get the set data so that the

timecounter memory barriers

2018-09-18 Thread Alexander Bluhm
Hi, In timecounter code, generation number and timehands are volatile, but there are no memory barriers. In general such code is wrong for SMP as it tells the compiler to care about ordering but ignores cache reordering. NetBSD puts membar_producer() at places where I would put them. But in

Re: [patch] Use the same backlog parameter for listen() function in netcat.c

2018-09-18 Thread Theo de Raadt
I don't see the point of making such a change. Nan Xiao wrote: > Hi tech@, > > Since netcat can only process one connection at one time, maybe > UNIX-domain socket can use the same backlog parameter for listen() > function as network socket, thanks! > > diff --git netcat.c netcat.c > index

[patch] Fix "Address already in use" issue when using netcat with UNIX-domain socket

2018-09-18 Thread Nan Xiao
Hi tech@, Assume I use netcat with UNIX-domain socket, and there is no temp_socket. Launch the server: # ./nc -U -l temp_socket It works normally. But after netcat exits, launch it again: # nc -U -l temp_socket nc: Address already in use The only method seems to delete temp_socket. I am not

PF: skip on VS pass in

2018-09-18 Thread Zbyszek Żółkiewski
Hi list, OpenBSD 6.3 -stable: I was playing with local network - tunning various things on pf, and i observe this odd(maybe not?) performance when using different approach: (trunk0 is local network, ext_1 is external, NAT is performed) when i used: set skip on trunk0 … … pass out on $ext_1

Re: mandoc: typo fix (?) in mandoc.1

2018-09-18 Thread Sascha Paunovic
Hi Ingo, Thanks for the quick feedback. Sorry for the wrong assumption. Regarding the styling documentation, I believe it should stay in, but maybe also add a small note describing it's hardcoded? That might however make the over-documentation situation even worse. Greetings, Sascha On

Re: uninitialized variable in if_mue.c

2018-09-18 Thread Kevin Lo
On Tue, Sep 18, 2018 at 08:40:24AM +0100, Ricardo Mestre wrote: > > Ouch, of course! Still not enough caffeine in the system! > > Unfortunately I don't have such a card to test it, but this is the way it's > done > everywhere else, the writes are always done unconditionally and we just need >

Re: ix0/1/2/3 at pci8 dev 0 function 0 "Intel X553 SFP+" rev 0x11: msi, address 00:30:18:xxxxxxx

2018-09-18 Thread Hrvoje Popovski
On 17.9.2018. 22:32, sven falempin wrote: > Dear Tech reader, > > I am recently working on Intel(R) Atom(TM) CPU C3758 intel devices. > SFP Intel card are not working in 6.3/current openBSD base > > I did patch intel driver reading netbsd, freebsd and intel code of ixgbe > driver. > > I am

Re: uninitialized variable in if_mue.c

2018-09-18 Thread Mark Kettenis
> Date: Tue, 18 Sep 2018 07:55:43 +0100 > From: Ricardo Mestre > > Hi, > > In the case that a mue(4) device is put in promiscuous mode then hashtbl will > be used uninitialized a little bit down the road so set it 0 like it's done in > a lot of other devices. Coverity ID 1473316. > > OK? > >

Re: uninitialized variable in if_mue.c

2018-09-18 Thread Ricardo Mestre
Ouch, of course! Still not enough caffeine in the system! Unfortunately I don't have such a card to test it, but this is the way it's done everywhere else, the writes are always done unconditionally and we just need to ensure that the hash table is initialized to 0 so I prefer to keep the

Re: memory leaks in bwfm

2018-09-18 Thread Patrick Wildt
The code hands off the reponsibility of ctl and ctl->buf to bs_txctl which will free both buffers if there is an error enqueueing the command. Only if bs_txctl succeeds in enqueueing and there is a response timeout we can free it. Thus, not ok. If this pattern is not understandable then we can

Re: memory leak in amdisplay_attach()

2018-09-18 Thread Jonathan Gray
On Tue, Sep 18, 2018 at 08:34:55AM +0200, Claudio Jeker wrote: > On Tue, Sep 18, 2018 at 03:49:15PM +1000, Jonathan Gray wrote: > > Index: amdisplay.c > > === > > RCS file: /cvs/src/sys/arch/armv7/omap/amdisplay.c,v > > retrieving

Re: uninitialized variable in if_mue.c

2018-09-18 Thread Claudio Jeker
On Tue, Sep 18, 2018 at 07:55:43AM +0100, Ricardo Mestre wrote: > Hi, > > In the case that a mue(4) device is put in promiscuous mode then hashtbl will > be used uninitialized a little bit down the road so set it 0 like it's done in > a lot of other devices. Coverity ID 1473316. > > OK? Please

uninitialized variable in if_mue.c

2018-09-18 Thread Ricardo Mestre
Hi, In the case that a mue(4) device is put in promiscuous mode then hashtbl will be used uninitialized a little bit down the road so set it 0 like it's done in a lot of other devices. Coverity ID 1473316. OK? Index: if_mue.c ===

Re: memory leaks in bwfm

2018-09-18 Thread Claudio Jeker
On Tue, Sep 18, 2018 at 03:52:45PM +1000, Jonathan Gray wrote: > Index: bwfm.c > === > RCS file: /cvs/src/sys/dev/ic/bwfm.c,v > retrieving revision 1.54 > diff -u -p -r1.54 bwfm.c > --- bwfm.c25 Jul 2018 20:37:11 - 1.54 >

Re: memory leak in ihidev_hid_command()

2018-09-18 Thread Claudio Jeker
On Tue, Sep 18, 2018 at 03:50:21PM +1000, Jonathan Gray wrote: > Index: ihidev.c > === > RCS file: /cvs/src/sys/dev/i2c/ihidev.c,v > retrieving revision 1.17 > diff -u -p -r1.17 ihidev.c > --- ihidev.c 25 Aug 2018 18:32:05 -

Re: memory leak in amdisplay_attach()

2018-09-18 Thread Claudio Jeker
On Tue, Sep 18, 2018 at 03:49:15PM +1000, Jonathan Gray wrote: > Index: amdisplay.c > === > RCS file: /cvs/src/sys/arch/armv7/omap/amdisplay.c,v > retrieving revision 1.7 > diff -u -p -r1.7 amdisplay.c > --- amdisplay.c 25 Oct

Re: mandoc: typo fix (?) in mandoc.1

2018-09-18 Thread Ingo Schwarze
Hi Sascha, Sascha Paunovic wrote on Tue, Sep 18, 2018 at 06:39:51AM +0200: > while reading mandoc(1), I noticed that under the PostScript output > section, it said the line-height was 1.4m, while it is 1.4em. I doubt > the line-height is approximately as tall as a 5th grader, so let's > clarify

Re: smtpctl.8 typo

2018-09-18 Thread Jason McIntyre
On Tue, Sep 18, 2018 at 11:52:59AM +0800, Michael Mikonos wrote: > Hello, > > My spell-checker found the following typo this morning. OK? > > - Michael > morning. yes, ok. jmc > > Index: smtpctl.8 > === > RCS file: