Re: anyone using gdb "kvm proc/pcb" ?

> Date: Sat, 2 Apr 2016 20:42:15 -0700 > From: Philip Guenther > > The gdb in base, when used against a live kernel or crash dump, is > supposed to be able to backtrace individual threads via the kvm proc and > kvm pcb commands. Is anyone actually using these on 5.9 or

Re: bug in grep

On Sat, Apr 02, 2016 at 09:13:20PM +, H??ctor Luis Gimbatti wrote: > Hi, > Apparently the error seems to be in /usr/src/usr.bin/grep/util.c at line 400: > > if ((!(lflag || cflag)) && ((!(bol || eol)) && > ((lastHalfDot) && ((firstHalfDot < 0) || >

Re: anyone using gdb "kvm proc/pcb" ?

On Sat, 2 Apr 2016, Philip Guenther wrote: > I ask as I see some "this can't work" logic between the kernel and gdb for > at least i386 and possibly others and I'd like to hear what *is* working > that I should verify I don't break when making changes... Here's a quick fix for the initial bug

Pledge promises as input for scheduling ?

Hi tech, Maybe it's too early to ask. I am not even sure if it's a good idea: If a process's pledge promises could be useful in something other than security like process scheduling or perhaps in memory management. Thanks, Arun

Re: bug in grep

On Sun, Apr 03, 2016 at 09:14:40AM +0200, Otto Moerbeek wrote: > On Sat, Apr 02, 2016 at 09:13:20PM +, H??ctor Luis Gimbatti wrote: > > > Hi, > > Apparently the error seems to be in /usr/src/usr.bin/grep/util.c at line > > 400: > > > > if ((!(lflag || cflag)) && ((!(bol || eol)) &&

Re: anyone using gdb "kvm proc/pcb" ?

> Date: Sun, 3 Apr 2016 00:39:14 -0700 > From: Philip Guenther > > On Sat, 2 Apr 2016, Philip Guenther wrote: > > I ask as I see some "this can't work" logic between the kernel and gdb for > > at least i386 and possibly others and I'd like to hear what *is* working > > that

uvm: UVM_FLAG_AMAPPAD has no effect anymore, nuke it

This flag caused amaps to be allocated with additional spare slots, to make extending them cheaper. However, the kernel never extends amaps, so allocating spare slots is pointless. Also UVM_FLAG_AMAPPAD only has an effect in combination with UVM_FLAG_OVERLAY. The only function that used both flags

Re: arm: 8-byte alignment (AAPCS)

> Can someone make sure this doesn't break armish/zaurus? No noticeable regression on armish.

Re: [patch] ftpd: pledge(2)

> > + if (pledge("stdio rpath getpw proc wpath cpath > > inet ioctl sendfd recvfd", > > + NULL) == -1) { > > + fatalx("pledge"); > > + } > > whoa, still a big list of

Re: [patch] ftpd: pledge(2)

On Sun, Apr 03, 2016 at 06:09:21PM +0200, frit...@alokat.org wrote: > On Sat, Apr 02, 2016 at 04:38:10PM +0200, frit...@alokat.org wrote: > > Hi, > > > > this adds pledge(2) to ftpd(8). > > > > --f. > > > > With help from semarie@ the original diff was changed a little > bit. > > The

Re: fdt: translate memory addresses

> Date: Sun, 3 Apr 2016 16:57:10 +0200 > From: Patrick Wildt > > Hi, > > now we're able to get a node's memory address. Though, a device tree > may implement so called ranges. Those ranges are used to translate from > one address space to another. > > This is used on a few

Re: [patch] ftpd: pledge(2)

On Sun, Apr 03, 2016 at 07:07:27PM +0200, frit...@alokat.org wrote: > - sendfd / recvfd are for active ftp > - ioctl is e.g. used for "ls" after ftp(1) established a connection > I'm not exactly sure why, as there is no ioctl(2) call, but maybe > in one underlaying library. > - proc for fork

Re: uvm: UVM_FLAG_AMAPPAD has no effect anymore, nuke it

> Date: Sun, 3 Apr 2016 16:11:40 +0200 > From: Stefan Kempf > > This flag caused amaps to be allocated with additional spare slots, to > make extending them cheaper. However, the kernel never extends amaps, > so allocating spare slots is pointless. Also UVM_FLAG_AMAPPAD only

Re: [patch] ftpd: pledge(2)

On Sun, Apr 03, 2016 at 06:28:21PM +0200, Sebastien Marie wrote: > > + > > + if (pledge("stdio rpath getpw proc wpath cpath > > inet ioctl sendfd recvfd", > > + NULL) == -1) { > > + fatalx("pledge");

Re: [patch] ftpd: pledge(2)

On Sun, Apr 03, 2016 at 06:51:47PM +0200, Theo Buehler wrote: > > > + if (pledge("stdio rpath getpw proc wpath cpath > > > inet ioctl sendfd recvfd", > > > +NULL) == -1) { > > > + fatalx("pledge"); > > > +

Re: [patch] ftpd: pledge(2)

On Sun, Apr 03, 2016 at 06:51:47PM +0200, Theo Buehler wrote: > > > + if (pledge("stdio rpath getpw proc wpath cpath > > > inet ioctl sendfd recvfd", > > > +NULL) == -1) { > > > + fatalx("pledge"); > > > +

Re: [patch] ftpd: pledge(2)

On Sun, Apr 03, 2016 at 06:51:47PM +0200, Theo Buehler wrote: > > > + if (pledge("stdio rpath getpw proc wpath cpath > > > inet ioctl sendfd recvfd", > > > +NULL) == -1) { > > > + fatalx("pledge"); > > > +

amd64: remove savectx() from cpu_fork()

amd64's savectx() only updates pcb_rsp and pcb_rbp, which in cpu_fork() are promptly overwriten in the child's pcb, so do the same simplification as on i386. ok? Philip Guenther Index: vm_machdep.c === RCS file:

Re: [patch] ftpd: pledge(2)

On Sat, Apr 02, 2016 at 04:38:10PM +0200, frit...@alokat.org wrote: > Hi, > > this adds pledge(2) to ftpd(8). > > --f. > With help from semarie@ the original diff was changed a little bit. The following processes are pledged: - [priv post-auth] - User-privileged slave - Unprivileged slave As

Re: uvm: UVM_FLAG_AMAPPAD has no effect anymore, nuke it

On Sun, Apr 03, 2016 at 04:11:40PM +0200, Stefan Kempf wrote: > This flag caused amaps to be allocated with additional spare slots, to > make extending them cheaper. However, the kernel never extends amaps, > so allocating spare slots is pointless. Also UVM_FLAG_AMAPPAD only > has an effect in

Re: [patch] ftpd: pledge(2)

On Sun, Apr 03, 2016 at 06:28:21PM +0200, Sebastien Marie wrote: > On Sun, Apr 03, 2016 at 06:09:21PM +0200, frit...@alokat.org wrote: > > On Sat, Apr 02, 2016 at 04:38:10PM +0200, frit...@alokat.org wrote: > > > Hi, > > > > > > this adds pledge(2) to ftpd(8). > > > > > > --f. > > > > > > >

sqlite c api manpages?

Hi, If you've used the SQLite C library, you're familiar with where their docs live: https://www.sqlite.org/c3ref/intro.html If you're on OpenBSD, you started with "apropos -s3 sqlite3", were shocked that there's nothing there, then moved on to Google with a wounding confusion in your heart.

[pledge] : Add pledge to sail (game)

Index: main.c === RCS file: /cvs/src/games/sail/main.c,v retrieving revision 1.11 diff -u -p -r1.11 main.c --- main.c 8 Jan 2016 20:26:33 - 1.11 +++ main.c 4 Apr 2016 01:19:59 - @@ -45,6 +45,9 @@

Re: spamd - DNS whitelist

Bob Beck wrote: > No. DNS based whitelisting does not belong in there. because it is > slow and DOS'able > > spamd is designed to be high speed low drag. If you want to do a DNS > based whitelist, write a little co-thing that spits one into a file or > into your nospamd table that then spamd

Re: Pledge error handling

Héctor Luis Gimbatti wrote: > I noticed there are (at least 2) diferent ways to handle a pledge > error (eg: /usr/src/usr.bin/): > > If (pledge(args, NULL) == -1) > . err(1, "pledge"); (wc; w; ..) > . perror("pledge"); exit(EXIT_CODE); (vi; openssl; ...) > > I am not familiar with the case of

bpf and dropping packets

this deprecates M_FILDROP. it is only set by bpf, and it is only respected on inbound packets. however, packets may be marked for dropping early, but it only comes into effect very late. this moves the dropping to right after the bpf calls. this is easy now that if_input run bpf on behalf of the

libc: prefer _MUTEX_LOCK() over _THREAD_PRIVATE_MUTEX_LOCK()

libc has a number of macros for dealing with thread safety such that it can operate efficiently when single-threaded but Do The Right Thing when multi-threaded. In include/thread_private.h are two sets of macros that look interchangable but that are quite different on the underside.

Re: Minor style rewrite for crypt.c

Index: crypt.c === RCS file: /cvs/src/lib/libc/crypt/crypt.c,v retrieving revision 1.31 diff -u -p -r1.31 crypt.c --- crypt.c 12 Sep 2015 14:56:50 - 1.31 +++ crypt.c 4 Apr 2016 02:57:09 - @@ -7,15 +7,10 @@ char *

Re: bug in grep

On Sun, Apr 03, 2016 at 10:31:33AM +0200, Martin Natano wrote: > On Sun, Apr 03, 2016 at 09:14:40AM +0200, Otto Moerbeek wrote: > > On Sat, Apr 02, 2016 at 09:13:20PM +, H??ctor Luis Gimbatti wrote: > > > > > Hi, > > > Apparently the error seems to be in /usr/src/usr.bin/grep/util.c at line

Re: amd64: remove savectx() from cpu_fork()

> Date: Sun, 3 Apr 2016 12:04:47 -0700 > From: Philip Guenther > > amd64's savectx() only updates pcb_rsp and pcb_rbp, which in cpu_fork() > are promptly overwriten in the child's pcb, so do the same simplification > as on i386. > > ok? ok kettenis@ > Index: vm_machdep.c

Re: amd64: remove savectx() from cpu_fork()

On Sun, 3 Apr 2016, Philip Guenther wrote: > amd64's savectx() only updates pcb_rsp and pcb_rbp, which in cpu_fork() > are promptly overwriten in the child's pcb, so do the same > simplification as on i386. Thinking about this more, I believe these savectx() calls date from when cpu_fork()

getdelim(3): note update on failure

One small trap to getdelim()/getline() is that the caller needs to free lineptr, even if it NULL when called and the call failed, ala: char *buf = NULL; size_t len = 0; ssize_t ret; ret = getline(, , fp); if (ret == -1) { free(buf);

Re: amd64: remove savectx() from cpu_fork()

On Sun, Apr 3, 2016 at 2:32 PM, Miod Vallat wrote: >> evil about the reset stuff, or just debug bits? m88k also calls it from >> cpu_switchto; other archs have inlined it...) > > The use of savectx() in cpu_switchto on m88k was simply to avoid code > duplication. If you have

new diff for reserved ports checks [2/2] Was: Re: move "privileged port" check out of in(6)_pcbaddrisavail()

On 03/31/16 14:07, Alexander Bluhm wrote: > On Wed, Mar 30, 2016 at 10:44:14PM +0200, Vincent Gross wrote: >> This diff moves the "are we binding to a privileged port while not being >> root ?" >> check from in(6)_pcbaddrisavail() to in_pcbbind(). > >> --- sys/netinet/in_pcb.c 26 Mar 2016

new diff for reserved ports checks [1/2] Was: Re: move "privileged port" check out of in(6)_pcbaddrisavail()

On 03/31/16 14:07, Alexander Bluhm wrote: > On Wed, Mar 30, 2016 at 10:44:14PM +0200, Vincent Gross wrote: >> This diff moves the "are we binding to a privileged port while not being >> root ?" >> check from in(6)_pcbaddrisavail() to in_pcbbind(). > >> --- sys/netinet/in_pcb.c 26 Mar 2016

Re: fdt: translate memory addresses

On Sun, Apr 03, 2016 at 06:56:52PM +0200, Mark Kettenis wrote: > > Date: Sun, 3 Apr 2016 16:57:10 +0200 > > From: Patrick Wildt > > > > Hi, > > > > now we're able to get a node's memory address. Though, a device tree > > may implement so called ranges. Those ranges are used

Re: amd64: remove savectx() from cpu_fork()

> evil about the reset stuff, or just debug bits? m88k also calls it from > cpu_switchto; other archs have inlined it...) The use of savectx() in cpu_switchto on m88k was simply to avoid code duplication. If you have longterm plans involving the demise of savectx(), it can easily be inlined