It seems that IN6_IS_ADDR_MC_INTFACELOCAL() is actually spelled
IN6_IS_ADDR_MC_NODELOCAL(). So better use that for portability.
--
:wq Claudio
Index: kroute.c
===
RCS file: /cvs/src/usr.sbin/bgpd/kroute.c,v
retrieving revision
Newer gcc likes to bitch about snprintf buffers being to small for
insane numbers. This made me look at fmt_timeframe() and I decided to
clean it up a bit.
First of all the ring buffer is not needed. fmt_timeframe() is never used
multiple time in a single printf() call. So drop that.
Then make
struct kif is internal to the kroute code with the exception of the
'depend on' tracking message. So create an extra object for this message
and move struct kif to kroute.c.
I renamed the IMSG just to make it clear what this is about and to make
sure I did not miss something.
After that struct
IPv6 is such a lovley protocol. Add the scope_id for link local addresses
in kr6_tofull() because IPv6 just has to be "special".
Maybe we should add a scope_id to struct kroute6 but heck it is mostly the
interface index except for non link local addresses because there it has
to be 0. So this
Diff is huge but mostly mechanical. Remove kroute_node, kroute6_node and
use struct kroute and kroute6 directly. Also do a similar dance for
struct knexthop_node.
I left kredist_node and kif_node for now since this diff is already large
enough.
--
:wq Claudio
Index: bgpd.h
Both struct kroute and struct kroute6 are no longer used outside of
kroute.c. As a first step move the definitions over to that file.
More will follow :)
--
:wq Claudio
? obj
? test
? test.c
Index: bgpd.h
===
RCS file:
Instead of passing either a struct kroute or struct kroute6 pointer
use kr_tofull() and use struct kroute_full. This makes the code in
bgpd_filternexthop() a lot cleaner.
--
:wq Claudio
Index: bgpd.c
===
RCS file:
On Wed, Jun 22, 2022 at 04:37:44PM +0200, Theo Buehler wrote:
> On Wed, Jun 22, 2022 at 04:13:43PM +0200, Claudio Jeker wrote:
> > Do not leak the address family specific struct kroute into bgpctl if there
> > is struct kroute_full which is address family independent.
> >
Do not leak the address family specific struct kroute into bgpctl if there
is struct kroute_full which is address family independent.
The result is mostly minus because the code no longer needs address family
specific code paths. This changes 'bgpctl show nexthop' but not its output.
OK?
--
:wq
This diff uses applymask() instead of the IPv4 and IPv6 version.
Makes the code a tiny bit simpler.
--
:wq Claudio
Index: parser.c
===
RCS file: /cvs/src/usr.sbin/bgpctl/parser.c,v
retrieving revision 1.111
diff -u -p -r1.111
On Fri, Jun 17, 2022 at 12:32:50PM +0200, Theo Buehler wrote:
> On Fri, Jun 17, 2022 at 11:37:29AM +0200, Claudio Jeker wrote:
> > On Thu, Jun 16, 2022 at 09:01:33PM +0200, Theo Buehler wrote:
> > > On Thu, Jun 16, 2022 at 07:15:51PM +0200, Claudio Jeker wrote:
> > &g
On Thu, Jun 16, 2022 at 09:01:33PM +0200, Theo Buehler wrote:
> On Thu, Jun 16, 2022 at 07:15:51PM +0200, Claudio Jeker wrote:
> > Not much holds us back to switch kroute_find() to use a struct bgpd_addr
> > as prefix argument. Only the match code needs some adoption.
> >
Not much holds us back to switch kroute_find() to use a struct bgpd_addr
as prefix argument. Only the match code needs some adoption.
I created applymask() for this which works on bgpd_addrs like
inet4applymask works on in_addrs.
I also switched a simple case in session.c over to applymask().
Copy the version of the __KAME__ hack from route/show.c and more
importantly copy the address after modifying the sa.
This only affects IPv6 link local addresses which are not really used by
bgpd. Still happy if a few more people can give this a spin.
--
:wq Claudio
? obj
Index: util.c
On Thu, Jun 16, 2022 at 03:28:58PM +0200, Theo Buehler wrote:
> On Thu, Jun 16, 2022 at 02:36:28PM +0200, Claudio Jeker wrote:
> > This diff kills external use of prefixlen2mask() and uses inet4applymask()
> > instead. With this the IPv4 and IPv6 code is more similar.
> >
tb@ noticed that name2id conversions never check for error.
Now I think this is fine but in that case the api should not do a half
assed job of setting errnos.
In the end if 0 is returned from name2id but the input was not the empty
string then an error occurred. None of the callers does this
This diff kills external use of prefixlen2mask() and uses inet4applymask()
instead. With this the IPv4 and IPv6 code is more similar.
Also I feel the code is a bit easier to read.
Also kroute{,6}_match() is changed to take a struct bgpd_addr *.
This is another step towards removing lots of copy
There is no reason to add the __func__ in this warning.
It is just clutter in the error message with no benefit.
OK to remove?
--
:wq Claudio
Index: pfkey.c
===
RCS file: /cvs/src/usr.sbin/bgpd/pfkey.c,v
retrieving revision 1.64
Found by accident. If the pfkey message failed (sadb_msg_errno is set)
then the pfkey code ends in an infinite loop because the erroneous message
is not removed from the queue.
pfkey_read() PEEKS at the message and returns 0 since it is what we
expect. pfkey_reply() realizes it is an error and
So pfkeyv2.h defines managed to sneak into the portable part of bgpd.
The fix was to just dump a pfkeyv2.h version into the -portable compat
code and call it a day. This is bad since pfkeyv2.h is highly OS
dependent.
This diff cleans up the mess by introducing new enums for the various
IPsec
On Tue, Jun 14, 2022 at 08:14:45PM +0200, Theo Buehler wrote:
> On Tue, Jun 14, 2022 at 06:36:13PM +0200, Claudio Jeker wrote:
> > This diff does introduce a new flag for routes that have been inserted
> > into the FIB. Now I actually renamed the F_BGPD_INSERTED flag to F_BGPD
This diff does introduce a new flag for routes that have been inserted
into the FIB. Now I actually renamed the F_BGPD_INSERTED flag to F_BGPD
and reused F_BGPD_INSERTED as this new flag.
Adjust and use the send_rtmsg() return value to set F_BGPD_INSERTED if the
route message was successfully
We have released OpenBGPD 7.4, which will be arriving in the
OpenBGPD directory of your local OpenBSD mirror soon.
This release includes the following changes to the previous release:
* Implement max-communities filter to limit the number of allowed
communities, ext-communities and
On Fri, Jun 10, 2022 at 11:38:53AM +0200, Theo Buehler wrote:
> On Fri, Jun 10, 2022 at 11:31:42AM +0200, Theo Buehler wrote:
> > This is a leftover of the conversion to ASN.1 templates. The diff
> > reinstates a simplified variant of the removed cms_econtent_version().
> >
> > None of the
Fix a crash because of a NULL pointer dereference in parse.y
Before:
/etc/bgpd.conf:85: macro 'UNDEFINED' not defined
Segmentation fault
After:
/etc/bgpd.conf:85: macro 'UNDEFINED' not defined
/etc/bgpd.conf:85: syntax error
--
:wq Claudio
Index: parse.y
Noticed that similar to fib_prio the rdomain id is passed around to some
places where it really makes no sense.
First of all kr_nexthop_add() and kr_nexthop_delete() can be simplified.
The imsg peerid is always 0. This was added in the beginning of L3VPN
support without realizing that all bgp
On Thu, Jun 09, 2022 at 02:54:28PM +0200, Theo Buehler wrote:
> On Wed, Jun 08, 2022 at 10:47:48PM +0200, Claudio Jeker wrote:
> > and here is the updated diff I forgot to include
>
> I think I've now done what I reasonably can do to review this. I buy
> that this mostly
On Thu, Jun 09, 2022 at 09:47:31AM +0100, Stuart Henderson wrote:
> On 2022/06/08 22:47, Claudio Jeker wrote:
> > and here is the updated diff I forgot to include
>
> Not sure if it's expected / not, but I lose interface information
> with this:
>
>
> $ diff -wu old
On Wed, Jun 08, 2022 at 06:27:36PM +0200, Claudio Jeker wrote:
> On Wed, Jun 08, 2022 at 06:10:21PM +0200, Theo Buehler wrote:
> > On Wed, Jun 08, 2022 at 01:28:14PM +0200, Claudio Jeker wrote:
> > > The idea behind this diff is to use struct kroute_full in more places.
> &g
On Wed, Jun 08, 2022 at 06:10:21PM +0200, Theo Buehler wrote:
> On Wed, Jun 08, 2022 at 01:28:14PM +0200, Claudio Jeker wrote:
> > The idea behind this diff is to use struct kroute_full in more places.
> > Mainly when parsing route messages. This allows to factor out the pure
&g
Notice while hacking in OpenBGPD. Unlike routing socket messages the
messages from the sysctl interface have RTF_DONE not set.
I think it would make sense to set RTF_DONE also in this case since it
makes reusing code easier.
All messages sent out via sysctl_dumpentry() have been processed by the
The idea behind this diff is to use struct kroute_full in more places.
Mainly when parsing route messages. This allows to factor out the pure
route message parsing into dispatch_rtmsg_addr() and use it in both the
gerneral routing socket code but also in fetchtables(). Which removes some
On Tue, Jun 07, 2022 at 06:21:37PM +0200, Theo Buehler wrote:
> On Tue, Jun 07, 2022 at 05:49:53PM +0200, Claudio Jeker wrote:
> > The kroute code can leak rtlabel references in various conditions.
> > In the end we want to drop the reference before free().
> > So move the unr
On Tue, Jun 07, 2022 at 05:47:52PM +0200, Theo Buehler wrote:
> On Tue, Jun 07, 2022 at 05:09:30PM +0200, Claudio Jeker wrote:
> > The F_RTLABEL flag does nothing. So just remove it.
> > Checking the rtlabelid != 0 is equivalent.
>
> Doesn't twiddling the F_RTLABEL potential
The kroute code can leak rtlabel references in various conditions.
In the end we want to drop the reference before free().
So move the unref into kroute_remove() so it is done mostly in one place.
On top fix a few other places where kroutes are freed.
This diff is on top of the previous diff
The F_RTLABEL flag does nothing. So just remove it.
Checking the rtlabelid != 0 is equivalent.
--
:wq Claudio
Index: bgpd.h
===
RCS file: /cvs/src/usr.sbin/bgpd/bgpd.h,v
retrieving revision 1.426
diff -u -p -r1.426 bgpd.h
---
On Mon, Jun 06, 2022 at 12:03:06AM +0200, Alexandr Nedvedicky wrote:
> Hello,
>
> I'll commit one-liner diff on Tuesday morning (Jun 6th) Prague time without
> explicit OK, unless there will be no objection.
The diff is OK claudio@.
> regards
> sashan
>
>
> On Sun, Jun 05, 2022 at 09:44:45AM
fib_priority was slapped into the code by passing it around all the time.
It is much smarter to use a global value in kr_state for the fib_prio and
then tag F_BGP_INSERTED routes with RTP_MINE (0xff) which is an impossible
RTP value. With that changing the prio requires "only" a fib decouple,
On Thu, Jun 02, 2022 at 12:44:49PM +0200, Theo Buehler wrote:
> On Thu, Jun 02, 2022 at 11:38:05AM +0200, Claudio Jeker wrote:
> > Lets use the same check for both priority checks in parse.y.
> > Also rephrase the error messages to be less cryptic.
> > Both checks do the same
Lets use the same check for both priority checks in parse.y.
Also rephrase the error messages to be less cryptic.
Both checks do the same check since RTP_NONE = 0 and RTP_LOCAL = 1.
Using RTP_LOCAL as a priority is actually not possible since that one is
reserved for the kernel (used by interface
On Thu, Jun 02, 2022 at 11:13:31AM +0200, Theo Buehler wrote:
> On Thu, Jun 02, 2022 at 11:05:26AM +0200, Claudio Jeker wrote:
> > When setting the default routing table for bgpd make sure that
> > ktable_exists() does not fail.
> > Also improve the warning message in
When setting the default routing table for bgpd make sure that
ktable_exists() does not fail.
Also improve the warning message in ktable_exists() a bit.
--
:wq Claudio
Index: kroute.c
===
RCS file: /cvs/src/usr.sbin/bgpd/kroute.c,v
On Wed, Jun 01, 2022 at 08:44:43AM +0200, Theo Buehler wrote:
> When compared to manifest FileAndHash, the RSC code doesn't limit the
> size of the FileNameAndHash list. Should we do this for consistency?
>
> The situation is of course not quite the same since we're in -f mode.
> However, we do
On Tue, May 31, 2022 at 01:16:19PM +0200, Theo Buehler wrote:
> I chose to implement the constrained versions of the RFC 3779 types from
> the draft because the OpenSSL RFC 3779 code has static IPAddrBlocks_it,
> so we have to work around that anyway. This isn't quite minimal, but it
> avoids
This introduces max-communities, max-ext-communities and
max-large-communities for filters which allows to limit the number of
communities in a path.
The 3 filters can all be used together and also with other match filters
including community X:Y.
--
:wq Claudio
Index: bgpd.conf.5
Long long ago it was considered chique to use AS_DOT to write 4-byte AS
numbers. Like 3.10 instead of 196618. tcpdump also followed this trend but
then the world switched to AS_PLAIN so did bgpd. It is time for tcpdump
to follow.
Now the ugly bit about the ASPATH attribute is that it is not
On Wed, May 25, 2022 at 03:50:38PM +0200, Theo Buehler wrote:
> On Wed, May 25, 2022 at 02:46:55PM +0200, Claudio Jeker wrote:
> > Noticed this morning working on something else. The non-transitive
> > extended community support is fairly messed up. In my case (set
> >
On Tue, May 24, 2022 at 08:12:25PM +, Job Snijders wrote:
> Hi all,
>
> I based this off reading https://datatracker.ietf.org/doc/html/rfc9234
>
> This code is untested! I haven't had a chance yet to tcpdump a RFC 9234
> capable BGP speaker. There might be some out there, according to
>
Noticed this morning working on something else. The non-transitive
extended community support is fairly messed up. In my case (set
ext-community rt 1:1) it causes the community to be skipped.
First of all the check in non_transitive_community() is messed up. It uses
the wrong data field, does a
This diff moves and renames the defines that define the maximum number of
parallel requests for http and rsync.
The defines are now MAX_HTTP_REQUESTS and MAX_RSYNC_REQUESTS the values
remane the same.
Also move the memset of pollfd sets in http.c into the loop. It is not
needed but I prefer it
On Sun, May 15, 2022 at 10:35:43AM +0200, Mark Kettenis wrote:
> > From: "Ted Unangst"
> > Date: Sat, 14 May 2022 20:23:39 -0400
> >
> > The cpu hz sensor is more accurate and updates faster than than the value
> > currently used for hw.cpuspeed. So return that value (scaled).
> >
> > This
This diff replaces most of the rttimer with a timeout(9) call.
Instead of running a 1 second timer all the time it runs idividual
timeouts for each rttimer object.
rt_timer_remove_all() needs to be careful to not remove the rttimer object
while the timeout callback is running or up to be run.
It
On Thu, May 12, 2022 at 07:44:51PM +0200, Theo Buehler wrote:
> ip_addr_parse() sticks its fingers into undocumented API surface of
> libcrypto. What is true is that the unused bit count is in the lower
> three bits of p->flags, provided that ASN1_STRING_FLAG_BITS_LEFT is set.
> This is
On Thu, May 12, 2022 at 11:27:21AM +0200, Theo Buehler wrote:
> This aligns sbgp_ipaddrblk() with sbgp_assysnum(), giving it a similar
> treatment. We trade the reallocarray() per prefix or range with at most
> two recallocarray(). I took the liberty of trimming some RFC section
> numbers in
On Thu, May 12, 2022 at 10:17:30AM +0200, Theo Buehler wrote:
> Before refactoring the IP side, let's streamline the code a little.
> Populate struct ip in the leaf functions instead of handing it through
> several layers and copying it along the way. Pass in the afi instead of
> letting struct ip
I took the liberty and refactored the sbgp_assysnum() code a bit more.
Main goal is to replace the reallocarray() in append_as() with an upfront
calloc() call since now the size is known. Also I decided to collaps
sbgp_asnum() into sbgp_assysnum().
One could also inline the now very simple
On Wed, May 11, 2022 at 08:50:57AM -0600, Bob Beck wrote:
> yes makes sense
>
> ok beck@
agreed, ok claudio@
> > On May 11, 2022, at 07:53, Theo Buehler wrote:
> >
> > Some funky libcrypto business ahead.
> >
> > X509 API functions such as X509_check_ca() or X509_get_extension_flags()
> >
On Tue, May 10, 2022 at 08:43:45PM +0200, Theo Buehler wrote:
> The ASIdentifiers code is a bit strangely factored presumably due to
> constraints of the low-level shoveling. I kept the coarse structure
> of the code and left some house keeping for later. The changes in
> sbgp_asrange() and
On Tue, May 10, 2022 at 01:27:17PM +0200, Theo Buehler wrote:
> This is a straightforward conversion to letting libcrypto's RFC 3779
> code parse a cert's IPAddrBlocks. The magic happens in X509V3_EXT_d2i()
> in sbgp_ipaddrblk(). After that, we simply have to walk the returned
> structure. The
On Tue, May 10, 2022 at 01:47:44PM +0200, Theo Buehler wrote:
> In sbgp_asrange() and sbgp_addr_range(), the ASN1_SEQUENCE_ANY *seq is
> potentially leaked due to early return 0 instead of goto out. The last
> hunk collides with my IPAddrBlocks diff. Sending this out so I don't
> forget.
>
>
On Tue, May 10, 2022 at 08:38:32AM +0200, Theo Buehler wrote:
> On Tue, May 10, 2022 at 08:28:10AM +0200, Claudio Jeker wrote:
> > On Tue, May 10, 2022 at 08:05:00AM +0200, Theo Buehler wrote:
> > > This moves valid_filename() to validate.c and splits out a helper
> > >
On Tue, May 10, 2022 at 08:05:00AM +0200, Theo Buehler wrote:
> This moves valid_filename() to validate.c and splits out a helper
> portable_filename() which can be used from the RSC code. While moving
> valid_filename() is not necessary, I thought it makes sense to keep the
> two functions next
On Mon, May 09, 2022 at 01:07:17PM +, Job Snijders wrote:
> On Mon, May 09, 2022 at 12:11:22PM +0200, Claudio Jeker wrote:
> > why does the draft allow for optional filenames? What the heck is the
> > digest then covering some random gunk?
>
> Yes, that is entirely
On Mon, May 09, 2022 at 12:53:05PM +0200, Theo Buehler wrote:
> > As the various same-named-but-different 'parse' structs are not easily
> > interchangeable without more refactoring, I marked them "XXX:". Perhaps
> > we can work on that in tree?
>
> I'm fine with fixing that in-tree. Sorry about
On Sun, May 08, 2022 at 08:05:08PM +, Job Snijders wrote:
> Dear Theo, fellow developers,
>
> Many thanks for the first review pass, much appreciated.
>
> > This is a good first step. I have a few initial comments inline. Once you
> > fix
> > those, review of the rest will be easier.
> >
>
On Thu, May 05, 2022 at 11:37:24AM +0200, Claudio Jeker wrote:
> So most routing daemons and other network daemons like pppd do not allow
> 240/4 as IPs because they check the IP against IN_BADCLASS().
> I think it is time to remove this restriction.
>
> Now there is another
In total there are 6 rt_timer_queues in our kernel. 3 IPv4 and 3 IPv6.
That number may be increased to 8 if arp and nd would use these timers as
well. Because of this allocation the queue heads via pool(9) is overkill.
Switch rt_timer_queue_create to rt_timer_queue_init which just sets up the
So most routing daemons and other network daemons like pppd do not allow
240/4 as IPs because they check the IP against IN_BADCLASS().
I think it is time to remove this restriction.
Now there is another magical network 0.0.0.0/8 which is not allowed in
some but not all of the routing daemons. Not
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
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
>
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
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().
>
On Tue, May 03, 2022 at 02:08:33PM +0200, Alexandr Nedvedicky wrote:
> Hello
>
> On Tue, May 03, 2022 at 10:44:48AM +0200, Claudio Jeker wrote:
>
> >
> > The RFC does not use the usual MUST to enforce any of this.
> > So yes, we should probably not be too
Next stage of rttimer cleanup. Move the callback from the rttimer to the
rttimer_queue struct. The callback is always the same for a queue so there
is no need to define it on every call.
On top of that replace rt_timer_queue_destroy() with
rt_timer_queue_flush(). With this queues can no longer be
On Tue, May 03, 2022 at 12:05:06AM +0200, Alexander Bluhm wrote:
> On Mon, May 02, 2022 at 11:30:58PM +0200, Alexandr Nedvedicky wrote:
> > hello,
> >
> > bluhm@ has committed a fix [1] which makes pf to accept IGMP/MLD messages.
> > If I remember correct pf(4) was dropping those messages because
The callback currently uses struct rttimer as an argument but the code
only needs the rtt_tableid element from there. Change the callbacks to
be of the form void (*rtt_callback)(struct rtentry *r, u_int rtableid)
Also change the default rttimer callback (in case the function is NULL)
to only
On Thu, Apr 28, 2022 at 07:24:22PM +0200, Alexander Bluhm wrote:
> I still need an ok for this diff. It is the final step before we
> can run IP forwaring in parallel.
Fine with me. If it holds you back put it in OK claudio@
I will rip the rttimer code appart in the next days and make that API a
On Thu, Apr 28, 2022 at 05:51:57PM +0200, Alexander Bluhm wrote:
> On Wed, Apr 27, 2022 at 12:10:59PM +0200, Claudio Jeker wrote:
> > There is no need to have a rttimer queue per rdomain. The rttimer itself
> > is rdomain aware and so this just make everything more complicated
spec_close() does a fair bit of extra work around the xlock flag.
Now spec_close() is called via VOP_CLOSE and either the vnode has VXLOCK
set (because it is called via vclean()) or it does not. In either case
VXLOCK can not change during call (at least that was my conclusion looking
at the code).
This is just a mini cleanup. Switch from vgone() to vgonel() like it is
done a bit later already. vgone() is just a wrapper around vgonel() using
curproc (which is cached in vop_generic_revoke()).
--
:wq Claudio
Index: vfs_default.c
There is no need to have a rttimer queue per rdomain. The rttimer itself
is rdomain aware and so this just make everything more complicated for no
gain.
This diff just drops back to a single queue and initializes the queues in
ip_init() and the IPv6 counterpart. I have no mrouter setup to test
On Mon, Apr 25, 2022 at 11:31:22AM -0400, Bryan Steele wrote:
> On Mon, Apr 25, 2022 at 05:20:46PM +0200, Claudio Jeker wrote:
> > On Sun, Apr 24, 2022 at 07:06:19PM +0200, Claudio Jeker wrote:
> > > On Ryzen CPUs each CCD has a temp sensor. If the CPU has CCDs (which
> >
On Mon, Apr 25, 2022 at 05:22:51PM +0200, Hrvoje Popovski wrote:
> On 25.4.2022. 16:50, Hrvoje Popovski wrote:
> > On 25.4.2022. 16:19, Claudio Jeker wrote:
> >> After I sent out my ksmn(4) diff to include cpu frequency sensors dlg@
> >> told me that this is a generic wa
On Sun, Apr 24, 2022 at 07:06:19PM +0200, Claudio Jeker wrote:
> On Ryzen CPUs each CCD has a temp sensor. If the CPU has CCDs (which
> excludes Zen APU CPUs) this should show additional temp info. This is
> based on info from the Linux k10temp driver.
>
> Additionally use t
After I sent out my ksmn(4) diff to include cpu frequency sensors dlg@
told me that this is a generic way to find the cpu frequency on modern x86
cpus (both intel and amd support it).
So this diff cleans up the CPU frequency sensors and moves them to the
cpu(4). I had to split the sensor
On Sun, Apr 24, 2022 at 02:30:37PM -0400, Bryan Steele wrote:
> On Sun, Apr 24, 2022 at 07:06:19PM +0200, Claudio Jeker wrote:
> > On Ryzen CPUs each CCD has a temp sensor. If the CPU has CCDs (which
> > excludes Zen APU CPUs) this should show additional temp info. This is
> &g
On Ryzen CPUs each CCD has a temp sensor. If the CPU has CCDs (which
excludes Zen APU CPUs) this should show additional temp info. This is
based on info from the Linux k10temp driver.
Additionally use the MSRs defined in "Open-Source Register Reference For
AMD Family 17h Processors" to measure
On Fri, Apr 22, 2022 at 12:28:21AM +0200, Sebastian Benoit wrote:
> Claudio Jeker(cje...@diehard.n-r-g.com) on 2022.04.20 15:12:57 +0200:
> > On Wed, Apr 20, 2022 at 03:00:15PM +0200, Theo Buehler wrote:
> > > Found this when looking at the timezone issue a co
On Thu, Apr 21, 2022 at 03:25:03PM +0200, Alexander Bluhm wrote:
> Hi,
>
> As claudio@ wants to refactor router timer before making them MP
> safe, I would like to protect them with kernel lock. It should fix
> this panic.
>
> https://marc.info/?l=openbsd-tech=164038527425440=2
>
> I hope this
On Thu, Apr 21, 2022 at 02:08:01PM +0200, Theo Buehler wrote:
> On Thu, Apr 21, 2022 at 01:14:31PM +0200, Claudio Jeker wrote:
> > So here is the cleanup of filemode.c and also a bit of cleanup in parse.c
> > This should also fix a few bugs in parse_load_certchain() (main
So here is the cleanup of filemode.c and also a bit of cleanup in parse.c
This should also fix a few bugs in parse_load_certchain() (mainly
memleaks).
--
:wq Claudio
Index: cert.c
===
RCS file:
On Wed, Apr 20, 2022 at 08:12:51PM +0200, Alexander Bluhm wrote:
> Hi,
>
> mvs@ reminded me of a crash I have seen in December. Route timers
> are not MP safe, but I think this can be fixed with a mutex. The
> idea is to protect the global lists with a mutex and move the rttimer
> into a
On Wed, Apr 20, 2022 at 08:07:06PM +0200, Theo Buehler wrote:
> On Wed, Apr 20, 2022 at 07:14:23PM +0200, Claudio Jeker wrote:
> > The filemode code is enough different from the regular parser code that it
> > makes sense to totally split it out. Only proc_parse
ct filepath_tree *, char *);
Index: filemode.c
===
RCS file: filemode.c
diff -N filemode.c
--- /dev/null 1 Jan 1970 00:00:00 -
+++ filemode.c 20 Apr 2022 16:47:12 -
@@ -0,0 +1,589 @@
+/* $OpenBSD: parser.c,v 1.70 2022/04/20 10:46:20 job Exp $ */
+/*
+ * Copyright
On Wed, Apr 20, 2022 at 03:00:15PM +0200, Theo Buehler wrote:
> Found this when looking at the timezone issue a couple of weeks back and
> then forgot about it:
>
> This setenv() + localtime() looks like a hack to me and I don't really
> understand why it should be preferable over using gmtime()
On Tue, Apr 19, 2022 at 10:49:44PM +0200, Alexander Bluhm wrote:
> Hi,
>
> I had a look in route timer queues in netinet and netinet6 and found
> some inconsistencies.
>
> - Timeout was a mixture of int, u_int and long. Make timeout
> int with sysctl bounds checking and make absolute time
On Tue, Apr 19, 2022 at 10:04:26PM +0200, Theo Buehler wrote:
> I first wanted to change the %i to a %d, then I noticed that timeout < 1
> can't be true since timeout != 0 and 0 <= timeout <= 24*60*60.
Makes sense. OK claudio@
> Index: main.c
>
On Tue, Apr 19, 2022 at 08:22:53PM +0200, Theo Buehler wrote:
> If the checks involving crlfile fail one way or the other, we'll leak
> crldp. Here's one way to fix it. We could also drop the free(crldp) in
> the body or add a free to the relevant conditional.
I think it would be better to only
On Tue, Apr 19, 2022 at 07:35:35PM +0200, Theo Buehler wrote:
> On Tue, Apr 19, 2022 at 07:24:04PM +0200, Claudio Jeker wrote:
> > I tripped over this and this optimisation hurts more then it helps.
> > So lets just create a new EVP_ENCODE_CTX for every base64_decode()
>
I tripped over this and this optimisation hurts more then it helps.
So lets just create a new EVP_ENCODE_CTX for every base64_decode()
call and cleanup at the end of the call.
--
:wq Claudio
Index: encoding.c
===
RCS file:
501 - 600 of 2249 matches
Mail list logo
