Re: please build unbound with --enable-event-api
On Mon, 30 May 2022 at 07:07, Stuart Henderson wrote: > > On 2022/05/29 14:20, Andrew Cagney wrote: > > On Sun, 29 May 2022 at 13:44, Stuart Henderson wrote: > > > > > > On 2022/05/29 19:08, Florian Obser wrote: > > > > On 2022-05-29 12:27 -04, Andrew Cagney wrote: > > > > > > Are you porting libreswan? > > > > Slowly. > > Good luck - it would be nice to have this running. I'm happy to help > get it into ports in future. > > > > This configure flag literally just installs the header file, that's all. > > > If there's a good reason for it, we could do that. > > > > Performance. It lets libunbound use a common (crypto heavy) thread pool. > > I've added this to ports/net/libunbound, it will show up in future > package builds. Thanks! > > > For (RT_)ADVANCE, we try to avoid header pollution. Suggest you just > > > make a local copy of the definition as is done in route.c. > > > > That's why I'm suggesting adding RT_ADVANCE(). The name, which I'm > > lifting from NetBSD, at least includes RT_*(), unlike FreeBSD's > > SA_SIZE(). I'd prefer to be relying on something that's part of a > > published interface, rather than magically gleaned from source code. > > Hmm, yes, it doesn't seem to be documented in the OS at all (at least > nothing returned by "man -k any=sa_len" describes how to advance past > padding), which is not ideal. Whether a common macro is needed or > not I can't really say (though it _would_ be helpful to have if we > were ever to change the alignment from long to 64-bit). Even a hint in the documentation - something to explain that the .sa_len field can be used to skip any sockaddr on BSD - would help. btw, SIOCGIFCONF has similar problems
Re: MTU setting during installation
Normally if you're using DHCP you wouldn't need to do this by hand anyway,
but it looks like this isn't yet implemented in dhcpleased.
--
Sent from a phone, apologies for poor formatting.
On 3 June 2022 15:28:23 "Theo de Raadt" wrote:
yes that is the way to do it.
guent...@openbsd.org wrote:
On Thu, 2 Jun 2022, Luca Di Gregorio wrote:
> when installing OpenBSD there is the chance to set a network interface,
> anyway, there is no chance to set the MTU on it.
>
> It would be good to add this setting in the installation process
No, we don't believe that imposing that burden on every single person on
every install is a net benefit. Indeed, the project's experience is that
very few people need to explicitly configure an MTU.
So, for those that need it, well, to quote all of the INSTALL.
files:
---
If any question has a default answer, it will be displayed in brackets
("[]") after the question. If you wish to stop the installation, you may
hit Control-C at any time, but if you do, you'll have to begin the
installation process again from scratch. Using Control-Z to suspend the
process may be a better option, or at any prompt enter "!" to get a shell,
from which "exit" will return you back to that prompt.
---
So, you can use '!' to get a shell where you enter the necessary ifconfig
command, and you can of course tweak the install before rebooting.
Philip Guenther
Re: MTU setting during installation
yes that is the way to do it.
guent...@openbsd.org wrote:
> On Thu, 2 Jun 2022, Luca Di Gregorio wrote:
> > when installing OpenBSD there is the chance to set a network interface,
> > anyway, there is no chance to set the MTU on it.
> >
> > It would be good to add this setting in the installation process
>
> No, we don't believe that imposing that burden on every single person on
> every install is a net benefit. Indeed, the project's experience is that
> very few people need to explicitly configure an MTU.
>
> So, for those that need it, well, to quote all of the INSTALL.
> files:
>
> ---
> If any question has a default answer, it will be displayed in brackets
> ("[]") after the question. If you wish to stop the installation, you may
> hit Control-C at any time, but if you do, you'll have to begin the
> installation process again from scratch. Using Control-Z to suspend the
> process may be a better option, or at any prompt enter "!" to get a shell,
> from which "exit" will return you back to that prompt.
> ---
>
> So, you can use '!' to get a shell where you enter the necessary ifconfig
> command, and you can of course tweak the install before rebooting.
>
>
> Philip Guenther
>
Re: Unchecked tls_config_new() in relayd
> diff --git a/src/usr.sbin/relayd/hce.c b/src/usr.sbin/relayd/hce.c
> index 5233e2c..4a1bf1c 100644
> --- a/src/usr.sbin/relayd/hce.c
> +++ b/src/usr.sbin/relayd/hce.c
> @@ -94,6 +94,9 @@ hce_setup_events(void)
> table->tls_cfg != NULL)
> continue;
> table->tls_cfg = tls_config_new();
> + if (table->tls_cfg == NULL) {
> + fatalx("%s: tls_config_new", __func__);
> + }
I have applied a version of this diff. Thanks!
Re: macppc panic: vref used where vget required
> Please do note that this change can introduce/expose other issues. It seems that this diff causes occasional hangs when building snapshots on my mac M1 mini. This happened twice in 10 builds, both times in xenocara. Unfortunately, both times the machine became entirely unresponsive and as I don't have serial console, that's all the info I have... This machine has been very reliable and built >50 snaps without any hang over the last 2.5 months. I'm now trying snap builds in a loop without the diff to make sure the machine doesn't hang due to another recent kernel change.
Re: macppc panic: vref used where vget required
On 02/06/22(Thu) 13:54, Sebastien Marie wrote: > On Tue, May 24, 2022 at 02:16:44PM +0200, Martin Pieuchot wrote: > > On 19/05/22(Thu) 13:33, Alexander Bluhm wrote: > > > On Tue, May 17, 2022 at 05:43:02PM +0200, Martin Pieuchot wrote: > > > > Andrew, Alexander, could you test this and report back? > > > > > > Panic "vref used where vget required" is still there. As usual it > > > needs a day to reproduce. This time I was running without the vref > > > history diff. > > > > Thanks for testing. Apparently calling uvm_vnp_terminate() in > > getnewvnode() isn't good enough. I suppose that in your case below the > > pdaemon is trying to flush the pages before the vnode has been recycled, > > so before uvm_vnp_terminate() has been called. > > > > So either we prevent the vnode from being put on the free list or we get > > rid of the persisting mechanism. I don't fully understand what could be > > the impact of always flushing the pages and why this hasn't been done in > > the first place. It seems the CANPERSIST logic has been"inherited from > > 44BSD's original vm. > > > > On the other hand I feel even less comfortable with preventing vnodes > > from being recycled until the pdaemon has freed related pages. > > > > Diff below has been lightly tested, it get rids of the extra CANPERSIST > > referenced. That means pages associated to a vnode will now always be > > flushed when uvn_detach() is called. This turns uvm_vnp_uncache() into > > a noop and open the possibility of further simplifications. > > > > I'd be happy to hear if this has any impact of the bug we're chasing. > > Please do note that this change can introduce/expose other issues. > > I don't know if you are looking for ok or not regarding this diff. I'd appreciate if it could be stress tested before that. > For me, it makes sense: it simplifies uvm_vnode code, and seems to fix the > vref > problem. > > Just some notes in case you want to commit it: > > - UVM_VNODE_CANPERSIST define should be removed from uvm/uvm_vnode.h too Indeed. > - uvm_vnp_uncache(9) man page (src/share/man/man9/uvn_attach.9) should be > amended: it mentions "uvm_vnp_uncache() function disables vnode vp from > persisting" > > - I wonder if UVM_VNODE_VALID could be removed too (it could be separated > commit): once UVM_VNODE_CANPERSIST disappear, UVM_VNODE_VALID flag should > be > equivalent to have uo_refs>0 if I properly understood the code > > - more simplification might be possible inside uvm_vnp_terminate() or > uvm_vnp_uncache(): they have both code path for uo_refs ==0 and >0 (and > without UVM_VNODE_CANPERSIST, a uvn should always have refs or be "free"). > uvm_vnp_uncache() might be deletable. I agree we should then simplify/cleanup all this logic. I'd like first to be sure there is no regression.
Re: macppc panic: vref used where vget required
On 02/06/22(Thu) 07:29, Theo de Raadt wrote: > So this basically converts the flag into a proper reference? It completely gets rid of the extra reference. UVM objects related to a vnode are no longer kept alive after uvn_detach() has been called. > If you go back to 4.4BSD, there's another aspect which was different: > I believe vnodes weren't allocated dynamically, but came out of a fixed > and therefore the recycling behaviour was different. Or maybe some > kernel code had a subtle use-after-free mistake? Indeed the PERSIST flag has been inherited/copied from 4.4BSD vm where objects where kept in a global cache data structure. It isn't clear to me why this logic has been kept in UVM.
Re: MTU setting during installation
On Thu, 2 Jun 2022, Luca Di Gregorio wrote:
> when installing OpenBSD there is the chance to set a network interface,
> anyway, there is no chance to set the MTU on it.
>
> It would be good to add this setting in the installation process
No, we don't believe that imposing that burden on every single person on
every install is a net benefit. Indeed, the project's experience is that
very few people need to explicitly configure an MTU.
So, for those that need it, well, to quote all of the INSTALL.
files:
---
If any question has a default answer, it will be displayed in brackets
("[]") after the question. If you wish to stop the installation, you may
hit Control-C at any time, but if you do, you'll have to begin the
installation process again from scratch. Using Control-Z to suspend the
process may be a better option, or at any prompt enter "!" to get a shell,
from which "exit" will return you back to that prompt.
---
So, you can use '!' to get a shell where you enter the necessary ifconfig
command, and you can of course tweak the install before rebooting.
Philip Guenther
MTU setting during installation
Hi, when installing OpenBSD there is the chance to set a network interface, anyway, there is no chance to set the MTU on it. It would be good to add this setting in the installation process Regards Luca
