Re: n_time in trpt(8)

On Wed, Dec 21, 2016 at 10:01:28PM -0500, Lawrence Teo wrote: > In 2014, mpi@ substituted n_time, n_long, and n_short with their equivalent > u_int_* types throughout the network stack to remove the dependency on > : > > http://marc.info/?l=openbsd-tech=140523875001860=2 > > As mentioned in his

n_time in trpt(8)

In 2014, mpi@ substituted n_time, n_long, and n_short with their equivalent u_int_* types throughout the network stack to remove the dependency on : http://marc.info/?l=openbsd-tech=140523875001860=2 As mentioned in his mail, trpt(8) is the only program in userland that uses n_time. The

Re: Minor improvement to socket(2) man page

Hi, Michael McConville wrote on Wed, Dec 21, 2016 at 08:17:20PM -0500: > Before I do the busy-work: do the man page gurus have a preferred > phrasing? I prefer fhopen(2)'s (listed above), which seems to be the > most common. The preferred version is something close to what .Rv produces:

Re: snmpd improvements

On 16-12-21 9:41 AM, Jan Klemkow wrote: On Wed, Dec 21, 2016 at 10:40:48AM +0100, Franco Fichtner wrote: The snmpd.conf can contain static values. If these values are rewritten/changed over time by rewriting the config, snmpd needs to be restarted. Is there a technical reason for not

Re: Minor improvement to socket(2) man page

Philip Guenther wrote: > On Wed, Sep 21, 2016 at 6:23 PM, Michael McConville wrote: > > The current version is somewhat awkward and forgets to mention that > > errno is set. I adapted the paragraph found in most other system call > > man pages. > > There are six syscalls that

Re: NET_LOCK() pflow panic

On Thu, Dec 22, 2016 at 11:41 AM, Alexander Bluhm wrote: > On Thu, Dec 22, 2016 at 11:32:26AM +1100, Darren Tucker wrote: >> > I don't have a solution for the moment and I want to be sure we know all >> > recursions before trying to write a fix. So here's a diff that

Re: NET_LOCK() pflow panic

On Thu, Dec 22, 2016 at 11:32:26AM +1100, Darren Tucker wrote: > > I don't have a solution for the moment and I want to be sure we know all > > recursions before trying to write a fix. So here's a diff that mark the > > recursions with a XXXSMP like in the NFS case. Looks like visa@'s crash. I

Re: NET_LOCK() pr_sysctl

On Tue, Dec 20, 2016 at 05:37:20PM +, Alexander Bluhm wrote: > Obviosly a NET_LOCK() is missing in tcp_sysctl(). > > I think it is better to place the lock into net_sysctl() where all > the protocol sysctls are called via pr_sysctl. Then we don't have > to decide each case individually. As

Re: NET_LOCK() pflow panic

Hi. On Tue, Dec 20, 2016 at 03:28:38PM +0100, Martin Pieuchot wrote: [...] > I don't have a solution for the moment and I want to be sure we know all > recursions before trying to write a fix. So here's a diff that mark the > recursions with a XXXSMP like in the NFS case. I think I have another

crtbegin.o and .ctors

Our crtbegin.o has: [ 8] .ctorsPROGBITS 000248 04 00 A 0 0 4 whereas crtend.o has: [ 8] .ctorsPROGBITS 48 04 00 WA 0 0 4 So in crtbegin.o the .ctors section is read-only while in crtend.o it is writable. Our

splassert: ip_output: want 1 have 0

splassert: ip_output: want 1 have 0 Starting stack trace... ip_output() at ip_output+0x7d ipsp_process_done() at ipsp_process_done+0x2ad esp_output_cb() at esp_output_cb+0x135 taskq_thread() at taskq_thread+0x6c end trace frame: 0x0, count: 253 End of stack trace. This makes no sense to me since

Re: ospf6d: handle interface MTU changes

i think this is ok Jeremie Courreges-Anglas(j...@wxcvbn.org) on 2016.12.21 12:08:23 +0100: > > Hi, > > After ospfd here's a diff to make ospf6d refresh his view of an > interface's MTU at runtime. This needs a fresh kernel. > > The parent should pass the IFINFO message to its children first,

Re: BFD: route get and route monitor

Hrvoje Popovski(hrv...@srce.hr) on 2016.12.21 22:03:56 +0100: > On 17.12.2016. 14:05, Peter Hessler wrote: > > Updated output, requested by Theo. A normal get will show just the bfd > > state, use "-bfd" to get all of the information. > > > > OK? > > > > $ route -n get 203.0.113.9 > >route

Re: clang amd64 libm: declare copysign() correctly

On Wed, Dec 21, 2016 at 4:49 AM, Mark Kettenis wrote: >> Date: Wed, 21 Dec 2016 13:28:26 +0100 >> From: Christian Weisgerber >> >> libm uses copysign() and copysignf() internally, but fails to declare >> the amd64 assembly versions that way. When

Re: BFD: route get and route monitor

On 17.12.2016. 14:05, Peter Hessler wrote: > Updated output, requested by Theo. A normal get will show just the bfd > state, use "-bfd" to get all of the information. > > OK? > > $ route -n get 203.0.113.9 >route to: 203.0.113.9 > destination: 203.0.113.9 >mask: 255.255.255.255 >

Re: ND6 and splsoftnet()

On 21/12/16(Wed) 18:22, Alexander Bluhm wrote: > On Wed, Dec 21, 2016 at 05:21:53PM +0100, Alexander Bluhm wrote: > > > @@ -430,15 +430,16 @@ nd6_llinfo_timer(void *arg) > > > void > > > nd6_timer_work(void *null) > > > { > > > - int s; > > > struct nd_defrouter *dr, *ndr; > > > struct

Re: snmpd improvements

On Wed, Dec 21, 2016 at 10:40:48AM +0100, Franco Fichtner wrote: > Hi, > > Switching from net-snmp to OpenBSD's snmpd raised two > issues and I'd like to know if they make sense to address: > > A pid file is missing. Would a patch for this be accepted? As far as I know, the OpenBSD project

Re: NET_LOCK() recursion during netboot

On Wed, Dec 21, 2016 at 04:52:32PM +, Visa Hankala wrote: > Network boot triggers a netlock recursion: > > panic > rw_enter > sosend <- NET_LOCK() > nfs_send > nfs_request > nfs_lookup > VOP_LOOKUP > vfs_lookup > namei > unp_connect > uipc_usrreq > soconnect <- NET_LOCK() > sys_connect > >

Re: ND6 and splsoftnet()

On Wed, Dec 21, 2016 at 05:21:53PM +0100, Alexander Bluhm wrote: > > @@ -430,15 +430,16 @@ nd6_llinfo_timer(void *arg) > > void > > nd6_timer_work(void *null) > > { > > - int s; > > struct nd_defrouter *dr, *ndr; > > struct nd_prefix *pr, *npr; > > struct in6_ifaddr *ia6, *nia6; >

Re: if attach/detach netlocks

On Tue, Dec 20, 2016 at 07:33:35PM +0100, Martin Pieuchot wrote: > On 20/12/16(Tue) 18:47, Mike Belopuhov wrote: > > On Tue, Dec 20, 2016 at 17:06 +0100, Martin Pieuchot wrote: > > > > > > You'll need to release the lock before calling ifc->ifc_create in > > > if_clone_create() and do the same

NET_LOCK() recursion during netboot

Network boot triggers a netlock recursion: panic rw_enter sosend <- NET_LOCK() nfs_send nfs_request nfs_lookup VOP_LOOKUP vfs_lookup namei unp_connect uipc_usrreq soconnect <- NET_LOCK() sys_connect An XXXSMP workaround seems appropriate here. OK? Index: kern/uipc_usrreq.c

Re: ND6 and splsoftnet()

On Wed, Dec 21, 2016 at 01:52:45PM +0100, Martin Pieuchot wrote: > ok? OK bluhm@, but comments inline > @@ -430,15 +430,16 @@ nd6_llinfo_timer(void *arg) > void > nd6_timer_work(void *null) > { > - int s; > struct nd_defrouter *dr, *ndr; > struct nd_prefix *pr, *npr; >

ND6 and splsoftnet()

This diff get rids of all splsoftet() in nd6 code. I converted timers to the NET_LOCK() even if ip6_output() doesn't assert for it for the moment. That's simply the way to go. Also because these functions iterates on global data structures that will need the NET_LOCK() or a rewrite. ok?

Re: clang amd64 libm: declare copysign() correctly

> Date: Wed, 21 Dec 2016 13:28:26 +0100 > From: Christian Weisgerber > > libm uses copysign() and copysignf() internally, but fails to declare > the amd64 assembly versions that way. When built with clang, this > results in undefined references to _libm_copysign etc. > >

clang amd64 libm: declare copysign() correctly

libm uses copysign() and copysignf() internally, but fails to declare the amd64 assembly versions that way. When built with clang, this results in undefined references to _libm_copysign etc. Presumably gcc replaces those calls to copysign with a builtin, but clang doesn't. Index:

Re: sleep.1: "while true;" -> "while :;"

On 2016-12-20, Jason McIntyre wrote: > i'm not sure why "while :" is better in this example, but "while true" > is clearer, i think. allowing for differences in preference, is their a > good reason to change what's there? I agree that "true" is clearer and I see no reason to

Re: if attach/detach netlocks

On Wed, Dec 21, 2016 at 12:45:37PM +0100, Mike Belopuhov wrote: > Anyways, OK for the diff below? OK bluhm@ > diff --git sys/net/if_pflow.c sys/net/if_pflow.c > index 0df0b69fd8a..8592d98a743 100644 > --- sys/net/if_pflow.c > +++ sys/net/if_pflow.c > @@ -265,14 +265,11 @@

Re: if attach/detach netlocks

On Wed, Dec 21, 2016 at 00:13 +0100, Alexander Bluhm wrote: > On Tue, Dec 20, 2016 at 06:47:31PM +0100, Mike Belopuhov wrote: > > @@ -1109,11 +1115,16 @@ if_clone_destroy(const char *name) > > s = splnet(); > > if_down(ifp); > > splx(s); > > } > > > > -

ospf6d: handle interface MTU changes

Hi, After ospfd here's a diff to make ospf6d refresh his view of an interface's MTU at runtime. This needs a fresh kernel. The parent should pass the IFINFO message to its children first, and then decide to react to a possible interface change. Like for ospfd, the engine runs the FSM only if

snmpd improvements

Hi, Switching from net-snmp to OpenBSD's snmpd raised two issues and I'd like to know if they make sense to address: A pid file is missing. Would a patch for this be accepted? The snmpd.conf can contain static values. If these values are rewritten/changed over time by rewriting the config,

vndcompress et al import?

Hi, Is anyone aware or interested in porting vndcompress et al from NetBSD to OpenBSD? Is there any technical reason against inclusion? We have a budget for this. If anyone is interested please let me know. Cheers, Franco

Re: sleep.1: "while true;" -> "while :;"

On Wed, Dec 21, 2016 at 09:59:18AM +0100, Michal Mazurek wrote: > On 22:49:38, 20.12.16, Jason McIntyre wrote: > > On Tue, Dec 20, 2016 at 10:58:40PM +0100, Michal Mazurek wrote: > > > While there is nothing wrong with "while true", "while :" is better > > > and used a lot more often in the source

Re: sleep.1: "while true;" -> "while :;"

On 22:49:38, 20.12.16, Jason McIntyre wrote: > On Tue, Dec 20, 2016 at 10:58:40PM +0100, Michal Mazurek wrote: > > While there is nothing wrong with "while true", "while :" is better > > and used a lot more often in the source tree. > > > > OK? > > > > i'm not sure why "while :" is better in