Re: turn rb tree code into functions in the kernel

this updates the diff after the SLIST changes in uvm. On Thu, Aug 11, 2016 at 10:19:20AM +1000, David Gwynne wrote: > i recently proposed replacing a hash with an rb tree somewhere in > the network stack, but it was pointed out that rb trees are big. > > in hindsight i think the other person was

Re: fuse needs ufs ihash

On Thu, Aug 11, 2016 at 10:48:59AM -0400, Ted Unangst wrote: > Martin Natano wrote: > > I'm already working on a diff to decouple fuse from ufs ihash. In the > > meantime: Make sure the necessary code is compiled in when fuse is > > enabled in the config. > > Are people building kernels with FFS?

Re: [PATCH] let the mbufs use more then 4gb of memory

On 2016-06-23 05:42, Theo de Raadt wrote: secondly, allocating more than 4g at a time to socket buffers is generally a waste of memory. and there is one further problem. Eventually, this subsystem will starve the system. Other subsystems which also need large amounts of memory, then have to

Re: [PATCH] let the mbufs use more then 4gb of memory

> On 1 Aug 2016, at 21:07, Simon Mages wrote: > > I sent this message to dlg@ directly to discuss my modification of his > diff to make the > bigger mbuf clusters work. i got no response so far, thats why i > decided to post it on tech@ > directly. Maybe this way i

Re: [PATCH] let the mbufs use more then 4gb of memory

> Date: Fri, 12 Aug 2016 14:26:34 +0200 > From: Claudio Jeker > > On Fri, Aug 12, 2016 at 04:38:45PM +1000, David Gwynne wrote: > > > > > On 1 Aug 2016, at 21:07, Simon Mages wrote: > > > > > > I sent this message to dlg@ directly to

Re: [PATCH] let the mbufs use more then 4gb of memory

On Fri, Aug 12, 2016 at 04:38:45PM +1000, David Gwynne wrote: > > > On 1 Aug 2016, at 21:07, Simon Mages wrote: > > > > I sent this message to dlg@ directly to discuss my modification of his > > diff to make the > > bigger mbuf clusters work. i got no response so

Re: OpenIKED Keepalive Broken

On Fri, Aug 12, 2016 at 09:56:41PM +0200, fRANz wrote: > On Sat, Aug 6, 2016 at 2:18 AM, William Ahern > wrote: > > isakmpd unconditionally sends NAT-T keepalive messages every 30 seconds, > > whereas iked's ikev2_ike_sa_alive only sends a keepalive message iff > >

Re: jot: use strchr(3) and strspn(3) in getprec()

Theo Buehler writes: > Here's one final diff I have for jot for now: > > Use strchr(3) and strspn(3) instead of handrolled functions. > > Part of dsl@NetBSD's r1.20. ok jca@ -- jca | PGP: 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE

Re: Fix relro coredumps

Mark Kettenis writes: > With relro, certain bits of a process that were mapped into memory as > writable are revreted back to read-only after making some initial > changes. Since the kernel coredump code only writes out writable > pieces of memory, these relro bits are

Fix relro coredumps

With relro, certain bits of a process that were mapped into memory as writable are revreted back to read-only after making some initial changes. Since the kernel coredump code only writes out writable pieces of memory, these relro bits are not written out. Unfortunately these bits contain

Re: Fix relro coredumps

On Fri, Aug 12, 2016 at 2:56 PM, Mark Kettenis wrote: > The diff below fixes that bu also dumping out all the bits that have > an amap allocated. That's a sign that the pages are no longer > pristine and have been written to. > > ok? _There's_ the check, nice! This

Re: OFW/FDT regulator API

I have to admit, it's a bit shocking that VOLTAGE REGULATORS have to be exposed to the software in the first place. Just imagine a bug in some OS or firmware causing the voltages to spike up and fry the hell out of a device. I guess that's modern-day hardware design for you. Mark Kettenis

Re: turn rb tree code into functions in the kernel

David Gwynne wrote: > i recently proposed replacing a hash with an rb tree somewhere in > the network stack, but it was pointed out that rb trees are big. > > in hindsight i think the other person was talking about the size > of an RB_ENTRY inside each thing you're tracking, but it made me > look

Re: acpiec: handle burst mode failure

On Fri, 08 Jul 2016 at 18:51:17 -0500, joshua stein wrote: > If the EC fails to go into burst mode for whatever reason, the Burst > Acknowledge byte will not be there to read, which means the status > won't have EC_STAT_OBF, which means acpiec_wait will spin forever, > hanging the machine. > >

Don't mention 6bone in sshd_config(5)

IPv6 provides a dedicated range for documentation, so let's use it. This is consistent with the IPv4 example. ok? Index: sshd_config.5 === RCS file: /cvs/src/usr.bin/ssh/sshd_config.5,v retrieving revision 1.227 diff -u -p -p -u

Re: [PATCH] let the mbufs use more then 4gb of memory

> From: David Gwynne > Date: Fri, 12 Aug 2016 16:38:45 +1000 > > > On 1 Aug 2016, at 21:07, Simon Mages wrote: > > > > I sent this message to dlg@ directly to discuss my modification of his > > diff to make the > > bigger mbuf clusters work. i

fuse: dedup vnode type

Fuse stores the vnode type in two places: vtype in struct fusefs_node and v_type in struct vnode. Given the fact, that fusefs_node structs are never allocated without an associated vnode and those two fields are always in sync, one of those locations is superfluous. Ok? natano Index:

Re: OFW/FDT regulator API

> I have to admit, it's a bit shocking that VOLTAGE REGULATORS have to be > exposed to the software in the first place. > Just imagine a bug in some OS or firmware causing the voltages to spike > up and fry the hell out of a device. > > I guess that's modern-day hardware design for you. No,

Re: OFW/FDT regulator API

On 2016-08-13 11:34, Theo de Raadt wrote: I have to admit, it's a bit shocking that VOLTAGE REGULATORS have to be exposed to the software in the first place. Just imagine a bug in some OS or firmware causing the voltages to spike up and fry the hell out of a device. I guess that's modern-day

www/60.html missing "syncachelimit"

someone once said tech@ is where patches go and www@ is no longer there... Bye, Marcus Index: 60.html === RCS file: /cvs/www/60.html,v retrieving revision 1.47 diff -u -p -u -r1.47 60.html --- 60.html 10 Aug 2016 13:49:33 -

httpd: be stricter with TLS configuration

The following diff makes httpd stricter with respect to TLS configuration: - Do not allow TLS and non-TLS to be configured on the same port. - Do not allow TLS options to be specified without a TLS listener. - Ensure that TLS options are the same when a server is specified on the same

Re: per cpu memory in the kernel

On 08/11/16 06:43, David Gwynne wrote: > ive been tinkering with per cpu memory in the kernel > [...] I'd like to have more people comment on this because we need an MP-safe way to handle counters in the network stack. > im still debating whether the API should do protection against > interrupts

Fwd: jot: remove crazy switch inside while loop

Any comment, support or objection on this one? I'm aware that this diff is hard to review, but doing it in several steps won't simplify the main step all that much, I think. The regression tests cover this part of the code quite well, I think. - Forwarded message from Theo Buehler

Re: Fwd: jot: remove crazy switch inside while loop

Theo Buehler wrote: > Any comment, support or objection on this one? > > I'm aware that this diff is hard to review, but doing it in several > steps won't simplify the main step all that much, I think. > > The regression tests cover this part of the code quite well, I think. move fast and break

Re: Fwd: jot: remove crazy switch inside while loop

> Theo Buehler wrote: > > Any comment, support or objection on this one? > > > > I'm aware that this diff is hard to review, but doing it in several > > steps won't simplify the main step all that much, I think. > > > > The regression tests cover this part of the code quite well, I think. > >

Re: fuse: dedup vnode type

> Index: miscfs/fuse/fusefs_node.h > === > RCS file: /cvs/src/sys/miscfs/fuse/fusefs_node.h,v > retrieving revision 1.2 > diff -u -p -r1.2 fusefs_node.h > --- miscfs/fuse/fusefs_node.h 1 Feb 2014 09:30:38 - 1.2 > +++

Re: per cpu memory in the kernel

> From: Martin Pieuchot > Date: Fri, 12 Aug 2016 20:44:04 +0200 > > On 08/11/16 06:43, David Gwynne wrote: > > ive been tinkering with per cpu memory in the kernel > > [...] > > I'd like to have more people comment on this because we need an MP-safe > way to handle counters in

OFW/FDT regulator API

The diff below adds a simple "regulator" API, Regulators are devices that apply voltage and/or current to subsystems to power them on. Examples are applying voltage to an SD card, powering a USB bus, turning on an Ethernet PHY, scaling the CPU voltage. Regulators come in many flavours. The

jot: use strchr(3) and strspn(3) in getprec()

Here's one final diff I have for jot for now: Use strchr(3) and strspn(3) instead of handrolled functions. Part of dsl@NetBSD's r1.20. Index: jot.c === RCS file: /cvs/src/usr.bin/jot/jot.c,v retrieving revision 1.33 diff -u -p