> Am 19.07.2016 um 23:16 schrieb Alexander Bluhm :
>
>> On Tue, Jul 19, 2016 at 09:48:19PM +0100, Jason McIntyre wrote:
>> oh oh. i should have been clearer: they are sorted in sysctl(3), but in
>> sysctl(8) they are merely listed in the order that running "sysctl"
>> dumps them. so no sort necc
Hi,
#define PV_BEEN_EXECD(f) (((f) & (PVF_REF | PVF_EXEC)) == (PVF_REF | PVF_EXEC))
#define PV_BEEN_REFD(f) (((f) & PVF_REF) != 0)
and from pmap.h:
* The PVF_MOD and PVF_REF flags are stored in the mdpage for each
* page. PVF_WIRED, PVF_WRITE, and PVF_NC are kept in individual
* pv_entry's
On 19 July 2016 at 23:00, Alexander Bluhm wrote:
> Hi,
>
> When looking at the error paths in tcp_output() I have found these
> returns that look like mbuf leaks.
>
> ok?
>
> bluhm
>
looks correct indeed. ok mikeb
On Tue, Jul 19, 2016 at 09:48:19PM +0100, Jason McIntyre wrote:
> oh oh. i should have been clearer: they are sorted in sysctl(3), but in
> sysctl(8) they are merely listed in the order that running "sysctl"
> dumps them. so no sort neccessary for sysctl(8).
So now sysctl(8) has all net.inet.tcp i
On Tue, Jul 19, 2016 at 11:00:04PM +0200, Alexander Bluhm wrote:
> Hi,
>
> When looking at the error paths in tcp_output() I have found these
> returns that look like mbuf leaks.
>
> ok?
Indeed. OK claudio@
Looking at tcp_signature() I actually think it can not fail but better
safe than sorry.
On Tue, Jul 19, 2016 at 10:40:14PM +0200, Alexander Bluhm wrote:
> On Tue, Jul 19, 2016 at 09:19:25PM +0100, Jason McIntyre wrote:
> > On Tue, Jul 19, 2016 at 10:09:47PM +0200, Alexander Bluhm wrote:
> > > On Tue, Jul 19, 2016 at 08:55:58PM +0200, Joerg Jung wrote:
> > > > Please, also document it,
Hi,
When looking at the error paths in tcp_output() I have found these
returns that look like mbuf leaks.
ok?
bluhm
Index: netinet/tcp_output.c
===
RCS file: /data/mirror/openbsd/cvs/src/sys/netinet/tcp_output.c,v
retrieving revisi
On Tue, Jul 19, 2016 at 09:19:25PM +0100, Jason McIntyre wrote:
> On Tue, Jul 19, 2016 at 10:09:47PM +0200, Alexander Bluhm wrote:
> > On Tue, Jul 19, 2016 at 08:55:58PM +0200, Joerg Jung wrote:
> > > Please, also document it, at least in sysctl(8).
Next try, with input from jmc@
bluhm
Index: li
On Tue, Jul 19, 2016 at 08:55:58PM +0200, Joerg Jung wrote:
> Please, also document it, at least in sysctl(8).
like this?
bluhm
Index: lib/libc/gen/sysctl.3
===
RCS file: /data/mirror/openbsd/cvs/src/lib/libc/gen/sysctl.3,v
retrievi
On Tue, Jul 19, 2016 at 06:13:42PM +0200, Alexander Bluhm wrote:
> Hi,
>
> claudio@ suggested to have a tunable size for the syn cache hash
> array. As we are swapping between two syn caches for random reseeding
> anyway, this feature can be added easily. When the cache is empty,
> we can change
Hi,
claudio@ suggested to have a tunable size for the syn cache hash
array. As we are swapping between two syn caches for random reseeding
anyway, this feature can be added easily. When the cache is empty,
we can change the hash size.
This allows an admin under SYN flood attack to tune his mach
On Tue, 19 Jul 2016, Sebastian Benoit wrote:
> maybe session cache disable should disable tickets too.
Well, what problem are you trying to solve by offering that option?
If it's to save memory, because original-flavor session caching requires
state and overhead on the server, then you should on
maybe session cache disable should disable tickets too.
some little things below, otherwise ok
Claudio Jeker(cje...@diehard.n-r-g.com) on 2016.07.19 15:32:13 +0200:
> At the moment relayd's TLS session caching is a bit busted because
> the multiple relay processes do not share state.
> The follow
At the moment relayd's TLS session caching is a bit busted because
the multiple relay processes do not share state.
The following diff adds SSL session caching and sharing of the TLS ticket
secrets. Which this openssl s_client -connect W.X.Y.Z:443 -reconnect
reuses the connection after the first on
faq4.html [1] already deal with the problem.
[1] http://www.openbsd.org/faq/faq4.html#AddThoughts
2016-07-19 3:29 GMT+02:00 Josh Grosse :
> I had a conversation with a new OpenBSD user who thought that he
> may have either misunderstood or been misled by the guidance to unpack
> the ports tree ta
15 matches
Mail list logo