Seems some hosting providers have annoying "out of prefix"
default gateways whuch are painful to configure
(https://marc.info/?t=16678224225&r=1&w=2), should
we give a pointer in route(8)?
Index: route.8
===
RCS file: /cvs/src/sbi
From: Martin Pieuchot
Date: Tue, 8 Nov 2022 11:12:43 +
> On 01/11/22(Tue) 15:26, Masato Asou wrote:
>> Hi,
>>
>> Return error number instead of call panic().
>
> Makes sense to me. Do you know how this error can occur? Is is a logic
> error or are we trusting values produced by a third pa
Index: pause.3
===
RCS file: /cvs/src/lib/libc/gen/pause.3,v
retrieving revision 1.15
diff -u -p -r1.15 pause.3
--- pause.3 2 Aug 2022 01:23:23 - 1.15
+++ pause.3 8 Nov 2022 21:22:46 -
@@ -39,7 +39,8 @@
.Fn pause
On Tue, 8 Nov 2022 at 14:23, Joerg Sonnenberger wrote:
> Am Tue, Nov 08, 2022 at 01:23:52PM +1100 schrieb Darren Tucker:
[...]
> > Not quite: the default value for IdentityFile has RSA before ED25519.
[...]
> I tried that first and it picked up id_ed25519 from the agent, even if
> both keys are ac
On Tue, Nov 08, 2022 at 11:06:43AM -0700, Todd C. Miller wrote:
> On Tue, 08 Nov 2022 18:33:48 +0100, Tobias Heider wrote:
>
> > If ain == NULL then a points to newly malloced memory which should be
> > freed when BN_bin2bn() fails.
>
> We don't have an "ain" function argument in LibreSSL so you
There is a segmentation fault that occurs in ypbind when domainname is
not set
Index: usr.sbin/ypbind/ypbind.c
===
RCS file: /cvs/src/usr.sbin/ypbind/ypbind.c,v
retrieving revision 1.76
diff -u -r1.76 ypbind.c
--- usr.sbin/ypbind/yp
On 22-11-08 18:48:44, Tobias Heider wrote:
> nm.a is initialized to NULL until it gets alloced by x509_name_ex_new().
> The following 'goto err' should free nm.a before returning.
>
> ok?
Unless I'm missing something, I do not believe this is correct -
nm is a union and nm.a is the same pointer a
The per-interface group list is protected by the net lock and already
documented as such.
The global interface group list `ifg_head' is also protected by the net
lock and all access to it (all within if.c) take it accordingly.
OK?
---
sys/net/if.c | 3 ++-
sys/net/if_var.h | 8
2 fi
> Actually, it needs freeing only here. If lh_OBJ_NAME_error() returns 0,
> there was no error and a hash-entry containing NULL was replaced.
The below diff is ok if you want to commit.
PS: our initial diff causes a uaf caught by omalloc via:
$ openssl x509 -in /etc/ssl/cert.pem -out /dev/null
ok
> On 8 Nov 2022, at 21:38, Klemens Nanni wrote:
>
> On Tue, Nov 08, 2022 at 09:34:36PM +0300, Vitaliy Makkoveev wrote:
>>> On 8 Nov 2022, at 21:26, Klemens Nanni wrote:
>>>
>>> On Tue, Nov 08, 2022 at 09:18:47PM +0300, Vitaliy Makkoveev wrote:
> On 8 Nov 2022, at 21:08, Klemens Nanni w
On Tue, Nov 08, 2022 at 09:34:36PM +0300, Vitaliy Makkoveev wrote:
> > On 8 Nov 2022, at 21:26, Klemens Nanni wrote:
> >
> > On Tue, Nov 08, 2022 at 09:18:47PM +0300, Vitaliy Makkoveev wrote:
> >>> On 8 Nov 2022, at 21:08, Klemens Nanni wrote:
> >>>
> >>> Now properly. How about a single comme
> On 8 Nov 2022, at 21:26, Klemens Nanni wrote:
>
> On Tue, Nov 08, 2022 at 09:18:47PM +0300, Vitaliy Makkoveev wrote:
>>> On 8 Nov 2022, at 21:08, Klemens Nanni wrote:
>>>
>>> Now properly. How about a single comment block at the top instead of
>>> repeating it for every struct?
>>>
>>>
>>
On Tue, Nov 08, 2022 at 09:18:47PM +0300, Vitaliy Makkoveev wrote:
> > On 8 Nov 2022, at 21:08, Klemens Nanni wrote:
> >
> > Now properly. How about a single comment block at the top instead of
> > repeating it for every struct?
> >
> >
>
> You forgot to mark [I] `if_cloners’ within net/if.c.
> On 8 Nov 2022, at 21:08, Klemens Nanni wrote:
>
> Now properly. How about a single comment block at the top instead of
> repeating it for every struct?
>
>
You forgot to mark [I] `if_cloners’ within net/if.c.
> diff --git a/sys/net/if_var.h b/sys/net/if_var.h
> index 28514a0bfcd..6272be882
On Tue, Nov 08, 2022 at 11:06:43AM -0700, Todd C. Miller wrote:
> On Tue, 08 Nov 2022 18:33:48 +0100, Tobias Heider wrote:
>
> > If ain == NULL then a points to newly malloced memory which should be
> > freed when BN_bin2bn() fails.
>
> We don't have an "ain" function argument in LibreSSL so you
Now properly. How about a single comment block at the top instead of
repeating it for every struct?
diff --git a/sys/net/if_var.h b/sys/net/if_var.h
index 28514a0bfcd..6272be882f4 100644
--- a/sys/net/if_var.h
+++ b/sys/net/if_var.h
@@ -73,6 +73,18 @@
* interfaces. These routines live in the
On Tue, 08 Nov 2022 18:05:24 +, Klemens Nanni wrote:
> Subject: Document ifc_list immutability
Sure. OK millert@
- todd
On Tue, 08 Nov 2022 18:33:48 +0100, Tobias Heider wrote:
> If ain == NULL then a points to newly malloced memory which should be
> freed when BN_bin2bn() fails.
We don't have an "ain" function argument in LibreSSL so you will
need a larger diff. Perhaps something like this (untested).
- todd
Subject: Document ifc_list immutability
OK?
diff --git a/sys/net/if_var.h b/sys/net/if_var.h
index 28514a0bfcd..a472c586f3c 100644
--- a/sys/net/if_var.h
+++ b/sys/net/if_var.h
@@ -78,11 +78,15 @@ struct ifnet;
struct task;
struct cpumem;
+/*
+ * Locks used to protect struct members in this
On Tue, Nov 08 2022, Mark Kettenis wrote:
>> Date: Tue, 8 Nov 2022 13:06:51 +
>> From: Scott Cheloha
>>
>> On Mon, Nov 07, 2022 at 09:23:26PM +0100, Jeremie Courreges-Anglas wrote:
>> > On Sun, Nov 06 2022, Scott Cheloha wrote:
>> > > This patch switches riscv64 to clockintr(9).
>> > >
>> >
nm.a is initialized to NULL until it gets alloced by x509_name_ex_new().
The following 'goto err' should free nm.a before returning.
ok?
Index: asn1/x_name.c
===
RCS file: /cvs/src/lib/libcrypto/asn1/x_name.c,v
retrieving revision 1.
On Tue, Nov 08, 2022 at 08:31:16PM +0300, Vitaliy Makkoveev wrote:
> No reason to keep kernel lock around if_clone_list() call.
Yes, that is why I will remove it in the very next commit.
This way there is one "move existing lock, make things clearer" and one
"actually remove a lock for a specific
If ain == NULL then a points to newly malloced memory which should be
freed when BN_bin2bn() fails.
ok?
Index: bn/bn_mpi.c
===
RCS file: /cvs/src/lib/libcrypto/bn/bn_mpi.c,v
retrieving revision 1.8
diff -u -p -r1.8 bn_mpi.c
--- bn/bn
Mike Larkin writes:
> This lock/unlock around an atomic operation was causing delays delivering
> interupts into VMs. Pointed out by claudio@ when he ran md5 - in a VM
> and it became very sluggish.
>
> Debugging help from dlg and mpi, thanks.
>
> ok?
>
ok dv@. This is overly defensive and
No reason to keep kernel lock around if_clone_list() call.
> On 8 Nov 2022, at 20:27, Klemens Nanni wrote:
>
> On Tue, Nov 08, 2022 at 08:04:16PM +0300, Vitaliy Makkoveev wrote:
>> The `if_cloners’ list is immutable. You don't need kernel lock
>> around if_clone_list() call.
>>
>>> case SIO
On Tue, Nov 08, 2022 at 04:47:23PM +, Martin Pieuchot wrote:
> On 08/11/22(Tue) 15:28, Klemens Nanni wrote:
> > After this mechanical move, I can unlock the individual SIOCG* in there.
>
> I'd suggest grabbing the KERNEL_LOCK() after NET_LOCK_SHARED().
> Otherwise you might spin for the first
On Tue, Nov 08, 2022 at 08:04:16PM +0300, Vitaliy Makkoveev wrote:
> The `if_cloners’ list is immutable. You don't need kernel lock
> around if_clone_list() call.
>
> > case SIOCIFGCLONERS:
> > + KERNEL_LOCK();
> > error = if_clone_list((struct if_clonereq *)data);
> > +
Same diff as for RSA_print(). Old version leaks when EVP_PKEY_set1_DSA()
fails.
ok?
Index: dsa/dsa_prn.c
===
RCS file: /cvs/src/lib/libcrypto/dsa/dsa_prn.c,v
retrieving revision 1.6
diff -u -p -r1.6 dsa_prn.c
--- dsa/dsa_prn.c
The `if_cloners’ list is immutable. You don't need kernel lock
around if_clone_list() call.
> case SIOCIFGCLONERS:
> + KERNEL_LOCK();
> error = if_clone_list((struct if_clonereq *)data);
> + KERNEL_UNLOCK();
> return (error);
With this fi
On 08/11/22(Tue) 15:28, Klemens Nanni wrote:
> After this mechanical move, I can unlock the individual SIOCG* in there.
I'd suggest grabbing the KERNEL_LOCK() after NET_LOCK_SHARED().
Otherwise you might spin for the first one then release it when going
to sleep.
> OK?
>
> Index: if.c
>
> Date: Tue, 8 Nov 2022 15:49:19 +
> From: Miod Vallat
>
> The following diff removes the last mentions of the sun4 old style
> eeprom behaviour in the eeprom(8) manual page, as well as options
> specific to it.
sure; ok kettenis@
> Index: eeprom.8
>
The following diff removes the last mentions of the sun4 old style
eeprom behaviour in the eeprom(8) manual page, as well as options
specific to it.
Index: eeprom.8
===
RCS file: /OpenBSD/src/usr.sbin/eeprom/eeprom.8,v
retrieving revi
This lock/unlock around an atomic operation was causing delays delivering
interupts into VMs. Pointed out by claudio@ when he ran md5 - in a VM
and it became very sluggish.
Debugging help from dlg and mpi, thanks.
ok?
-ml
Index: arch/amd64/amd64/vmm.c
==
After this mechanical move, I can unlock the individual SIOCG* in there.
OK?
Index: if.c
===
RCS file: /cvs/src/sys/net/if.c,v
retrieving revision 1.667
diff -u -p -r1.667 if.c
--- if.c8 Nov 2022 15:20:24 - 1.667
++
On Wed, Nov 09, 2022 at 12:09:50AM +1000, David Gwynne wrote:
> i'm hacking on pfsync(4) at the moment, and i wasted way too much time
> wondering how i broke the pfsync ioctls after i didn't the pfsync_status
> output. turns out if you don't have a sync interface set, it skips
> output.
>
> i thi
i'm hacking on pfsync(4) at the moment, and i wasted way too much time
wondering how i broke the pfsync ioctls after i didn't the pfsync_status
output. turns out if you don't have a sync interface set, it skips
output.
i think it's useful to show that the sync interface is not set, so i
came up wi
On Mon, Nov 07, 2022 at 06:53:47PM +0100, Alexandr Nedvedicky wrote:
> Hello,
>
> updated diff. It buys suggestions from Klemens:
>
> pf.conf(5) section which covers once rules reads as follows:
>
> onceCreates a one shot rule. The first matching packet marks rule as
>
Another mechanical diff without semantic changes to avoid churn in
actual unlocking diffs.
OK?
Index: if.c
===
RCS file: /cvs/src/sys/net/if.c,v
retrieving revision 1.666
diff -u -p -r1.666 if.c
--- if.c8 Nov 2022 11:25:01 -0
> Date: Tue, 8 Nov 2022 13:06:51 +
> From: Scott Cheloha
>
> On Mon, Nov 07, 2022 at 09:23:26PM +0100, Jeremie Courreges-Anglas wrote:
> > On Sun, Nov 06 2022, Scott Cheloha wrote:
> > > This patch switches riscv64 to clockintr(9).
> > >
> > > jca@ has been testing it (on a SiFive board?).
On Tue, Nov 08, 2022 at 01:14:02PM +, Martin Pieuchot wrote:
> Now that mmap/munmap/mprotect(2) are no longer creating contention it is
> possible to see that sched_yield(2) is one of the syscalls waiting for
> the KERNEL_LOCK() to be released. However this is no longer necessary.
>
> Traversi
Now that mmap/munmap/mprotect(2) are no longer creating contention it is
possible to see that sched_yield(2) is one of the syscalls waiting for
the KERNEL_LOCK() to be released. However this is no longer necessary.
Traversing `ps_threads' require either the KERNEL_LOCK() or the
SCHED_LOCK() and w
On Mon, Nov 07, 2022 at 09:23:26PM +0100, Jeremie Courreges-Anglas wrote:
> On Sun, Nov 06 2022, Scott Cheloha wrote:
> > This patch switches riscv64 to clockintr(9).
> >
> > jca@ has been testing it (on a SiFive board?). It has survived two
> > parallel release builds and upgrades from the resul
> Date: Tue, 8 Nov 2022 11:59:17 +
> From: Scott Cheloha
>
> On some arm64 machines, the agtimer(4) ticks slowly enough that the
> tc_delta() doesn't overflow across brief suspends. While working on
> arm64 suspend/resume, kettenis@ has been seeing warnings like this
> during resume:
>
> tc
On Tue, Nov 08, 2022 at 01:33:47PM +0100, Moritz Buhl wrote:
> In case lh_OBJ_NAME_insert returns NULL due to a failed malloc, onp
> is leaked in OBJ_NAME_add.
>
> Found by CodeChecker.
>
> OK?
> mbuhl
>
> Index: lib/libcrypto/objects/o_names.c
> =
In case lh_OBJ_NAME_insert returns NULL due to a failed malloc, onp
is leaked in OBJ_NAME_add.
Found by CodeChecker.
OK?
mbuhl
Index: lib/libcrypto/objects/o_names.c
===
RCS file: /cvs/src/lib/libcrypto/objects/o_names.c,v
retrievin
On Tue, Nov 08, 2022 at 01:01:17PM +0100, Tobias Heider wrote:
> If EVP_PKEY_set1_RSA() returns 0 we seem leak pk here.
>
> ok?
>
> Index: rsa/rsa_prn.c
> ===
> RCS file: /cvs/src/lib/libcrypto/rsa/rsa_prn.c,v
> retrieving revision 1
On Tue, Nov 08, 2022 at 11:59:17AM +, Scott Cheloha wrote:
> On some arm64 machines, the agtimer(4) ticks slowly enough that the
> tc_delta() doesn't overflow across brief suspends. While working on
> arm64 suspend/resume, kettenis@ has been seeing warnings like this
> during resume:
>
> tc_se
If EVP_PKEY_set1_RSA() returns 0 we seem leak pk here.
ok?
Index: rsa/rsa_prn.c
===
RCS file: /cvs/src/lib/libcrypto/rsa/rsa_prn.c,v
retrieving revision 1.7
diff -u -p -r1.7 rsa_prn.c
--- rsa/rsa_prn.c 29 Jan 2017 17:49:23 -000
On some arm64 machines, the agtimer(4) ticks slowly enough that the
tc_delta() doesn't overflow across brief suspends. While working on
arm64 suspend/resume, kettenis@ has been seeing warnings like this
during resume:
tc_setclock: cannot rewind uptime to 307.253324249
The warning is misleading a
On 01/11/22(Tue) 15:26, Masato Asou wrote:
> Hi,
>
> Return error number instead of call panic().
Makes sense to me. Do you know how this error can occur? Is is a logic
error or are we trusting values produced by a third party?
> comment, ok?
> --
> ASOU Masato
>
> diff --git a/sys/dev/pv/xen
More read-only filesystems mean less fsck during boot after crashes.
Especially on crappy machines like the Pinebook Poop, I keep /usr
read-only and run with this diff so I still get a relinked kernel.
rc's reorder_libs() already does the same remount dance, but for
multiple directories/filesystem
I concur, my 8-cores laptop (amd64) is happy with this patch.
Mostly using ungoogled-chromium, mutt, ncspot, xterm along with a few
vmd guests as dev machines. No isuses to report.
Jesper Wallin
On Tue, Nov 08, 2022 at 09:55:36AM +, Stefan Hagen wrote:
> Martin Pieuchot wrote (2022-11-06 1
I have now been running it for two days, I *thought * had one hang a day ago,
with chrome and local building churning away with me mashing on the editor..
but I’ve now been doing the same thing with witness on for a day and had no
issues. So I think whatever I might have seen is not reproducibl
Hi Greg, Hi Joe,
dlg@ hinted to me that the ring might overwrite it's own starting
position with the current code.
Does this help?
mbuhl
Index: dev/pci/if_igc.c
===
RCS file: /cvs/src/sys/dev/pci/if_igc.c,v
retrieving revision 1.9
d
On Tue, Nov 08, 2022 at 10:23:23AM +, Stuart Henderson wrote:
> On 2022/11/07 23:54, Theo de Raadt wrote:
> > Klemens Nanni wrote:
> >
> > > > I know this makes rc(8) a bit noisier but it really does improve my
> > > > (for want of a better term) "user experience" as I wait for my machine
> >
On Tue, Nov 08, 2022 at 10:30:47AM +, Martin Pieuchot wrote:
> On 08/11/22(Tue) 11:12, Mark Kettenis wrote:
> > I think that means it should be comitted.
>
> I agree. This has been tested on i386, riscv64, m88k, arm64, amd64 (of
> course) and sparc64. I'm pretty confident.
OK kn
Stuart Henderson wrote:
> > But I am not sure people need to see this detail. It just takes a bit
> > of time. How does knowing what steps are being taken help...
>
> Sometimes it's a bit of time, sometimes it's a _lot_ of time until
> people get a new computer or raid battery or something and
Klemens Nanni wrote:
> On Tue, Nov 08, 2022 at 10:23:23AM +, Stuart Henderson wrote:
> > On 2022/11/07 23:54, Theo de Raadt wrote:
> > > Klemens Nanni wrote:
> > >
> > > > > I know this makes rc(8) a bit noisier but it really does improve my
> > > > > (for want of a better term) "user exper
On 08/11/22(Tue) 11:12, Mark Kettenis wrote:
> > Date: Tue, 8 Nov 2022 10:32:14 +0100
> > From: Christian Weisgerber
> >
> > Martin Pieuchot:
> >
> > > These 3 syscalls should now be ready to run w/o KERNEL_LOCK(). This
> > > will reduce contention a lot. I'd be happy to hear from test reports
On Tue, Nov 08, 2022 at 10:23:23AM +, Stuart Henderson wrote:
> On 2022/11/07 23:54, Theo de Raadt wrote:
> > Klemens Nanni wrote:
> >
> > > > I know this makes rc(8) a bit noisier but it really does improve my
> > > > (for want of a better term) "user experience" as I wait for my machine
> >
On 2022/11/07 23:54, Theo de Raadt wrote:
> Klemens Nanni wrote:
>
> > > I know this makes rc(8) a bit noisier but it really does improve my
> > > (for want of a better term) "user experience" as I wait for my machine
> > > to boot.
> >
> > I like this and it doesn't add more **lines** to the bo
> Date: Tue, 8 Nov 2022 10:32:14 +0100
> From: Christian Weisgerber
>
> Martin Pieuchot:
>
> > These 3 syscalls should now be ready to run w/o KERNEL_LOCK(). This
> > will reduce contention a lot. I'd be happy to hear from test reports
> > on many architectures and possible workloads.
>
> Thi
Martin Pieuchot wrote (2022-11-06 10:54 WET):
> These 3 syscalls should now be ready to run w/o KERNEL_LOCK(). This
> will reduce contention a lot. I'd be happy to hear from test reports
> on many architectures and possible workloads.
My two amd64 machines are happy with it for two days now. Wit
Martin Pieuchot:
> These 3 syscalls should now be ready to run w/o KERNEL_LOCK(). This
> will reduce contention a lot. I'd be happy to hear from test reports
> on many architectures and possible workloads.
This survived a full amd64 package build.
--
Christian "naddy" Weisgerber
64 matches
Mail list logo
