On Thu, May 05, 2022 at 12:58:06PM +1000, Damien Miller wrote:
> On Wed, 4 May 2022, Seth David Schoen wrote:
>
> [snip]
>
> > Anyway, one thing we would like to propose that OpenBSD update is the
> > in_canforward treatment of 240/4 (former class E) addresses. Apparently
> > mainly as a result
Hello,
On Wed, May 04, 2022 at 10:50:15PM +0200, Alexander Bluhm wrote:
> Hi,
>
> I missed that pf divert packet is not MP safe yet. The problem is
> that divert_packet() is called from pf with shared net lock and
> sbappendaddr() needs exclusive net lock.
>
> The direct call from pf in IP laye
On Wed, 4 May 2022, Seth David Schoen wrote:
[snip]
> Anyway, one thing we would like to propose that OpenBSD update is the
> in_canforward treatment of 240/4 (former class E) addresses. Apparently
> mainly as a result of proposals in 2008 to make these addresses more
> usable, most OSes now no
Hi!
I'm working on a project with John Gilmore to make it possible for
people to make better use of historically reserved IPv4 address space.
In many cases address types were reserved in the 1980s for purposes
that made sense at the time but that are no longer relevant today.
There are several ch
On Wed, 4 May 2022, Martin Vahlensieck wrote:
> Hi
>
> I noticed that sshkey_unshield_private contains a exact duplicate
> of the code in private2_check_padding. So by pulling
> private2_check_padding up, the code can be reused. Or is there
> a reason for this split?
Thanks - this has been app
applied
On Wed, 4 May 2022, Martin Vahlensieck wrote:
> Hi
>
> channel_new no longer frees remote_name. So update the comment
> accordingly. As remote_name is not modified, it can be const
> as well.
>
> Best,
>
> Martin
>
> Index: channels.c
> ==
applied - thanks
On Wed, 4 May 2022, Martin Vahlensieck wrote:
> Index: mux.c
> ===
> RCS file: /home/reposync/cvs/src/usr.bin/ssh/mux.c,v
> retrieving revision 1.92
> diff -u -p -r1.92 mux.c
> --- mux.c 11 Jan 2022 01:26:47 -000
Hi,
I missed that pf divert packet is not MP safe yet. The problem is
that divert_packet() is called from pf with shared net lock and
sbappendaddr() needs exclusive net lock.
The direct call from pf in IP layer to divert in protocol layer is
not nice. I not sure how to address that.
As a first
Hi
I noticed that sshkey_unshield_private contains a exact duplicate
of the code in private2_check_padding. So by pulling
private2_check_padding up, the code can be reused. Or is there
a reason for this split?
Best,
Martin
P.S.: This diff also removes two trailing spaces while here.
Index: s
Index: mux.c
===
RCS file: /home/reposync/cvs/src/usr.bin/ssh/mux.c,v
retrieving revision 1.92
diff -u -p -r1.92 mux.c
--- mux.c 11 Jan 2022 01:26:47 - 1.92
+++ mux.c 13 Jan 2022 16:27:14 -
@@ -227,7 +227,7 @@
Hi
channel_new no longer frees remote_name. So update the comment
accordingly. As remote_name is not modified, it can be const
as well.
Best,
Martin
Index: channels.c
===
RCS file: /home/reposync/cvs/src/usr.bin/ssh/channels.c,v
On Wed, May 04, 2022 at 05:40:43PM +0200, Marc Espie wrote:
> On Wed, May 04, 2022 at 07:43:35AM -0400, Bryan Steele wrote:
> > On Wed, May 04, 2022 at 01:20:10PM +0200, Frederic Cambus wrote:
> > > Hi tech@,
> > >
> > > The base system includes the compiler-rt profile library for
> > > source-bas
Marc Espie wrote:
> On Wed, May 04, 2022 at 07:43:35AM -0400, Bryan Steele wrote:
> > On Wed, May 04, 2022 at 01:20:10PM +0200, Frederic Cambus wrote:
> > > Hi tech@,
> > >
> > > The base system includes the compiler-rt profile library for
> > > source-based code coverage.
> > >
> > > So here i
On Wed, May 04, 2022 at 07:43:35AM -0400, Bryan Steele wrote:
> On Wed, May 04, 2022 at 01:20:10PM +0200, Frederic Cambus wrote:
> > Hi tech@,
> >
> > The base system includes the compiler-rt profile library for
> > source-based code coverage.
> >
> > So here is a diff to document support in clan
On Wed, May 04, 2022 at 04:26:18PM +0200, Alexander Bluhm wrote:
> On Wed, May 04, 2022 at 02:21:11PM +0200, Alexandr Nedvedicky wrote:
> > I'm not sure flipping a flag is a right change. In general we don't want
> > to hold NET_LOCK()/PF_LOCK() while waiting for memory.
>
> - We must not
On Wed, May 04, 2022 at 02:21:11PM +0200, Alexandr Nedvedicky wrote:
> I'm not sure flipping a flag is a right change. In general we don't want
> to hold NET_LOCK()/PF_LOCK() while waiting for memory.
- We must not wait for memory when in the packet processing hot path.
Drop the packet i
On Wed, May 04, 2022 at 04:09:41PM +0200, Theo Buehler wrote:
> On Wed, May 04, 2022 at 04:03:21PM +0200, Claudio Jeker wrote:
> > On Wed, May 04, 2022 at 03:51:02PM +0200, Theo Buehler wrote:
> > > I had output from rpki-client -f something piped into less. After an
> > > hour rpki-client couldn't
On Wed, May 04, 2022 at 04:03:21PM +0200, Claudio Jeker wrote:
> On Wed, May 04, 2022 at 03:51:02PM +0200, Theo Buehler wrote:
> > I had output from rpki-client -f something piped into less. After an
> > hour rpki-client couldn't take it any longer and decided to move on to
> > a better place. It a
On Wed, May 04, 2022 at 03:51:02PM +0200, Theo Buehler wrote:
> I had output from rpki-client -f something piped into less. After an
> hour rpki-client couldn't take it any longer and decided to move on to
> a better place. It also left a residue via syslog on its way out. I
> don't think it should
I had output from rpki-client -f something piped into less. After an
hour rpki-client couldn't take it any longer and decided to move on to
a better place. It also left a residue via syslog on its way out. I
don't think it should do that in file mode or offline mode:
Index: main.c
Scott Cheloha wrote:
> speaker(4) is a whimsical thing, but I don't think we should have a
> dedicated chiptune interpreter in the kernel.
>
> This patch unhooks the driver and the manpage from the build. The
> driver is built for alpha, amd64, and i386.
>
> A subsequent patch will move all rel
On Tue, May 03, 2022 at 09:31:51PM +0200, Alexander Bluhm wrote:
> On Tue, May 03, 2022 at 07:42:34PM +0200, Moritz Buhl wrote:
> > commit 4b3977248902c22d96aaebdb5784840debc2631c
> > Author: mikeb
> > Date: Mon Nov 24 13:22:09 2008 +
> >
> > Fix splasserts seen in pr 5987 by propagatin
On Wed, May 04, 2022 at 01:20:10PM +0200, Frederic Cambus wrote:
> Hi tech@,
>
> The base system includes the compiler-rt profile library for
> source-based code coverage.
>
> So here is a diff to document support in clang-local.1, the same
> way we document support for the ubsan_minimal sanitize
Hi tech@,
The base system includes the compiler-rt profile library for
source-based code coverage.
So here is a diff to document support in clang-local.1, the same
way we document support for the ubsan_minimal sanitizer runtime
which is also part of compiler-rt.
Comments? OK?
Index: share/man/m
On Wed, May 04, 2022 at 12:14:01AM +0200, Alexander Bluhm wrote:
> Hi,
>
> We have one comment that locking for ratecheck(9) is missing. In
> all other places locking status of the struct timeval *lasttime
> is unclear.
>
> The easiest fix is a global mutex for all lasttime in ratecheck().
> Thi
On Wed, May 04, 2022 at 04:42:21AM -0500, Scott Cheloha wrote:
> > On May 3, 2022, at 17:16, Alexander Bluhm wrote:
> >
> > ???Hi,
> >
> > We have one comment that locking for ratecheck(9) is missing. In
> > all other places locking status of the struct timeval *lasttime
> > is unclear.
> >
>
> On May 3, 2022, at 17:16, Alexander Bluhm wrote:
>
> Hi,
>
> We have one comment that locking for ratecheck(9) is missing. In
> all other places locking status of the struct timeval *lasttime
> is unclear.
>
> The easiest fix is a global mutex for all lasttime in ratecheck().
> This covers
Florian Obser wrote:
> On 2022-05-03 17:41 +0430, Ali Farzanrad wrote:
> >
> > Hi Florian,
> >
> > Yes, I read the RFC, it should work, but I couldn't test it yet, because
> > my domain manager is a little lazy (I've registeret 2 subdomains for my
> > domain, but it is not listed in name servers
28 matches
Mail list logo
