Re: Why store pointers for some functions in malloc.c?

From: Otto Moerbeek Date: Wed, 18 Oct 2023 07:28:47 +0200 > On Wed, Oct 18, 2023 at 09:23:49AM +0900, Masato Asou wrote: > >> Hello tech@ and otto, >> >> Why do only some calling functions store the pinttes in region_info as >> below: >> >> static void * >> malloc_bytes(struct dir_info *d,

Re: Why store pointers for some functions in malloc.c?

On Wed, Oct 18, 2023 at 09:23:49AM +0900, Masato Asou wrote: > Hello tech@ and otto, > > Why do only some calling functions store the pinttes in region_info as > below: > > static void * > malloc_bytes(struct dir_info *d, size_t size, void *f) > { > > found: > if (i == 0 && k == 0 &&

Re: pkg_add: No progress meter: failed termcap loop

On Tue, Oct 17, 2023 at 06:34:58PM -0700, Andrew Hewus Fresh wrote: > On Tue, Oct 17, 2023 at 06:13:30PM -0700, Andrew Hewus Fresh wrote: > > On Tue, Oct 17, 2023 at 05:10:44PM -0700, Greg Steuck wrote: > > > I just got myself a fresh snapshot with libncurses.so.15.0: > > > OpenBSD 7.4-current

Re: pkg_add: No progress meter: failed termcap loop

On Tue, Oct 17, 2023 at 06:34:58PM -0700, Andrew Hewus Fresh wrote: > On Tue, Oct 17, 2023 at 06:13:30PM -0700, Andrew Hewus Fresh wrote: > > On Tue, Oct 17, 2023 at 05:10:44PM -0700, Greg Steuck wrote: > > > I just got myself a fresh snapshot with libncurses.so.15.0: > > > OpenBSD 7.4-current

mention U-Boot file and offset for Rockchip RK356x

ok? Index: distrib/notes/arm64/prep === RCS file: /cvs/src/distrib/notes/arm64/prep,v retrieving revision 1.18 diff -u -p -u -p -r1.18 prep --- distrib/notes/arm64/prep10 Apr 2023 12:57:15 - 1.18 +++

Re: pkg_add: No progress meter: failed termcap loop

On Tue, Oct 17, 2023 at 06:13:30PM -0700, Andrew Hewus Fresh wrote: > On Tue, Oct 17, 2023 at 05:10:44PM -0700, Greg Steuck wrote: > > I just got myself a fresh snapshot with libncurses.so.15.0: > > OpenBSD 7.4-current (GENERIC.MP) #1409: Tue Oct 17 17:08:49 MDT 2023 > > > > I get some

Re: pkg_add: No progress meter: failed termcap loop

On Tue, Oct 17, 2023 at 05:10:44PM -0700, Greg Steuck wrote: > I just got myself a fresh snapshot with libncurses.so.15.0: > OpenBSD 7.4-current (GENERIC.MP) #1409: Tue Oct 17 17:08:49 MDT 2023 > > I get some unhappiness now: > # pkg_add -ui > No progress meter: failed termcap loop > quirks-6.161

Why store pointers for some functions in malloc.c?

Hello tech@ and otto, Why do only some calling functions store the pinttes in region_info as below: static void * malloc_bytes(struct dir_info *d, size_t size, void *f) { found: if (i == 0 && k == 0 && DO_STATS) { struct region_info *r = find(d, bp->page);

Re: HAMMER2 filesystem for OpenBSD

Chris Narkiewicz writes: > On Tue, 2023-10-17 at 16:22 -0600, Theo de Raadt wrote: >> What will come of this discussion of opinions? > > If it's doable and the code quality is acceptable, I see 2 outcomes: > 1. I could start looking for sponsorship, as I feel like my level of > expertise is too

pkg_add: No progress meter: failed termcap loop

I just got myself a fresh snapshot with libncurses.so.15.0: OpenBSD 7.4-current (GENERIC.MP) #1409: Tue Oct 17 17:08:49 MDT 2023 I get some unhappiness now: # pkg_add -ui No progress meter: failed termcap loop quirks-6.161 signed on 2023-10-16T11:16:03Z Fallout from the ncurses upgrade? Thanks

syslogd udp dropped counter

Hi, Now that syslogd handles delayed DNS lookups, I think we should count dropped packets to UDP loghosts. Although not every dropped UDP packet can be detected, the message makes the admin aware that there may be a blind spot during startup. syslogd[26493]: dropped 8 messages to udp loghost

Re: HAMMER2 filesystem for OpenBSD

On Tue, 2023-10-17 at 16:22 -0600, Theo de Raadt wrote: > What will come of this discussion of opinions? If it's doable and the code quality is acceptable, I see 2 outcomes: 1. I could start looking for sponsorship, as I feel like my level of expertise is too limited to chew it myself 2. perhaps

Re: HAMMER2 filesystem for OpenBSD

What will come of this discussion of opinions? Chris Narkiewicz wrote: > Hi, > > Tomohiro Kusumi is currently working on HAMMER2 implementation > for OpenBSD, FreeBSD and NetBSD. > > The repository is here: > https://github.com/kusumi/openbsd_hammer2 > > > He maintains repositories for

HAMMER2 filesystem for OpenBSD

Hi, Tomohiro Kusumi is currently working on HAMMER2 implementation for OpenBSD, FreeBSD and NetBSD. The repository is here: https://github.com/kusumi/openbsd_hammer2 He maintains repositories for NetBSD, FreeBSD and OpenBSD, which suggests that the implementation is portable. He also provides

Re: smtpd: implement nullmx RFC 7505

[2023-10-17 17:32] Omar Polo > sorry for the terrifc delay. > > On 2023/10/01 14:59:15 +0200, Philipp wrote: > > Hi > > > > Setting Null MX is a way for domainowners to indicate that the domain > > does not accept mail. Currently a Null MX causes a tempfail and the > > mail will be queued and

Re: snmpd [3/16]: Distinguish between parseerror and openfailed for agentx-open-pdu

On Tue, Oct 17, 2023 at 02:51:03PM +0200, Martijn van Duren wrote: > RFC2741 section 7.1.1 tells us that if a pdu can't be parsed we must > return a parseerror. Section 7.1 gives an example of "An unrecognized > value is encountered". The spec is vague is a bit vague on what > constitutes a

Re: snmpd [1.1/16]: Don't overflow oid in agentx parser

On Tue, Oct 17, 2023 at 02:49:05PM +0200, Martijn van Duren wrote: > > Currently ax.c doesn't check the maximum length of an OID ax_pdutooid. > > This can lead to a buffer overflow. Even though it must be fixed, I > > don't think there's a big risk here, since an attacker would need to have > >

Re: snmpd [2.2/16]: Don't set NON_DEFAULT_CONTEXT for agentx-response-pdu

On Tue, Oct 17, 2023 at 02:49:57PM +0200, Martijn van Duren wrote: > > According to RFC2741 section 6.1.1 an agentx-response-pdu shouldn't have > > the NON_DEFAULT_CONTEXT set. Remove the argument from ax_response(). > > Here's the libagentx counterpart. ok

Re: smtpd: implement nullmx RFC 7505

Hello, sorry for the terrifc delay. On 2023/10/01 14:59:15 +0200, Philipp wrote: > Hi > > Setting Null MX is a way for domainowners to indicate that the domain > does not accept mail. Currently a Null MX causes a tempfail and the > mail will be queued and tried to resubmitted till a timeout.

Re: Please test: make ipsec(4) timeouts mpsafe

On 17.10.2023. 1:07, Vitaliy Makkoveev wrote: >> On 13 Oct 2023, at 18:40, Hrvoje Popovski wrote: >> >> On 12.10.2023. 20:10, Vitaliy Makkoveev wrote: >>> Hi, MP safe process timeouts were landed to the tree, so time to test >>> them with network stack :) Diff below makes tdb and ids garbage >>>

Re: bgpd cleanup around mask2prefixlen

On Tue, Oct 17, 2023 at 04:47:36PM +0200, Claudio Jeker wrote: > Looking at fixing portable I realized that some bits around mask2prefixlen > can be cleaned up. > > First in session.c the plen != 0xff check is not needed since it never can > happen. > > 2nd the checks for sin_len and sin6_len ==

bgpd cleanup around mask2prefixlen

Looking at fixing portable I realized that some bits around mask2prefixlen can be cleaned up. First in session.c the plen != 0xff check is not needed since it never can happen. 2nd the checks for sin_len and sin6_len == 0 are also impossible. A sockaddr can not have length 0. A default route

snmpd [16/16]: Keep track of exact registrations via AgentX

This diff I'm least convinced about, but I do want to put it out there. As far as I'm aware RFC2741 places no restrictions on direct mapping of unregistrations on registrations. Meaning that if I register 1.3.6.1.2.[1-10] and I just unregister 1.3.6.1.2.5 this should leave 1.3.6.1.2.[1-4] and

snmpd [15/16]: When we have an error, all oids must be identical to the request

RFC3416 section 4.2.1 (and others) tells us that if an error occurs the varbindlist in the response must be identical to the original request. There might be other edge-cases here, but let's at least make sure that the OIDs haven't been tampered with. OK? martijn@ diff --git a/application.c

snmpd [14/16]: Validate the returned error code

Certain error codes are only intended for certain request-types. Add an appl_error_valid() function to test for this. OK? martijn@ diff --git a/application.c b/application.c index 6ddeb39..53e793d 100644 --- a/application.c +++ b/application.c @@ -130,6 +130,7 @@ void

snmpd [13/16]: registered instances must not return below OID

If a backend registers as an instance it must never return OIDs below their registration. Add a test for this in appl_varbind_valid(). OK? martijn@ diff --git a/application.c b/application.c index dfa7220..6ddeb39 100644 --- a/application.c +++ b/application.c @@ -128,8 +128,8 @@ void

snmpd [12/16]: Make ab_range in application_agentx explicit 1

appl_agentx_session doesn't set ab_range explicitly to 1, and thus relies on malloc randomness to set it. Sit it explicitly. OK? martijn@ diff --git a/application_agentx.c b/application_agentx.c index 680725d..79900d6 100644 --- a/application_agentx.c +++ b/application_agentx.c @@ -548,6 +548,7

snmpd [11/16]: When a request results in EOMV we must return the requesting OID

According to RFC3416 section 4.2.2 and 4.2.3 case "(2)" when an endOfMibView is returned the OID must be identical to originally requested OID. Currently this can fail when the original request is in a !last registered region and all subsequent regions also return EOMV. Store the original OID and

snmpd [10/16]: Make retries on open session where connection is closed return early

Here's a special case unlikely to be found in the wild: When opening 2 sessions on an agentx connection (already unusual) and registering 2 overlapping regions on the different sessions, e.g. by differing in priority (even more unusual) and we close the underlying connection with an outstanding

snmpd [9/16]: Fix range handling with appl_unregister

Right now (un)registering a region with range_subid set to !0 will fail. Apparently nothing in the wild uses this, but let's fix it. This is the unregister part. OK? martijn@ diff --git a/application.c b/application.c index f8709b8..e780025 100644 --- a/application.c +++ b/application.c @@

snmpd [8/16]: Fix range handling with appl_register

Right now (un)registering a region with range_subid set to !0 will fail. Apparently nothing in the wild uses this, but let's fix it. This is the register part. OK? martijn@ diff --git a/application.c b/application.c index a02260b..f8709b8 100644 --- a/application.c +++ b/application.c @@

snmpd [7/16]: Treat agentx-close-pdu with reasonByManager as a parseerror

RFC2741 section 6.2.2 says that reasonByManager can only be used by the agentx master. Treat this reason as a parseerror. OK? martijn@ diff --git a/application_agentx.c b/application_agentx.c index d1efae2..2231d4c 100644 --- a/application_agentx.c +++ b/application_agentx.c @@ -576,16

snmpd [6/16]: support close reason for appl_agentx_free

appl_agentx_free() closes any potential open sessions before closing the connection and cleaning up. This function is called from multiple contexts and the current APPL_CLOSE_REASONSHUTDOWN is not always applicable. Add a second reason parameter that can be passed onto appl_agentx_forceclose().

snmpd [5/16]: Check context existence in appl_agentx_recv

application.c checks the context where applicable, but not every agentx-pdu goes through there (e.g. agentx-ping-pdu). Make sure we always check the context in appl_agentx_recv() OK? martijn@ diff --git a/application.c b/application.c index dd92864..a02260b 100644 --- a/application.c +++

snmpd [4/16]: check agentx-pdu-header flags for validity

RFC2741 section 6.1 specifies which PDUs can contain which header flags. Check that that incoming agentx PDUs have valid flags in appl_agentx_recv(). While here I cleaned up a few log messages some minor restructuring to prevent the function growing too large. OK? martijn@ diff --git

snmpd [3/16]: Distinguish between parseerror and openfailed for agentx-open-pdu

RFC2741 section 7.1.1 tells us that if a pdu can't be parsed we must return a parseerror. Section 7.1 gives an example of "An unrecognized value is encountered". The spec is vague is a bit vague on what constitutes a parseerror, vs a protocol error, so I don't want to muddle too much with that

snmpd [2.2/16]: Don't set NON_DEFAULT_CONTEXT for agentx-response-pdu

> According to RFC2741 section 6.1.1 an agentx-response-pdu shouldn't have > the NON_DEFAULT_CONTEXT set. Remove the argument from ax_response(). Here's the libagentx counterpart. OK? martijn@ Index: agentx.c === RCS file:

Re: snmpd [1.1/16]: Don't overflow oid in agentx parser

> Currently ax.c doesn't check the maximum length of an OID ax_pdutooid. > This can lead to a buffer overflow. Even though it must be fixed, I > don't think there's a big risk here, since an attacker would need to have > access to the agentx socket, which by default is disabled and defaults > to

snmpd [2.1/16]: Don't set NON_DEFAULT_CONTEXT for agentx-response-pdu

According to RFC2741 section 6.1.1 an agentx-response-pdu shouldn't have the NON_DEFAULT_CONTEXT set. Remove the argument from ax_response(). OK? martijn@ diff --git a/application_agentx.c b/application_agentx.c index c7a2a26..0d73e08 100644 --- a/application_agentx.c +++ b/application_agentx.c

snmpd [1.1/16]: Don't overflow oid in agentx parser

Currently ax.c doesn't check the maximum length of an OID ax_pdutooid. This can lead to a buffer overflow. Even though it must be fixed, I don't think there's a big risk here, since an attacker would need to have access to the agentx socket, which by default is disabled and defaults to

Prevent off-by-one accounting hang in out-of-swap situations

Diff below makes out-of-swap checks more robust. When a system is low on swap, two variables are used to adapt the behavior of the page daemon and fault handler: `swpginuse' indicates how much swap space is being currently used `swpgonly' indicates how much swap space stores

Re: small fix in uvmpd_scan_inactive()

On Tue, Oct 17, 2023 at 12:41:57PM +0200, Martin Pieuchot wrote: > Diff below merges two equivalent if blocks. No functional change, ok? ok tb > > > Index: uvm/uvm_pdaemon.c > === > RCS file: /cvs/src/sys/uvm/uvm_pdaemon.c,v >

small fix in uvmpd_scan_inactive()

Diff below merges two equivalent if blocks. No functional change, ok? Index: uvm/uvm_pdaemon.c === RCS file: /cvs/src/sys/uvm/uvm_pdaemon.c,v retrieving revision 1.107 diff -u -p -r1.107 uvm_pdaemon.c --- uvm/uvm_pdaemon.c 16 Oct

Re: nfsd: don't clear SB_NOINTR flag

On Mon, Oct 16, 2023 at 10:17:50PM +0300, Vitaliy Makkoveev wrote: > This socket comes from userland, so this flag is never set. This makes > SB_NOINTR flag immutable, because we only set this bit on NFS client > socket buffers for all it's lifetime. > > I want to do this because this flag

Re: Improve IPv6 link-local support in bgpd

Claudio Jeker(cje...@diehard.n-r-g.com) on 2023.10.16 09:23:12 +0200: > This diff fixes a few more things when establishing connections with > link-local IPv6 addresses. In get_alternate_addr() the interface scope > of the connection is recovered and then passed to the RDE. The RDE can > then use

Re: log.c use buffered IO

Theo Buehler(t...@theobuehler.org) on 2023.10.17 09:13:15 +0200: > On Mon, Oct 16, 2023 at 12:19:17PM +0200, Claudio Jeker wrote: > > I dislike how log.c does all these asprintf() calls with dubious > > workaround calls in case asprintf() fails. > > You're not alone. > > > IMO it is easier to

Re: log.c use buffered IO

On Mon, Oct 16, 2023 at 12:19:17PM +0200, Claudio Jeker wrote: > I dislike how log.c does all these asprintf() calls with dubious > workaround calls in case asprintf() fails. You're not alone. > IMO it is easier to use the stdio provided buffers and fflush() to get > "atomic" writes on stderr.