let the pool gc reclaim items from the per cpu caches

this diff lets the pool gc reclaim idle memory held by cpu caches. it does this by recording when the global depot of items was first added to. the gc checks that timestamp and if the depot hasnt been emptied again in the last 4 seconds, it moves a list of items from the depot back to the pools

remove more obsolete emulation hooks

Emulation had multiple sets of hooks; here's the diff to kill the hooks used at exec, fork, and exit time, as they are always NULL. ok? Philip Index: sys/proc.h === RCS file: /cvs/src/sys/sys/proc.h,v retrieving revision 1.232

ipsec protocol input callbacks

Hi, Remove the ipsec protocol callbacks which all do the same. Implement it in ipsec_common_input_cb() instead. The code that was copied to ah6_input_cb() is now in ip6_ours() so we can call it directly. ok? bluhm Index: netinet/ipsec_input.c

Re: PF & CPU hogging

Martin Pieuchot wrote: > On 07/02/17(Tue) 10:29, Ted Unangst wrote: > > Martin Pieuchot wrote: > > > PF has its own home-brewed solution for dealing with CPU hogging. It > > > has been introduced in r1.88 of net/pf_table.c and I couldn't find any > > > explanation why it is different than the

ipsec void functions

Hi, Error propagation does neither make sense for ip input path nor for asynchronous callbacks. Make the IPsec functions void, there is already a counter in the error path. ok? bluhm Index: netinet/ip_ipsp.h === RCS file:

Re: tcpstat percpu counters

On Mon, Feb 06, 2017 at 07:44:23PM +0100, Jeremie Courreges-Anglas wrote: > Revised after the change in the counters api. Passed make release on > amd64, runtime tested on GENERIC armv7 and GENERIC.MP amd64. OK bluhm@ > > > Index: net/pf.c >

Re: ipsec output failure counter

OK once the XXX from ip_esp.c is removed too. On Tue, Feb 07, 2017 at 06:15:03PM +0100, Alexander Bluhm wrote: > Hi, > > As mentioned before, IPsec packets could be dropped unaccounted if > output after crypto failed. Add a counter for that case. > > ok? > > bluhm > > Index:

ipsec output failure counter

Hi, As mentioned before, IPsec packets could be dropped unaccounted if output after crypto failed. Add a counter for that case. ok? bluhm Index: sys/netinet/ip_ah.c === RCS file: /data/mirror/openbsd/cvs/src/sys/netinet/ip_ah.c,v

divert(4) percpu counters

Could someone who uses divert socket confirm that this diff works fine? ok? Index: netinet/ip_divert.c === RCS file: /d/cvs/src/sys/netinet/ip_divert.c,v retrieving revision 1.43 diff -u -p -r1.43 ip_divert.c ---

libressl-2.5.1 patches

libressl-2.5.1-medusade.tar.gz Description: GNU Zip compressed data

Re: PF & CPU hogging

On 07/02/17(Tue) 10:29, Ted Unangst wrote: > Martin Pieuchot wrote: > > PF has its own home-brewed solution for dealing with CPU hogging. It > > has been introduced in r1.88 of net/pf_table.c and I couldn't find any > > explanation why it is different than the idiom we use in other places. > >

Re: PF & CPU hogging

Martin Pieuchot wrote: > PF has its own home-brewed solution for dealing with CPU hogging. It > has been introduced in r1.88 of net/pf_table.c and I couldn't find any > explanation why it is different than the idiom we use in other places. oh, just because i didn't bother making them all the

Re: SOCKET_LOCK makes his come back

On 07/02/17(Tue) 13:54, Martin Pieuchot wrote: > Now that we found and fixed multiple deadlocks involving the NET_LOCK() > and unix domain sockets, let's do as if it wasn't strictly necessary. > > The NET_LOCK() has been introduced to prevent the softnet thread to run > while a userland process

SOCKET_LOCK makes his come back

Now that we found and fixed multiple deadlocks involving the NET_LOCK() and unix domain sockets, let's do as if it wasn't strictly necessary. The NET_LOCK() has been introduced to prevent the softnet thread to run while a userland process is pushing packets down into the Network Stack. This do

11n hostap: enable short slot time

This diff enables short slot time, accidentally left disabled in 11n mode. Short vs. long slot time controls the (very small) amount of time devices spend waiting between frame transmissions. The only wifi devices which do not support short slot time are 11b ones. Index: ieee80211_proto.c

Re: specify curves via ecdhe statement in httpd.conf

On Monday 06 February 2017 20:18:48 Andreas Bartelt wrote: > Yes, right - thanks. I wasn't aware that this is actually a MUST > requirement from RFC 4492. I'm quite surprised that the "Supported > Elliptic Curves Extension" is also used in order to specify any allowed > curves for use in the

Re: Add quirks to support M-Audio FastTrack Pro (uaudio)

On 03/02/17(Fri) 12:06, Christopher Zimmermann wrote: > [...] > > > > > @@ -444,6 +447,11 @@ uaudio_match(struct device *parent, void > > > > > if (uaa->iface == NULL || uaa->device == NULL) > > > > > return (UMATCH_NONE); > > > > > > > > > > + if (uaa->vendor ==

Re: PF & CPU hogging

On 07/02/17(Tue) 11:15, Mike Belopuhov wrote: > On 7 February 2017 at 10:12, Martin Pieuchot wrote: > > On 06/02/17(Mon) 17:18, Mike Belopuhov wrote: > >> On 6 February 2017 at 17:02, Martin Pieuchot wrote: > >> > PF has its own home-brewed solution for

Re: PF & CPU hogging

On 7 February 2017 at 11:14, Martin Pieuchot wrote: > On 07/02/17(Tue) 11:03, Mike Belopuhov wrote: >> On 7 February 2017 at 10:13, Martin Pieuchot wrote: >> > On 06/02/17(Mon) 17:19, Mike Belopuhov wrote: >> >> On 6 February 2017 at 17:02, Martin Pieuchot

Re: PF & CPU hogging

On 07/02/17(Tue) 11:03, Mike Belopuhov wrote: > On 7 February 2017 at 10:13, Martin Pieuchot wrote: > > On 06/02/17(Mon) 17:19, Mike Belopuhov wrote: > >> On 6 February 2017 at 17:02, Martin Pieuchot wrote: > >> > PF has its own home-brewed solution for

Re: PF & CPU hogging

On 7 February 2017 at 10:12, Martin Pieuchot wrote: > On 06/02/17(Mon) 17:18, Mike Belopuhov wrote: >> On 6 February 2017 at 17:02, Martin Pieuchot wrote: >> > PF has its own home-brewed solution for dealing with CPU hogging. It >> > has been introduced in

Re: PF & CPU hogging

On 7 February 2017 at 10:13, Martin Pieuchot wrote: > On 06/02/17(Mon) 17:19, Mike Belopuhov wrote: >> On 6 February 2017 at 17:02, Martin Pieuchot wrote: >> > PF has its own home-brewed solution for dealing with CPU hogging. It >> > has been introduced in

Re: Xorg vs wifi scanning

On Mon, Feb 06, 2017 at 03:54:56PM +0100, Martin Pieuchot wrote: > On 06/02/17(Mon) 12:27, Martin Pieuchot wrote: > > Paul and Antoine reported that, since the NET_LOCK() went in, doing a > > channel scan with iwm(4) and iwn(4) freezes X. > > > > This is a deadlock due to the fact that wireless

Re: PF & CPU hogging

On 06/02/17(Mon) 17:19, Mike Belopuhov wrote: > On 6 February 2017 at 17:02, Martin Pieuchot wrote: > > PF has its own home-brewed solution for dealing with CPU hogging. It > > has been introduced in r1.88 of net/pf_table.c and I couldn't find any > > explanation why it is

Re: PF & CPU hogging

On 06/02/17(Mon) 17:18, Mike Belopuhov wrote: > On 6 February 2017 at 17:02, Martin Pieuchot wrote: > > PF has its own home-brewed solution for dealing with CPU hogging. It > > has been introduced in r1.88 of net/pf_table.c and I couldn't find any > > explanation why it is