Re: Special casing fd's opened before pledge(2)

> There has been developer pressure to permit an increasing number of > ioctl's to pledged programs. The problem is that providing a specific > ioctl under a promise to one program, means it becomes supplied to all > other programs that make that promise. There is no discrete method > to

Re: less

Theo de Raadt(dera...@openbsd.org) on 2017.01.22 22:01:22 -0700: > This change causes less(1) to open /dev/tty slightly earlier, > or fallback to stderr. > > As a result the TIOCGWINSZ operation can be done against the most > likely tty descriptor. > > As a side effect, that tty descriptor will

network booting efi systems with dhcpd(8)

For network boot clients, dhcpd(8) can supply a filename for the initial boot file for the client, which is something like pxeboot (or pxelinux.0). EFI and BIOS clients need different boot files, though, so the server needs to know what mode the client is booting in, in order to supply the right

Re: network booting efi systems with dhcpd(8)

> > The ISC dhcpd approach to using this looks something like this: > > > > option arch code 93 = unsigned integer 16; > > > > if option arch = 00:00 { > > filename "bios/pxelinux.0"; > > } elsif option arch = 00:07 { > > filename "efi.x64/syslinux.efi"; > > } > > [...] IIUC

Re: network booting efi systems with dhcpd(8)

On Mon, Jan 23, 2017 at 08:39:17PM +1000, Jonathan Matthew wrote: > For network boot clients, dhcpd(8) can supply a filename for the initial > boot file for the client, which is something like pxeboot (or pxelinux.0). > EFI and BIOS clients need different boot files, though, so the server > needs

Re: network booting efi systems with dhcpd(8)

On Mon, Jan 23, 2017 at 08:39:17PM +1000, Jonathan Matthew wrote: > For network boot clients, dhcpd(8) can supply a filename for the initial > boot file for the client, which is something like pxeboot (or pxelinux.0). > EFI and BIOS clients need different boot files, though, so the server > needs

Re: rtsock refactoring

On Sat, Jan 21, 2017 at 01:28:02AM +0100, Claudio Jeker wrote: > On Fri, Jan 20, 2017 at 02:51:52AM +0100, Claudio Jeker wrote: > > I sent this diff out some time ago and would really like to get this in. > > This is one step on makeing rtsock.c less of a hornets nest. > > This reduces the side

Re: rtwn: fix iq calibration

On Sun, Jan 22, 2017 at 11:07:00PM +0100, Jeremie Courreges-Anglas wrote: > Stefan Sperling writes: > > > FreeBSD committed a couple of interesting things in r307529 > > https://svnweb.freebsd.org/base?view=revision=r307529 > > Unfortunately the commit is a giant patch bomb which

Re: network booting efi systems with dhcpd(8)

On Mon, Jan 23, 2017 at 09:57:28PM +1100, Jonathan Gray wrote: > On Mon, Jan 23, 2017 at 08:39:17PM +1000, Jonathan Matthew wrote: > > For network boot clients, dhcpd(8) can supply a filename for the initial > > boot file for the client, which is something like pxeboot (or pxelinux.0). > > EFI and

Re: rtsock refactoring

On Mon, Jan 23, 2017 at 01:18:05AM +0100, Claudio Jeker wrote: > Last bit for now. This is changing the reporting madness. It moves it in > its own function which is called after the big switch statement. > If you hit a bad error in the switch the code should eiter goto fail or > flush. > The new

Re: split pledge "ioctl" into "bpf" and "tape"

Theo de Raadt wrote: > So let's just split these cases out. "ioctl"'s number gets reused for > tape, and a new "bpf" promise is added.. That paves the way for a > more complex diff coming in a few hours. The mention of bpf made me worried that dhclient would be affected, but I checked and it's

Re: split pledge "ioctl" into "bpf" and "tape"

>Theo de Raadt wrote: >> So let's just split these cases out. "ioctl"'s number gets reused for >> tape, and a new "bpf" promise is added.. That paves the way for a >> more complex diff coming in a few hours. > >The mention of bpf made me worried that dhclient would be affected, but I >checked

fd-passing: convert internalized format to a struct

File descriptor passing internalizes process fd's to an array of struct file *. This results in tricky pointer management. How about passing it as an array of structs instead. Only one field inside for now, struct file *. However soon I'll need to pass additional fields along with the file,

Re: pfind(9) -> tfind(9)

On Tue, 24 Jan 2017, Martin Pieuchot wrote: > We live in a thread world! Let's face it. > > ok? Heh, I lost track that I managed to get it down to such a small set. ok on the rename, just some small manpage wankery: > --- /dev/null 1 Jan 1970 00:00:00 - > +++ share/man/man9/tfind.924

Re: NET_LOCK() ordering issue

On Tue, Jan 24, 2017 at 01:48:49AM +0100, Alexander Bluhm wrote: > On Tue, Jan 24, 2017 at 10:01:02AM +1000, Martin Pieuchot wrote: > > Updated diff, thanks for your review. > > > @@ -360,24 +358,20 @@ redo: > > error = soaccept(so, nam); > > if (!error && name != NULL) > >

Re: rtsock refactoring

On 23/01/17(Mon) 01:18, Claudio Jeker wrote: > [...] > Last bit for now. This is changing the reporting madness. It moves it in > its own function which is called after the big switch statement. > If you hit a bad error in the switch the code should eiter goto fail or > flush. > The new function

Re: fd-passing: convert internalized format to a struct

On 23/01/17(Mon) 16:05, Theo de Raadt wrote: > File descriptor passing internalizes process fd's to an array of > struct file *. This results in tricky pointer management. > > How about passing it as an array of structs instead. Only one field > inside for now, struct file *. However soon I'll

Re: rtsock refactoring

On Mon, Jan 23, 2017 at 04:56:02PM +0100, Alexander Bluhm wrote: > On Mon, Jan 23, 2017 at 01:18:05AM +0100, Claudio Jeker wrote: > > Last bit for now. This is changing the reporting madness. It moves it in > > its own function which is called after the big switch statement. > > If you hit a bad

Re: Help for ddb(4)'s "tr /p"

On Tue, 24 Jan 2017, Martin Pieuchot wrote: > Now that pfind(9) takes tid we need a way to show TID in ddb(4) ps > output. Otherwise it's hard to use "ps /p" You mean "tr /p", right? > Here's the difference: > > Before: >PID PPID PGRPUID S FLAGS WAIT COMMAND >

refactor PF option parsing loops

Hi, PF implements six distinct TCP option parsing loops. This patch converts these to one inline function in pfvar_priv.h, normalises their semantics, and strips ~100 lines. I've laid out the existing semantics below. The new loop implements the timestamp parser's semantics of "(s-b) (v-3)

Re: refactor PF option parsing loops

PS Find this patch broken down for easier review here: http://203.79.107.124/opts/ On Tue, 24 Jan 2017, Richard Procter wrote: > Hi, > > PF implements six distinct TCP option parsing loops. This patch converts > these to one inline function in pfvar_priv.h, normalises their semantics, > and

Re: NET_LOCK() ordering issue

On Sat, Jan 21, 2017 at 10:46:42AM +1000, Martin Pieuchot wrote: > Here's another way to fix the problem, call falloc() before grabbing the > NET_LOCK(). > > Comments? There a two bugs in the "goto redo" block that is not part of the diff. You could do a m_freem(nam), then goto redo, get an

Re: NET_LOCK() ordering issue

On 24/01/17(Tue) 00:51, Alexander Bluhm wrote: > On Sat, Jan 21, 2017 at 10:46:42AM +1000, Martin Pieuchot wrote: > > Here's another way to fix the problem, call falloc() before grabbing the > > NET_LOCK(). > > > > Comments? > > There a two bugs in the "goto redo" block that is not part of the >

Re: NET_LOCK() ordering issue

On Tue, Jan 24, 2017 at 10:01:02AM +1000, Martin Pieuchot wrote: > Updated diff, thanks for your review. > @@ -360,24 +358,20 @@ redo: > error = soaccept(so, nam); > if (!error && name != NULL) > error = copyaddrout(p, nam, name, namelen, anamelen); > - > + if

Re: global mbuf memory limit

On Wed, Dec 14, 2016 at 03:52:32PM +1000, David Gwynne wrote: > > Wouldn't it make sense to use atomic operations to keep track of the > > amount of memory that was allocated? > > the mtx may be slow, but it is a slow path id like to keep simple. Is allocate and free of mbuf clusters in the slow

Re: rtsock refactoring

On Tue, Jan 24, 2017 at 08:54:23AM +1000, Martin Pieuchot wrote: > On 23/01/17(Mon) 01:18, Claudio Jeker wrote: > > [...] > > Last bit for now. This is changing the reporting madness. It moves it in > > its own function which is called after the big switch statement. > > If you hit a bad error in

[WWW] Reverse chronological order for faq/current.html

Hi all, As faq/current.html[0] grows, each major change is being added at the very bottom, chronologically. There already are several other pages where this kind of ordering makes sense, i.e. innovations.html[1]. Given the "current" (unintentional pun) nature of changes on the aforementioned

Help for ddb(4)'s "ps /p"

Now that pfind(9) takes tid we need a way to show TID in ddb(4) ps output. Otherwise it's hard to use "ps /p" Diff below does that and fix some documentation about "show all procs". pfind(9) manual still needs a fix, and we can all decide afterward if we should rename "/p" into "/t". Here's

pfind(9) -> tfind(9)

We live in a thread world! Let's face it. ok? Index: sys/arch/amd64/amd64/db_trace.c === RCS file: /cvs/src/sys/arch/amd64/amd64/db_trace.c,v retrieving revision 1.23 diff -u -p -r1.23 db_trace.c --- sys/arch/amd64/amd64/db_trace.c

let bfd survive link-down

When an interface loses link, we delete all directly connected and cloned routes. However, this means we also lose any BFD configuration on those routes. Surviving link-down is pretty much mandatory for BFD to work. So instead, I bypass the route deletion, and clean up the link-local gateway

Re: [WWW] Reverse chronological order for faq/current.html

> As faq/current.html[0] grows, each major change is being added at > the very bottom, chronologically. There already are several other > pages where this kind of ordering makes sense, i.e. innovations.html[1]. > > Given the "current" (unintentional pun) nature of changes on the > aforementioned

Re: Help for ddb(4)'s "tr /p"

On 24/01/17(Tue) 10:08, Philip Guenther wrote: > On Tue, 24 Jan 2017, Martin Pieuchot wrote: > > Now that pfind(9) takes tid we need a way to show TID in ddb(4) ps > > output. Otherwise it's hard to use "ps /p" > > You mean "tr /p", right? I do :) > Hmm, ps/n (the default) is the only of the

Re: Help for ddb(4)'s "tr /p"

On Tue, 24 Jan 2017, Martin Pieuchot wrote: > On 24/01/17(Tue) 10:08, Philip Guenther wrote: ... > > Hmm, ps/n (the default) is the only of the ps subcommands to not show > > the TID...so that it can show more columns of COMMAND. You've added 8 > > columns without shrinking any of the existing

document that RES_USE_EDNS0 and RES_USE_DNSSEC currently do nothing

To reduce the risk that others spend hours doing the same excercise that myself (https://marc.info/?l=openbsd-misc=148513378718363), here's a patch that mentiones that RES_USE_EDNS0 and RES_USE_DNSSEC options currently do nothing. Index: lib/libc/net/resolver.3

httpd TLS ticket support

Since I just added ticket support to libtls here is a diff to enable it in httpd. Cheers -- :wq Claudio Index: config.c === RCS file: /cvs/src/usr.sbin/httpd/config.c,v retrieving revision 1.50 diff -u -p -r1.50 config.c ---

Re: freestanding take 2, part 1

On Tue, Jan 24, 2017 at 3:33 PM, Mark Kettenis wrote: > Turns out our compilers support different sets of builtins. So the > diff below does the following: > > * Enables bzero, memcmp, memcpy and memset for all compilers. > * Enables bcmp, bcopy and memmove for gcc4. > >

Re: global mbuf memory limit

On Tue, Jan 24, 2017 at 02:55:50AM +0100, Alexander Bluhm wrote: > On Wed, Dec 14, 2016 at 03:52:32PM +1000, David Gwynne wrote: > > > Wouldn't it make sense to use atomic operations to keep track of the > > > amount of memory that was allocated? > > > > the mtx may be slow, but it is a slow path

Re: clean up and modernize test calls in bsd.obj.mk

On Tue, Jan 24, 2017 at 01:01:57PM +1000, Theo Buehler wrote: > We're currently using several idioms for conditionally executing code in > bsd.obj.mk. I'd like to unify them for the sake of readability and > consistency. This was done joint with rpe. OK rpe@ > Index: share/mk/bsd.obj.mk >

Re: let bfd survive link-down

On 2017 Jan 24 (Tue) at 02:38:54 +0100 (+0100), Peter Hessler wrote: :When an interface loses link, we delete all directly connected and :cloned routes. However, this means we also lose any BFD configuration :on those routes. : :Surviving link-down is pretty much mandatory for BFD to work. : :So

Re: let bfd survive link-down

On 24/01/17(Tue) 04:55, Peter Hessler wrote: > On 2017 Jan 24 (Tue) at 02:38:54 +0100 (+0100), Peter Hessler wrote: > :When an interface loses link, we delete all directly connected and > :cloned routes. However, this means we also lose any BFD configuration > :on those routes. > : > :Surviving

ld.so: don't use _dl_exit() for fatal errors

So right now, ld.so simply exits iun various error cases, like unknown relocation. This isn't great, as it's a normal exit when a linking failure really should be an abnormal exit as from a fatal signal. If "grep" has a linking failure I want it to *die* instead of meekly returning

pool_debug

I'd like to force a yield() for every pool_get(9) using PR_WAITOK, just like we do with malloc(9), in order to ensure that the NET_LOCK() is not held across context switches. ok? Index: kern/subr_pool.c === RCS file:

Scheduler ping-pong with preempt()

Userland threads are preempt()'d when hogging a CPU or when processing an AST. Currently when such a thread is preempted the scheduler looks for an idle CPU and puts it on its run queue. That means the number of involuntary context switch often result in a migration. This is not a problem per

ypldap(8) tls

This adds TLS to ypldap(8), both 'ldaps' (TLS on port 636) and 'tls' (on port 389, after a 'starttls' extended operation) variants. I've tried this against one of our AD servers and against ldapd. Index: Makefile === RCS file:

freestanding take 2, part 1

Turns out our compilers support different sets of builtins. So the diff below does the following: * Enables bzero, memcmp, memcpy and memset for all compilers. * Enables bcmp, bcopy and memmove for gcc4. This diff should be a no-op for kernels compiled without -ffreestanding. I've checked a

Re: httpd TLS ticket support

> Am 24.01.2017 um 02:54 schrieb Claudio Jeker : > > Since I just added ticket support to libtls here is a diff to enable it > in httpd. > Thanks, comments below. Reyk > Cheers > -- > :wq Claudio > > Index: config.c >

Re: NET_LOCK() ordering issue

On Mon, Jan 23, 2017 at 4:01 PM, Martin Pieuchot wrote: > On 24/01/17(Tue) 00:51, Alexander Bluhm wrote: >> On Sat, Jan 21, 2017 at 10:46:42AM +1000, Martin Pieuchot wrote: ... > Updated diff, thanks for your review. Very close... > --- kern/uipc_syscalls.c29 Dec 2016

Re: ypldap(8) tls

DPADD= ${LIBEVENT} ${LIBUTIL} ${LIBRPCSVC} -LDADD= -levent -lutil -lrpcsvc +LDADD= -ltls -levent -lutil -lrpcsvc You will need to use: DPADD=${LIBTLS} ${LIBSSL} ${LIBCRYPTO} ${LIBEVENT} ${LIBUTIL} ${LIBRPCSVC} LDADD=-ltls -lssl -lcrypto -levent -lutil

Re: Help for ddb(4)'s "tr /p"

On 24/01/17(Tue) 11:35, Philip Guenther wrote: > On Tue, 24 Jan 2017, Martin Pieuchot wrote: > > On 24/01/17(Tue) 10:08, Philip Guenther wrote: > ... > > > Hmm, ps/n (the default) is the only of the ps subcommands to not show > > > the TID...so that it can show more columns of COMMAND. You've

Re: pool_debug

On Tue, Jan 24, 2017 at 04:46:01PM +1000, Martin Pieuchot wrote: > I'd like to force a yield() for every pool_get(9) using PR_WAITOK, just > like we do with malloc(9), in order to ensure that the NET_LOCK() is not > held across context switches. > > ok? ok > > Index: kern/subr_pool.c >

Re: NET_LOCK() ordering issue

On 23/01/17(Mon) 18:45, Philip Guenther wrote: > On Mon, Jan 23, 2017 at 4:01 PM, Martin Pieuchot wrote: > [...] > > @@ -277,19 +277,35 @@ doaccept(struct proc *p, int sock, struc > > return (error); > > > > headfp = fp; > > + head = headfp->f_data;

Re: Help for ddb(4)'s "tr /p"

On Tue, 24 Jan 2017, Martin Pieuchot wrote: > Diff below does that and fix alignment issues with /a /o and /w. The > problem was that TID needs 6 columns not 5. > > With this ps /a no longer wraps on i386. > > ddb{0}> ps /a > TID COMMAND STRUCT PROC * UAREA *

clean up and modernize test calls in bsd.obj.mk

We're currently using several idioms for conditionally executing code in bsd.obj.mk. I'd like to unify them for the sake of readability and consistency. This was done joint with rpe. Index: share/mk/bsd.obj.mk === RCS file:

Re: clean up and modernize test calls in bsd.obj.mk

fOn Tue, 24 Jan 2017, Theo Buehler wrote: > We're currently using several idioms for conditionally executing code in > bsd.obj.mk. I'd like to unify them for the sake of readability and > consistency. This was done joint with rpe. Looks good. The only caveat that comes to mind is that