> On 3 Sep 2023, at 21:08, Alexander Bluhm wrote:
>
> Hi,
>
> Avoid a useless increment and decrement of of the tcp syn cache
> refcount by unexpanding the SYN_CACHE_TIMER_ARM() macro in the timer
> callback.
>
> ok?
>
ok mvs
> bluhm
>
> Index: netinet/tcp_input.c
>
Mischa writes:
> Nice!! Thanx Dave!
>
> Running go brrr as we speak.
> Testing with someone who is running Debian.
Great. I'll plan on committing this tomorrow afternoon (4 Sep) my time
unless I hear of any issues.
Hi,
Avoid a useless increment and decrement of of the tcp syn cache
refcount by unexpanding the SYN_CACHE_TIMER_ARM() macro in the timer
callback.
ok?
bluhm
Index: netinet/tcp_input.c
===
RCS file: /data/mirror/openbsd/cvs/src/sys/
On Thu, Aug 31, 2023 at 08:59:53AM +0200, Marc Espie wrote:
> A long time ago, I tried to host our fork of make, in the hope it would get
> picked up by other systems.
>
> Accordingly, some features were added to mimic netbsd's extensions, hidden
> behind FEATURES macros.
>
> Turns out that, for
Nice!! Thanx Dave!
Running go brrr as we speak.
Testing with someone who is running Debian.
Mischa
On 2023-09-01 21:50, Dave Voutila wrote:
Now that my i8259 fix is in, it's safe to expand the testing pool for
this diff. (Without that fix, users would definitely hit the hung block
device issue
On Sun, Sep 03, 2023 at 09:30:49AM +0200, Otto Moerbeek wrote:
> > You can also be set upon a wrong foot: if an out of bounds write on a
> > adjacent chunk happens and lands in (another) free chunk, upon
> > allocation of that free chunk it will be reported as a "write after
> > free" case. It mig
Hi,
forgot to include the corresponding dmesg output:
nvme1 at pci20 dev 0 function 0 "Intel P1600X" rev 0x00: msix, NVMe 1.1
nvme1: INTEL SSDPEK1A118GA, firmware U5110550, serial BTOC14120X9P118B
Could this please be committed?
Best regards
Andreas
On 8/20/23 14:00, Andreas Bartelt wrote:
Hi
On Fri, Sep 01, 2023 at 03:50:31PM -0400, Dave Voutila wrote:
> Now that my i8259 fix is in, it's safe to expand the testing pool for
> this diff. (Without that fix, users would definitely hit the hung block
> device issue testing this one.) Hoping that folks that run non-OpenBSD
> guests or strang
On Sun, Sep 03, 2023 at 09:21:18AM +0200, Otto Moerbeek wrote:
> Hello,
>
> I'm seeing some reports of "write after free" reported by malloc by
> peolpe running current. Malloc has become more strict since begining
> of June. Let me explain:
>
> Small allocations share a page. e.g. a 4k page wi
Hello,
I'm seeing some reports of "write after free" reported by malloc by
peolpe running current. Malloc has become more strict since begining
of June. Let me explain:
Small allocations share a page. e.g. a 4k page will hold 8 512 byte
allocations.
When one such allocation is freed, it will be
10 matches
Mail list logo
