this prefixes (some of the) pf_state_key struct members with sk_, and
pf_state_item struct members with si_ (and renames one completely).
this makes searching for and the struct members so much easier, which in
turn makes tweaking code around them a lot easier too. sk_refcnt in
particular would
On Sun, 18 Dec 2022 at 17:01, Theo Buehler wrote:
>
> This is the remaining bit of mpf's recent netcat diff. The commit log
> shows that it was bumped to 64k in the past, but that was promptly
> reverted due to concerns of buffer bloat caused by atomicio blocking
> traffic in the other direction.
nc of 0's from one rge to another at full speed crashes
in the input interrupt path with corruption of the memory
pool used for the mbufs
It's 100% reproduceable.
Probably race condition & use-after-free or some such
since it takes 200,000+ packets to happen.
I suspect that the crash happens when
Hi,
This is the latest verion of a diff I sent around previously, but now
it's time this gets wider testing for real.
The main purpose is to rearrange malloc init in such a way that a few
pages containing mallic internal data structures can be made
immutable. In addtion to that, each pools is
On Sun, Dec 18, 2022 at 05:53:25PM +0100, Marco Pfatschbacher wrote:
>
> On Sun, Dec 18, 2022 at 02:00:24PM +0100, Theo Buehler wrote:
> > This is the remaining bit of mpf's recent netcat diff. The commit log
> > shows that it was bumped to 64k in the past, but that was promptly
> > reverted due
you say
"I can't think of a real world scenario where this is a problem right now."
Wait, has something changed?
I don't understand what you think has changed that undoes the justification
for tedu's backout.
Are there perhaps modes that should use larger buffer sizes, and modes that
should
On Sun, Dec 18, 2022 at 02:00:24PM +0100, Theo Buehler wrote:
> This is the remaining bit of mpf's recent netcat diff. The commit log
> shows that it was bumped to 64k in the past, but that was promptly
> reverted due to concerns of buffer bloat caused by atomicio blocking
> traffic in the other
> Date: Fri, 16 Dec 2022 16:28:03 -0600
> From: Scott Cheloha
>
> miod@'s UltraSPARC IIe machine really, really hates the following
> code:
>
> stickcmpr_set(stick());
>
> When we try that code, invariably the clock interrupt does not fire
> and the machine hangs.
>
> I think
Stuart Henderson wrote:
> On 2022/12/18 03:06, Lucas wrote:
> > The following patch expands acme-client config file `domain` blocks to
> > allow for a `owner user:group` directive, which allows to get rid of
> > customs scripts that "fix" permissions for issued certs, mostly needed
> > in ports
On Sun, Dec 18, 2022 at 12:56:59PM +, Klemens Nanni wrote:
> 12/18/22 15:53, Stefan Hagen ??:
> > Ross L Richardson wrote (2022-12-18 10:55 CET):
> >> The word "array" occurs only once in sh.1. Therefore, either it deserves
> >> more explanation, or removal with something like the
This is the remaining bit of mpf's recent netcat diff. The commit log
shows that it was bumped to 64k in the past, but that was promptly
reverted due to concerns of buffer bloat caused by atomicio blocking
traffic in the other direction.
I don't know if things are different enough 8 years later
12/18/22 15:53, Stefan Hagen пишет:
Ross L Richardson wrote (2022-12-18 10:55 CET):
The word "array" occurs only once in sh.1. Therefore, either it deserves
more explanation, or removal with something like the patch below.
I think you're right. This looks like an oversight from the works
On 2022/12/18 03:06, Lucas wrote:
> The following patch expands acme-client config file `domain` blocks to
> allow for a `owner user:group` directive, which allows to get rid of
> customs scripts that "fix" permissions for issued certs, mostly needed
> in ports land. I don't find it too invasive,
Lucas wrote:
> Hi tech@,
>
> The following patch expands acme-client config file `domain` blocks to
> allow for a `owner user:group` directive, which allows to get rid of
> customs scripts that "fix" permissions for issued certs, mostly needed
> in ports land. I don't find it too invasive, so I
Ross L Richardson wrote (2022-12-18 10:55 CET):
> The word "array" occurs only once in sh.1. Therefore, either it deserves
> more explanation, or removal with something like the patch below.
I think you're right. This looks like an oversight from the works when
sh(1) was rewritten / split from
On Sun, Dec 11, 2022 at 01:57:13PM -0500, Daniel Dickman wrote:
> I have a laptop with these Transmeta devices:
>
> pchb0 at pci0 dev 0 function 0 vendor "Transmeta", unknown product 0x0060 rev
> 0x00
> ppb0 at pci0 dev 1 function 0 vendor "Transmeta", unknown product 0x0061 rev
> 0x00
>
>
The word "array" occurs only once in sh.1. Therefore, either it deserves
more explanation, or removal with something like the patch below.
Ross
==
--- sh.1.orig Thu Sep 1 10:07:22 2022
+++ sh.1Sun Dec 18 20:47:53 2022
@@ -1390,7 +1390,7 @@
.Pp
Where
.Ar expression
-is an integer,
Sven M. Hallberg wrote (2022-12-08 14:12 CET):
> Marcus Glocker on Sat, Sep 03 2022:
> > I have an Wacom One CTL-672, never used it on OpenBSD.
>
> This is the "Wacom One M", which I also own...
>
> > Currently it attaches to ums(4). Works fine with that.
>
> It seems to expose two HIDs, one
18 matches
Mail list logo
