Re: dev/i2c: nxptda(4)

On Tue, Aug 23, 2016 at 12:44:03AM -0400, Ian Sutton wrote: > On Fri, Aug 19, 2016 at 03:02:34PM +1000, Jonathan Gray wrote: > > On Fri, Aug 19, 2016 at 02:38:32PM +1000, Jonathan Gray wrote: > > > On Thu, Aug 18, 2016 at 04:34:38PM -0400, Ian Sutton wrote: > > > > On Sat, Aug 06, 2016 at

Re: dev/i2c: nxptda(4)

On Fri, Aug 19, 2016 at 03:02:34PM +1000, Jonathan Gray wrote: > On Fri, Aug 19, 2016 at 02:38:32PM +1000, Jonathan Gray wrote: > > On Thu, Aug 18, 2016 at 04:34:38PM -0400, Ian Sutton wrote: > > > On Sat, Aug 06, 2016 at 04:26:27AM -0400, Ian Sutton wrote: > > > > Interestingly, the am335x SoC

Re: ld.so initarray support

On Mon, 22 Aug 2016, Mark Kettenis wrote: ... > +void > +_dl_run_dtors(elf_object_t *obj) > +{ > + if (obj->dyn.fini_array) { > + int num = obj->dyn.fini_arraysz / sizeof(Elf_Addr); > + int i; > + > + DL_DEB(("doing finiarray obj %p @%p: [%s]\n", > +

pax: stop getting mode via strcmp(argv0)

pax, tar, and cpio are one binary that changes behavior based on the last component of argv[0]. Lots of shared code, so sure, but I find the strcmp() tests in the main code overly complex and perhaps an affront to clear style. (It's _not_ really a perf issue, as in per-file processing it

Add libtls functionality for OCSP, and OCSP stapling support - take 2

On Tue, Jul 05, 2016 at 09:11:37PM -0600, Bob Beck wrote: > Ok, so this work was done by Marko Kreen, all as the result of a very long > discussion in: > > https://github.com/libressl-portable/openbsd/pull/47 > > In a nutshell, I threw down a glove that libtls could have functions to > support

Re: multi-pool malloc wip diff

Otto Moerbeek wrote: > > After a forkl of a threaded program __isthreaded is reset, but > existing allocations are spread around the pools. But the new single > threaded child only looks in the first pool. I have to think how to > solve this. Create a new flag, _malloc_threads. Init to 0.

Re: ld.so initarray support

> Date: Sun, 21 Aug 2016 16:35:21 -0700 > From: Philip Guenther > > On Fri, 19 Aug 2016, Mark Kettenis wrote: > > > From: Philip Guenther > > > Date: Thu, 18 Aug 2016 21:09:10 -0700 > > > > > > On Thursday, August 18, 2016, Mark Kettenis

Re: smtpd: log ip/hostname for failed-command events

Dear all, I have local patch which implements IP/hostname logging for all SMTP operations. It simplifies log processing for me since I don't have to keep reference between session ids and IPs/hostnames and check it every time I need to check who's originating given SMTP transaction. Does it make

Re: multi-pool malloc wip diff

On Mon, Aug 22, 2016 at 08:37:30PM +0200, Otto Moerbeek wrote: > On Mon, Aug 22, 2016 at 07:35:49PM +0200, Otto Moerbeek wrote: > > > On Mon, Aug 22, 2016 at 07:07:21PM +0200, Gregor Best wrote: > > > > > On Mon, Aug 22, 2016 at 05:03:34PM +0200, Otto Moerbeek wrote: > > > > On Mon, Aug 22,

Re: multi-pool malloc wip diff

On Mon, Aug 22, 2016 at 07:07:21PM +0200, Gregor Best wrote: > On Mon, Aug 22, 2016 at 05:03:34PM +0200, Otto Moerbeek wrote: > > On Mon, Aug 22, 2016 at 05:00:12PM +0200, Otto Moerbeek wrote: > > > > > Hmm, indeed, looking into it. > > > > Fixed diff now online, > > [...] > > With that one,

Re: multi-pool malloc wip diff

On Mon, Aug 22, 2016 at 05:03:34PM +0200, Otto Moerbeek wrote: > On Mon, Aug 22, 2016 at 05:00:12PM +0200, Otto Moerbeek wrote: > > > Hmm, indeed, looking into it. > > Fixed diff now online, > [...] With that one, Firefox and Chromium work fine. There's a problem with Gimp though: $ gimp

Re: bigger mbuf clusters for sosend()

On 22.8.2016. 8:20, David Gwynne wrote: > >> On 22 Aug 2016, at 03:36, Hrvoje Popovski wrote: >> >> On 13.8.2016. 10:59, Claudio Jeker wrote: >>> This diff refactors the uio to mbuf code to make use of bigger buffers (up >>> to 64k) and also switches the MCLGET to use M_WAIT like

Re: multi-pool malloc wip diff

On Mon, Aug 22, 2016 at 05:00:12PM +0200, Otto Moerbeek wrote: > Hmm, indeed, looking into it. Fixed diff now online, -Otto

Re: Fewer in6_selectsrc() / struct route_in6

On Mon, Aug 22, 2016 at 01:50:53PM +0200, Martin Pieuchot wrote: > Diff below replace in6_selectsrc() by rtalloc(9) for source address > selection when send NS and NA. OK bluhm@ > While this can be a controversial change, it's the only way I found to > move forward to change the existing route

Re: multi-pool malloc wip diff

6c70 in pthread_attr_destroy (attrp=0x7f7c3850) at > /usr/src/lib/librthread/rthread_attr.c:64 > [... other stuff omitted from here on ...] > > Is the diff (I chose malloc-20160822.dif) missing a librthread change? Hmm, indeed, looking into it. -Otto > > -- > Gregor > -- > > For those who like this sort of thing, this is the sort of thing they like. > -- Abraham Lincoln

Re: ip_icmp reference fix

On Mon, Aug 22, 2016 at 01:21:47PM +0200, Martin Pieuchot wrote: > When it comes to reference counting in the receiving path, route entries > act as proxy for interface addresses. In other words you CANNOT > dereference ``rt->rt_ifa'' after calling rtfree(9). > > Diff below fixes that in

Re: Do not use 'struct route_in6'

On Mon, Aug 22, 2016 at 12:58:31PM +0200, Martin Pieuchot wrote: > I'd like to implement a route caching mechanism that works with PF state > keys and always pick newest more specific route when available. > > In order to do so I need to get rid of the 'struct route'. The problem > of the

Re: multi-pool malloc wip diff

dlib/malloc.c:1390 #4 0x0c2760446c70 in pthread_attr_destroy (attrp=0x7f7c3850) at /usr/src/lib/librthread/rthread_attr.c:64 [... other stuff omitted from here on ...] Is the diff (I chose malloc-20160822.dif) missing a librthread change? -- Gregor -- For those who like this

Re: ip_icmp reference fix

On Mon, Aug 22, 2016 at 01:21:47PM +0200, Martin Pieuchot wrote: > When it comes to reference counting in the receiving path, route entries > act as proxy for interface addresses. In other words you CANNOT > dereference ``rt->rt_ifa'' after calling rtfree(9). > > Diff below fixes that in

Re: per cpu memory in the kernel

On 17/08/16(Wed) 22:19, David Gwynne wrote: > On Wed, Aug 17, 2016 at 09:13:04PM +1000, David Gwynne wrote: > > On Wed, Aug 17, 2016 at 08:27:19PM +1000, David Gwynne wrote: > > > On Thu, Aug 11, 2016 at 02:43:16PM +1000, David Gwynne wrote: > > > > ive been tinkering with per cpu memory in the

Re: Correct order of route removal

On 08/08/16(Mon) 11:48, Martin Pieuchot wrote: > The rtable_walk() & prio bug I just sent a fix for should theoretically > not cause any trouble. Sadly it is piled on top of another bug for > which a fix is attached. > > When an interface is removed the current code starts by purging all its >

Re: MP-safe L2 "lookup" w/o atomic operation

On Mon, Aug 22, 2016 at 12:20:17PM +0200, Martin Pieuchot wrote: > @@ -1495,17 +1512,17 @@ nd6_resolve(struct ifnet *ifp, struct rt > - error = rt_checkgate(rt0, ); > - if (error) { > + rt = rt_getll(rt0); > + > + if (ISSET(rt->rt_flags, RTF_REJECT)) { > m_freem(m); >

Re: ip_icmp reference fix

Martin Pieuchot writes: > When it comes to reference counting in the receiving path, route entries > act as proxy for interface addresses. In other words you CANNOT > dereference ``rt->rt_ifa'' after calling rtfree(9). > > Diff below fixes that in icmp_reflect(), ok? ok jca@

Re: Do not use 'struct route_in6'

Martin Pieuchot writes: > I'd like to implement a route caching mechanism that works with PF state > keys and always pick newest more specific route when available. > > In order to do so I need to get rid of the 'struct route'. The problem > of the 'struct route' is that you

Re: ftp: avoid casts in networking functions

"Todd C. Miller" writes: > On Sun, 21 Aug 2016 14:23:33 -0600, "Todd C. Miller" wrote: > >> We could get rid of struct sockinet entirely but I wasn't sure > it > was worth it. > > Here's a diff that replaces sockunion with the more common > sockaddr_union. ok jca@ --

Fewer in6_selectsrc() / struct route_in6

Diff below replace in6_selectsrc() by rtalloc(9) for source address selection when send NS and NA. While this can be a controversial change, it's the only way I found to move forward to change the existing route caching mechanism. My goal is to stop passing a 'struct route{_in6}' to

ip_icmp reference fix

When it comes to reference counting in the receiving path, route entries act as proxy for interface addresses. In other words you CANNOT dereference ``rt->rt_ifa'' after calling rtfree(9). Diff below fixes that in icmp_reflect(), ok? Index: netmpls/mpls_input.c

Do not use 'struct route_in6'

I'd like to implement a route caching mechanism that works with PF state keys and always pick newest more specific route when available. In order to do so I need to get rid of the 'struct route'. The problem of the 'struct route' is that you have to pass it to ip{,6}_output() which might change

Re: MP-safe L2 "lookup" w/o atomic operation

On 19/08/16(Fri) 19:19, Alexander Bluhm wrote: > On Mon, Aug 15, 2016 at 01:52:46PM +0200, Martin Pieuchot wrote: > > More tests, comments, ok are welcome. > > There is an issue with path mtu discovery that my regression test > found, but i think that can be fixed with this diff in tree. I

Re: smtpd 5.9.1 vs 6.0 & possible corner case / regression

On 08/20/16 10:03, Anthony La Porte wrote: On Sat, 20 Aug 2016, Eric Faurot wrote: Can you guys try this diff? With this hostname and message-id are back. Thanks! +1 - cheers. - C

Re: multi-pool malloc wip diff

On Wed, May 11, 2016 at 10:04:48AM +0200, Otto Moerbeek wrote: > On Fri, Apr 29, 2016 at 08:42:00AM +0200, Otto Moerbeek wrote: > > > Hi, > > > > new diff in http://www.drijf.net/openbsd/malloc/ > > > > Should fix the issue Ted spotted and contains initial code to only set > > up multiple

Re: bigger mbuf clusters for sosend()

> On 22 Aug 2016, at 03:36, Hrvoje Popovski wrote: > > On 13.8.2016. 10:59, Claudio Jeker wrote: >> This diff refactors the uio to mbuf code to make use of bigger buffers (up >> to 64k) and also switches the MCLGET to use M_WAIT like the MGET calls in >> the same function. I see

Re: add option for disabling TLS session tickets to libttls

On Sun, Aug 21, 2016 at 02:25:15PM -0400, Ted Unangst wrote: > Andreas Bartelt wrote: > > Since the use of TLS session tickets potentially interferes with forward > > secrecy on a per-session basis, I'd personally prefer an opt-in in > > libtls as well as in httpd with regard to its usage.