Re: In amsdu_decap(), check for n->m_pkthdr.len == 0, not n->m_len == 0

On Tue, Jan 24, 2017 at 03:34:59PM +0100, Imre Vadász wrote: > Since m_split() in some cases returns an mbuf chain, where the pkthdr element > contains no data (i.e. m_len == 0), the n->m_len == 0 check in > sys/net80211/ieee80211_input.c in the amsdu_decap() function sometimes > signals the end

Re: tcpdump(63969): syscall 54 "tty"

On Tue, Jan 24, 2017 at 03:32:25PM +0100, Hrvoje Popovski wrote: > Hi all, > > every time when quitting tcpdump with ^C i see that log on console. > Source is fetched few minutes ago ... > > Don't know is this good or bad so i'm sending it here .. > > tcpdump(63969): syscall 54 "tty" >

Re: pool_debug

Not sure I get it, the rwlock when is not released when you yield()). So this will in fact context switch holding the rwlock for every pool_get(). Did I miss another a change ? On Tue, 24 Jan 2017 at 07:48, Martin Pieuchot wrote: > I'd like to force a yield() for every

freestanding take 2, part 2

So here is a diff that starts using -ffreestanding on amd64 and brings arm64 and armv7 (which are already using -ffreestanding) in line with amd64. I'd like to get this in to give it some exposure before I start converting the other architectures. Index: arch/amd64/conf/Makefile.amd64

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

On Mon, Jan 23, 2017 at 11:46:52PM GMT, Theo de Raadt wrote: > > 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

Re: document that RES_USE_EDNS0 and RES_USE_DNSSEC currently do nothing

On Tue, Jan 24, 2017 at 09:02:46AM +0100, Kirill Miazine wrote: > > Let's give it another try: > a little inconsistency here... we already note that edns does nothing in resolv.conf(5) but that file makes no mention of dnssec. so i'm not sure if something needs to be added to resolv.conf(5)

Re: document that RES_USE_EDNS0 and RES_USE_DNSSEC currently do nothing

Kirill Miazine writes: > * Kirill Miazine [2017-01-24 08:26]: >>> Index: lib/libc/net/resolver.3 >>> === >>> RCS file: /cvs/src/lib/libc/net/resolver.3,v >>> retrieving revision 1.33 >>> diff -u -p -r1.33 resolver.3

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

> Another way to look at it is, "Let me have a look if there's anything > new on faq/current.html - I open the page and, *without* moving > forward, can see straight away if something new has been added. No? > Then I move on with my life without scrolling down or doing anything > else apart from

Re: document that RES_USE_EDNS0 and RES_USE_DNSSEC currently do nothing

* Kirill Miazine [2017-01-24 08:26]: >> Index: lib/libc/net/resolver.3 >> === >> RCS file: /cvs/src/lib/libc/net/resolver.3,v >> retrieving revision 1.33 >> diff -u -p -r1.33 resolver.3 >> --- lib/libc/net/resolver.3 16 Dec 2015

Re: pool_debug

On Tue, 24 Jan 2017 at 09:14, Martin Pieuchot wrote: > On 24/01/17(Tue) 08:06, Christiano F. Haesbaert wrote: > > > Not sure I get it, the rwlock when is not released when you yield()). So > > > this will in fact context switch holding the rwlock for every pool_get(). > > > Did

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

> Date: Tue, 24 Jan 2017 15:39:49 +1000 > From: Philip Guenther > > 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

Re: freestanding take 2, part 2

Mark Kettenis writes: > So here is a diff that starts using -ffreestanding on amd64 and brings > arm64 and armv7 (which are already using -ffreestanding) in line with > amd64. > > I'd like to get this in to give it some exposure before I start > converting the other

Re: pool_debug

On 24/01/17(Tue) 08:06, Christiano F. Haesbaert wrote: > Not sure I get it, the rwlock when is not released when you yield()). So > this will in fact context switch holding the rwlock for every pool_get(). > Did I miss another a change ? That's true. I'd like to know when that happens and where.

Re: document that RES_USE_EDNS0 and RES_USE_DNSSEC currently do nothing

Jason McIntyre writes: > On Tue, Jan 24, 2017 at 09:02:46AM +0100, Kirill Miazine wrote: >> >> Let's give it another try: >> > > a little inconsistency here... we already note that edns does nothing in > resolv.conf(5) but that file makes no mention of dnssec. so i'm not

Re: pool_debug

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? Is there an assertwaitok() missing? Indeed there is. I think that should be added,

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

On Tue, 24 Jan 2017, Mark Kettenis wrote: ... > Looks ok to me. However: > > > @@ -57,6 +57,8 @@ int _dl_getcwd(char *, size_t); > > int_dl_utrace(const char *, const void *, size_t); > > int_dl_getentropy(char *, size_t); > > int_dl_sendsyslog(const char *,

armv7 stack size bump

The following diff applies to armv7 the same stack limits as on i386. Not touching MAXDSIZ for now. Comments / ok? Index: arch/armv7/include/vmparam.h === RCS file: /d/cvs/src/sys/arch/armv7/include/vmparam.h,v retrieving revision

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

> On 2017/01/24 09:06, Raf Czlonka wrote: > > Another way to look at it is, "Let me have a look if there's anything > > new on faq/current.html - I open the page and, *without* moving > > forward, can see straight away if something new has been added. > > Since we've been doing it the other way

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

> Date: Tue, 24 Jan 2017 19:38:11 +1000 > From: Philip Guenther > > On Tue, 24 Jan 2017, Mark Kettenis wrote: > ... > > Looks ok to me. However: > > > > > @@ -57,6 +57,8 @@ int _dl_getcwd(char *, size_t); > > > int _dl_utrace(const char *, const void *, size_t); >

NET_LOCK() for bpf(4)

ok? Index: net/bpf.c === RCS file: /cvs/src/sys/net/bpf.c,v retrieving revision 1.158 diff -u -p -r1.158 bpf.c --- net/bpf.c 9 Jan 2017 19:15:01 - 1.158 +++ net/bpf.c 21 Jan 2017 00:55:26 - @@ -624,9 +624,9 @@

Re: no pointer sign warnings

Perhaps. Also my position remains that our tree should not avoid -Werror. It is unmanageable with the number of architectures we support. > clang complains about pointer sign changes The most simple fix > would be to disable the warning for clang. > > Example from librthread: > >

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

On 01/24/17 04:08, Theo de Raadt wrote: Another way to look at it is, "Let me have a look if there's anything new on faq/current.html - I open the page and, *without* moving forward, can see straight away if something new has been added. No? Then I move on with my life without scrolling down or

no pointer sign warnings

Hi, clang complains about pointer sign changes The most simple fix would be to disable the warning for clang. Example from librthread: /home/patrick/openbsd-src/lib/librthread/rthread_sem.c:316:13: error: passing 'const char *' to parameter of type 'const u_int8_t *' (aka 'const unsigned char

realloc(3) and MALLOC_MOVE

Hi, malloc(3) has the nice feature to move (subject to alignment constraints) allocations that are between the max chunk size (half a page) and a page size towards the end of the allocated page, to catch more buffer overflows. Due to the allocation being higher up within a page, buffer overflows

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

On 2017/01/24 09:06, Raf Czlonka wrote: > Another way to look at it is, "Let me have a look if there's anything > new on faq/current.html - I open the page and, *without* moving > forward, can see straight away if something new has been added. Since we've been doing it the other way for 12 years,

Re: refactor PF option parsing loops

Hello Richard, > 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. what is the reason to keep function definition in pfvar_priv.h? I would expect to stick

Re: document that RES_USE_EDNS0 and RES_USE_DNSSEC currently do nothing

On Tue, Jan 24, 2017 at 08:13:07AM +, Jason McIntyre wrote: > On Tue, Jan 24, 2017 at 09:02:46AM +0100, Kirill Miazine wrote: > > > > Let's give it another try: > > > > a little inconsistency here... we already note that edns does nothing in > resolv.conf(5) but that file makes no mention

Re: httpd TLS ticket support

On Tue, Jan 24, 2017 at 07:52:07AM +0100, Reyk Floeter wrote: > > > 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. > New version that

Re: httpd TLS ticket support

> On 24.01.2017, at 12:44, Claudio Jeker wrote: > > On Tue, Jan 24, 2017 at 07:52:07AM +0100, Reyk Floeter wrote: >> >>> Am 24.01.2017 um 02:54 schrieb Claudio Jeker : >>> >>> Since I just added ticket support to libtls here is a diff to

pfctl: Kill states within a rdomain

Hi, This patch fix `pfctl` to be able to kill states within a rdomain. Currently only states in rdomain 0 can be kill when using host or label because check is done in ioctl DIOCKILLSTATES sys/net/pf_ioctl.c: `psk->psk_rdomain == sk->rdomain` I used -V like `arp`, `ping`... but it could be

Re: tcpdump(63969): syscall 54 "tty"

On 24.1.2017. 19:03, Sebastien Marie wrote: > On Tue, Jan 24, 2017 at 03:32:25PM +0100, Hrvoje Popovski wrote: >> Hi all, >> >> every time when quitting tcpdump with ^C i see that log on console. >> Source is fetched few minutes ago ... >> >> Don't know is this good or bad so i'm sending it here

Re: Special rules for early-open fd's in pledge

> 2. vmd calls openpty() in the pledged parent whenever a new VM is > started - effectively doing ioctls on post-pledge fds. I will > probably solve this by opening the pty in the non-pledged "priv" > process, and do some additional passing, but then I'll also have to > give up its chroot to

Re: Special rules for early-open fd's in pledge

> On Wed, Jan 25, 2017 at 12:33:36AM -0700, Theo de Raadt wrote: > > > 2. vmd calls openpty() in the pledged parent whenever a new VM is > > > started - effectively doing ioctls on post-pledge fds. I will > > > probably solve this by opening the pty in the non-pledged "priv" > > > process, and do

Re: pr_input var args

On Wed, 25 Jan 2017, Alexander Bluhm wrote: > Now since raw_input() and route_input() are gone from pr_input, we can > make the variable parameters of the protocol input functions fixed. I > have decided to add the proto to make it similar to IPv6. My goal is to > have one struct protosw for

Help with the NET_LOCK()

I just enabled the NET_LOCK() again and I'm looking for test reports. Please go build a kernel from sources or wait for the next snapshot, run it and report back. If you're looking for some small coding tasks related to the NET_LOCK() just do: # sysctl kern.splassert=2 # sysctl

Re: Special rules for early-open fd's in pledge

Hi, two notes about vmd with this diff: 1. "vmm" pledge can be !fdpledged as well as it already pre-opens the /dev/vmm fd for ioctls. I added the following chunk on top of your diff and it works as expected: ---snip--- if ((p->p_p->ps_pledge & PLEDGE_VMM)) { #if NVMM > 0 -

Re: Special rules for early-open fd's in pledge

On Wed, Jan 25, 2017 at 12:33:36AM -0700, Theo de Raadt wrote: > > 2. vmd calls openpty() in the pledged parent whenever a new VM is > > started - effectively doing ioctls on post-pledge fds. I will > > probably solve this by opening the pty in the non-pledged "priv" > > process, and do some

pr_input var args

Hi, Now since raw_input() and route_input() are gone from pr_input, we can make the variable parameters of the protocol input functions fixed. I have decided to add the proto to make it similar to IPv6. My goal is to have one struct protosw for both IP versions. ok? bluhm Index:

Re: refactor PF option parsing loops

On 24/01/17(Tue) 14:43, 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 strips ~100 lines. I like it. > I've laid out the existing semantics below. The

Re: Two fixes for m_split() in sys/kern/uipc_mbuf.c.

On Tue, Jan 24, 2017 at 03:22:13PM +0100, Imre Vad?sz wrote: > This patch fixes two issues in m_split() in sys/kern/uipc_mbuf.c, which > are correctly handled in FreeBSD's m_split(): OK bluhm@ > > If the m_split() would split an mbuf chain exactly between 2 mbufs (i.e. > remain == 0), the

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

On Tue, 24 Jan 2017 15:39:49 +1000, Philip Guenther wrote: I see this is already in but one minor nit below. > Index: dl_printf.c > === > RCS file: /cvs/src/libexec/ld.so/dl_printf.c,v > retrieving revision 1.18 > diff -u -p -r1.18

minor mount.c cleanup

* check strdup for malloc failure * remove obvious /* NOTREACHED */ * return instead of exit from main * err(1, NULL) instead of err(1, "malloc") * mark usage as __dead Index: mount.c === RCS file: /cvs/src/sbin/mount/mount.c,v

Re: global mbuf memory limit

On Tue, Jan 24, 2017 at 03:26:42PM +0100, Alexander Bluhm wrote: > On Tue, Jan 24, 2017 at 05:46:31PM +1000, David Gwynne wrote: > > > Apart from the problem that I don't know wether the mutex kills > > > performance, the diff looks good. > > > > the tests ive done and simon mages has done show a

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

On Tue, 24 Jan 2017, Todd C. Miller wrote: > On Tue, 24 Jan 2017 15:39:49 +1000, Philip Guenther wrote: ... > > +static char ldso[] = "ld.so: "; > > Any reason this can't be const? Good catch, ok guenther@

Re: pfctl: Kill states within a rdomain

Hi, thanks, i like this. but your diff does not seem to be against -current, you started from 6.0 But even with 6.0 i get rejects, maybe you mail client messes this up. Can you please resend a good diff? /Benno Bertrand Provost(provost.bertr...@gmail.com) on 2017.01.24 16:53:02 -0500: >

Re: minor mount.c cleanup

On Wed, Jan 25, 2017 at 10:29:47AM +1000, Theo Buehler wrote: > * check strdup for malloc failure > * remove obvious /* NOTREACHED */ > * return instead of exit from main > * err(1, NULL) instead of err(1, "malloc") > * mark usage as __dead Sorry, I sent the wrong version of the diff with an

Special rules for early-open fd's in pledge

Here is the proposed ioctl lock-down policy for file descriptors allocated in a process before pledge(2). The manual page diff is first, that explains the direction this is going. The other supporting code has been commited already, so feel free to take this for a ride and let's see what

Re: global mbuf memory limit

On Tue, Jan 24, 2017 at 05:46:31PM +1000, David Gwynne wrote: > > Apart from the problem that I don't know wether the mutex kills > > performance, the diff looks good. > > the tests ive done and simon mages has done show a slight benefit. > id expect to see that grow as we use pools more

Re: NET_LOCK() for bpf(4)

On 24.1.2017. 10:59, Martin Pieuchot wrote: > ok? > > Index: net/bpf.c > === > RCS file: /cvs/src/sys/net/bpf.c,v > retrieving revision 1.158 > diff -u -p -r1.158 bpf.c > --- net/bpf.c 9 Jan 2017 19:15:01 - 1.158 > +++

In amsdu_decap(), check for n->m_pkthdr.len == 0, not n->m_len == 0

Since m_split() in some cases returns an mbuf chain, where the pkthdr element contains no data (i.e. m_len == 0), the n->m_len == 0 check in sys/net80211/ieee80211_input.c in the amsdu_decap() function sometimes signals the end of the AMSDU frame too early. Instead it should check the actual

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

On 01/24/17 04:06, Raf Czlonka wrote: ... > Another way to look at it is, "Let me have a look if there's anything > new on faq/current.html - I open the page and, *without* moving > forward, can see straight away if something new has been added. No? > Then I move on with my life without scrolling

Two fixes for m_split() in sys/kern/uipc_mbuf.c.

This patch fixes two issues in m_split() in sys/kern/uipc_mbuf.c, which are correctly handled in FreeBSD's m_split(): If the m_split() would split an mbuf chain exactly between 2 mbufs (i.e. remain == 0), the returned M_PKTHDR might unnecessarily reference an mbuf cluster from the first part of

tcpdump(63969): syscall 54 "tty"

Hi all, every time when quitting tcpdump with ^C i see that log on console. Source is fetched few minutes ago ... Don't know is this good or bad so i'm sending it here .. OpenBSD 6.0-current (GENERIC.MP) #15: Tue Jan 24 15:09:53 CET 2017