Re: CVS: cvs.openbsd.org: src

[Todd C . Miller]

On Tue, 10 Oct 2023 10:14:10 -0700, Chris Cappuccio wrote:

> The Message-ID should be added to any message that doesn't have one.
> An existing Message-ID should not be removed or changed.
>
> The RFC says it "MAY be applied when necessary by an originating SMTP server"
> so the port numbers aren't a terrible idea, but it leaves open plenty
> of room to not add one if someone isn't following the 465/587 scheme.

But smtpd may not be the originating SMTP server.  For "local"
messages (that originated on the server) it knows to add the
Message-ID if missing.  I don't think it should be adding it to
relayed messages.  Messages received on the submission port are
special, they need to be treated as local even though they originated
elsewhere.

 - todd

Re: CVS: cvs.openbsd.org: src

[Chris Cappuccio]

Todd C. Miller [mill...@openbsd.org] wrote:
> On Tue, 10 Oct 2023 10:50:08 +0100, Stuart Henderson wrote:
> 
> > Presumably 465 should be treated the same, though the hardcoded ports
> > don't feel entirely right here - this is presumably something that would
> > want adding for any connection which is allowed to relay ..
> 
> Yes, I think so.  Hard-coding ports is not great but there isn't a
> way in the config file to indicate that explicitly.
> 

The Message-ID should be added to any message that doesn't have one.
An existing Message-ID should not be removed or changed.

The RFC says it "MAY be applied when necessary by an originating SMTP server"
so the port numbers aren't a terrible idea, but it leaves open plenty
of room to not add one if someone isn't following the 465/587 scheme.

If the smtp_tx_dataline or a subset could be called when we know the
message isn't being delivered locally, that would be ideal and avoid
the need to lookup port numbers.

Chris

Re: CVS: cvs.openbsd.org: src

[Todd C . Miller]

On Tue, 10 Oct 2023 10:50:08 +0100, Stuart Henderson wrote:

> Presumably 465 should be treated the same, though the hardcoded ports
> don't feel entirely right here - this is presumably something that would
> want adding for any connection which is allowed to relay ..

Yes, I think so.  Hard-coding ports is not great but there isn't a
way in the config file to indicate that explicitly.

 - todd

Re: CVS: cvs.openbsd.org: src

[Stuart Henderson]

On 2023/10/09 14:55, Todd C. Miller wrote:
> CVSROOT:  /cvs
> Module name:  src
> Changes by:   mill...@cvs.openbsd.org 2023/10/09 14:55:33
> 
> Modified files:
>   usr.sbin/smtpd : smtp_session.c 
> 
> Log message:
> Add Message-Id as needed for messages received on the submission port.
> 
> Since listener->port is in network byte order we need to compare
> against htons(587).  The fix for this got dropped in the rewrite
> in revision 1.335.

Presumably 465 should be treated the same, though the hardcoded ports
don't feel entirely right here - this is presumably something that would
want adding for any connection which is allowed to relay ..

Index: smtp_session.c
===
RCS file: /cvs/src/usr.sbin/smtpd/smtp_session.c,v
retrieving revision 1.436
diff -u -p -r1.436 smtp_session.c
--- smtp_session.c  9 Oct 2023 20:55:32 -   1.436
+++ smtp_session.c  10 Oct 2023 09:41:05 -
@@ -2624,6 +2624,7 @@ smtp_tx_dataline(struct smtp_tx *tx, con
 
case RFC5322_END_OF_HEADERS:
if (tx->session->listener->local ||
+   tx->session->listener->port == htons(465) ||
tx->session->listener->port == htons(587)) {
 
if (!tx->has_date) {

Re: CVS: cvs.openbsd.org: src

[Theo de Raadt]

This change fixes another wart in unveil/pledge which wasn't resolved in
the original design. pledge allows bypass-reading of
/usr/share/zoneinfo/ files for TZ=zone but absolute path support
remained a wart.

Once again, we have to remove a rarely used behavior of libc.  

During pledge and unveil propagation in programs, and even earlier with
privsep development (meaning use of chroot), we added many early calls
to tzset() in programs.  Some programs stopped using chroot, and rely upon
pledge and unveil instead.

Many of those tzset() calls could potentially be removed because other
libc functions can initialize late due to the zoneinfo directory bypass.
When doing so, please remmber -portable versions will still need to
perform the initialization calls early, and also the chroot case still
needs early initialization also.

Todd C. Miller  wrote:

> CVSROOT:  /cvs
> Module name:  src
> Changes by:   mill...@cvs.openbsd.org 2022/09/21 09:57:49
> 
> Modified files:
>   lib/libc/time  : localtime.c tzset.3 
> 
> Log message:
> tzset: ignore TZ if it contains an absolute path or issetugid().
> Reading time zone files from user-controlled paths can result in
> pledge(2) or unveil(2) violations.  We also ignore files that contain
> a '.' character to avoid paths containing ".." or hidden files.
> Work with and OK deraadt@
> 

Re: [EXTERNAL] Re: CVS: cvs.openbsd.org: src

[Eichert, Diana]

Once initially defined engineid should be static, a lot of SNMP polling 
applications use engineid as device identifier.
Consistency and uniqueness are both important.  Some polling system will not 
allow you to add another snmp device 
If engineid is a duplicate.

Network devices usually derive engineid from lowest "numbered" interface.  
Unfortunately you can manually set them, 
this is bad when someone creates a configuration base template which has 
engineid defined, then you end up with 100's 
of network devices with the same engineid.  I've spent quite a bit of time 
cleaning up from the mess this created.

diana 

Re: CVS: cvs.openbsd.org: src

[Martijn van Duren]

On Mon, 2021-08-09 at 21:58 +0100, Stuart Henderson wrote:
> On 2021/08/09 22:35, Martijn van Duren wrote:
> > Moving to tech@
> > 
> > On Mon, 2021-08-09 at 20:56 +0100, Stuart Henderson wrote:
> > > On 2021/08/09 12:14, Martijn van Duren wrote:
> > > > CVSROOT:/cvs
> > > > Module name:src
> > > > Changes by: mart...@cvs.openbsd.org2021/08/09 12:14:53
> > > > 
> > > > Modified files:
> > > > usr.sbin/snmpd : parse.y snmpd.c snmpd.conf.5 snmpd.h snmpe.c 
> > > >  util.c 
> > > > 
> > > > Log message:
> > > > Allow setting the engineid.
> > > > 
> > > > The previous engineid was based aronud the engine boottime and a random
> > > > value, which gives problems when sending/receiving unacknowledged PDUs
> > > > (trapv2) over SNMPv3 with authentication enabled, which need a 
> > > > consistent
> > > > engineid across restarts to determine the correct user from the sender.
> > > > 
> > > > The new default engineid takes a sha256 hash (chosen for its longer 
> > > > output)
> > > > of gethostname(3) and places the first 27 bytes after the new format 
> > > > number
> > > > 129. This should give us a very low probability of collisions, assuming
> > > > all machines have a unique name.
> > > 
> > > what happens if there's a collision? i'm not sure it's safe to assume
> > > unique names.
> > 
> > The engineid is used to load the engine context of the originator agent.
> > For unacknowledged pdu's this means at least loading the remote users
> > (unlike get requests the users, keys and engineid are from the
> > originator).
> > 
> > If there's a collision for trapv2 this means that if a user exists on
> > both remote agents but with different keys one of them will fail.
> > 
> > But if you want to enter a new user of a new system and you find that
> > that engineid already exist it should be a pretty big red flag that
> > there's a collision and the new system can explicitly set the engineid.
> > Similar if you ever want to set up something like "this engineid can
> > only send from this ip": If you see that a new systems engineid already
> > has such restriction it means you have to manually set the engineid.
> > 
> > For existing get requests we don't have any risk: For acknowledged PDUs
> > (get*/set) the engineid will be discovered (RFC3414 Section 4). And
> > people can't have any hefty restrictions in place as is, because
> > previously it was randomly generated at startup, so no persistent
> > engineid to check on.
> > 
> > I don't see any big risks here.
> > 
> > A minor risk would be that if a hostname ever changes traps won't be
> > received anymore, since the engineid changes. But changing a hostname
> > seems like something that doesn't happen very often and brings with it
> > a lot more migration research.
> > 
> > But considering the question if there was a better idea for generating
> > a consistent engineid by jmatthew@ on the 1st without any feedback I
> > went with this one.
> > If you still feel like there's a risk here after my previous reasoning
> > feel free to come up with an alternative. We still have time to change
> > it, and even then we have the range 130-255 to implement new formats
> > (although then we come back to the discussion about defaults without
> > negotiation)
> > > 
> > > > The other formats as specified in SNMP-FRAMEWORK-MIB (RFC3411) are also
> > > > supported as well as arbitrary formats in the range 128-255 for other
> > > > private enterprise numbers in hex format.
> > > > 
> > > > OK jmatthew@
> > > > 
> > > 
> > 
> > 
> 
> Thanks. I haven't looked closely at this before, I just know that it's
> common for agents to set it randomly at startup (net-snmp docs say "must
> be consistent through time and should not change or conflict with another
> agent's engineID.  Ever." which isn't exactly clear which is the stronger
> requirement - consistency or not conflicting).

I'd say the not changing. Because it determines how a password is
changed to an auth-/priv-key, which is needed to decipher an incoming
unacknowledged trap. However, users will always find some legitimate
reason to change it. But that should be their burden.
If during setup it's found that a conflict occurs it should be fine to
change the engineid, but if you change it in production authentication
might fail.
> 
> Regarding the commit, the manual doesn't mention that there's a default.
> Should it? e.g. maybe

Manpages: not my strong suit :-)

I've documented it under hosthash: "This format is the default"
Maybe it should be more clear.
Does this read better (including some extra explanation for your
prior questions)?

Index: snmpd.conf.5
===
RCS file: /cvs/src/usr.sbin/snmpd/snmpd.conf.5,v
retrieving revision 1.54
diff -u -p -r1.54 snmpd.conf.5
--- snmpd.conf.59 Aug 2021 19:13:08 -   1.54
+++ snmpd.conf.59 Aug 2021 22:16:18 -
@@ -158,6 +158,12 @@ specifies the 

Re: CVS: cvs.openbsd.org: src

[Stuart Henderson]

On 2021/08/09 22:35, Martijn van Duren wrote:
> Moving to tech@
> 
> On Mon, 2021-08-09 at 20:56 +0100, Stuart Henderson wrote:
> > On 2021/08/09 12:14, Martijn van Duren wrote:
> > > CVSROOT:/cvs
> > > Module name:src
> > > Changes by: mart...@cvs.openbsd.org2021/08/09 12:14:53
> > > 
> > > Modified files:
> > > usr.sbin/snmpd : parse.y snmpd.c snmpd.conf.5 snmpd.h snmpe.c 
> > >  util.c 
> > > 
> > > Log message:
> > > Allow setting the engineid.
> > > 
> > > The previous engineid was based aronud the engine boottime and a random
> > > value, which gives problems when sending/receiving unacknowledged PDUs
> > > (trapv2) over SNMPv3 with authentication enabled, which need a consistent
> > > engineid across restarts to determine the correct user from the sender.
> > > 
> > > The new default engineid takes a sha256 hash (chosen for its longer 
> > > output)
> > > of gethostname(3) and places the first 27 bytes after the new format 
> > > number
> > > 129. This should give us a very low probability of collisions, assuming
> > > all machines have a unique name.
> > 
> > what happens if there's a collision? i'm not sure it's safe to assume
> > unique names.
> 
> The engineid is used to load the engine context of the originator agent.
> For unacknowledged pdu's this means at least loading the remote users
> (unlike get requests the users, keys and engineid are from the
> originator).
> 
> If there's a collision for trapv2 this means that if a user exists on
> both remote agents but with different keys one of them will fail.
> 
> But if you want to enter a new user of a new system and you find that
> that engineid already exist it should be a pretty big red flag that
> there's a collision and the new system can explicitly set the engineid.
> Similar if you ever want to set up something like "this engineid can
> only send from this ip": If you see that a new systems engineid already
> has such restriction it means you have to manually set the engineid.
> 
> For existing get requests we don't have any risk: For acknowledged PDUs
> (get*/set) the engineid will be discovered (RFC3414 Section 4). And
> people can't have any hefty restrictions in place as is, because
> previously it was randomly generated at startup, so no persistent
> engineid to check on.
> 
> I don't see any big risks here.
> 
> A minor risk would be that if a hostname ever changes traps won't be
> received anymore, since the engineid changes. But changing a hostname
> seems like something that doesn't happen very often and brings with it
> a lot more migration research.
> 
> But considering the question if there was a better idea for generating
> a consistent engineid by jmatthew@ on the 1st without any feedback I
> went with this one.
> If you still feel like there's a risk here after my previous reasoning
> feel free to come up with an alternative. We still have time to change
> it, and even then we have the range 130-255 to implement new formats
> (although then we come back to the discussion about defaults without
> negotiation)
> > 
> > > The other formats as specified in SNMP-FRAMEWORK-MIB (RFC3411) are also
> > > supported as well as arbitrary formats in the range 128-255 for other
> > > private enterprise numbers in hex format.
> > > 
> > > OK jmatthew@
> > > 
> > 
> 
> 

Thanks. I haven't looked closely at this before, I just know that it's
common for agents to set it randomly at startup (net-snmp docs say "must
be consistent through time and should not change or conflict with another
agent's engineID.  Ever." which isn't exactly clear which is the stronger
requirement - consistency or not conflicting).

Regarding the commit, the manual doesn't mention that there's a default.
Should it? e.g. maybe

Index: snmpd.conf.5
===
RCS file: /cvs/src/usr.sbin/snmpd/snmpd.conf.5,v
retrieving revision 1.54
diff -u -p -r1.54 snmpd.conf.5
--- snmpd.conf.59 Aug 2021 19:13:08 -   1.54
+++ snmpd.conf.59 Aug 2021 20:57:10 -
@@ -153,6 +153,7 @@ generation for the
 .Ar auth
 and
 .Ar key .
+By default, a hash of the system hostname is used.
 .Ar enterprise
 specifies the private enterprise number of the instance and can be either an
 integer or
.

Re: CVS: cvs.openbsd.org: src

[Martijn van Duren]

Moving to tech@

On Mon, 2021-08-09 at 20:56 +0100, Stuart Henderson wrote:
> On 2021/08/09 12:14, Martijn van Duren wrote:
> > CVSROOT:/cvs
> > Module name:src
> > Changes by: mart...@cvs.openbsd.org2021/08/09 12:14:53
> > 
> > Modified files:
> > usr.sbin/snmpd : parse.y snmpd.c snmpd.conf.5 snmpd.h snmpe.c 
> >  util.c 
> > 
> > Log message:
> > Allow setting the engineid.
> > 
> > The previous engineid was based aronud the engine boottime and a random
> > value, which gives problems when sending/receiving unacknowledged PDUs
> > (trapv2) over SNMPv3 with authentication enabled, which need a consistent
> > engineid across restarts to determine the correct user from the sender.
> > 
> > The new default engineid takes a sha256 hash (chosen for its longer output)
> > of gethostname(3) and places the first 27 bytes after the new format number
> > 129. This should give us a very low probability of collisions, assuming
> > all machines have a unique name.
> 
> what happens if there's a collision? i'm not sure it's safe to assume
> unique names.

The engineid is used to load the engine context of the originator agent.
For unacknowledged pdu's this means at least loading the remote users
(unlike get requests the users, keys and engineid are from the
originator).

If there's a collision for trapv2 this means that if a user exists on
both remote agents but with different keys one of them will fail.

But if you want to enter a new user of a new system and you find that
that engineid already exist it should be a pretty big red flag that
there's a collision and the new system can explicitly set the engineid.
Similar if you ever want to set up something like "this engineid can
only send from this ip": If you see that a new systems engineid already
has such restriction it means you have to manually set the engineid.

For existing get requests we don't have any risk: For acknowledged PDUs
(get*/set) the engineid will be discovered (RFC3414 Section 4). And
people can't have any hefty restrictions in place as is, because
previously it was randomly generated at startup, so no persistent
engineid to check on.

I don't see any big risks here.

A minor risk would be that if a hostname ever changes traps won't be
received anymore, since the engineid changes. But changing a hostname
seems like something that doesn't happen very often and brings with it
a lot more migration research.

But considering the question if there was a better idea for generating
a consistent engineid by jmatthew@ on the 1st without any feedback I
went with this one.
If you still feel like there's a risk here after my previous reasoning
feel free to come up with an alternative. We still have time to change
it, and even then we have the range 130-255 to implement new formats
(although then we come back to the discussion about defaults without
negotiation)
> 
> > The other formats as specified in SNMP-FRAMEWORK-MIB (RFC3411) are also
> > supported as well as arbitrary formats in the range 128-255 for other
> > private enterprise numbers in hex format.
> > 
> > OK jmatthew@
> > 
> 

Re: sshd proctitle [Re: CVS: cvs.openbsd.org: src]

[Damien Miller]

On Fri, 24 Jan 2020, Stuart Henderson wrote:

> That works - etc/rc.d/sshd diff to match as follows:
> 
> Index: sshd
> ===
> RCS file: /cvs/src/etc/rc.d/sshd,v
> retrieving revision 1.5
> diff -u -p -r1.5 sshd
> --- sshd  22 Jan 2020 13:14:51 -  1.5
> +++ sshd  24 Jan 2020 11:59:52 -
> @@ -6,7 +6,7 @@ daemon="/usr/sbin/sshd"
>  
>  . /etc/rc.d/rc.subr
>  
> -pexp="sshd: \[listener\].*"
> +pexp="sshd: ${daemon}${daemon_flags:+ ${daemon_flags}} \[listener\].*"
>  
>  rc_reload() {
>   ${daemon} ${daemon_flags} -t && pkill -HUP -xf "${pexp}"

ok djm

Re: sshd proctitle [Re: CVS: cvs.openbsd.org: src]

[Damien Miller]

On Fri, 24 Jan 2020, Antoine Jacoutot wrote:

> Great :-)
> Ok aja 

committed, the proctitle looks like this now in case the rc scripts need
further tweaking:

$ pgrep -lf sshd
12844 sshd: /usr/sbin/sshd -f /etc/ssh/sshd_config [listener] 0 of 10-100 
startups

Re: sshd proctitle [Re: CVS: cvs.openbsd.org: src]

[Antoine Jacoutot]

Great :-)
Ok aja 

—
Antoine

> On 24 Jan 2020, at 13:02, Stuart Henderson  wrote:
> 
> On 2020/01/23 21:20, Damien Miller wrote:
>>> On Thu, 23 Jan 2020, Damien Miller wrote:
>>> 
 On Thu, 23 Jan 2020, Damien Miller wrote:
>>> 
 What information would you like there? We could put the first N listen
 addrs in the proctitle if that would help.
>>> 
>>> Maybe like this:
>>> 
>>> 63817 ??  S0:00.05 sshd: [listen] on [0.0.0.0]:22, [::]:22, 0 of 
>>> 10-100
>> 
>> antoine@ said this was not sufficient, so please try the following:
>> 
>> 63817 ??  I0:00.09 sshd: /usr/sbin/sshd [listener] 0 of 10-100 
>> startups
> 
> That works - etc/rc.d/sshd diff to match as follows:
> 
> Index: sshd
> ===
> RCS file: /cvs/src/etc/rc.d/sshd,v
> retrieving revision 1.5
> diff -u -p -r1.5 sshd
> --- sshd22 Jan 2020 13:14:51 -1.5
> +++ sshd24 Jan 2020 11:59:52 -
> @@ -6,7 +6,7 @@ daemon="/usr/sbin/sshd"
> 
> . /etc/rc.d/rc.subr
> 
> -pexp="sshd: \[listener\].*"
> +pexp="sshd: ${daemon}${daemon_flags:+ ${daemon_flags}} \[listener\].*"
> 
> rc_reload() {
>${daemon} ${daemon_flags} -t && pkill -HUP -xf "${pexp}"
> 
> 
> 
>> 
>> diff --git a/sshd.c b/sshd.c
>> index f6139fe..b7ed0f3 100644
>> --- a/sshd.c
>> +++ b/sshd.c
>> @@ -240,6 +240,8 @@ void destroy_sensitive_data(void);
>> void demote_sensitive_data(void);
>> static void do_ssh2_kex(struct ssh *);
>> 
>> +static char *listener_proctitle;
>> +
>> /*
>>  * Close all listening sockets
>>  */
>> @@ -1032,9 +1034,9 @@ server_accept_loop(int *sock_in, int *sock_out, int 
>> *newsock, int *config_s)
>> */
>>for (;;) {
>>if (ostartups != startups) {
>> -setproctitle("[listener] %d of %d-%d startups",
>> -startups, options.max_startups_begin,
>> -options.max_startups);
>> +setproctitle("%s [listener] %d of %d-%d startups",
>> +listener_proctitle, startups,
>> +options.max_startups_begin, options.max_startups);
>>ostartups = startups;
>>}
>>if (received_sighup) {
>> @@ -1347,6 +1349,41 @@ accumulate_host_timing_secret(struct sshbuf 
>> *server_cfg,
>>sshbuf_free(buf);
>> }
>> 
>> +static void
>> +xextendf(char **s, const char *sep, const char *fmt, ...)
>> +__attribute__((__format__ (printf, 3, 4))) __attribute__((__nonnull__ 
>> (3)));
>> +static void
>> +xextendf(char **sp, const char *sep, const char *fmt, ...)
>> +{
>> +va_list ap;
>> +char *tmp1, *tmp2;
>> +
>> +va_start(ap, fmt);
>> +xvasprintf(, fmt, ap);
>> +va_end(ap);
>> +
>> +if (*sp == NULL || **sp == '\0') {
>> +free(*sp);
>> +*sp = tmp1;
>> +return;
>> +}
>> +xasprintf(, "%s%s%s", *sp, sep, tmp1);
>> +free(tmp1);
>> +free(*sp);
>> +*sp = tmp2;
>> +}
>> +
>> +static char *
>> +prepare_proctitle(int ac, char **av)
>> +{
>> +char *ret = NULL;
>> +int i;
>> +
>> +for (i = 0; i < ac; i++)
>> +xextendf(, " ", "%s", av[i]);
>> +return ret;
>> +}
>> +
>> /*
>>  * Main program for the daemon.
>>  */
>> @@ -1774,6 +1811,7 @@ main(int ac, char **av)
>>rexec_argv[rexec_argc] = "-R";
>>rexec_argv[rexec_argc + 1] = NULL;
>>}
>> +listener_proctitle = prepare_proctitle(ac, av);
>> 
>>/* Ensure that umask disallows at least group and world write */
>>new_umask = umask(0077) | 0022;
>> 
> 

Re: sshd proctitle [Re: CVS: cvs.openbsd.org: src]

[Stuart Henderson]

On 2020/01/23 21:20, Damien Miller wrote:
> On Thu, 23 Jan 2020, Damien Miller wrote:
> 
> > On Thu, 23 Jan 2020, Damien Miller wrote:
> > 
> > > What information would you like there? We could put the first N listen
> > > addrs in the proctitle if that would help.
> > 
> > Maybe like this:
> > 
> > 63817 ??  S0:00.05 sshd: [listen] on [0.0.0.0]:22, [::]:22, 0 of 
> > 10-100
> 
> antoine@ said this was not sufficient, so please try the following:
> 
> 63817 ??  I0:00.09 sshd: /usr/sbin/sshd [listener] 0 of 10-100 
> startups

That works - etc/rc.d/sshd diff to match as follows:

Index: sshd
===
RCS file: /cvs/src/etc/rc.d/sshd,v
retrieving revision 1.5
diff -u -p -r1.5 sshd
--- sshd22 Jan 2020 13:14:51 -  1.5
+++ sshd24 Jan 2020 11:59:52 -
@@ -6,7 +6,7 @@ daemon="/usr/sbin/sshd"
 
 . /etc/rc.d/rc.subr
 
-pexp="sshd: \[listener\].*"
+pexp="sshd: ${daemon}${daemon_flags:+ ${daemon_flags}} \[listener\].*"
 
 rc_reload() {
${daemon} ${daemon_flags} -t && pkill -HUP -xf "${pexp}"



> 
> diff --git a/sshd.c b/sshd.c
> index f6139fe..b7ed0f3 100644
> --- a/sshd.c
> +++ b/sshd.c
> @@ -240,6 +240,8 @@ void destroy_sensitive_data(void);
>  void demote_sensitive_data(void);
>  static void do_ssh2_kex(struct ssh *);
>  
> +static char *listener_proctitle;
> +
>  /*
>   * Close all listening sockets
>   */
> @@ -1032,9 +1034,9 @@ server_accept_loop(int *sock_in, int *sock_out, int 
> *newsock, int *config_s)
>*/
>   for (;;) {
>   if (ostartups != startups) {
> - setproctitle("[listener] %d of %d-%d startups",
> - startups, options.max_startups_begin,
> - options.max_startups);
> + setproctitle("%s [listener] %d of %d-%d startups",
> + listener_proctitle, startups,
> + options.max_startups_begin, options.max_startups);
>   ostartups = startups;
>   }
>   if (received_sighup) {
> @@ -1347,6 +1349,41 @@ accumulate_host_timing_secret(struct sshbuf 
> *server_cfg,
>   sshbuf_free(buf);
>  }
>  
> +static void
> +xextendf(char **s, const char *sep, const char *fmt, ...)
> +__attribute__((__format__ (printf, 3, 4))) __attribute__((__nonnull__ 
> (3)));
> +static void
> +xextendf(char **sp, const char *sep, const char *fmt, ...)
> +{
> + va_list ap;
> + char *tmp1, *tmp2;
> +
> + va_start(ap, fmt);
> + xvasprintf(, fmt, ap);
> + va_end(ap);
> +
> + if (*sp == NULL || **sp == '\0') {
> + free(*sp);
> + *sp = tmp1;
> + return;
> + }
> + xasprintf(, "%s%s%s", *sp, sep, tmp1);
> + free(tmp1);
> + free(*sp);
> + *sp = tmp2;
> +}
> +
> +static char *
> +prepare_proctitle(int ac, char **av)
> +{
> + char *ret = NULL;
> + int i;
> +
> + for (i = 0; i < ac; i++)
> + xextendf(, " ", "%s", av[i]);
> + return ret;
> +}
> +
>  /*
>   * Main program for the daemon.
>   */
> @@ -1774,6 +1811,7 @@ main(int ac, char **av)
>   rexec_argv[rexec_argc] = "-R";
>   rexec_argv[rexec_argc + 1] = NULL;
>   }
> + listener_proctitle = prepare_proctitle(ac, av);
>  
>   /* Ensure that umask disallows at least group and world write */
>   new_umask = umask(0077) | 0022;
> 

Re: sshd proctitle [Re: CVS: cvs.openbsd.org: src]

[Damien Miller]

On Thu, 23 Jan 2020, Damien Miller wrote:

> On Thu, 23 Jan 2020, Damien Miller wrote:
> 
> > What information would you like there? We could put the first N listen
> > addrs in the proctitle if that would help.
> 
> Maybe like this:
> 
> 63817 ??  S0:00.05 sshd: [listen] on [0.0.0.0]:22, [::]:22, 0 of 
> 10-100

antoine@ said this was not sufficient, so please try the following:

63817 ??  I0:00.09 sshd: /usr/sbin/sshd [listener] 0 of 10-100 startups


diff --git a/sshd.c b/sshd.c
index f6139fe..b7ed0f3 100644
--- a/sshd.c
+++ b/sshd.c
@@ -240,6 +240,8 @@ void destroy_sensitive_data(void);
 void demote_sensitive_data(void);
 static void do_ssh2_kex(struct ssh *);
 
+static char *listener_proctitle;
+
 /*
  * Close all listening sockets
  */
@@ -1032,9 +1034,9 @@ server_accept_loop(int *sock_in, int *sock_out, int 
*newsock, int *config_s)
 */
for (;;) {
if (ostartups != startups) {
-   setproctitle("[listener] %d of %d-%d startups",
-   startups, options.max_startups_begin,
-   options.max_startups);
+   setproctitle("%s [listener] %d of %d-%d startups",
+   listener_proctitle, startups,
+   options.max_startups_begin, options.max_startups);
ostartups = startups;
}
if (received_sighup) {
@@ -1347,6 +1349,41 @@ accumulate_host_timing_secret(struct sshbuf *server_cfg,
sshbuf_free(buf);
 }
 
+static void
+xextendf(char **s, const char *sep, const char *fmt, ...)
+__attribute__((__format__ (printf, 3, 4))) __attribute__((__nonnull__ 
(3)));
+static void
+xextendf(char **sp, const char *sep, const char *fmt, ...)
+{
+   va_list ap;
+   char *tmp1, *tmp2;
+
+   va_start(ap, fmt);
+   xvasprintf(, fmt, ap);
+   va_end(ap);
+
+   if (*sp == NULL || **sp == '\0') {
+   free(*sp);
+   *sp = tmp1;
+   return;
+   }
+   xasprintf(, "%s%s%s", *sp, sep, tmp1);
+   free(tmp1);
+   free(*sp);
+   *sp = tmp2;
+}
+
+static char *
+prepare_proctitle(int ac, char **av)
+{
+   char *ret = NULL;
+   int i;
+
+   for (i = 0; i < ac; i++)
+   xextendf(, " ", "%s", av[i]);
+   return ret;
+}
+
 /*
  * Main program for the daemon.
  */
@@ -1774,6 +1811,7 @@ main(int ac, char **av)
rexec_argv[rexec_argc] = "-R";
rexec_argv[rexec_argc + 1] = NULL;
}
+   listener_proctitle = prepare_proctitle(ac, av);
 
/* Ensure that umask disallows at least group and world write */
new_umask = umask(0077) | 0022;

Re: sshd proctitle [Re: CVS: cvs.openbsd.org: src]

[Antoine Jacoutot]

On Thu, Jan 23, 2020 at 02:36:43PM +1100, Damien Miller wrote:
> On Wed, 22 Jan 2020, Stuart Henderson wrote:
> 
> > On 2020/01/21 15:39, Damien Miller wrote:
> > > CVSROOT:  /cvs
> > > Module name:  src
> > > Changes by:   d...@cvs.openbsd.org2020/01/21 15:39:57
> > > 
> > > Modified files:
> > >   usr.bin/ssh: sshd.c 
> > > 
> > > Log message:
> > > expose the number of currently-authenticating connections
> > > along with the MaxStartups limit in the proctitle;
> > > suggestion from Philipp Marek, w/ feedback from Craig Miskell
> > > ok dtucker@
> > > 
> > 
> > It's nice to have this information visible, but it brings some problems.
> > You can't now distinguish between multiple sshd processes (e.g. if you
> > run several on different ports it's hard to figure out which one to
> > signal if needed).
> 
> How could you discern between different sshd processes before? Just the
> command-line args?

Yes.
e.g. for 2 different sshd running:
root 92105  0.0  0.0  1360  1296 ??  I  Wed07AM0:00.05 
/usr/sbin/sshd
root 68236  0.0  0.0  1372  1364 ??  S   7:08AM0:00.00 
/usr/sbin/sshd -f /etc/ssh/sshd_config2

> What information would you like there? We could put the first N listen
> addrs in the proctitle if that would help.

Can't we put the args back and append the new things we expose?
That will also be easier to know which currently-authenticating / MaxStartups
sshd process we are talking about if we run several.
proctitle bit us in the arse several times in the past with rc.d.

My 2 cents, maybe I am talking garbage.

-- 
Antoine

Re: sshd proctitle [Re: CVS: cvs.openbsd.org: src]

[Damien Miller]

On Thu, 23 Jan 2020, Damien Miller wrote:

> On Wed, 22 Jan 2020, Stuart Henderson wrote:
> 
> > On 2020/01/21 15:39, Damien Miller wrote:
> > > CVSROOT:  /cvs
> > > Module name:  src
> > > Changes by:   d...@cvs.openbsd.org2020/01/21 15:39:57
> > > 
> > > Modified files:
> > >   usr.bin/ssh: sshd.c 
> > > 
> > > Log message:
> > > expose the number of currently-authenticating connections
> > > along with the MaxStartups limit in the proctitle;
> > > suggestion from Philipp Marek, w/ feedback from Craig Miskell
> > > ok dtucker@
> > > 
> > 
> > It's nice to have this information visible, but it brings some problems.
> > You can't now distinguish between multiple sshd processes (e.g. if you
> > run several on different ports it's hard to figure out which one to
> > signal if needed).
> 
> How could you discern between different sshd processes before? Just the
> command-line args?
> 
> What information would you like there? We could put the first N listen
> addrs in the proctitle if that would help.

Maybe like this:

63817 ??  S0:00.05 sshd: [listen] on [0.0.0.0]:22, [::]:22, 0 of 10-100

ok?

diff --git a/sshd.c b/sshd.c
index ec644c9..15014d1 100644
--- a/sshd.c
+++ b/sshd.c
@@ -240,6 +240,9 @@ void destroy_sensitive_data(void);
 void demote_sensitive_data(void);
 static void do_ssh2_kex(struct ssh *);
 
+/* Listen info for proctitle */
+static char *proctitle_listen_addr;
+
 /*
  * Close all listening sockets
  */
@@ -913,7 +916,7 @@ listen_on_addrs(struct listenaddr *la)
 {
int ret, listen_sock;
struct addrinfo *ai;
-   char ntop[NI_MAXHOST], strport[NI_MAXSERV];
+   char *cp, ntop[NI_MAXHOST], strport[NI_MAXSERV];
 
for (ai = la->addrs; ai; ai = ai->ai_next) {
if (ai->ai_family != AF_INET && ai->ai_family != AF_INET6)
@@ -973,6 +976,15 @@ listen_on_addrs(struct listenaddr *la)
ntop, strport,
la->rdomain == NULL ? "" : " rdomain ",
la->rdomain == NULL ? "" : la->rdomain);
+   if (num_listen_socks < 3) {
+   cp = proctitle_listen_addr;
+   xasprintf(_listen_addr, "%s%s[%s]:%s%s%s",
+   cp == NULL ? "" : cp, cp == NULL ? "" : ", ",
+   ntop, strport,
+   la->rdomain == NULL ? "" : " rdomain ",
+   la->rdomain == NULL ? "" : la->rdomain);
+   free(cp);
+   }
}
 }
 
@@ -1030,7 +1042,9 @@ server_accept_loop(int *sock_in, int *sock_out, int 
*newsock, int *config_s)
 */
for (;;) {
if (ostartups != startups) {
-   setproctitle("[listener] %d of %d-%d startups",
+   setproctitle("[listen] on %s%s, "
+   "%d of %d-%d startups", proctitle_listen_addr,
+   num_listen_socks > 3 ? " [...]" : "",
startups, options.max_startups_begin,
options.max_startups);
ostartups = startups;

Re: sshd proctitle [Re: CVS: cvs.openbsd.org: src]

[Damien Miller]

On Wed, 22 Jan 2020, Stuart Henderson wrote:

> On 2020/01/21 15:39, Damien Miller wrote:
> > CVSROOT:/cvs
> > Module name:src
> > Changes by: d...@cvs.openbsd.org2020/01/21 15:39:57
> > 
> > Modified files:
> > usr.bin/ssh: sshd.c 
> > 
> > Log message:
> > expose the number of currently-authenticating connections
> > along with the MaxStartups limit in the proctitle;
> > suggestion from Philipp Marek, w/ feedback from Craig Miskell
> > ok dtucker@
> > 
> 
> It's nice to have this information visible, but it brings some problems.
> You can't now distinguish between multiple sshd processes (e.g. if you
> run several on different ports it's hard to figure out which one to
> signal if needed).

How could you discern between different sshd processes before? Just the
command-line args?

What information would you like there? We could put the first N listen
addrs in the proctitle if that would help.

-d

Re: sshd proctitle [Re: CVS: cvs.openbsd.org: src]

[Theo de Raadt]

I guess this needs to be changed again, to retain more info from the
original title.

Stuart Henderson  wrote:

> On 2020/01/21 15:39, Damien Miller wrote:
> > CVSROOT:/cvs
> > Module name:src
> > Changes by: d...@cvs.openbsd.org2020/01/21 15:39:57
> > 
> > Modified files:
> > usr.bin/ssh: sshd.c 
> > 
> > Log message:
> > expose the number of currently-authenticating connections
> > along with the MaxStartups limit in the proctitle;
> > suggestion from Philipp Marek, w/ feedback from Craig Miskell
> > ok dtucker@
> > 
> 
> It's nice to have this information visible, but it brings some problems.
> You can't now distinguish between multiple sshd processes (e.g. if you
> run several on different ports it's hard to figure out which one to
> signal if needed).
> 
> The rc.d script also needs updating because it uses pgrep to find the
> matching process:
> 
> Index: sshd
> ===
> RCS file: /cvs/src/etc/rc.d/sshd,v
> retrieving revision 1.4
> diff -u -p -r1.4 sshd
> --- sshd  11 Jan 2018 19:52:12 -  1.4
> +++ sshd  22 Jan 2020 12:52:15 -
> @@ -6,6 +6,8 @@ daemon="/usr/sbin/sshd"
>  
>  . /etc/rc.d/rc.subr
>  
> +pexp="sshd: \[listener\].*"
> +
>  rc_reload() {
>   ${daemon} ${daemon_flags} -t && pkill -HUP -xf "${pexp}"
>  }
> 
> 

sshd proctitle [Re: CVS: cvs.openbsd.org: src]

[Stuart Henderson]

On 2020/01/21 15:39, Damien Miller wrote:
> CVSROOT:  /cvs
> Module name:  src
> Changes by:   d...@cvs.openbsd.org2020/01/21 15:39:57
> 
> Modified files:
>   usr.bin/ssh: sshd.c 
> 
> Log message:
> expose the number of currently-authenticating connections
> along with the MaxStartups limit in the proctitle;
> suggestion from Philipp Marek, w/ feedback from Craig Miskell
> ok dtucker@
> 

It's nice to have this information visible, but it brings some problems.
You can't now distinguish between multiple sshd processes (e.g. if you
run several on different ports it's hard to figure out which one to
signal if needed).

The rc.d script also needs updating because it uses pgrep to find the
matching process:

Index: sshd
===
RCS file: /cvs/src/etc/rc.d/sshd,v
retrieving revision 1.4
diff -u -p -r1.4 sshd
--- sshd11 Jan 2018 19:52:12 -  1.4
+++ sshd22 Jan 2020 12:52:15 -
@@ -6,6 +6,8 @@ daemon="/usr/sbin/sshd"
 
 . /etc/rc.d/rc.subr
 
+pexp="sshd: \[listener\].*"
+
 rc_reload() {
${daemon} ${daemon_flags} -t && pkill -HUP -xf "${pexp}"
 }

Re: pthread process-private futexes [Re: CVS: cvs.openbsd.org: src]

[Martin Pieuchot]

On 24/10/19(Thu) 13:30, Stuart Henderson wrote:
> On 2019/10/21 04:06, Martin Pieuchot wrote:
> > CVSROOT:/cvs
> > Module name:src
> > Changes by: m...@cvs.openbsd.org2019/10/21 04:06:31
> > 
> > Modified files:
> > lib/librthread : synch.h 
> > 
> > Log message:
> > Use process-private futexes to avoid the uvm_map lookup overhead.
> > 
> > While here kill unused _wait() function.
> > 
> > ok visa@
> > 
> 
> I'm going to back this one out for now - it causes hangs with Python
> (seems to be 100% reproducible). Easy/fast test case:
> 
> cd /usr/ports/graphics/py-Pillow
> make
> 
> With this commit, it hangs after
> 
> writing manifest file 'src/Pillow.egg-info/SOURCES.txt'

robert@ figured out that Python3 doesn't have that problem.  If somebody
could figure out which upstream change fixed the issue that would be great.

Re: pthread process-private futexes [Re: CVS: cvs.openbsd.org: src]

[Martin Pieuchot]

On 24/10/19(Thu) 13:30, Stuart Henderson wrote:
> On 2019/10/21 04:06, Martin Pieuchot wrote:
> > CVSROOT:/cvs
> > Module name:src
> > Changes by: m...@cvs.openbsd.org2019/10/21 04:06:31
> > 
> > Modified files:
> > lib/librthread : synch.h 
> > 
> > Log message:
> > Use process-private futexes to avoid the uvm_map lookup overhead.
> > 
> > While here kill unused _wait() function.
> > 
> > ok visa@
> > 
> 
> I'm going to back this one out for now - it causes hangs with Python
> (seems to be 100% reproducible). Easy/fast test case:
> 
> cd /usr/ports/graphics/py-Pillow
> make
> 
> With this commit, it hangs after
> 
> writing manifest file 'src/Pillow.egg-info/SOURCES.txt'

ltrace shows that sempahore are used.

gdb says that sem_init() is always called with `pshared' set to 0.

However python forks then sleeps in futex(2), via sem_wait(3), when
private futexes are used. 

When non-private futexes are used it it seems that threads from a
process wake up the sleeping thread from a parent process:

 84294/104794  python2.7 CALL  futex(0x1a49bbca3008,0x1,0,0,0)
 84677/611464  python2.7 CALL  futex(0x1a49bbca3008,0x2,1,0,0)

To me it seems that shared semaphore, that are advertised in librthread as
non-supported, are in fact used.

Python has a second lock implementation using mutex and condvar, I'd be
interested to know if that works.

pthread process-private futexes [Re: CVS: cvs.openbsd.org: src]

[Stuart Henderson]

On 2019/10/21 04:06, Martin Pieuchot wrote:
> CVSROOT:  /cvs
> Module name:  src
> Changes by:   m...@cvs.openbsd.org2019/10/21 04:06:31
> 
> Modified files:
>   lib/librthread : synch.h 
> 
> Log message:
> Use process-private futexes to avoid the uvm_map lookup overhead.
> 
> While here kill unused _wait() function.
> 
> ok visa@
> 

I'm going to back this one out for now - it causes hangs with Python
(seems to be 100% reproducible). Easy/fast test case:

cd /usr/ports/graphics/py-Pillow
make

With this commit, it hangs after

writing manifest file 'src/Pillow.egg-info/SOURCES.txt'

Re: bgpd "export default-route" [Re: CVS: cvs.openbsd.org: src]

[Stuart Henderson]

Thanks for a couple of offlist replies .. I had a partial src checkout
and "make install" was installing the new binaries to / rather than /usr/sbin.
I thought I had accounted for that and copied them into place but I guess with
the late hour I must have missed something, as I've done a full src checkout
from -current now and it's working as expected.


On 2019/05/29 02:53, Stuart Henderson wrote:
> On 2019/05/13 07:47, Denis Fondras wrote:
> > CVSROOT:/cvs
> > Module name:src
> > Changes by: de...@cvs.openbsd.org   2019/05/13 07:47:36
> > 
> > Modified files:
> > usr.sbin/bgpd  : rde_update.c 
> > 
> > Log message:
> > fix export default-route.
> > 
> > OK claudio@
> > 
> 
> I've just been updating some remaining 6.3-ish boxes and running into
> problems with this.. Does anyone have a config with "export default-route"
> that works OK on -current that I could take a look at and see if I can
> figure out what I've missed?
> 
> I started with a working 6.3 config that has several peer groups (all
> ibgp in this case). For one group it passes a full table, for another
> (a couple of firewalls/VPN boxes etc) it uses "announce default-route"
> to just feed a default route.
> 
> In preparation for the update I made sure I have explicit default "deny
> from/to any" rules at the top of the ruleset, "allow to group XX" for
> that peer group, and no other rules that should deny the default route
> being sent to them.
> 
> After updating to 6.5, 0 routes are received at the peer.
> 
> After spotting the above commit I updated bgpd to -current, same
> again - no routes received at the peer.
> 
> -current$ bgpctl sh rib out
> flags: * = Valid, > = Selected, I = via IBGP, A = Announced,
>S = Stale, E = Error
> origin validation state: N = not-found, V = valid, ! = invalid
> origin: i = IGP, e = EGP, ? = Incomplete
> 
> flags ovs destination  gateway  lpref   med aspath origin
> I*  N 0.0.0.0/00.0.0.0100 0 i
> *   N 0.0.0.0/00.0.0.0100 0 i
> *   N 0.0.0.0/00.0.0.0100 0 i
> I*  N 0.0.0.0/00.0.0.0100 0 i
> I*  N 0.0.0.0/00.0.0.0100 0 i
> I*  N 0.0.0.0/00.0.0.0100 0 i
> I*  N 0.0.0.0/00.0.0.0100 0 i
> I*  N 0.0.0.0/00.0.0.0100 0 i
> I*  N ::/0 :: 100 0 i
> 
> -current$ bgpctl sh rib out nei somepeer
> flags: * = Valid, > = Selected, I = via IBGP, A = Announced,
>S = Stale, E = Error
> origin validation state: N = not-found, V = valid, ! = invalid
> origin: i = IGP, e = EGP, ? = Incomplete
> 
> flags ovs destination  gateway  lpref   med aspath origin
> I*  N 0.0.0.0/00.0.0.0100 0 i
> 
> ... I'm not sure about the 0.0.0.0 for gateway, it doesn't feel right,
> but I can't compare with 6.3 because I don't see anything from "sh rib out 
> nei XX"
> and a plain "sh rib out" isn't available there.
> 
> somepeer$ bgpctl sh
> Neighbor   ASMsgRcvdMsgSent  OutQ Up/Down  
> State/PrfRcvd
> (-current)  x 386398 386395 0 00:53:13  0
> (6.3)   x 386382 386368 0 00:00:02  1
> 
> ..
> 
> I've backed out to 2018/06/12 so I can remove my hastily-added static
> defaults ;) but would be grateful for any clues ..
> 

bgpd "export default-route" [Re: CVS: cvs.openbsd.org: src]

[Stuart Henderson]

On 2019/05/13 07:47, Denis Fondras wrote:
> CVSROOT:  /cvs
> Module name:  src
> Changes by:   de...@cvs.openbsd.org   2019/05/13 07:47:36
> 
> Modified files:
>   usr.sbin/bgpd  : rde_update.c 
> 
> Log message:
> fix export default-route.
> 
> OK claudio@
> 

I've just been updating some remaining 6.3-ish boxes and running into
problems with this.. Does anyone have a config with "export default-route"
that works OK on -current that I could take a look at and see if I can
figure out what I've missed?

I started with a working 6.3 config that has several peer groups (all
ibgp in this case). For one group it passes a full table, for another
(a couple of firewalls/VPN boxes etc) it uses "announce default-route"
to just feed a default route.

In preparation for the update I made sure I have explicit default "deny
from/to any" rules at the top of the ruleset, "allow to group XX" for
that peer group, and no other rules that should deny the default route
being sent to them.

After updating to 6.5, 0 routes are received at the peer.

After spotting the above commit I updated bgpd to -current, same
again - no routes received at the peer.

-current$ bgpctl sh rib out
flags: * = Valid, > = Selected, I = via IBGP, A = Announced,
   S = Stale, E = Error
origin validation state: N = not-found, V = valid, ! = invalid
origin: i = IGP, e = EGP, ? = Incomplete

flags ovs destination  gateway  lpref   med aspath origin
I*  N 0.0.0.0/00.0.0.0100 0 i
*   N 0.0.0.0/00.0.0.0100 0 i
*   N 0.0.0.0/00.0.0.0100 0 i
I*  N 0.0.0.0/00.0.0.0100 0 i
I*  N 0.0.0.0/00.0.0.0100 0 i
I*  N 0.0.0.0/00.0.0.0100 0 i
I*  N 0.0.0.0/00.0.0.0100 0 i
I*  N 0.0.0.0/00.0.0.0100 0 i
I*  N ::/0 :: 100 0 i

-current$ bgpctl sh rib out nei somepeer
flags: * = Valid, > = Selected, I = via IBGP, A = Announced,
   S = Stale, E = Error
origin validation state: N = not-found, V = valid, ! = invalid
origin: i = IGP, e = EGP, ? = Incomplete

flags ovs destination  gateway  lpref   med aspath origin
I*  N 0.0.0.0/00.0.0.0100 0 i

... I'm not sure about the 0.0.0.0 for gateway, it doesn't feel right,
but I can't compare with 6.3 because I don't see anything from "sh rib out nei 
XX"
and a plain "sh rib out" isn't available there.

somepeer$ bgpctl sh
Neighbor   ASMsgRcvdMsgSent  OutQ Up/Down  State/PrfRcvd
(-current)  x 386398 386395 0 00:53:13  0
(6.3)   x 386382 386368 0 00:00:02  1

..

I've backed out to 2018/06/12 so I can remove my hastily-added static
defaults ;) but would be grateful for any clues ..

Re: CVS: cvs.openbsd.org: src

[Denis Fondras]

On Fri, Dec 28, 2018 at 03:05:15PM -0700, Denis Fondras wrote:
> CVSROOT:  /cvs
> Module name:  src
> Changes by:   de...@cvs.openbsd.org   2018/12/28 15:05:15
> 
> Modified files:
>   usr.sbin/bgpd  : kroute.c 
> 
> Log message:
> move kroute_find() call later
> 
> No need to scan the list if we return early.
> 
> OK claudio@
> 

Doh! I forgot to mention this was spotted by kn@. Sorry.

Re: CVS: cvs.openbsd.org: src

[Paul Irofti]

> Because you can tuna meltover, but you can't tune a fish.
> (hat tip to the author of the tunefs(8) manpage.)

And to REO Speedwagon!

Re: CVS: cvs.openbsd.org: src

[Philip Guenther]

On Thu, Jul 12, 2018 at 2:11 PM Philip Guenther 
wrote:

> CVSROOT:/cvs
> Module name:src
> Changes by: guent...@cvs.openbsd.org2018/07/12 08:11:11
>
> Modified files:
> sys/arch/amd64/amd64: cpu.c identcpu.c locore.S machdep.c pmap.c
>   vector.S
> sys/arch/amd64/conf: ld.script
> sys/arch/amd64/include: asm.h codepatch.h
>
> Log message:
> Reorganize the Meltdown entry and exit trampolines for syscall and
> traps so that the "mov %rax,%cr3" is followed by an infinite loop
> which is avoided because the mapping of the code being executed is
> changed.  This means the sysretq/iretq isn't even present in that
> flow of instructions in the kernel mapping, so userspace code can't
> be speculatively reached on the kernel mapping and totally eliminates
> the conditional jump over the the %cr3 change that supported CPUs
> without the Meltdown vulnerability.  The return paths were probably
> vulnerable to Spectre v1 (and v1.1/1.2) style attacks, speculatively
> executing user code post-system-call with the kernel mappings, thus
> creating cache/TLB/etc side-effects.


Damnit, I left out that since this evolves the _Meltdown_ fix with mapping
_over_ the trampoline, we're calling this the Tuna Meltover.

Because you can tuna meltover, but you can't tune a fish.
(hat tip to the author of the tunefs(8) manpage.)


Philip Guenther

Re: CVS: cvs.openbsd.org: src

[Theo de Raadt]

> On Fri, Feb 9, 2018, at 3:46 PM, Theo de Raadt wrote:
> > > On Thu, Feb 8, 2018, at 9:01 PM, Theo de Raadt wrote:
> > > > CVSROOT:/cvs
> > > > Module name:src
> > > > Changes by: dera...@cvs.openbsd.org 2018/02/08 20:01:24
> > > > 
> > > > Modified files:
> > > > sys/dev: rnd.c 
> > > > 
> > > > Log message:
> > > > Situation occur where bootloader cannot supply kernel with early
> > > > random data. But a new source of entropy arrived a few months ago
> > > > -- KARL generates highly disturbed images for some kernels (well,
> > > > not for bsd.rd)
> > > > This assumes the tail of text (just before etext[]) is readable.
> > > > We are trying to use a portable symbol name, and also avoid reading
> > > > a locore0 which has been unmapped...
> > > > ok mortimer
> > > > 
> > > 
> > > I'm seeing an unaligned access fault on armv7. But should etext be 
> > > aligned, or should the code using it take alignment into account?
> > 
> > Please add printf's and figure out what is going on.
> > 
> > 
> 
> etext is coming from the linker script, and as such isn't necessarily aligned 
> like clang assumes it is. So clang generates LDR instead of LDRB and loses.
> 
> I have also been seeing other similar problems for a while now (relinked 
> kernels getting stuck in early boot, crashes before going multiuser, etc.) on 
> armv7 that I think might also be alignment problems. I've been digging around 
> in it for a while now but don't have it 100% nailed yet.
> 
> I will continue to look into this.
> 
> Press SPACE to abort autoboot in 2 seconds
> switch to partitions #0, OK
> mmc0 is current device
> SD/MMC found on device 0
> ** Unable to read file boot.scr **
> ** Unable to read file uEnv.txt **
> switch to partitions #0, OK
> mmc0 is current device
> Scanning mmc 0:1...
> reading /am335x-boneblack.dtb
> 35930 bytes read in 9 ms (3.8 MiB/s)
> Found EFI removable media binary efi/boot/bootarm.efi
> Scanning disks on usb...
> Scanning disks on mmc...
> MMC Device 2 not found
> MMC Device 3 not found
> Found 6 disks
> reading efi/boot/bootarm.efi
> 76528 bytes read in 14 ms (5.2 MiB/s)
> ## Starting EFI application at 8200 ...
> >> OpenBSD/armv7 BOOTARM 1.0
> boot>  
> booting sd0a:/bsd: 4535443+206344+562616 [277544+90+282224+244902]=0x5d8520
> 
> OpenBSD/armv7 booting ...
> arg0 0xc08d8520 arg1 0xe05 arg2 0x8800
> Allocating page tables
> freestart = 0x808d9000, free_pages = 128807 (0x0001f727)
> IRQ stack: p0x80907000 v0xc0907000
> ABT stack: p0x80908000 v0xc0908000
> UND stack: p0x80909000 v0xc0909000
> SVC stack: p0x8090a000 v0xc090a000
> Creating L1 page table at 0x808dc000
> Mapping kernel
> Constructing L2 page tables
> undefined page pmap [ using 805216 bytes of bsd ELF symbol table ]
> board type: 3589
> Copyright (c) 1982, 1986, 1989, 1991, 1993
>   The Regents of the University of California.  All rights reserved.
> Copyright (c) 1995-2018 OpenBSD. All rights reserved.  https://www.OpenBSD.org
> 
> OpenBSD 6.2-current (GENERIC) #1: Sun Jan 28 16:48:36 CST 2018
> r...@beagle3.east.rtk0.net:/usr/src/sys/arch/armv7/compile/GENERIC
> real mem  = 536870912 (512MB)
> avail mem = 516878336 (492MB)
> Fatal kernel mode data abort: 'Alignment fault'
> trapframe: 0xc090bf38
> DFSR=0001, DFAR=c0733493, spsr=2193
> r0 =c0733493, r1 =0800, r2 =c07efcdc, r3 =c073b234
> r4 =c07acce0, r5 =0005, r6 =0007, r7 =0006
> r8 =c07d3288, r9 =0332, r10=019a, r11=c090bfa8
> r12=000b, ssp=c090bf8c, slr=c05da2e4, pc =c05d8f50
> 
> Stopped at  add_entropy_words+0x5c: ldr r8, [r0], #0x004
> ddb> show registers
> spsr  0x2193
> r00xc0733493ieee80211_mira_valid_tx_mcs.max_mcs+0xf8b
> r1 0x800fiqvector+0x7e4
> r20xc07efcdcentropy_add_ptr
> r30xc073b234add_entropy_words.twist_table
> r40xc07acce0entropy_pool
> r5   0x5
> r6   0x7
> r7   0x6
> r80xc07d3288cpu_info_primary
> r9 0x332fiqvector+0x316
> r100x19afiqvector+0x17e
> r11   0xc090bfa8_bss_end__+0xf83e8
> r12  0xb
> usr_sp 0
> usr_lr 0
> svc_sp0xc090bf8c_bss_end__+0xf83cc
> svc_lr0xc05da2e4random_start+0x8c
> pc0xc05d8f50add_entropy_words+0x5c
> und_sp0xc090a000_bss_end__+0xf6440
> abt_sp0xc0909000_bss_end__+0xf5440
> irq_sp0xc0908000_bss_end__+0xf4440
> add_entropy_words+0x5c: ldr r8, [r0], #0x004
> 
> 
> -
> 
> This patch fixes the abort for me.
> 
> 
> Index: sys/arch/arm/conf/ldscript.tail
> ===
> RCS file: /cvs/src/sys/arch/arm/conf/ldscript.tail,v
> retrieving revision 1.5
> diff -u -p -u -r1.5 ldscript.tail
> --- 

Re: CVS: cvs.openbsd.org: src

[Brandon Bergren]

On Fri, Feb 9, 2018, at 3:46 PM, Theo de Raadt wrote:
> > On Thu, Feb 8, 2018, at 9:01 PM, Theo de Raadt wrote:
> > > CVSROOT:  /cvs
> > > Module name:  src
> > > Changes by:   dera...@cvs.openbsd.org 2018/02/08 20:01:24
> > > 
> > > Modified files:
> > >   sys/dev: rnd.c 
> > > 
> > > Log message:
> > > Situation occur where bootloader cannot supply kernel with early
> > > random data. But a new source of entropy arrived a few months ago
> > > -- KARL generates highly disturbed images for some kernels (well,
> > > not for bsd.rd)
> > > This assumes the tail of text (just before etext[]) is readable.
> > > We are trying to use a portable symbol name, and also avoid reading
> > > a locore0 which has been unmapped...
> > > ok mortimer
> > > 
> > 
> > I'm seeing an unaligned access fault on armv7. But should etext be aligned, 
> > or should the code using it take alignment into account?
> 
> Please add printf's and figure out what is going on.
> 
> 

etext is coming from the linker script, and as such isn't necessarily aligned 
like clang assumes it is. So clang generates LDR instead of LDRB and loses.

I have also been seeing other similar problems for a while now (relinked 
kernels getting stuck in early boot, crashes before going multiuser, etc.) on 
armv7 that I think might also be alignment problems. I've been digging around 
in it for a while now but don't have it 100% nailed yet.

I will continue to look into this.

Press SPACE to abort autoboot in 2 seconds
switch to partitions #0, OK
mmc0 is current device
SD/MMC found on device 0
** Unable to read file boot.scr **
** Unable to read file uEnv.txt **
switch to partitions #0, OK
mmc0 is current device
Scanning mmc 0:1...
reading /am335x-boneblack.dtb
35930 bytes read in 9 ms (3.8 MiB/s)
Found EFI removable media binary efi/boot/bootarm.efi
Scanning disks on usb...
Scanning disks on mmc...
MMC Device 2 not found
MMC Device 3 not found
Found 6 disks
reading efi/boot/bootarm.efi
76528 bytes read in 14 ms (5.2 MiB/s)
## Starting EFI application at 8200 ...
>> OpenBSD/armv7 BOOTARM 1.0
boot>  
booting sd0a:/bsd: 4535443+206344+562616 [277544+90+282224+244902]=0x5d8520

OpenBSD/armv7 booting ...
arg0 0xc08d8520 arg1 0xe05 arg2 0x8800
Allocating page tables
freestart = 0x808d9000, free_pages = 128807 (0x0001f727)
IRQ stack: p0x80907000 v0xc0907000
ABT stack: p0x80908000 v0xc0908000
UND stack: p0x80909000 v0xc0909000
SVC stack: p0x8090a000 v0xc090a000
Creating L1 page table at 0x808dc000
Mapping kernel
Constructing L2 page tables
undefined page pmap [ using 805216 bytes of bsd ELF symbol table ]
board type: 3589
Copyright (c) 1982, 1986, 1989, 1991, 1993
The Regents of the University of California.  All rights reserved.
Copyright (c) 1995-2018 OpenBSD. All rights reserved.  https://www.OpenBSD.org

OpenBSD 6.2-current (GENERIC) #1: Sun Jan 28 16:48:36 CST 2018
r...@beagle3.east.rtk0.net:/usr/src/sys/arch/armv7/compile/GENERIC
real mem  = 536870912 (512MB)
avail mem = 516878336 (492MB)
Fatal kernel mode data abort: 'Alignment fault'
trapframe: 0xc090bf38
DFSR=0001, DFAR=c0733493, spsr=2193
r0 =c0733493, r1 =0800, r2 =c07efcdc, r3 =c073b234
r4 =c07acce0, r5 =0005, r6 =0007, r7 =0006
r8 =c07d3288, r9 =0332, r10=019a, r11=c090bfa8
r12=000b, ssp=c090bf8c, slr=c05da2e4, pc =c05d8f50

Stopped at  add_entropy_words+0x5c: ldr r8, [r0], #0x004
ddb> show registers
spsr  0x2193
r00xc0733493ieee80211_mira_valid_tx_mcs.max_mcs+0xf8b
r1 0x800fiqvector+0x7e4
r20xc07efcdcentropy_add_ptr
r30xc073b234add_entropy_words.twist_table
r40xc07acce0entropy_pool
r5   0x5
r6   0x7
r7   0x6
r80xc07d3288cpu_info_primary
r9 0x332fiqvector+0x316
r100x19afiqvector+0x17e
r11   0xc090bfa8_bss_end__+0xf83e8
r12  0xb
usr_sp 0
usr_lr 0
svc_sp0xc090bf8c_bss_end__+0xf83cc
svc_lr0xc05da2e4random_start+0x8c
pc0xc05d8f50add_entropy_words+0x5c
und_sp0xc090a000_bss_end__+0xf6440
abt_sp0xc0909000_bss_end__+0xf5440
irq_sp0xc0908000_bss_end__+0xf4440
add_entropy_words+0x5c: ldr r8, [r0], #0x004


-

This patch fixes the abort for me.


Index: sys/arch/arm/conf/ldscript.tail
===
RCS file: /cvs/src/sys/arch/arm/conf/ldscript.tail,v
retrieving revision 1.5
diff -u -p -u -r1.5 ldscript.tail
--- sys/arch/arm/conf/ldscript.tail 26 Oct 2017 19:01:06 -  1.5
+++ sys/arch/arm/conf/ldscript.tail 9 Feb 2018 23:28:43 -
@@ -1,5 +1,6 @@
 /* $OpenBSD: ldscript.tail,v 1.5 2017/10/26 19:01:06 kettenis Exp $
 */
   } =0
+  . = ALIGN(4);
   

Re: CVS: cvs.openbsd.org: src

[Theo de Raadt]

> On Thu, Feb 8, 2018, at 9:01 PM, Theo de Raadt wrote:
> > CVSROOT:/cvs
> > Module name:src
> > Changes by: dera...@cvs.openbsd.org 2018/02/08 20:01:24
> > 
> > Modified files:
> > sys/dev: rnd.c 
> > 
> > Log message:
> > Situation occur where bootloader cannot supply kernel with early
> > random data. But a new source of entropy arrived a few months ago
> > -- KARL generates highly disturbed images for some kernels (well,
> > not for bsd.rd)
> > This assumes the tail of text (just before etext[]) is readable.
> > We are trying to use a portable symbol name, and also avoid reading
> > a locore0 which has been unmapped...
> > ok mortimer
> > 
> 
> I'm seeing an unaligned access fault on armv7. But should etext be aligned, 
> or should the code using it take alignment into account?

Please add printf's and figure out what is going on.

Re: CVS: cvs.openbsd.org: src

[Brandon Bergren]

On Thu, Feb 8, 2018, at 9:01 PM, Theo de Raadt wrote:
> CVSROOT:  /cvs
> Module name:  src
> Changes by:   dera...@cvs.openbsd.org 2018/02/08 20:01:24
> 
> Modified files:
>   sys/dev: rnd.c 
> 
> Log message:
> Situation occur where bootloader cannot supply kernel with early
> random data. But a new source of entropy arrived a few months ago
> -- KARL generates highly disturbed images for some kernels (well,
> not for bsd.rd)
> This assumes the tail of text (just before etext[]) is readable.
> We are trying to use a portable symbol name, and also avoid reading
> a locore0 which has been unmapped...
> ok mortimer
> 

I'm seeing an unaligned access fault on armv7. But should etext be aligned, or 
should the code using it take alignment into account?

Re: CVS: cvs.openbsd.org: src

[Philip Guenther]

On Fri, 8 Sep 2017, Alexander Bluhm wrote:
> On Tue, Sep 05, 2017 at 10:20:12PM -0600, Philip Guenther wrote:
> > CVSROOT:/cvs
> > Module name:src
> > Changes by: guent...@cvs.openbsd.org2017/09/05 22:20:12
> > 
> > Modified files:
> > regress/sys/kern/ptrace: ptrace.c 
> > 
> > Log message:
> > Fix declarations
> > ptrace(PT_IO) memory protection faults return EACCES, not EFAULT
> 
> Now the test fails on i386.
> 
> /usr/src/regress/sys/kern/ptrace/ptrace -Irib
> ptrace: ptrace(PT_IO): Bad address   
> *** Error 1 in . (Makefile:19 'io_read_i_bad')
> FAILED  
> 
> Apparently i386 and amd64 return different errors.  Do you know
> why?  Is it worth to invesitgate or shoud we just accept both cases?

It was worth investigating and, having done so, I think my change was 
incorrect and should be reverted and the amd64 kernel fixed to return 
EFAULT in that case.

Currently on amd64, the copyin(9) family of calls will pass through the 
return value of uvm_fault() and thus return not just EFAULT but possibly 
EACCES, ENOMEM, and EIO.  Since the return value of those functions is 
usually passed through to userspace, that's a Bad Thing IMO and we need to 
fix them to always return EFAULT when uvm_fault() fails.

The diff below does that by merging copy_fault and copy_efault, and ditto 
copystr_fault and copystr_efault, and dropping the attempt to pass the 
error number from trap() to the pcb_onfault callback.

While here, delete the similar attempt on arm64 to pass the error number 
from trap() to the pcb_onfault callback...which already ignores it and 
always return EFAULT.

ok?

Philip


Index: sys/arch/amd64/amd64/trap.c
===
RCS file: /cvs/src/sys/arch/amd64/amd64/trap.c,v
retrieving revision 1.57
diff -u -p -r1.57 trap.c
--- sys/arch/amd64/amd64/trap.c 25 Aug 2017 19:28:48 -  1.57
+++ sys/arch/amd64/amd64/trap.c 9 Sep 2017 23:30:19 -
@@ -211,10 +211,8 @@ trap(struct trapframe *frame)
goto we_re_toast;
/* Check for copyin/copyout fault. */
if (pcb->pcb_onfault != 0) {
-   error = EFAULT;
 copyfault:
frame->tf_rip = (u_int64_t)pcb->pcb_onfault;
-   frame->tf_rax = error;
return;
}
 
Index: sys/arch/amd64/amd64/copy.S
===
RCS file: /cvs/src/sys/arch/amd64/amd64/copy.S,v
retrieving revision 1.10
diff -u -p -r1.10 copy.S
--- sys/arch/amd64/amd64/copy.S 25 Aug 2017 19:28:48 -  1.10
+++ sys/arch/amd64/amd64/copy.S 9 Sep 2017 23:30:19 -
@@ -107,10 +107,10 @@ ENTRY(copyout)

movq%rdi,%rdx
addq%rax,%rdx
-   jc  _C_LABEL(copy_efault)
+   jc  _C_LABEL(copy_fault)
movq$VM_MAXUSER_ADDRESS,%r8
cmpq%r8,%rdx
-   ja  _C_LABEL(copy_efault)
+   ja  _C_LABEL(copy_fault)
 
movqCPUVAR(CURPCB),%rdx
leaq_C_LABEL(copy_fault)(%rip),%r11
@@ -145,10 +145,10 @@ ENTRY(copyin)
 
movq%rsi,%rdx
addq%rax,%rdx
-   jc  _C_LABEL(copy_efault)
+   jc  _C_LABEL(copy_fault)
movq$VM_MAXUSER_ADDRESS,%r8
cmpq%r8,%rdx
-   ja  _C_LABEL(copy_efault)
+   ja  _C_LABEL(copy_fault)
 
 3: /* bcopy(%rsi, %rdi, %rax); */
movq%rax,%rcx
@@ -171,13 +171,11 @@ ENTRY(copyin)
xorl%eax,%eax
ret
 
-NENTRY(copy_efault)
-   movq$EFAULT,%rax
-
 NENTRY(copy_fault)
SMAP_CLAC
movqCPUVAR(CURPCB),%rdx
popqPCB_ONFAULT(%rdx)
+   movl$EFAULT,%eax
ret
 
 ENTRY(copyoutstr)
@@ -194,7 +192,7 @@ ENTRY(copyoutstr)
 */
movq$VM_MAXUSER_ADDRESS,%rax
subq%rdi,%rax
-   jbe _C_LABEL(copystr_efault)/* die if CF == 1 || ZF == 1 */
+   jbe _C_LABEL(copystr_fault) /* die if CF == 1 || ZF == 1 */
cmpq%rdx,%rax
jae 1f
movq%rax,%rdx
@@ -217,8 +215,8 @@ ENTRY(copyoutstr)
 2: /* rdx is zero -- return EFAULT or ENAMETOOLONG. */
movq$VM_MAXUSER_ADDRESS,%r11
cmpq%r11,%rdi
-   jae _C_LABEL(copystr_efault)
-   movq$ENAMETOOLONG,%rax
+   jae _C_LABEL(copystr_fault)
+   movl$ENAMETOOLONG,%eax
jmp copystr_return
 
 ENTRY(copyinstr)
@@ -236,7 +234,7 @@ ENTRY(copyinstr)
 */
movq$VM_MAXUSER_ADDRESS,%rax
subq%rsi,%rax
-   jbe _C_LABEL(copystr_efault)/* die if CF == 1 || ZF == 1 */
+   jbe _C_LABEL(copystr_fault) /* die if CF == 1 || ZF == 1 */
cmpq%rdx,%rax
jae 1f
movq%rax,%rdx
@@ -259,14 +257,12 @@ ENTRY(copyinstr)
 2: /* edx is zero -- return EFAULT or ENAMETOOLONG. */

Re: i386 zzz broken, Was: CVS: cvs.openbsd.org: src

[lists]

Wed, 30 Aug 2017 16:39:18 -0700 Mike Larkin 
> On Wed, Aug 30, 2017 at 12:48:20AM -0700, Mike Larkin wrote:
> > On Tue, Aug 29, 2017 at 04:32:04PM -0700, Mike Larkin wrote:  
> > > On Mon, Aug 28, 2017 at 11:18:13PM +0300, li...@wrant.com wrote:  
> > > > Mon, 28 Aug 2017 10:16:58 -0600 (MDT) Ted Unangst   
> > > > > CVSROOT:  /cvs
> > > > > Module name:  src
> > > > > Changes by:   t...@cvs.openbsd.org2017/08/28 10:16:58
> > > > > 
> > > > > Modified files:
> > > > >   usr.sbin/apmd  : apmd.8 apmd.c 
> > > > > 
> > > > > Log message:
> > > > > add -z and -Z options to auto suspend or hibernate when low on 
> > > > > battery.
> > > > > from Jesper Wallin
> > > > >   
> > > > 
> > > > Hi tech@,
> > > > 
> > > > Could someone please test and confirm suspend still works on i386?  I am
> > > > getting the laptop to wake but it's stuck, black screen, high fan speed,
> > > > no response, only long press on the power button works.  It used to work
> > > > flawless, I suspect it might be from the last few snapshots, can't tell.
> > > > 
> > > > Ready to provide details if this works elsewhere & someone's interested.
> > > > Please let me know if it's a known/expected issue, or better sendbug(1).
> > > > 
> > > > Kind regards,
> > > > Anton Lazarov
> > > >   
> > > 
> > > Hmm, I can repro this here even with qemu. It's stuck in lapic_delay.
> > > 
> > > I'll see if I can track down what's going wrong. It would also help if you
> > > could narrow down when it broke.
> > > 
> > > -ml
> > >   
> > 
> > I figured out what was going on, but it's unclear why this suddenly broke.
> > 
> > Once we get to the bottom of what caused the breakage, I'll commit a fix.
> > 
> > -ml
> >   
> 
> We figured out what was going wrong. I just committed a fix. Should be in
> snaps soon. Thanks for reporting it.
> 
> -ml

Wed, 30 Aug 2017 17:40:22 -0600 (MDT) Mike Larkin 
> CVSROOT:  /cvs
> Module name:  src
> Changes by:   mlar...@cvs.openbsd.org 2017/08/30 17:40:22
> 
> Modified files:
>   sys/arch/amd64/amd64: acpi_wakecode.S 
>   sys/arch/i386/i386: acpi_wakecode.S 
> 
> Log message:
> adjust ACPI resume-time saved stack location to account for a different
> layout used by clang on i386. Also add a clarification to amd64's version
> of the same (amd64 already had such an adjustment).
> 
> ok deraadt, tom, kettenis
> 

Hi Mike,

I just installed the snapshot immediately after it became available on
the mirrors, and can confirm suspend & resume works on my i386 laptop.
Hibernation works too.  Thank you very much for sorting this so quick.

Kind regards,
Anton Lazarov

Re: i386 zzz broken, Was: CVS: cvs.openbsd.org: src

[Mike Larkin]

On Wed, Aug 30, 2017 at 12:48:20AM -0700, Mike Larkin wrote:
> On Tue, Aug 29, 2017 at 04:32:04PM -0700, Mike Larkin wrote:
> > On Mon, Aug 28, 2017 at 11:18:13PM +0300, li...@wrant.com wrote:
> > > Mon, 28 Aug 2017 10:16:58 -0600 (MDT) Ted Unangst 
> > > > CVSROOT:/cvs
> > > > Module name:src
> > > > Changes by: t...@cvs.openbsd.org2017/08/28 10:16:58
> > > > 
> > > > Modified files:
> > > > usr.sbin/apmd  : apmd.8 apmd.c 
> > > > 
> > > > Log message:
> > > > add -z and -Z options to auto suspend or hibernate when low on battery.
> > > > from Jesper Wallin
> > > > 
> > > 
> > > Hi tech@,
> > > 
> > > Could someone please test and confirm suspend still works on i386?  I am
> > > getting the laptop to wake but it's stuck, black screen, high fan speed,
> > > no response, only long press on the power button works.  It used to work
> > > flawless, I suspect it might be from the last few snapshots, can't tell.
> > > 
> > > Ready to provide details if this works elsewhere & someone's interested.
> > > Please let me know if it's a known/expected issue, or better sendbug(1).
> > > 
> > > Kind regards,
> > > Anton Lazarov
> > > 
> > 
> > Hmm, I can repro this here even with qemu. It's stuck in lapic_delay.
> > 
> > I'll see if I can track down what's going wrong. It would also help if you
> > could narrow down when it broke.
> > 
> > -ml
> > 
> 
> I figured out what was going on, but it's unclear why this suddenly broke.
> 
> Once we get to the bottom of what caused the breakage, I'll commit a fix.
> 
> -ml
> 

We figured out what was going wrong. I just committed a fix. Should be in
snaps soon. Thanks for reporting it.

-ml

Re: i386 zzz broken, Was: CVS: cvs.openbsd.org: src

[Stuart Henderson]

On 2017/08/30 09:04, Florian Obser wrote:
> On Tue, Aug 29, 2017 at 07:25:33PM -0700, Chris Cappuccio wrote:
> > li...@wrant.com [li...@wrant.com] wrote:
> > > 
> > > Please let me know if you want me to generate some dumps or similar, but
> > > unfortunately, I can't yet test patches or handle compilation on my own.
> > > I realise my info on this is incredibly lacking as quality & usefulness.
> > > 
> > 
> > Stuart Henderson has an archive of kernels from snapshot builds that you
> > can use to better narrow down when the regression started.
> > 
> > Unfortunately I don't remember the URL.
> 
> IIRC sthen asked for it to not be shared, it got shared on misc and he
> changed the URL or shutdown the archive. Use this:
> https://ftp.hostserver.de/archive/
> 
> It keeps all base for all archs and packages for amd64 for 80 days.

Yes - I do still have the archive for some arches (amd64, armv7, i386,
loongson, macppc, octeon, sparc64) - kernels only, archived daily if they
changed since the previous snapshot, currently back to the start of 2015
(though I may cull them at some point).

If the archive on hostserver doesn't go back far enough, let me know
which arch and approx dates of interest and I'll copy the relevant files
to somewhere suitable to fetch from.

Re: i386 zzz broken, Was: CVS: cvs.openbsd.org: src

[Florian Obser]

On Tue, Aug 29, 2017 at 07:25:33PM -0700, Chris Cappuccio wrote:
> li...@wrant.com [li...@wrant.com] wrote:
> > 
> > Please let me know if you want me to generate some dumps or similar, but
> > unfortunately, I can't yet test patches or handle compilation on my own.
> > I realise my info on this is incredibly lacking as quality & usefulness.
> > 
> 
> Stuart Henderson has an archive of kernels from snapshot builds that you
> can use to better narrow down when the regression started.
> 
> Unfortunately I don't remember the URL.

IIRC sthen asked for it to not be shared, it got shared on misc and he
changed the URL or shutdown the archive. Use this:
https://ftp.hostserver.de/archive/

It keeps all base for all archs and packages for amd64 for 80 days.

-- 
I'm not entirely sure you are real.

Re: i386 zzz broken, Was: CVS: cvs.openbsd.org: src

[Mike Larkin]

On Tue, Aug 29, 2017 at 04:32:04PM -0700, Mike Larkin wrote:
> On Mon, Aug 28, 2017 at 11:18:13PM +0300, li...@wrant.com wrote:
> > Mon, 28 Aug 2017 10:16:58 -0600 (MDT) Ted Unangst 
> > > CVSROOT:  /cvs
> > > Module name:  src
> > > Changes by:   t...@cvs.openbsd.org2017/08/28 10:16:58
> > > 
> > > Modified files:
> > >   usr.sbin/apmd  : apmd.8 apmd.c 
> > > 
> > > Log message:
> > > add -z and -Z options to auto suspend or hibernate when low on battery.
> > > from Jesper Wallin
> > > 
> > 
> > Hi tech@,
> > 
> > Could someone please test and confirm suspend still works on i386?  I am
> > getting the laptop to wake but it's stuck, black screen, high fan speed,
> > no response, only long press on the power button works.  It used to work
> > flawless, I suspect it might be from the last few snapshots, can't tell.
> > 
> > Ready to provide details if this works elsewhere & someone's interested.
> > Please let me know if it's a known/expected issue, or better sendbug(1).
> > 
> > Kind regards,
> > Anton Lazarov
> > 
> 
> Hmm, I can repro this here even with qemu. It's stuck in lapic_delay.
> 
> I'll see if I can track down what's going wrong. It would also help if you
> could narrow down when it broke.
> 
> -ml
> 

I figured out what was going on, but it's unclear why this suddenly broke.

Once we get to the bottom of what caused the breakage, I'll commit a fix.

-ml

Re: i386 zzz broken, Was: CVS: cvs.openbsd.org: src

[Chris Cappuccio]

li...@wrant.com [li...@wrant.com] wrote:
> 
> Please let me know if you want me to generate some dumps or similar, but
> unfortunately, I can't yet test patches or handle compilation on my own.
> I realise my info on this is incredibly lacking as quality & usefulness.
> 

Stuart Henderson has an archive of kernels from snapshot builds that you
can use to better narrow down when the regression started.

Unfortunately I don't remember the URL. Someone who has it easily accessible
may choose to provide it in a reply. You should be able to boot the older
kernels with either the 6.2-beta userland, or with the 6.1 userland. One or
the other will work typically. If you can try them and narrow down,
that's all that's necessary.

Chris

Re: i386 zzz broken, Was: CVS: cvs.openbsd.org: src

[lists]

Tue, 29 Aug 2017 16:32:04 -0700 Mike Larkin 
> On Mon, Aug 28, 2017 at 11:18:13PM +0300, li...@wrant.com wrote:
> > Mon, 28 Aug 2017 10:16:58 -0600 (MDT) Ted Unangst   
> > > CVSROOT:  /cvs
> > > Module name:  src
> > > Changes by:   t...@cvs.openbsd.org2017/08/28 10:16:58
> > > 
> > > Modified files:
> > >   usr.sbin/apmd  : apmd.8 apmd.c 
> > > 
> > > Log message:
> > > add -z and -Z options to auto suspend or hibernate when low on battery.
> > > from Jesper Wallin
> > >   
> > 
> > Hi tech@,
> > 
> > Could someone please test and confirm suspend still works on i386?  I am
> > getting the laptop to wake but it's stuck, black screen, high fan speed,
> > no response, only long press on the power button works.  It used to work
> > flawless, I suspect it might be from the last few snapshots, can't tell.
> > 
> > Ready to provide details if this works elsewhere & someone's interested.
> > Please let me know if it's a known/expected issue, or better sendbug(1).
> > 
> > Kind regards,
> > Anton Lazarov
> >   
> 
> Hmm, I can repro this here even with qemu. It's stuck in lapic_delay.
> 
> I'll see if I can track down what's going wrong. It would also help if you
> could narrow down when it broke.
> 
> -ml
> 

Hi Mike,

Thank you for looking into this.  I'm using the laptop as a 24/7 desktop
machine, and rarely suspend it to be honest, especially since it started
having this problem, maybe somewhere after the last release.  Sorry that
I can not be more specific about it, I'll keep a track on this from now.

Please let me know if you want me to generate some dumps or similar, but
unfortunately, I can't yet test patches or handle compilation on my own.
I realise my info on this is incredibly lacking as quality & usefulness.

Kind regards,
Anton Lazarov

> > OpenBSD 6.2-beta (GENERIC.MP) #91: Sun Aug 27 17:26:00 MDT 2017
> > dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC.MP
> > cpu0: Intel(R) Atom(TM) CPU N280 @ 1.66GHz ("GenuineIntel" 686-class) 1.67 
> > GHz
> > cpu0: 
> > FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,NXE,SSE3,DTES64,MWAIT,DS-CPL,EST,TM2,SSSE3,xTPR,PDCM,MOVBE,LAHF,PERF,SENSOR
> > real mem  = 1064452096 (1015MB)
> > avail mem = 1029943296 (982MB)
> > mpath0 at root
> > scsibus0 at mpath0: 256 targets
> > mainbus0 at root
> > bios0 at mainbus0: date 04/18/11, BIOS32 rev. 0 @ 0xf0010, SMBIOS rev. 2.5 
> > @ 0xf0720 (30 entries)
> > bios0: vendor American Megatrends Inc. version "1601" date 04/18/2011
> > bios0: ASUSTeK Computer INC. 1005HA
> > acpi0 at bios0: rev 0
> > acpi0: sleep states S0 S3 S4 S5
> > acpi0: tables DSDT FACP APIC MCFG OEMB HPET SSDT
> > acpi0: wakeup devices P0P2(S4) P0P1(S4) HDAC(S4) P0P4(S4) P0P8(S4) P0P5(S4) 
> > P0P7(S4) P0P9(S4) P0P6(S4)
> > acpitimer0 at acpi0: 3579545 Hz, 24 bits
> > acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
> > cpu0 at mainbus0: apid 0 (boot processor)
> > mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
> > cpu0: apic clock running at 166MHz
> > cpu0: mwait min=64, max=64, C-substates=0.2.2.0.2, IBE
> > cpu1 at mainbus0: apid 1 (application processor)
> > cpu1: Intel(R) Atom(TM) CPU N280 @ 1.66GHz ("GenuineIntel" 686-class) 1.67 
> > GHz
> > cpu1: 
> > FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,NXE,SSE3,DTES64,MWAIT,DS-CPL,EST,TM2,SSSE3,xTPR,PDCM,MOVBE,LAHF,PERF,SENSOR
> > ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 24 pins
> > acpimcfg0 at acpi0 addr 0xe000, bus 0-63
> > acpihpet0 at acpi0: 14318179 Hz
> > acpiprt0 at acpi0: bus 0 (PCI0)
> > acpiprt1 at acpi0: bus 2 (P0P5)
> > acpiprt2 at acpi0: bus 1 (P0P7)
> > acpiprt3 at acpi0: bus -1 (P0P6)
> > acpiec0 at acpi0
> > acpicpu0 at acpi0: !C2(500@1 mwait.1@0x10), C1(1000@1 mwait.1), PSS
> > acpicpu1 at acpi0: !C2(500@1 mwait.1@0x10), C1(1000@1 mwait.1), PSS
> > acpitz0 at acpi0: critical temperature is 88 degC
> > "SYN0A13" at acpi0 not configured
> > acpibat0 at acpi0: BAT0 model "1005HA" serial   type LION oem "ASUS"
> > acpiac0 at acpi0: AC unit online
> > acpibtn0 at acpi0: LID_
> > acpibtn1 at acpi0: SLPB
> > acpibtn2 at acpi0: PWRB
> > "PNP0C14" at acpi0 not configured
> > acpivideo0 at acpi0: VGA_
> > acpivout0 at acpivideo0: LCDD
> > bios0: ROM list: 0xc/0xec00! 0xcf000/0x1000
> > cpu0: Enhanced SpeedStep 1667 MHz: speeds: 1667, 1333, 1000 MHz
> > pci0 at mainbus0 bus 0: configuration mode 1 (bios)
> > pchb0 at pci0 dev 0 function 0 "Intel 82945GME Host" rev 0x03
> > inteldrm0 at pci0 dev 2 function 0 "Intel 82945GME Video" rev 0x03
> > drm0 at inteldrm0
> > intagp0 at inteldrm0
> > agp0 at intagp0: aperture at 0xd000, size 0x1000
> > inteldrm0: apic 2 int 16
> > inteldrm0: 1024x600, 32bpp
> > wsdisplay0 at inteldrm0 mux 1: console (std, vt100 emulation)
> > wsdisplay0: screen 1-5 added (std, vt100 emulation)
> > "Intel 82945GM Video" rev 0x03 

i386 zzz broken, Was: CVS: cvs.openbsd.org: src

[Mike Larkin]

On Mon, Aug 28, 2017 at 11:18:13PM +0300, li...@wrant.com wrote:
> Mon, 28 Aug 2017 10:16:58 -0600 (MDT) Ted Unangst 
> > CVSROOT:/cvs
> > Module name:src
> > Changes by: t...@cvs.openbsd.org2017/08/28 10:16:58
> > 
> > Modified files:
> > usr.sbin/apmd  : apmd.8 apmd.c 
> > 
> > Log message:
> > add -z and -Z options to auto suspend or hibernate when low on battery.
> > from Jesper Wallin
> > 
> 
> Hi tech@,
> 
> Could someone please test and confirm suspend still works on i386?  I am
> getting the laptop to wake but it's stuck, black screen, high fan speed,
> no response, only long press on the power button works.  It used to work
> flawless, I suspect it might be from the last few snapshots, can't tell.
> 
> Ready to provide details if this works elsewhere & someone's interested.
> Please let me know if it's a known/expected issue, or better sendbug(1).
> 
> Kind regards,
> Anton Lazarov
> 

Hmm, I can repro this here even with qemu. It's stuck in lapic_delay.

I'll see if I can track down what's going wrong. It would also help if you
could narrow down when it broke.

-ml

> OpenBSD 6.2-beta (GENERIC.MP) #91: Sun Aug 27 17:26:00 MDT 2017
> dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC.MP
> cpu0: Intel(R) Atom(TM) CPU N280 @ 1.66GHz ("GenuineIntel" 686-class) 1.67 GHz
> cpu0: 
> FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,NXE,SSE3,DTES64,MWAIT,DS-CPL,EST,TM2,SSSE3,xTPR,PDCM,MOVBE,LAHF,PERF,SENSOR
> real mem  = 1064452096 (1015MB)
> avail mem = 1029943296 (982MB)
> mpath0 at root
> scsibus0 at mpath0: 256 targets
> mainbus0 at root
> bios0 at mainbus0: date 04/18/11, BIOS32 rev. 0 @ 0xf0010, SMBIOS rev. 2.5 @ 
> 0xf0720 (30 entries)
> bios0: vendor American Megatrends Inc. version "1601" date 04/18/2011
> bios0: ASUSTeK Computer INC. 1005HA
> acpi0 at bios0: rev 0
> acpi0: sleep states S0 S3 S4 S5
> acpi0: tables DSDT FACP APIC MCFG OEMB HPET SSDT
> acpi0: wakeup devices P0P2(S4) P0P1(S4) HDAC(S4) P0P4(S4) P0P8(S4) P0P5(S4) 
> P0P7(S4) P0P9(S4) P0P6(S4)
> acpitimer0 at acpi0: 3579545 Hz, 24 bits
> acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
> cpu0 at mainbus0: apid 0 (boot processor)
> mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
> cpu0: apic clock running at 166MHz
> cpu0: mwait min=64, max=64, C-substates=0.2.2.0.2, IBE
> cpu1 at mainbus0: apid 1 (application processor)
> cpu1: Intel(R) Atom(TM) CPU N280 @ 1.66GHz ("GenuineIntel" 686-class) 1.67 GHz
> cpu1: 
> FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,NXE,SSE3,DTES64,MWAIT,DS-CPL,EST,TM2,SSSE3,xTPR,PDCM,MOVBE,LAHF,PERF,SENSOR
> ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 24 pins
> acpimcfg0 at acpi0 addr 0xe000, bus 0-63
> acpihpet0 at acpi0: 14318179 Hz
> acpiprt0 at acpi0: bus 0 (PCI0)
> acpiprt1 at acpi0: bus 2 (P0P5)
> acpiprt2 at acpi0: bus 1 (P0P7)
> acpiprt3 at acpi0: bus -1 (P0P6)
> acpiec0 at acpi0
> acpicpu0 at acpi0: !C2(500@1 mwait.1@0x10), C1(1000@1 mwait.1), PSS
> acpicpu1 at acpi0: !C2(500@1 mwait.1@0x10), C1(1000@1 mwait.1), PSS
> acpitz0 at acpi0: critical temperature is 88 degC
> "SYN0A13" at acpi0 not configured
> acpibat0 at acpi0: BAT0 model "1005HA" serial   type LION oem "ASUS"
> acpiac0 at acpi0: AC unit online
> acpibtn0 at acpi0: LID_
> acpibtn1 at acpi0: SLPB
> acpibtn2 at acpi0: PWRB
> "PNP0C14" at acpi0 not configured
> acpivideo0 at acpi0: VGA_
> acpivout0 at acpivideo0: LCDD
> bios0: ROM list: 0xc/0xec00! 0xcf000/0x1000
> cpu0: Enhanced SpeedStep 1667 MHz: speeds: 1667, 1333, 1000 MHz
> pci0 at mainbus0 bus 0: configuration mode 1 (bios)
> pchb0 at pci0 dev 0 function 0 "Intel 82945GME Host" rev 0x03
> inteldrm0 at pci0 dev 2 function 0 "Intel 82945GME Video" rev 0x03
> drm0 at inteldrm0
> intagp0 at inteldrm0
> agp0 at intagp0: aperture at 0xd000, size 0x1000
> inteldrm0: apic 2 int 16
> inteldrm0: 1024x600, 32bpp
> wsdisplay0 at inteldrm0 mux 1: console (std, vt100 emulation)
> wsdisplay0: screen 1-5 added (std, vt100 emulation)
> "Intel 82945GM Video" rev 0x03 at pci0 dev 2 function 1 not configured
> azalia0 at pci0 dev 27 function 0 "Intel 82801GB HD Audio" rev 0x02: msi
> azalia0: codecs: Realtek ALC269
> audio0 at azalia0
> ppb0 at pci0 dev 28 function 0 "Intel 82801GB PCIE" rev 0x02: apic 2 int 16
> pci1 at ppb0 bus 4
> ppb1 at pci0 dev 28 function 1 "Intel 82801GB PCIE" rev 0x02: apic 2 int 17
> pci2 at ppb1 bus 2
> athn0 at pci2 dev 0 function 0 "Atheros AR9285" rev 0x01: apic 2 int 17
> athn0: AR9285 rev 2 (1T1R), ROM rev 13, address 00:25:d3:5f:06:4c
> ppb2 at pci0 dev 28 function 3 "Intel 82801GB PCIE" rev 0x02: apic 2 int 19
> pci3 at ppb2 bus 1
> alc0 at pci3 dev 0 function 0 "Attansic Technology L2C" rev 0xc0: msi, 
> address 00:26:18:93:af:0b
> atphy0 at alc0 phy 0: F1 10/100/1000 PHY, rev. 11
> uhci0 at pci0 dev 29 function 0 "Intel 82801GB USB" rev 0x02: apic 

Re: CVS: cvs.openbsd.org: src

[lists]

Mon, 28 Aug 2017 10:16:58 -0600 (MDT) Ted Unangst 
> CVSROOT:  /cvs
> Module name:  src
> Changes by:   t...@cvs.openbsd.org2017/08/28 10:16:58
> 
> Modified files:
>   usr.sbin/apmd  : apmd.8 apmd.c 
> 
> Log message:
> add -z and -Z options to auto suspend or hibernate when low on battery.
> from Jesper Wallin
> 

Hi tech@,

Could someone please test and confirm suspend still works on i386?  I am
getting the laptop to wake but it's stuck, black screen, high fan speed,
no response, only long press on the power button works.  It used to work
flawless, I suspect it might be from the last few snapshots, can't tell.

Ready to provide details if this works elsewhere & someone's interested.
Please let me know if it's a known/expected issue, or better sendbug(1).

Kind regards,
Anton Lazarov

OpenBSD 6.2-beta (GENERIC.MP) #91: Sun Aug 27 17:26:00 MDT 2017
dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC.MP
cpu0: Intel(R) Atom(TM) CPU N280 @ 1.66GHz ("GenuineIntel" 686-class) 1.67 GHz
cpu0: 
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,NXE,SSE3,DTES64,MWAIT,DS-CPL,EST,TM2,SSSE3,xTPR,PDCM,MOVBE,LAHF,PERF,SENSOR
real mem  = 1064452096 (1015MB)
avail mem = 1029943296 (982MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: date 04/18/11, BIOS32 rev. 0 @ 0xf0010, SMBIOS rev. 2.5 @ 
0xf0720 (30 entries)
bios0: vendor American Megatrends Inc. version "1601" date 04/18/2011
bios0: ASUSTeK Computer INC. 1005HA
acpi0 at bios0: rev 0
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP APIC MCFG OEMB HPET SSDT
acpi0: wakeup devices P0P2(S4) P0P1(S4) HDAC(S4) P0P4(S4) P0P8(S4) P0P5(S4) 
P0P7(S4) P0P9(S4) P0P6(S4)
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
cpu0: apic clock running at 166MHz
cpu0: mwait min=64, max=64, C-substates=0.2.2.0.2, IBE
cpu1 at mainbus0: apid 1 (application processor)
cpu1: Intel(R) Atom(TM) CPU N280 @ 1.66GHz ("GenuineIntel" 686-class) 1.67 GHz
cpu1: 
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,NXE,SSE3,DTES64,MWAIT,DS-CPL,EST,TM2,SSSE3,xTPR,PDCM,MOVBE,LAHF,PERF,SENSOR
ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 24 pins
acpimcfg0 at acpi0 addr 0xe000, bus 0-63
acpihpet0 at acpi0: 14318179 Hz
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus 2 (P0P5)
acpiprt2 at acpi0: bus 1 (P0P7)
acpiprt3 at acpi0: bus -1 (P0P6)
acpiec0 at acpi0
acpicpu0 at acpi0: !C2(500@1 mwait.1@0x10), C1(1000@1 mwait.1), PSS
acpicpu1 at acpi0: !C2(500@1 mwait.1@0x10), C1(1000@1 mwait.1), PSS
acpitz0 at acpi0: critical temperature is 88 degC
"SYN0A13" at acpi0 not configured
acpibat0 at acpi0: BAT0 model "1005HA" serial   type LION oem "ASUS"
acpiac0 at acpi0: AC unit online
acpibtn0 at acpi0: LID_
acpibtn1 at acpi0: SLPB
acpibtn2 at acpi0: PWRB
"PNP0C14" at acpi0 not configured
acpivideo0 at acpi0: VGA_
acpivout0 at acpivideo0: LCDD
bios0: ROM list: 0xc/0xec00! 0xcf000/0x1000
cpu0: Enhanced SpeedStep 1667 MHz: speeds: 1667, 1333, 1000 MHz
pci0 at mainbus0 bus 0: configuration mode 1 (bios)
pchb0 at pci0 dev 0 function 0 "Intel 82945GME Host" rev 0x03
inteldrm0 at pci0 dev 2 function 0 "Intel 82945GME Video" rev 0x03
drm0 at inteldrm0
intagp0 at inteldrm0
agp0 at intagp0: aperture at 0xd000, size 0x1000
inteldrm0: apic 2 int 16
inteldrm0: 1024x600, 32bpp
wsdisplay0 at inteldrm0 mux 1: console (std, vt100 emulation)
wsdisplay0: screen 1-5 added (std, vt100 emulation)
"Intel 82945GM Video" rev 0x03 at pci0 dev 2 function 1 not configured
azalia0 at pci0 dev 27 function 0 "Intel 82801GB HD Audio" rev 0x02: msi
azalia0: codecs: Realtek ALC269
audio0 at azalia0
ppb0 at pci0 dev 28 function 0 "Intel 82801GB PCIE" rev 0x02: apic 2 int 16
pci1 at ppb0 bus 4
ppb1 at pci0 dev 28 function 1 "Intel 82801GB PCIE" rev 0x02: apic 2 int 17
pci2 at ppb1 bus 2
athn0 at pci2 dev 0 function 0 "Atheros AR9285" rev 0x01: apic 2 int 17
athn0: AR9285 rev 2 (1T1R), ROM rev 13, address 00:25:d3:5f:06:4c
ppb2 at pci0 dev 28 function 3 "Intel 82801GB PCIE" rev 0x02: apic 2 int 19
pci3 at ppb2 bus 1
alc0 at pci3 dev 0 function 0 "Attansic Technology L2C" rev 0xc0: msi, address 
00:26:18:93:af:0b
atphy0 at alc0 phy 0: F1 10/100/1000 PHY, rev. 11
uhci0 at pci0 dev 29 function 0 "Intel 82801GB USB" rev 0x02: apic 2 int 23
uhci1 at pci0 dev 29 function 1 "Intel 82801GB USB" rev 0x02: apic 2 int 19
uhci2 at pci0 dev 29 function 2 "Intel 82801GB USB" rev 0x02: apic 2 int 18
uhci3 at pci0 dev 29 function 3 "Intel 82801GB USB" rev 0x02: apic 2 int 16
ehci0 at pci0 dev 29 function 7 "Intel 82801GB USB" rev 0x02: apic 2 int 23
usb0 at ehci0: USB revision 2.0
uhub0 at usb0 configuration 1 interface 0 "Intel EHCI root hub" rev 2.00/1.00 
addr 1
ppb3 at pci0 dev 30 

Re: CVS: cvs.openbsd.org: src

[Martijn van Duren]

On 07/03/17 08:30, Martijn van Duren wrote:
> On 07/01/17 18:14, Mark Kettenis wrote:
>> CVSROOT: /cvs
>> Module name: src
>> Changes by:  kette...@cvs.openbsd.org2017/07/01 10:14:10
>>
>> Modified files:
>>  sys/dev/pci/drm: drm_irq.c drm_linux.c drm_linux.h 
>>   drm_linux_list.h drm_mm.c drm_mm.h drm_mode.h 
>>   drm_modes.c drm_rect.c drm_rect.h 
>>   drm_vma_manager.c files.drm i915_drm.h 
>>   i915_pciids.h linux_hdmi.h 
>>  sys/dev/pci/drm/i915: dvo.h dvo_ch7017.c dvo_ch7xxx.c dvo_ivch.c 
>>dvo_ns2501.c dvo_sil164.c dvo_tfp410.c 
>>i915_dma.c i915_drv.c i915_drv.h 
>>i915_gem.c i915_gem_context.c 
>>i915_gem_evict.c i915_gem_execbuffer.c 
>>i915_gem_gtt.c i915_gem_stolen.c 
>>i915_gem_tiling.c i915_gpu_error.c 
>>i915_irq.c i915_reg.h i915_suspend.c 
>>i915_trace.h intel_bios.c intel_bios.h 
>>intel_crt.c intel_ddi.c intel_display.c 
>>intel_dp.c intel_drv.h intel_dvo.c 
>>intel_fbdev.c intel_hdmi.c intel_i2c.c 
>>intel_lvds.c intel_modes.c 
>>intel_opregion.c intel_overlay.c 
>>intel_panel.c intel_pm.c 
>>intel_ringbuffer.c intel_ringbuffer.h 
>>intel_sdvo.c intel_sdvo_regs.h 
>>intel_sideband.c intel_sprite.c intel_tv.c 
>>intel_uncore.c 
>>  sys/dev/pci/drm/radeon: atombios_crtc.c atombios_dp.c 
>>  atombios_i2c.c nid.h r100.c radeon.h 
>>  radeon_connectors.c radeon_device.c 
>>  radeon_display.c radeon_fb.c 
>>  radeon_i2c.c radeon_irq_kms.c 
>>  radeon_kms.c radeon_legacy_crtc.c 
>>  radeon_legacy_encoders.c radeon_mode.h 
>>  radeon_pm.c 
>>  sys/dev/pci/drm/ttm: ttm_bo_manager.c 
>> Added files:
>>  sys/dev/pci/drm: drm_linux_atomic.h drm_mipi_dsi.h drm_modes.h 
>>   drm_modeset_lock.c drm_modeset_lock.h 
>>   drm_panel.c drm_panel.h drm_plane_helper.c 
>>   drm_plane_helper.h drm_probe_helper.c 
>>   linux_list_sort.c linux_types.h 
>>   linux_ww_mutex.h 
>>  sys/dev/pci/drm/i915: i915_cmd_parser.c i915_gem_batch_pool.c 
>>i915_gem_batch_pool.h i915_gem_fence.c 
>>i915_gem_gtt.h i915_gem_render_state.c 
>>i915_gem_render_state.h i915_gem_userptr.c 
>>i915_guc_reg.h i915_guc_submission.c 
>>i915_params.c i915_vgpu.c i915_vgpu.h 
>>intel_atomic.c intel_atomic_plane.c 
>>intel_audio.c intel_csr.c intel_dp_mst.c 
>>intel_dsi.c intel_dsi.h 
>>intel_dsi_panel_vbt.c intel_dsi_pll.c 
>>intel_fbc.c intel_fifo_underrun.c 
>>intel_frontbuffer.c intel_gtt.c 
>>intel_guc.h intel_guc_fwif.h 
>>intel_guc_loader.c intel_hotplug.c 
>>intel_lrc.c intel_lrc.h intel_mocs.c 
>>intel_mocs.h intel_psr.c 
>>intel_renderstate.h 
>>intel_renderstate_gen6.c 
>>intel_renderstate_gen7.c 
>>intel_renderstate_gen8.c 
>>intel_renderstate_gen9.c 
>>intel_runtime_pm.c 
>>  sys/dev/pci/drm/radeon: radeon_dp_auxch.c 
>>
>> Log message:
>> Update inteldrm(4) to code based on Linux 4.4.70.  This brings us support for
>> Skylake and Cherryview and better support for Broadwell and Valleyview.  Also
>> adds MST support.  Some tweaks to the TTM code and radeondrm(4) to keep it
>> working with the updated generic DRM code needed for inteldrm(4).
>>
>> Tested by many.
>>
> This change *STILL* breaks my $DAYJOB machine.
> 
After a couple of updates where I had to revert back to an old kernel I
managed to lay claim to a "new" system. This one is intel only and
doesn't have any issues.

If there's still interest in fixing this issue, the hardware is still
available, but there's no direct need for me any more.

OpenBSD 6.1-current (GENERIC.MP) #95: Wed Jul 12 19:23:28 MDT 2017
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
RTC BIOS 

Re: CVS: cvs.openbsd.org: src

[J Doe]

Hi,

On Jul 4, 2017, at 7:40 AM, Mark Kettenis  wrote:

>> From: Frank Groeneveld 
>> Date: Tue, 04 Jul 2017 09:38:18 +0200
>> 
>>> On Mon, Jul 3, 2017, at 08:30, Martijn van Duren wrote:
>>> This change *STILL* breaks my $DAYJOB machine.
>>> 
>>> dmesg with DRMDEBUG enabled
>> 
>> Maybe you shouldn't chose Apple hardware ;-)

I've actually had really positive experiences with running OpenBSD with Apple 
hardware.  I had an iMac that I used as an experimental box and the only issue 
with it was retrieving the blob for the video card.  Likewise, I had a 
firewall/NIDS running on a headless Mac Mini with no issues.  Even more 
impressive, I had zero-configuration support for an Apple USB 10/100 NIC, which 
I expected would be a bit more of a niche device.

I note that you mention ThinkPads and I know they are highly regarded within 
the OpenBSD community . . . I just thought I'd throw in my two cents on Apple 
hardware!

Cheers,

- J

Re: CVS: cvs.openbsd.org: src

[Mark Kettenis]

> From: Frank Groeneveld 
> Date: Tue, 04 Jul 2017 09:38:18 +0200
> 
> On Mon, Jul 3, 2017, at 08:30, Martijn van Duren wrote:
> > This change *STILL* breaks my $DAYJOB machine.
> > 
> > dmesg with DRMDEBUG enabled
> 
> Maybe you shouldn't chose Apple hardware ;-)

Well.  That machine used to work.  Some change in the generic drm code
or my changes to radeondrm(4) made it stop working.  Hopefully the
problem can be reproduced and we can get some clues what broke.

Re: CVS: cvs.openbsd.org: src

[Frank Groeneveld]

On Mon, Jul 3, 2017, at 08:30, Martijn van Duren wrote:
> This change *STILL* breaks my $DAYJOB machine.
> 
> dmesg with DRMDEBUG enabled

Maybe you shouldn't chose Apple hardware ;-)

Works great here on a Thinkpad X260 Mark, thank you very much!

Frank

Re: CVS: cvs.openbsd.org: src

[Martijn van Duren]

On 07/01/17 18:14, Mark Kettenis wrote:
> CVSROOT:  /cvs
> Module name:  src
> Changes by:   kette...@cvs.openbsd.org2017/07/01 10:14:10
> 
> Modified files:
>   sys/dev/pci/drm: drm_irq.c drm_linux.c drm_linux.h 
>drm_linux_list.h drm_mm.c drm_mm.h drm_mode.h 
>drm_modes.c drm_rect.c drm_rect.h 
>drm_vma_manager.c files.drm i915_drm.h 
>i915_pciids.h linux_hdmi.h 
>   sys/dev/pci/drm/i915: dvo.h dvo_ch7017.c dvo_ch7xxx.c dvo_ivch.c 
> dvo_ns2501.c dvo_sil164.c dvo_tfp410.c 
> i915_dma.c i915_drv.c i915_drv.h 
> i915_gem.c i915_gem_context.c 
> i915_gem_evict.c i915_gem_execbuffer.c 
> i915_gem_gtt.c i915_gem_stolen.c 
> i915_gem_tiling.c i915_gpu_error.c 
> i915_irq.c i915_reg.h i915_suspend.c 
> i915_trace.h intel_bios.c intel_bios.h 
> intel_crt.c intel_ddi.c intel_display.c 
> intel_dp.c intel_drv.h intel_dvo.c 
> intel_fbdev.c intel_hdmi.c intel_i2c.c 
> intel_lvds.c intel_modes.c 
> intel_opregion.c intel_overlay.c 
> intel_panel.c intel_pm.c 
> intel_ringbuffer.c intel_ringbuffer.h 
> intel_sdvo.c intel_sdvo_regs.h 
> intel_sideband.c intel_sprite.c intel_tv.c 
> intel_uncore.c 
>   sys/dev/pci/drm/radeon: atombios_crtc.c atombios_dp.c 
>   atombios_i2c.c nid.h r100.c radeon.h 
>   radeon_connectors.c radeon_device.c 
>   radeon_display.c radeon_fb.c 
>   radeon_i2c.c radeon_irq_kms.c 
>   radeon_kms.c radeon_legacy_crtc.c 
>   radeon_legacy_encoders.c radeon_mode.h 
>   radeon_pm.c 
>   sys/dev/pci/drm/ttm: ttm_bo_manager.c 
> Added files:
>   sys/dev/pci/drm: drm_linux_atomic.h drm_mipi_dsi.h drm_modes.h 
>drm_modeset_lock.c drm_modeset_lock.h 
>drm_panel.c drm_panel.h drm_plane_helper.c 
>drm_plane_helper.h drm_probe_helper.c 
>linux_list_sort.c linux_types.h 
>linux_ww_mutex.h 
>   sys/dev/pci/drm/i915: i915_cmd_parser.c i915_gem_batch_pool.c 
> i915_gem_batch_pool.h i915_gem_fence.c 
> i915_gem_gtt.h i915_gem_render_state.c 
> i915_gem_render_state.h i915_gem_userptr.c 
> i915_guc_reg.h i915_guc_submission.c 
> i915_params.c i915_vgpu.c i915_vgpu.h 
> intel_atomic.c intel_atomic_plane.c 
> intel_audio.c intel_csr.c intel_dp_mst.c 
> intel_dsi.c intel_dsi.h 
> intel_dsi_panel_vbt.c intel_dsi_pll.c 
> intel_fbc.c intel_fifo_underrun.c 
> intel_frontbuffer.c intel_gtt.c 
> intel_guc.h intel_guc_fwif.h 
> intel_guc_loader.c intel_hotplug.c 
> intel_lrc.c intel_lrc.h intel_mocs.c 
> intel_mocs.h intel_psr.c 
> intel_renderstate.h 
> intel_renderstate_gen6.c 
> intel_renderstate_gen7.c 
> intel_renderstate_gen8.c 
> intel_renderstate_gen9.c 
> intel_runtime_pm.c 
>   sys/dev/pci/drm/radeon: radeon_dp_auxch.c 
> 
> Log message:
> Update inteldrm(4) to code based on Linux 4.4.70.  This brings us support for
> Skylake and Cherryview and better support for Broadwell and Valleyview.  Also
> adds MST support.  Some tweaks to the TTM code and radeondrm(4) to keep it
> working with the updated generic DRM code needed for inteldrm(4).
> 
> Tested by many.
> 
This change *STILL* breaks my $DAYJOB machine.

dmesg with DRMDEBUG enabled

OpenBSD 6.1-current (GENERIC.MP) #21: Mon Jul  3 08:14:45 CEST 2017

mart...@martijn.office.rootnet.nl:/home/martijn/src/OpenBSD/sys/arch/amd64/compile/GENERIC.MP
RTC BIOS diagnostic error d1
real mem = 4253237248 (4056MB)
avail mem = 4118540288 (3927MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.4 @ 0x8ed34000 (61 entries)
bios0: vendor Apple Inc. version 

Re: CVS: cvs.openbsd.org: src - removal of sys/scanio.h

[Sebastien Marie]

On Mon, May 29, 2017 at 03:40:59PM +0200, Sebastien Marie wrote:
> On Mon, May 29, 2017 at 06:10:51AM -0600, Ted Unangst wrote:
> > CVSROOT:/cvs
> > Module name:src
> > Changes by: t...@cvs.openbsd.org2017/05/29 06:10:51
> > 
> > Removed files:
> > sys/sys: scanio.h 
> > 
> > Log message:
> > scanner support died some time ago, the header can be removed too.
> > a gift from miod
> > 
> 
> The remove of sys/scanio.h broke usr.bin/kdump.
> 

correction was just commited. sorry for the noise :)
-- 
Sebastien Marie

Re: CVS: cvs.openbsd.org: src - removal of sys/scanio.h

[Ted Unangst]

Sebastien Marie wrote:
> On Mon, May 29, 2017 at 06:10:51AM -0600, Ted Unangst wrote:
> > CVSROOT:/cvs
> > Module name:src
> > Changes by: t...@cvs.openbsd.org2017/05/29 06:10:51
> > 
> > Removed files:
> > sys/sys: scanio.h 
> > 
> > Log message:
> > scanner support died some time ago, the header can be removed too.
> > a gift from miod
> > 
> 
> The remove of sys/scanio.h broke usr.bin/kdump.

yes, sorry, it's fixed now.

Re: CVS: cvs.openbsd.org: src - removal of sys/scanio.h

[Sebastien Marie]

On Mon, May 29, 2017 at 06:10:51AM -0600, Ted Unangst wrote:
> CVSROOT:  /cvs
> Module name:  src
> Changes by:   t...@cvs.openbsd.org2017/05/29 06:10:51
> 
> Removed files:
>   sys/sys: scanio.h 
> 
> Log message:
> scanner support died some time ago, the header can be removed too.
> a gift from miod
> 

The remove of sys/scanio.h broke usr.bin/kdump.

Below a diff to unbreak it.

Thanks.
-- 
Sebastien Marie


Index: usr.bin/kdump/Makefile
===
RCS file: /cvs/src/usr.bin/kdump/Makefile,v
retrieving revision 1.33
diff -u -p -r1.33 Makefile
--- usr.bin/kdump/Makefile  25 Apr 2016 19:18:41 -  1.33
+++ usr.bin/kdump/Makefile  29 May 2017 13:39:52 -
@@ -43,7 +43,6 @@ ioctl.c: ${.CURDIR}/Makefile ${.CURDIR}/
${SYS_DIR}/sys/mtio.h \
${SYS_DIR}/sys/pciio.h \
${SYS_DIR}/sys/radioio.h \
-   ${SYS_DIR}/sys/scanio.h \
${SYS_DIR}/sys/scsiio.h \
${SYS_DIR}/sys/sockio.h \
${SYS_DIR}/sys/videoio.h \
Index: usr.bin/kdump/mkioctls
===
RCS file: /cvs/src/usr.bin/kdump/mkioctls,v
retrieving revision 1.37
diff -u -p -r1.37 mkioctls
--- usr.bin/kdump/mkioctls  25 Apr 2016 19:18:41 -  1.37
+++ usr.bin/kdump/mkioctls  29 May 2017 13:39:52 -
@@ -73,7 +73,6 @@ BEGIN {
print "#include "
print "#include "
print "#include "
-   print "#include "
print "#include "
print "#include "
print "#include "

Re: CVS: cvs.openbsd.org: src (fwd)

[Mark Kettenis]

> Date: Sun, 16 Oct 2016 13:58:17 -0700
> From: Philip Guenther <guent...@gmail.com>
> 
> Should have sent this to tech...

Yes please!  But by terminating the loop early, I you'll miss the case
where the symbol shadows both a function and a global variable.

> -- Forwarded message --
> Date: Sun, 16 Oct 2016 13:57:42 -0700
> From: Philip Guenther <guent...@gmail.com>
> To: Jeremie Courreges-Anglas <j...@openbsd.org>
> Cc: source-chan...@openbsd.org
> Subject: Re: CVS: cvs.openbsd.org: src
> 
> On Sun, 16 Oct 2016, Jeremie Courreges-Anglas wrote:
> > CVSROOT:/cvs
> > Module name:src
> > Changes by: j...@cvs.openbsd.org2016/10/16 04:40:59
> > 
> > Modified files:
> > usr.sbin/rpc.bootparamd: bootparamd.c 
> > 
> > Log message:
> > Rename local variable 'err' to 'error', to avoid -Wshadow conflicts with 
> > err.h
> 
> Ick.  I know that newer gcc's have stopped generating shadow warning for 
> local variables vs global functions, such as this case.  Making these 
> changes just because we have an old gcc is kinda annoying.
> 
> So let's fix that and make our gcc a bit more like new ones.  Written 
> without peeking at the new ones and tested against the .c file at bottom 
> to verify that it doesn't fail or crash on some weird combo of shadowing.
> 
> oks?
> 
> Philip Guenther
> 
> 
> Index: c-decl.c
> ===
> RCS file: /data/src/openbsd/src/gnu/gcc/gcc/c-decl.c,v
> retrieving revision 1.4
> diff -u -p -r1.4 c-decl.c
> --- c-decl.c  10 Sep 2015 10:56:35 -  1.4
> +++ c-decl.c  16 Oct 2016 20:50:10 -
> @@ -1946,8 +1946,19 @@ warn_if_shadowing (tree new_decl)
> warning (OPT_Wshadow, "declaration of %q+D shadows a parameter",
>  new_decl);
>   else if (DECL_FILE_SCOPE_P (old_decl))
> -   warning (OPT_Wshadow, "declaration of %q+D shadows a global "
> -"declaration", new_decl);
> +   {
> + /* Don't warn about shadowing a global function unless the local
> +variable is a pointer to a function */
> + if (TREE_CODE (old_decl) == FUNCTION_DECL
> + && TREE_CODE (new_decl) != FUNCTION_DECL
> + && (TREE_CODE (new_decl) != VAR_DECL
> + || !POINTER_TYPE_P (TREE_TYPE (new_decl))
> + || TREE_CODE (TREE_TYPE (TREE_TYPE (new_decl)))
> +!= FUNCTION_TYPE))
> +   break;
> + warning (OPT_Wshadow, "declaration of %q+D shadows a global "
> +  "declaration", new_decl);
> +   }
>   else if (TREE_CODE (old_decl) == FUNCTION_DECL
>&& DECL_BUILT_IN (old_decl))
> {
> 
> 
> 
> -- test-shadow.c ---
> int var;
> void func(void);
> void (*func_ptr)(void) = func;
> enum { ENUM };
> typedef int type;
> 
> void
> test_var(int var_arg, void (*func_ptr_arg)(void))
> {
>   int var;
>   int func;
>   int func_ptr;
>   int ENUM;
>   int type;
>   {
>   int var_arg;
>   int func_ptr_arg;
>   }
> }
> 
> void
> test_func_ptr(int var_arg, void (*func_ptr_arg)(void))
> {
>   void (*var)(void);
>   void (*func)(void);
>   void (*func_ptr)(void);
>   void (*ENUM)(void);
>   void (*type)(void);
>   {
>   void (*var_arg)(void);
>   void (*func_ptr_arg)(void);
>   }
> }
> 
> void
> test_int_ptr(int var_arg, void (*func_ptr_arg)(void))
> {
>   int *var;
>   int *func;
>   int *func_ptr;
>   int *ENUM;
>   int *type;
>   {
>   int *var_arg;
>   int *func_ptr_arg;
>   }
> }
> 
> void
> test_enum(int var_arg, void (*func_ptr_arg)(void))
> {
>   enum { var };
>   enum { func };
>   enum { func_ptr };
>   enum { ENUM };
>   enum { type };
>   {
>   enum { var_arg };
>   enum { func_ptr_arg };
>   }
> }
> 
> void
> test_type(int var_arg, void (*func_ptr_arg)(void))
> {
>   typedef int var;
>   typedef int func;
>   typedef int func_ptr;
>   typedef int ENUM;
>   typedef int type;
>   {
>   typedef int var_arg;
>   typedef int func_ptr_arg;
>   }
> }
> 
> void
> test_var_param(
>   int var,
>   int func,
>   int func_ptr,
>   int ENUM,
>   int type)
> {
> }
> 
> void
> test_func_ptr_param(
>   void (*var)(void),
>   void (*func)(void),
>   void (*func_ptr)(void),
>   void (*ENUM)(void),
>   void (*type)(void))
> {
> }
> 
> 

CVS: cvs.openbsd.org: src (fwd)

[Philip Guenther]

Should have sent this to tech...

-- Forwarded message --
Date: Sun, 16 Oct 2016 13:57:42 -0700
From: Philip Guenther <guent...@gmail.com>
To: Jeremie Courreges-Anglas <j...@openbsd.org>
Cc: source-chan...@openbsd.org
Subject: Re: CVS: cvs.openbsd.org: src

On Sun, 16 Oct 2016, Jeremie Courreges-Anglas wrote:
> CVSROOT:  /cvs
> Module name:  src
> Changes by:   j...@cvs.openbsd.org2016/10/16 04:40:59
> 
> Modified files:
>   usr.sbin/rpc.bootparamd: bootparamd.c 
> 
> Log message:
> Rename local variable 'err' to 'error', to avoid -Wshadow conflicts with err.h

Ick.  I know that newer gcc's have stopped generating shadow warning for 
local variables vs global functions, such as this case.  Making these 
changes just because we have an old gcc is kinda annoying.

So let's fix that and make our gcc a bit more like new ones.  Written 
without peeking at the new ones and tested against the .c file at bottom 
to verify that it doesn't fail or crash on some weird combo of shadowing.

oks?

Philip Guenther


Index: c-decl.c
===
RCS file: /data/src/openbsd/src/gnu/gcc/gcc/c-decl.c,v
retrieving revision 1.4
diff -u -p -r1.4 c-decl.c
--- c-decl.c10 Sep 2015 10:56:35 -  1.4
+++ c-decl.c16 Oct 2016 20:50:10 -
@@ -1946,8 +1946,19 @@ warn_if_shadowing (tree new_decl)
  warning (OPT_Wshadow, "declaration of %q+D shadows a parameter",
   new_decl);
else if (DECL_FILE_SCOPE_P (old_decl))
- warning (OPT_Wshadow, "declaration of %q+D shadows a global "
-  "declaration", new_decl);
+ {
+   /* Don't warn about shadowing a global function unless the local
+  variable is a pointer to a function */
+   if (TREE_CODE (old_decl) == FUNCTION_DECL
+   && TREE_CODE (new_decl) != FUNCTION_DECL
+   && (TREE_CODE (new_decl) != VAR_DECL
+   || !POINTER_TYPE_P (TREE_TYPE (new_decl))
+   || TREE_CODE (TREE_TYPE (TREE_TYPE (new_decl)))
+  != FUNCTION_TYPE))
+ break;
+   warning (OPT_Wshadow, "declaration of %q+D shadows a global "
+"declaration", new_decl);
+ }
else if (TREE_CODE (old_decl) == FUNCTION_DECL
 && DECL_BUILT_IN (old_decl))
  {



-- test-shadow.c ---
int var;
void func(void);
void (*func_ptr)(void) = func;
enum { ENUM };
typedef int type;

void
test_var(int var_arg, void (*func_ptr_arg)(void))
{
int var;
int func;
int func_ptr;
int ENUM;
int type;
{
int var_arg;
int func_ptr_arg;
}
}

void
test_func_ptr(int var_arg, void (*func_ptr_arg)(void))
{
void (*var)(void);
void (*func)(void);
void (*func_ptr)(void);
void (*ENUM)(void);
void (*type)(void);
{
void (*var_arg)(void);
void (*func_ptr_arg)(void);
}
}

void
test_int_ptr(int var_arg, void (*func_ptr_arg)(void))
{
int *var;
int *func;
int *func_ptr;
int *ENUM;
int *type;
{
int *var_arg;
int *func_ptr_arg;
}
}

void
test_enum(int var_arg, void (*func_ptr_arg)(void))
{
enum { var };
enum { func };
enum { func_ptr };
enum { ENUM };
enum { type };
{
enum { var_arg };
enum { func_ptr_arg };
}
}

void
test_type(int var_arg, void (*func_ptr_arg)(void))
{
typedef int var;
typedef int func;
typedef int func_ptr;
typedef int ENUM;
typedef int type;
{
typedef int var_arg;
typedef int func_ptr_arg;
}
}

void
test_var_param(
int var,
int func,
int func_ptr,
int ENUM,
int type)
{
}

void
test_func_ptr_param(
void (*var)(void),
void (*func)(void),
void (*func_ptr)(void),
void (*ENUM)(void),
void (*type)(void))
{
}

Re: CVS: cvs.openbsd.org: src

[halex]

On August 10, 2016 11:52:29 AM GMT+02:00, Sebastien Marie  
wrote:
>On Tue, Aug 09, 2016 at 03:24:32PM -0600, Alexander Hall wrote:
>> CVSROOT: /cvs
>> Module name: src
>> Changes by:  ha...@cvs.openbsd.org   2016/08/09 15:24:32
>> 
>> Modified files:
>>  etc: Makefile 
>>  etc/mtree  : special 
>> Removed files:
>>  etc: csh.cshrc csh.login csh.logout 
>> 
>> Log message:
>> remove pointless csh placeholder files from /etc
>> 
>> ok jung@ (some time ago) phessler@
>> 
>
>does /etc/changelist should be cleared too ? I am unsure as it could
>also make sens to keep csh.{cshrc,login,logout} entries in it.

I think it makes sense to keep it, like we do for other initially non-existing 
files in there.

/Alexander

>
>thanks.

Re: CVS: cvs.openbsd.org: src

[Sebastien Marie]

On Tue, Aug 09, 2016 at 03:24:32PM -0600, Alexander Hall wrote:
> CVSROOT:  /cvs
> Module name:  src
> Changes by:   ha...@cvs.openbsd.org   2016/08/09 15:24:32
> 
> Modified files:
>   etc: Makefile 
>   etc/mtree  : special 
> Removed files:
>   etc: csh.cshrc csh.login csh.logout 
> 
> Log message:
> remove pointless csh placeholder files from /etc
> 
> ok jung@ (some time ago) phessler@
> 

does /etc/changelist should be cleared too ? I am unsure as it could
also make sens to keep csh.{cshrc,login,logout} entries in it.

thanks.
-- 
Sebastien Marie


Index: changelist
===
RCS file: /cvs/src/etc/changelist,v
retrieving revision 1.112
diff -u -p -r1.112 changelist
--- changelist  20 Apr 2016 12:41:30 -  1.112
+++ changelist  10 Aug 2016 09:49:59 -
@@ -16,9 +16,6 @@
 /etc/changelist
 /etc/chio.conf
 /etc/crontab
-/etc/csh.cshrc
-/etc/csh.login
-/etc/csh.logout
 /etc/daily
 /etc/daily.local
 /etc/defaultdomain

Fwd: CVS: cvs.openbsd.org: src

[Philip Guenther]

For those who don't following source-changes but build -current from source...

I just committed a major ABI change; threaded binaries from before
late-March will no longer work and you need to follow the instructions
I just committed to the FAQ's "following -current" page!

This is probably a good time to wait for a snapshot and install that.
That'll give ports builds a chance to catch up too.  :-)


Philip Guenther


-- Forwarded message --
From: Philip Guenther <guent...@openbsd.org>
Date: Sat, May 7, 2016 at 12:05 PM
Subject: CVS: cvs.openbsd.org: src
To: source-chan...@openbsd.org


CVSROOT:/cvs
Module name:src
Changes by: guent...@cvs.openbsd.org2016/05/07 13:05:24

Modified files:


Log message:
Use a Thread Information Block in both single and multi-threaded programs.
This stores errno, the cancelation flags, and related bits for each thread
and is allocated by ld.so or libc.a.  This is an ABI break from 5.9-stable!

Make libpthread dlopen'able by moving the cancelation wrappers into libc
and doing locking and fork/errno handling via callbacks that libpthread
registers when it first initializes.  'errno' *must* be declared via
 now!

Clean up libpthread's symbol exports like libc.

On powerpc, offset the TIB/TCB/TLS data from the register per the ELF spec.

Testing by various, particularly sthen@ and patrick@
ok kettenis@

Re: pppd and ioctl(TIOCSETD) (was: CVS: cvs.openbsd.org: src)

[Stefan Fritsch]

On Tue, 22 Dec 2015, David Coppa wrote:
> I suspect this broke my 3G connection:

Oops. Sorry. Try this diff (already committed):

--- sys/kern/tty_conf.c
+++ sys/kern/tty_conf.c
@@ -42,6 +42,11 @@
 #include 
 #include 
 
+#include "ppp.h"
+#include "nmea.h"
+#include "msts.h"
+#include "endrun.h"
+
 #definettynodisc ((int (*)(dev_t, struct tty *, struct proc *))enodev)
 #definettyerrclose ((int (*)(struct tty *, int flags, struct proc 
*))enodev)
 #definettyerrio ((int (*)(struct tty *, struct uio *, int))enodev)

pppd and ioctl(TIOCSETD) (was: CVS: cvs.openbsd.org: src)

[David Coppa]

On Mon, 21 Dec 2015, Stefan Fritsch wrote:

> CVSROOT:  /cvs
> Module name:  src
> Changes by:   s...@cvs.openbsd.org2015/12/21 14:49:03
> 
> Modified files:
>   sys/kern   : tty_conf.c tty_endrun.c tty_msts.c tty_nmea.c 
>   sys/net: ppp_tty.c 
>   sys/sys: tty.h 
> 
> Log message:
> Move ppp, nmea, endrun, and msts prototypes to tty.h
> 
> Fix inconsistent arguments for pppopen/pppclose/pppstart.
> Use passed in argument p in pppopen instead of curproc.
> 
> "Looks good to me" deraadt@

I suspect this broke my 3G connection:

Dec 22 13:22:51 t420 chat[16397]: send (ATDT*99***1#^M)
Dec 22 13:22:52 t420 chat[16397]: timeout set to 30 seconds
Dec 22 13:22:52 t420 chat[16397]: expect (CONNECT)
Dec 22 13:22:52 t420 chat[16397]: ^M
Dec 22 13:22:52 t420 chat[16397]: ^M
Dec 22 13:22:52 t420 chat[16397]: CONNECT
Dec 22 13:22:52 t420 chat[16397]:  -- got it
Dec 22 13:22:52 t420 chat[16397]: send (\\d)
Dec 22 13:22:53 t420 pppd[12116]: Serial connection established.
Dec 22 13:22:54 t420 pppd[12116]: ioctl(TIOCSETD): Operation not supported by 
device

I start this connection using:

/usr/sbin/pppd file /etc/ppp/peers/postemobile

And it always worked w/o problems until now.

It's a -current from ~1 hour ago:

$ sysctl kern.version
kern.version=OpenBSD 5.9-beta (GENERIC.MP) #0: Tue Dec 22 12:08:24 CET 2015
dco...@t420.bsdgeek.it:/usr/src/sys/arch/amd64/compile/GENERIC.MP

Ideas?

TIA!
David

Re: tail -n +NUM broken [Was CVS: cvs.openbsd.org: src]

[Ted Unangst]

> > Modified files:
> > usr.bin/tail   : extern.h forward.c misc.c read.c reverse.c 
> >  tail.c 
> > 
> > Log message:
> > another try to allow tailing multiple files. maybe it works?
> > commit now to allow people to test.
> 
> I just updated to very latest snapshot and tail with plus num doesn't
> work:
> 
> OpenBSD 5.8-current (GENERIC.MP) #1636: Thu Nov 19 14:05:34 MST 2015
> dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> 
> $ ps auxwww | tail -n +3 | wc -l
>0

(Everyone else: Please report all tail bugs to either tech or bugs.)

Definitely a regression here, the rewrite of forward() is apparently not
counting the offset correctly.

Re: tail -n +NUM broken [Was CVS: cvs.openbsd.org: src]

[Ted Unangst]

Ted Unangst wrote:
> > > Modified files:
> > >   usr.bin/tail   : extern.h forward.c misc.c read.c reverse.c 
> > >tail.c 
> > > 
> > > Log message:
> > > another try to allow tailing multiple files. maybe it works?
> > > commit now to allow people to test.
> > 
> > I just updated to very latest snapshot and tail with plus num doesn't
> > work:
> > 
> > OpenBSD 5.8-current (GENERIC.MP) #1636: Thu Nov 19 14:05:34 MST 2015
> > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> > 
> > $ ps auxwww | tail -n +3 | wc -l
> >0
> 
> (Everyone else: Please report all tail bugs to either tech or bugs.)
> 
> Definitely a regression here, the rewrite of forward() is apparently not
> counting the offset correctly.

So the problem is that after the for loop over files, we have:
(void)fflush(stdout);
if (!fflag || kq < 0)
return;

That code used to live a little farther down, in the loop that copied data,
and didn't break until after we hit EOF.

I think it may make sense to do the copying in the file loop instead. This
handles one case, but I think there are more. We also need to reset the offset
for each file, or later ones don't print anything.

Index: forward.c
===
RCS file: /cvs/src/usr.bin/tail/forward.c,v
retrieving revision 1.27
diff -u -p -r1.27 forward.c
--- forward.c   19 Nov 2015 17:50:04 -  1.27
+++ forward.c   20 Nov 2015 00:25:17 -
@@ -52,6 +52,16 @@ static const struct timespec *tfreopen(s
 
 static int kq = -1;
 
+static void
+printtail(FILE *fp)
+{
+   int ch;
+
+   while (!feof(fp) && (ch = getc(fp)) != EOF)
+   if (putchar(ch) == EOF)
+   oerr();
+}
+
 /*
  * forward -- display the file, from an offset, forward.
  *
@@ -75,7 +85,7 @@ static int kq = -1;
  * NOREG   cyclically read lines into a wrap-around array of buffers
  */
 void
-forward(struct tailfile *tf, int nfiles, enum STYLE style, off_t off)
+forward(struct tailfile *tf, int nfiles, enum STYLE style, off_t origoff)
 {
int ch;
struct tailfile *ctf, *ltf;
@@ -91,6 +101,7 @@ forward(struct tailfile *tf, int nfiles,
warn("kqueue");
 
for (i = 0; i < nfiles; i++) {
+   off_t off = origoff;
if (nfiles > 1)
printfname(tf[i].fname);
 
@@ -125,8 +136,11 @@ forward(struct tailfile *tf, int nfiles,
}
break;
}
-   if (ch == '\n' && !--off)
+   if (ch == '\n' && !--off) {
+   if (!fflag)
+   printtail(tf[i].fp);
break;
+   }
}
break;
case RBYTES:

Re: CVS: cvs.openbsd.org: src

[Joerg Jung]

On Wed, Sep 30, 2015 at 06:07:54PM +0200, Joerg Jung wrote:
> On Wed, Sep 30, 2015 at 05:13:31PM +0200, Martijn van Duren wrote:
> > On 09/30/15 14:15, Joerg Jung wrote:
> 
> > Thanks! Although it does add about 5-10 seconds to my boot-time, waiting
> > primarily for the temperature sensors.
> 
> Yes, they are probed during startup. That probing is slow, as the SMC is
> slow.  This needs some rethinking/polishing, moving the probing to a
> later point.

tl;dr: please find below a refactoring diff that fixes this.


The -current asmc(4) code suffers from two problems:

I.  The initial sensors read may take several seconds.
II. The update of the sensor values tsleep()s excessively within the
sensor task.

The following suggestions and hints to fix these timing issues were
provided to me:

1. mpi@ and Theo recommended not to tsleep() within the sensor task,
   mpi@ says: "Sleeping in the sensor thread might add latency to others
  sensors discovery."

   -> This is totally right, and matches II. problem statement above.

2. Theo suggested an async model using the sensor task (similar to
   ugold(4)), something like: sensor task comes, some command is issued,
   task returns, comes back later, reads result, next sensor, ...

   -> This sounds promising in theory, but I played a bit with this
  approach and it seems to be impossible to implement with asmc(4).
   -> The problem is that SMC requires several read() and write()
  operations for one command/sensor read, all of them acknowledged
  with waiting for the correct status, the protocol looks like this:
 1. write command, wait for status "accepted",
 2. write key, 4 single byte writes, each wait for status "accepted"
 3. write data length expected to read, wait for status "accepted"
 4. finally read data values, single byte reads each waiting for
status "ready for read"
  Step 1-3 might take in the seldom worst case several seconds 
  (retries + timeout).  I can not see an easy way to do this async
  and step-by-step as waiting too long will result in
  "comm collision" errors or might take ages, as it reads values
  from up to 100 sensors using these steps.

So, I came to the conclusion that solving I.+II. really requires an
additional thread.

3. uebayasi@ suggested to look into sys/dev/ipmi.c, which uses a kthread
   to initially read all sensor values from a slow serial bus.

   -> This was a good hint, related ipmi code is simple and it can be
  easily done in the same way in asmc(4), but according to a quick
  grep it is the ONLY sensor driver which does it in this way, and
  moreover:

4. tedu@ says: "oh, don't make your own thread unless you really need
   the loop. you can create your own taskq as well"

   -> Makes sense, a quick grep revealed, that (again) ONLY one single
  driver does it like this: viomb(4), again using an easy pattern to
  copy into asmc(4).

So, finally the refactoring diff below follows tedu's suggestion and
uses an own taskq to solve I.+II.

Tests, comments and OKs are welcome.

Thanks,
Regards,
Joerg



Index: asmc.c
===
RCS file: /cvs/src/sys/dev/isa/asmc.c,v
retrieving revision 1.11
diff -u -p -r1.11 asmc.c
--- asmc.c  15 Oct 2015 01:14:33 -  1.11
+++ asmc.c  23 Oct 2015 13:24:34 -
@@ -23,6 +23,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #include 
@@ -62,7 +63,13 @@ struct asmc_softc {
bus_space_handle_t   sc_ioh;
 
struct asmc_prod*sc_prod;
-   uint8_t  sc_lightlen;   /* light data len */
+   uint8_t  sc_init;   /* initialization done? */
+   uint8_t  sc_nfans;  /* number of fans */
+   uint8_t  sc_lightlen;   /* light data len */
+
+   struct taskq*sc_taskq;
+   struct task  sc_task_init;
+   struct task  sc_task_refresh;
 
struct ksensor   sc_sensor_temp[ASMC_MAXTEMP];
struct ksensor   sc_sensor_fan[ASMC_MAXFAN];
@@ -72,7 +79,12 @@ struct asmc_softc {
struct sensor_task  *sc_sensor_task;
 };
 
-intasmc_init(struct asmc_softc *);
+uint8_tasmc_status(struct asmc_softc *);
+intasmc_try(struct asmc_softc *, int, const char *, uint8_t *, uint8_t);
+void   asmc_kbdled(struct asmc_softc *, uint8_t);
+
+void   asmc_init(void *);
+void   asmc_refresh(void *);
 void   asmc_update(void *);
 
 intasmc_match(struct device *, void *, void *);
@@ -243,6 +255,8 @@ asmc_attach(struct device *parent, struc
 {
struct asmc_softc *sc = (struct asmc_softc *)self;
struct isa_attach_args *ia = aux;
+   uint8_t buf[6];
+   int i;
 
if (bus_space_map(ia->ia_iot, ia->ia_iobase, ia->ia_iosize, 0,
>sc_ioh)) {
@@ -251,23 +265,64 @@ asmc_attach(struct device *parent, 

Re: CVS: cvs.openbsd.org: src

[Joerg Jung]

On Wed, Sep 30, 2015 at 06:07:54PM +0200, Joerg Jung wrote:
> On Wed, Sep 30, 2015 at 05:13:31PM +0200, Martijn van Duren wrote:
> > 
> > What I find somewhat strange is that although the dmesg says it has "2
> > lights", it only shows one illuminance sensor in my sysctl. 
> 
> This is expected. In newer models the SMC shows up with two sensor keys,
> but only *one* provides useful/valid values (with 10bit instead of 6bit
> in older models). I probably should remove the number from the initial
> message to avoid confusion.

I committed a fix to -current, so that it should show now the correct
number of light sensors on initialization.

Re: CVS: cvs.openbsd.org: src

[Joerg Jung]

On Sun, Oct 04, 2015 at 09:20:06PM +0200, Mark Kettenis wrote:
> 
> Here is what I get on the Macmini 1,1 now:
> 
> asmc0 at isa0 port 0x300/32
> asmc0: rev 1.3f503, 137 keys, 5 temperatures, 1 fan, 0 lights, kbdled

Thanks for testing! I think printing "0 lights" is not very useful,
so I will tweak the output a bit further.
 
> hw.sensors.cpu0.temp0=54.00 degC
> hw.sensors.asmc0.temp0=56.00 degC (TC0D CPU0 Die Core)
> hw.sensors.asmc0.temp1=51.00 degC (TC0H CPU0 Heatsink)
> hw.sensors.asmc0.temp2=55.00 degC (TC0P CPU0 Proximity)
> hw.sensors.asmc0.temp3=54.00 degC (TN0P Northbridge Proximity)
> hw.sensors.asmc0.temp4=55.00 degC (TN1P Northbridge 2)
> hw.sensors.asmc0.fan0=1538 RPM (Master)
> 
> To answer your earlier question: I think having asmc(4) provide the
> Die Core temperature is good even though it is redundant.  This allows
> us to verify that cpu(4) is providing the right temperature/

Ok, fair enough.

Re: CVS: cvs.openbsd.org: src

[Mark Kettenis]

> Date: Sun, 4 Oct 2015 14:10:18 +0200
> From: Joerg Jung 
> 
> On Wed, Sep 30, 2015 at 06:07:54PM +0200, Joerg Jung wrote:
> > On Wed, Sep 30, 2015 at 05:13:31PM +0200, Martijn van Duren wrote:
> > > 
> > > What I find somewhat strange is that although the dmesg says it has "2
> > > lights", it only shows one illuminance sensor in my sysctl. 
> > 
> > This is expected. In newer models the SMC shows up with two sensor keys,
> > but only *one* provides useful/valid values (with 10bit instead of 6bit
> > in older models). I probably should remove the number from the initial
> > message to avoid confusion.
> 
> I committed a fix to -current, so that it should show now the correct
> number of light sensors on initialization.

Here is what I get on the Macmini 1,1 now:

asmc0 at isa0 port 0x300/32
asmc0: rev 1.3f503, 137 keys, 5 temperatures, 1 fan, 0 lights, kbdled

hw.sensors.cpu0.temp0=54.00 degC
hw.sensors.asmc0.temp0=56.00 degC (TC0D CPU0 Die Core)
hw.sensors.asmc0.temp1=51.00 degC (TC0H CPU0 Heatsink)
hw.sensors.asmc0.temp2=55.00 degC (TC0P CPU0 Proximity)
hw.sensors.asmc0.temp3=54.00 degC (TN0P Northbridge Proximity)
hw.sensors.asmc0.temp4=55.00 degC (TN1P Northbridge 2)
hw.sensors.asmc0.fan0=1538 RPM (Master)

To answer your earlier question: I think having asmc(4) provide the
Die Core temperature is good even though it is redundant.  This allows
us to verify that cpu(4) is providing the right temperature/

Re: CVS: cvs.openbsd.org: src

[Philip Guenther]

On Sat, Oct 3, 2015 at 2:12 AM, Vadim Zhukov  wrote:
> CVSROOT:/cvs
> Module name:src
> Changes by: z...@cvs.openbsd.org2015/10/03 03:12:39
>
> Modified files:
> usr.bin/kdump  : kdump.c
>
> Log message:
> Fix wrong cast.
>
> This one should be an unsigned long in theory, but the formatter function
> argument we're printing from is already an int (being casted from register_t
> at the formatter call time). So lets fix one bug at a time.

To expand a bit on why the use of int vs long is not a problem here:
the only thing using long gains is 32 more bits on LP64 archs.  That's
critical for pointers and buffer sizes, of course, where they really
are limited to 32bit on ILP32 archs, but for enumeration and
bitsets/flags like ioctl's 'request' argument, an enumeration value or
flag bit >=2^32 would make that value impossible to use on ILP32
archs.

Perhaps some day someone will come up with an ioctl() request that is
legitimately specific to LP64 archs and can thus be safely assigned a
request value >=2^32, but I don't foresee that and even then we would
need to be running out of ioctl requests <2^32 to make it worth it.
Until then, kdump can stick with ints for enumerations and flags,
perhaps serve as a compilation check against someone breaking that
rule accidentally.

If a bitset/flag argument needs to exceed 32bits in an MD way, it
should be typed as long long and thus be portably sized.


Philip Guenther

Re: CVS: cvs.openbsd.org: src

[Joerg Jung]

On Wed, Sep 30, 2015 at 05:13:31PM +0200, Martijn van Duren wrote:
> On 09/30/15 14:15, Joerg Jung wrote:
> >CVSROOT: /cvs
> >Module name: src
> >Changes by:  j...@cvs.openbsd.org2015/09/30 06:15:12
> >
> >Modified files:
> > share/man/man4 : isa.4
> > sys/arch/amd64/conf: GENERIC
> > sys/arch/i386/conf: GENERIC
> > sys/dev/isa: files.isa
> >Added files:
> > share/man/man4 : asmc.4
> > sys/dev/isa: asmc.c
> >
> >Log message:
> >add a (disabled) driver for the Apple System Management Controller (SMC) as
> >found in Apple Intel based devices
> >
> >"go at it" deraadt@
> >
> Just backported this driver to my 5.7-stable system at work (yes, I like to
> live dangerous from time to time) and the driver seems to work properly.

:)

> Thanks! Although it does add about 5-10 seconds to my boot-time, waiting
> primarily for the temperature sensors.

Yes, they are probed during startup. That probing is slow, as the SMC is
slow.  This needs some rethinking/polishing, moving the probing to a
later point.

> See sysctl and dmesg output below.
> 
> What I find somewhat strange is that although the dmesg says it has "2
> lights", it only shows one illuminance sensor in my sysctl. 

This is expected. In newer models the SMC shows up with two sensor keys,
but only *one* provides useful/valid values (with 10bit instead of 6bit
in older models). I probably should remove the number from the initial
message to avoid confusion.

> This does
> somewhat seems to fit with the right side of my screen being marginally
> darker then the left side of my screen. Although this is something that
> doesn't bother me in the least it seem like something that might be worth
> mentioning.
> 
> $ sysctl | grep asmc
> hw.sensors.asmc0.temp0=30.00 degC (TA0P Ambient)
> hw.sensors.asmc0.temp1=51.00 degC (TC0H CPU0 Heatsink)
> hw.sensors.asmc0.temp2=58.00 degC (TC0P CPU0 Proximity)
> hw.sensors.asmc0.temp3=78.00 degC (TG0D GPU0 Diode)
> hw.sensors.asmc0.temp4=73.00 degC (TG0H GPU0 Heatsink)
> hw.sensors.asmc0.temp5=49.00 degC (TL0P LCD Proximity)
> hw.sensors.asmc0.temp6=51.00 degC (TO0P Optical Drive)
> hw.sensors.asmc0.temp7=67.00 degC (Tm0P Memory Controller)
> hw.sensors.asmc0.fan0=997 RPM (ODD)
> hw.sensors.asmc0.fan1=1099 RPM (HDD)
> hw.sensors.asmc0.fan2=1198 RPM (CPU)
> hw.sensors.asmc0.illuminance0=4078.00 lx (left)
> $
> 
> OpenBSD 5.7-stable (ASMC) #1: Wed Sep 30 16:46:45 CEST 2015
> mart...@martijn.office.rootnet.nl:/usr/src/sys/arch/amd64/compile/ASMC
> RTC BIOS diagnostic error d1
> real mem = 4253237248 (4056MB)
> avail mem = 4136079360 (3944MB)
> mpath0 at root
> scsibus0 at mpath0: 256 targets
> mainbus0 at root
> bios0 at mainbus0: SMBIOS rev. 2.4 @ 0xe (61 entries)
> bios0: vendor Apple Inc. version "IM121.88Z.0047.B1F.1201241648" date
> 01/24/12
> bios0: Apple Inc. iMac12,1
> acpi0 at bios0: rev 2
> acpi0: sleep states S0 S3 S4 S5
> acpi0: tables DSDT FACP HPET APIC SBST ECDT SSDT SSDT SSDT SSDT SSDT SSDT
> SSDT SSDT MCFG SSDT SSDT SSDT
> acpi0: wakeup devices P0P2(S4) GFX0(S4) EC__(S4) HDEF(S4) GIGE(S4) RP01(S4)
> ARPT(S4) RP02(S4) RP03(S4) RP05(S4) EHC1(S3) EHC2(S3)
> acpitimer0 at acpi0: 3579545 Hz, 24 bits
> acpihpet0 at acpi0: 14318179 Hz
> acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
> cpu0 at mainbus0: apid 0 (boot processor)
> cpu0: Intel(R) Core(TM) i5-2400S CPU @ 2.50GHz, 2500.36 MHz
> cpu0: 
> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,LONG,LAHF,PERF,ITSC
> cpu0: 256KB 64b/line 8-way L2 cache
> cpu0: smt 0, core 0, package 0
> mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges
> cpu0: apic clock running at 100MHz
> cpu0: mwait min=64, max=64, C-substates=0.2.1.1.0, IBE
> cpu1 at mainbus0: apid 2 (application processor)
> cpu1: Intel(R) Core(TM) i5-2400S CPU @ 2.50GHz, 2500.03 MHz
> cpu1: 
> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,LONG,LAHF,PERF,ITSC
> cpu1: 256KB 64b/line 8-way L2 cache
> cpu1: smt 0, core 1, package 0
> cpu2 at mainbus0: apid 4 (application processor)
> cpu2: Intel(R) Core(TM) i5-2400S CPU @ 2.50GHz, 2500.03 MHz
> cpu2: 
> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,LONG,LAHF,PERF,ITSC
> cpu2: 256KB 64b/line 8-way L2 cache
> cpu2: smt 0, core 2, package 0
> cpu3 at mainbus0: apid 6 (application processor)
> cpu3: Intel(R) Core(TM) i5-2400S CPU @ 2.50GHz, 2500.03 MHz
> cpu3: 
> 

Re: CVS: cvs.openbsd.org: src

[Martijn van Duren]

On 09/30/15 14:15, Joerg Jung wrote:

CVSROOT:/cvs
Module name:src
Changes by: j...@cvs.openbsd.org2015/09/30 06:15:12

Modified files:
share/man/man4 : isa.4
sys/arch/amd64/conf: GENERIC
sys/arch/i386/conf: GENERIC
sys/dev/isa: files.isa
Added files:
share/man/man4 : asmc.4
sys/dev/isa: asmc.c

Log message:
add a (disabled) driver for the Apple System Management Controller (SMC) as
found in Apple Intel based devices

"go at it" deraadt@

Just backported this driver to my 5.7-stable system at work (yes, I like 
to live dangerous from time to time) and the driver seems to work 
properly. Thanks! Although it does add about 5-10 seconds to my 
boot-time, waiting primarily for the temperature sensors.

See sysctl and dmesg output below.

What I find somewhat strange is that although the dmesg says it has "2 
lights", it only shows one illuminance sensor in my sysctl. This does 
somewhat seems to fit with the right side of my screen being marginally 
darker then the left side of my screen. Although this is something that 
doesn't bother me in the least it seem like something that might be 
worth mentioning.


$ sysctl | grep asmc
hw.sensors.asmc0.temp0=30.00 degC (TA0P Ambient)
hw.sensors.asmc0.temp1=51.00 degC (TC0H CPU0 Heatsink)
hw.sensors.asmc0.temp2=58.00 degC (TC0P CPU0 Proximity)
hw.sensors.asmc0.temp3=78.00 degC (TG0D GPU0 Diode)
hw.sensors.asmc0.temp4=73.00 degC (TG0H GPU0 Heatsink)
hw.sensors.asmc0.temp5=49.00 degC (TL0P LCD Proximity)
hw.sensors.asmc0.temp6=51.00 degC (TO0P Optical Drive)
hw.sensors.asmc0.temp7=67.00 degC (Tm0P Memory Controller)
hw.sensors.asmc0.fan0=997 RPM (ODD)
hw.sensors.asmc0.fan1=1099 RPM (HDD)
hw.sensors.asmc0.fan2=1198 RPM (CPU)
hw.sensors.asmc0.illuminance0=4078.00 lx (left)
$

OpenBSD 5.7-stable (ASMC) #1: Wed Sep 30 16:46:45 CEST 2015
mart...@martijn.office.rootnet.nl:/usr/src/sys/arch/amd64/compile/ASMC
RTC BIOS diagnostic error d1
real mem = 4253237248 (4056MB)
avail mem = 4136079360 (3944MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.4 @ 0xe (61 entries)
bios0: vendor Apple Inc. version "IM121.88Z.0047.B1F.1201241648" date 
01/24/12

bios0: Apple Inc. iMac12,1
acpi0 at bios0: rev 2
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP HPET APIC SBST ECDT SSDT SSDT SSDT SSDT SSDT 
SSDT SSDT SSDT MCFG SSDT SSDT SSDT
acpi0: wakeup devices P0P2(S4) GFX0(S4) EC__(S4) HDEF(S4) GIGE(S4) 
RP01(S4) ARPT(S4) RP02(S4) RP03(S4) RP05(S4) EHC1(S3) EHC2(S3)

acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpihpet0 at acpi0: 14318179 Hz
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Core(TM) i5-2400S CPU @ 2.50GHz, 2500.36 MHz
cpu0: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,LONG,LAHF,PERF,ITSC

cpu0: 256KB 64b/line 8-way L2 cache
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges
cpu0: apic clock running at 100MHz
cpu0: mwait min=64, max=64, C-substates=0.2.1.1.0, IBE
cpu1 at mainbus0: apid 2 (application processor)
cpu1: Intel(R) Core(TM) i5-2400S CPU @ 2.50GHz, 2500.03 MHz
cpu1: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,LONG,LAHF,PERF,ITSC

cpu1: 256KB 64b/line 8-way L2 cache
cpu1: smt 0, core 1, package 0
cpu2 at mainbus0: apid 4 (application processor)
cpu2: Intel(R) Core(TM) i5-2400S CPU @ 2.50GHz, 2500.03 MHz
cpu2: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,LONG,LAHF,PERF,ITSC

cpu2: 256KB 64b/line 8-way L2 cache
cpu2: smt 0, core 2, package 0
cpu3 at mainbus0: apid 6 (application processor)
cpu3: Intel(R) Core(TM) i5-2400S CPU @ 2.50GHz, 2500.03 MHz
cpu3: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,LONG,LAHF,PERF,ITSC

cpu3: 256KB 64b/line 8-way L2 cache
cpu3: smt 0, core 3, package 0
ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 24 pins
ioapic0: misconfigured as apic 0, remapped to apid 2
acpiec0 at acpi0
acpimcfg0 at acpi0 addr 0xe000, bus 0-155
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus 1 (P0P2)
acpiprt2 at acpi0: bus 2 (RP01)
acpiprt3 at acpi0: bus 3 (RP02)
acpiprt4 at 

Fwd: CVS: cvs.openbsd.org: src

[Philip Guenther]

A heads up on this commit: if you're following -current and using any
perl modules that pull in threaded libraries from packages, such as
mysql/mariadb integration via DBD::mysql, then you may want to wait
the day or so until the ports package builds have caught up with the
change.  The perl in base built against libpthread.19.0 cannot load
the mysql.so shared object linked against libpthread.18.1

Philip Guenther

-- Forwarded message --
From: Philip Guenther guent...@cvs.openbsd.org
Date: Mon, Apr 6, 2015 at 6:27 PM
Subject: CVS: cvs.openbsd.org: src
To: source-chan...@cvs.openbsd.org


CVSROOT:/cvs
Module name:src
Changes by: guent...@cvs.openbsd.org2015/04/06 19:27:07

Modified files:
lib/csu: crtbegin.c crtbeginS.c
lib/libc   : shlib_version
lib/libc/arch/alpha: SYS.h
lib/libc/arch/alpha/sys: fork.S
lib/libc/arch/amd64: SYS.h
lib/libc/arch/amd64/sys: fork.S
lib/libc/arch/arm: SYS.h
lib/libc/arch/arm/sys: fork.S
lib/libc/arch/hppa: SYS.h
lib/libc/arch/hppa/sys: fork.S
lib/libc/arch/hppa64: SYS.h
lib/libc/arch/hppa64/sys: fork.S
lib/libc/arch/i386: SYS.h
lib/libc/arch/i386/sys: fork.S
lib/libc/arch/m88k: SYS.h
lib/libc/arch/m88k/sys: fork.S
lib/libc/arch/mips64: SYS.h
lib/libc/arch/mips64/sys: fork.S
lib/libc/arch/powerpc: SYS.h
lib/libc/arch/powerpc/sys: fork.S
lib/libc/arch/sh: SYS.h
lib/libc/arch/sh/sys: fork.S
lib/libc/arch/sparc: SYS.h
lib/libc/arch/sparc/sys: fork.S
lib/libc/arch/sparc64: SYS.h
lib/libc/arch/sparc64/sys: fork.S
lib/libc/arch/vax: SYS.h
lib/libc/arch/vax/sys: fork.S
lib/libc/include: thread_private.h
lib/libc/stdlib: atexit.c
lib/libc/sys   : Makefile.inc
lib/libc/thread: Makefile.inc unithread_malloc_lock.c
lib/librthread : rthread.c rthread_fork.c rthread_libc.c
 shlib_version
regress/lib/csu/callbacks: Makefile
regress/lib/csu/callbacks/pthread_atfork: Makefile
  pthread_atfork_test.c
Added files:
lib/libc/include: atfork.h
lib/libc/sys   : w_fork.c
lib/libc/thread: atfork.c
regress/lib/csu/callbacks/pthread_atfork: expected_child.out
  expected_parent.out

Log message:
Make pthread_atfork() track the DSO that called it like atexit() does,
unregistering callbacks if the DSO is unloaded.  Move the callback
handling from libpthread to libc, though libpthread still overrides the
inner call to handle locking and thread-library reinitialization.
Major version bump for both libc and libpthread.

verification that this fixes various ports ajacoutot@
asm assistance miod@; ok millert@ deraadt@

Re: CVS: cvs.openbsd.org: src

[Guenther Niess]

The patch below should unbreak make release.

On 07/15/14 11:14, Marc Espie wrote:
 CVSROOT:  /cvs
 Module name:  src
 Changes by:   es...@cvs.openbsd.org   2014/07/15 03:14:50
 
 Removed files:
   etc/mtree  : BSD.local.dist 
 
 Log message:
 folded back into 4.4BSD.dist
 removed to unconfuse devs
 
 okay aja, theo
 

Index: etc/Makefile
===
RCS file: /cvs/src/etc/Makefile,v
retrieving revision 1.375
diff -u -p -r1.375 Makefile
--- etc/Makefile15 Jul 2014 09:27:04 -  1.375
+++ etc/Makefile15 Jul 2014 13:59:37 -
@@ -85,8 +85,6 @@ install-mtree:
${DESTDIR}${MTREEDIR}
${INSTALL} -c -o root -g wheel -m 444 mtree/4.4BSD.dist \
${DESTDIR}${MTREEDIR}
-   ${INSTALL} -c -o root -g wheel -m 444 mtree/BSD.local.dist \
-   ${DESTDIR}${MTREEDIR}
${INSTALL} -c -o root -g wheel -m 444 mtree/BSD.x11.dist \
${DESTDIR}${MTREEDIR}

Re: CVS: cvs.openbsd.org: src

[Martijn van Duren]

Hello tech@,

I just saw the commit message below.
Currently I use the source functionality to determine whether I'm in my 
home network or not and use it to customize sndiod_flags to redirect 
sound to my main server.


Is there an alternative to dynamically change the rc.conf flags based on 
my network?


At the moment my rc.conf.local looks as follow for sndiod:
if nc -z 192.168.153.4 11025 2 /dev/null; then
sndiod_flags=-f snd@192.168.153.4/0
fi

Sincerely,

Martijn van Duren

On 07/12/14 12:14, Robert Nagy wrote:

CVSROOT:/cvs
Module name:src
Changes by: rob...@cvs.openbsd.org  2014/07/12 04:14:03

Modified files:
etc: netstart rc rc.conf
etc/rc.d   : rc.subr

Log message:
Make rc.conf a parsed configuration file and stop sourcing it as a shell
script.
 From now on rc.conf has a fixed syntax (key=val) and it is not allowed
to add anything to it besides the supported syntax, it all going to be
ignored.

discussed with and help from deraadt@ and halex@

Re: CVS: cvs.openbsd.org: src

[Stuart Henderson]

On 2014/07/12 14:04, Martijn van Duren wrote:
 Hello tech@,
 
 I just saw the commit message below.
 Currently I use the source functionality to determine whether I'm in my home
 network or not and use it to customize sndiod_flags to redirect sound to my
 main server.
 
 Is there an alternative to dynamically change the rc.conf flags based on my
 network?

Maybe sndiod_flags=NO and start sndiod from /etc/rc.local instead.

Re: CVS: cvs.openbsd.org: src

[Theo de Raadt]

 I am however curious about the rational behind this change. Does it 
 solve any particular problem/risk?
 I seldomly use this style in my own scripts when I need to be able to 
 dynamically determine variables at runtime. So it might be wise to know 
 what hidden daemons I might be facing.

The rc configuration file is becoming a well-managed clean file so that
a mix of tools and admins can manage it.  Not quite at the level of
master.passwd, which is strictly controlled.  Still admin editable, but
well formed so that the future automatic tools won't screw up scripting
in the file.

Re: CVS: cvs.openbsd.org: src

[Bob Beck]

The OPENSSL_VERSION number is a guarantee for a certain version of the
ABI. As we dont' provide that (in fact much
of the ABI in LIbreSSL is beyond 1.0.1g, it is not accurate to use
the old OPENSSL_VERSION. Essnentially this OPENSSL_VERSION
is bigger than 1.0.1g's.



On Fri, Jul 11, 2014 at 4:15 PM, Stuart Henderson s...@spacehopper.org wrote:
 On 2014/07/11 15:21, Bob Beck wrote:
 CVSROOT:  /cvs
 Module name:  src
 Changes by:   b...@cvs.openbsd.org2014/07/11 15:21:59

 Modified files:
   lib/libssl/src/crypto: opensslv.h

 Log message:
 Provide LIBRESSL_VERSION_NUMBER for people who use such things to
 detect versions distinct from OPENSSL_BLAH_WOOF..
 ok jsing@ tedu@ deraadt@


 I think it would ease porting work if the old OPENSSL_VERSION_NUMBER could
 be retained and we use LIBRESSL_VERSION_NUMBER to distinguish LibreSSL
 versions..


 dovecot-2.2.10/dovecot-2.2.10/src/login-common/ssl-proxy-openssl.c
 http://hg.dovecot.org/dovecot-2.2/file/fd0616d553b0/src/login-common/ssl-proxy-openssl.c#l130
 32:#if !defined(OPENSSL_NO_ECDH)  OPENSSL_VERSION_NUMBER = 0x1000L
 129:#if defined(HAVE_ECDH)  OPENSSL_VERSION_NUMBER  0x10002000L
 1028:#if defined(HAVE_ECDH)  OPENSSL_VERSION_NUMBER  0x10002000L
 1041:#if OPENSSL_VERSION_NUMBER = 0x10002000L
 1076:#if OPENSSL_VERSION_NUMBER = 0x00907000L
 1156:#if defined(HAVE_ECDH)  OPENSSL_VERSION_NUMBER  0x10002000L

 chromium-34.0.1847.137/chromium-34.0.1847.137/net/socket/ssl_client_socket_openssl.cc
 54:#if OPENSSL_VERSION_NUMBER  0x1000103fL
 ...(checking for a version of openssl other than the embedded one?)


 apache-httpd
 http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/ssl/ssl_private.h?revision=1598107view=markup#l86
 : #include openssl/opensslv.h
 : #if (OPENSSL_VERSION_NUMBER = 0x10001000)
 : /* must be defined before including ssl.h */
 : #define OPENSSL_NO_SSL_INTERN
 : #endif

 knot-dns
 https://gitlab.labs.nic.cz/labs/knot/blob/2354047b6402aa68daffe96d6f82f30f0dad1cff/src/libknot/dnssec/config.h
 : // ECDSA support requires OpenSSL version = 1.0.1
 : #if !defined(OPENSSL_NO_ECDSA)  OPENSSL_VERSION_NUMBER = 0x10001000L
 :   #define KNOT_ENABLE_ECDSA 1
 : #else
 :   #undef KNOT_ENABLE_ECDSA
 : #endif

Re: CVS: cvs.openbsd.org: src

[Stuart Henderson]

I'm worried that bogus codepaths will be taken in software that expects a
certain openssl version - things failing to build we can cope with in ports
easily enough, I'm more concerned about software that does build but behaves
incorrectly at runtime.

Re: CVS: cvs.openbsd.org: src

[Theo de Raadt]

 I'm worried that bogus codepaths will be taken in software that expects a
 certain openssl version - things failing to build we can cope with in ports
 easily enough, I'm more concerned about software that does build but behaves
 incorrectly at runtime.

If the software is that fragile, then I am happy Bob, Joel, Miod, and Ted
are simplifying the interface.

Re: CVS: cvs.openbsd.org: src

[Matthew Dempsky]

On Fri, Jul 11, 2014 at 3:41 PM, Bob Beck b...@obtuse.com wrote:
 The OPENSSL_VERSION number is a guarantee for a certain version of the
 ABI. As we dont' provide that (in fact much
 of the ABI in LIbreSSL is beyond 1.0.1g, it is not accurate to use
 the old OPENSSL_VERSION. Essnentially this OPENSSL_VERSION
 is bigger than 1.0.1g's.

By that argument, we won't be ABI compatible with OpenSSL 2.0 either,
so we shouldn't provide OPENSSL_VERSION at all.

My 2c is for keeping OPENSSL_VERSION_NUMBER as the most recent OpenSSL
version that we're *mostly* API/feature compatible with, and using
LIBRESSL_VERSION_NUMBER to identify the exact LibreSSL version.  By
polluting the OPENSSL_VERSION_NUMBER namespace we just make things
more difficult for downstream users that want to be compatible with
both OpenSSL and LibreSSL.

E.g., to check for a feature that was added in OpenSSL 1.2 but isn't
present in LibreSSL, that code now needs to be

#if OPENSSL_VERSION_NUMBER = 1.2  !defined(LIBRESSL_VERSION_NUMBER)

rather than simply

#if OPENSSL_VERSION_NUMBER = 1.2

Breaking the latter just seems like making it more difficult to get
people to port their software from OpenSSL to LibreSSL.

Re: CVS: cvs.openbsd.org: src

[Bob Beck]

The fundamental probelm with this Matthew - is that next time, if we
do this, by the next release we will
be chasing what features we have imported from 1.0.2g  and 10.2.z, and
1.0.2.qq - where does it end?
We will be continuing to add functionality in here from many sources,
and so assuming we could just keep
this as the 1.0.1g version number is completely wrong.

If we do that we will be perpetually updating this to be close to
whatever happens to be the orthogonal openssl.
feature set, we're screwed. We'll be doing this forever, and be in a
situation where it's as bad a what it is with
ACPI, where the only safe thing to report as is Windows so we don't
get screwed by the software trying to
do incompatible junk.

Now the mistake we made this go around is to not provide a way for
identifying that it is libressl. that has been corrected.



On Fri, Jul 11, 2014 at 4:56 PM, Matthew Dempsky matt...@dempsky.org wrote:
 On Fri, Jul 11, 2014 at 3:41 PM, Bob Beck b...@obtuse.com wrote:
 The OPENSSL_VERSION number is a guarantee for a certain version of the
 ABI. As we dont' provide that (in fact much
 of the ABI in LIbreSSL is beyond 1.0.1g, it is not accurate to use
 the old OPENSSL_VERSION. Essnentially this OPENSSL_VERSION
 is bigger than 1.0.1g's.

 By that argument, we won't be ABI compatible with OpenSSL 2.0 either,
 so we shouldn't provide OPENSSL_VERSION at all.

 My 2c is for keeping OPENSSL_VERSION_NUMBER as the most recent OpenSSL
 version that we're *mostly* API/feature compatible with, and using
 LIBRESSL_VERSION_NUMBER to identify the exact LibreSSL version.  By
 polluting the OPENSSL_VERSION_NUMBER namespace we just make things
 more difficult for downstream users that want to be compatible with
 both OpenSSL and LibreSSL.

 E.g., to check for a feature that was added in OpenSSL 1.2 but isn't
 present in LibreSSL, that code now needs to be

 #if OPENSSL_VERSION_NUMBER = 1.2  !defined(LIBRESSL_VERSION_NUMBER)

 rather than simply

 #if OPENSSL_VERSION_NUMBER = 1.2

 Breaking the latter just seems like making it more difficult to get
 people to port their software from OpenSSL to LibreSSL.

Re: CVS: cvs.openbsd.org: src

[Matthew Dempsky]

On Fri, Jul 11, 2014 at 4:37 PM, Bob Beck b...@obtuse.com wrote:
 The fundamental probelm with this Matthew - is that next time, if we
 do this, by the next release we will
 be chasing what features we have imported from 1.0.2g  and 10.2.z, and
 1.0.2.qq - where does it end?

It ends whenever it stops helping portability for apps that are
currently written for OpenSSL.  We've expressly decided to ignore any
API/ABI compatibility guarantees with OpenSSL, so an OpenSSL version
number is inherently just a best effort to make things easier on
applications to transition from OpenSSL to LibreSSL.

Clang went through this same process with code that did GCC version
checks.  Today Clang still claims it's GCC 4.2, but in a separate
version it reveals it's Clang 3.5.

Existing code that only knows to check for older versions of GCC
(e.g., OpenBSD's sys/cdefs.h) continues work just fine with Clang,
because it picks up all of the definitions targeted towards GCC 4.2.
New code that wants to make use of features in GCC 4.7 and Clang 3.5
though needs to check for both; but even if it doesn't, if it includes
fallback for older versions of GCC it should still work okay with
Clang.

Concrete analogy: suppose LibreSSL 2.1 and OpenSSL 1.1 both add some
new feature, and an application that wants to be compatible with both
wants to make use of that feature.  How do they version check for its
availability?

Naively, it would be

#if LibreSSL = 2.1 || OpenSSL = 1.1

but that's going to cause the application to break when compiled with
older versions of LibreSSL.  It would actually needs to be

#if LibreSSL = 2.1 || (!defined(LibreSSL)  OpenSSL = 1.1)

We don't gain anything by making people need to write the latter, IMO.

Re: CVS: cvs.openbsd.org: src

[Kent R. Spillner]

On Thu, Jul 10, 2014 at 08:29:04AM -0600, Philip Guenther wrote:
 CVSROOT:  /cvs
 Module name:  src
 Changes by:   guent...@cvs.openbsd.org2014/07/10 08:29:03
 
 Modified files:
   usr.bin/rdist  : common.c config-data.h 
 
 Log message:
 Assume POSIX: write() takes size_t and returns ssize_t

Do we need to do anything specific to build rdist after this change?


=== usr.bin/rdist
cc -O2 -pipe  -I. -I/usr/src/usr.bin/rdist -DOS_H=\os-openbsd.h\ -Wall 
-Wpointer-arith -Wuninitialized -Wstrict-prototypes -Wmissing-prototypes 
-Wunused -Wsign-compare -Wshadow -Wdeclaration-after-statement   -c gram.c
cc -O2 -pipe  -I. -I/usr/src/usr.bin/rdist -DOS_H=\os-openbsd.h\ -Wall 
-Wpointer-arith -Wuninitialized -Wstrict-prototypes -Wmissing-prototypes 
-Wunused -Wsign-compare -Wshadow -Wdeclaration-after-statement   -c 
/usr/src/usr.bin/rdist/message.c
cc -O2 -pipe  -I. -I/usr/src/usr.bin/rdist -DOS_H=\os-openbsd.h\ -Wall 
-Wpointer-arith -Wuninitialized -Wstrict-prototypes -Wmissing-prototypes 
-Wunused -Wsign-compare -Wshadow -Wdeclaration-after-statement   -c 
/usr/src/usr.bin/rdist/lookup.c
cc -O2 -pipe  -I. -I/usr/src/usr.bin/rdist -DOS_H=\os-openbsd.h\ -Wall 
-Wpointer-arith -Wuninitialized -Wstrict-prototypes -Wmissing-prototypes 
-Wunused -Wsign-compare -Wshadow -Wdeclaration-after-statement   -c 
/usr/src/usr.bin/rdist/isexec.c
cc -O2 -pipe  -I. -I/usr/src/usr.bin/rdist -DOS_H=\os-openbsd.h\ -Wall 
-Wpointer-arith -Wuninitialized -Wstrict-prototypes -Wmissing-prototypes 
-Wunused -Wsign-compare -Wshadow -Wdeclaration-after-statement   -c 
/usr/src/usr.bin/rdist/expand.c
cc -O2 -pipe  -I. -I/usr/src/usr.bin/rdist -DOS_H=\os-openbsd.h\ -Wall 
-Wpointer-arith -Wuninitialized -Wstrict-prototypes -Wmissing-prototypes 
-Wunused -Wsign-compare -Wshadow -Wdeclaration-after-statement   -c 
/usr/src/usr.bin/rdist/distopt.c
cc -O2 -pipe  -I. -I/usr/src/usr.bin/rdist -DOS_H=\os-openbsd.h\ -Wall 
-Wpointer-arith -Wuninitialized -Wstrict-prototypes -Wmissing-prototypes 
-Wunused -Wsign-compare -Wshadow -Wdeclaration-after-statement   -c 
/usr/src/usr.bin/rdist/common.c
cc -O2 -pipe  -I. -I/usr/src/usr.bin/rdist -DOS_H=\os-openbsd.h\ -Wall 
-Wpointer-arith -Wuninitialized -Wstrict-prototypes -Wmissing-prototypes 
-Wunused -Wsign-compare -Wshadow -Wdeclaration-after-statement   -c 
/usr/src/usr.bin/rdist/child.cIn file included from 
/usr/src/usr.bin/rdist/lookup.c:32:
/usr/src/usr.bin/rdist/defs.h:336: error: expected '=', ',', ';', 'asm' or 
'__attribute__' before 'xwrite'

cc -O2 -pipe  -I. -I/usr/src/usr.bin/rdist -DOS_H=\os-openbsd.h\ -Wall 
-Wpointer-arith -Wuninitialized -Wstrict-prototypes -Wmissing-prototypes 
-Wunused -Wsign-compare -Wshadow -Wdeclaration-after-statement   -c 
/usr/src/usr.bin/rdist/client.c
cc -O2 -pipe  -I. -I/usr/src/usr.bin/rdist -DOS_H=\os-openbsd.h\ -Wall 
-Wpointer-arith -Wuninitialized -Wstrict-prototypes -Wmissing-prototypes 
-Wunused -Wsign-compare -Wshadow -Wdeclaration-after-statement   -c 
/usr/src/usr.bin/rdist/docmd.c
cc -O2 -pipe  -I. -I/usr/src/usr.bin/rdist -DOS_H=\os-openbsd.h\ -Wall 
-Wpointer-arith -Wuninitialized -Wstrict-prototypes -Wmissing-prototypes 
-Wunused -Wsign-compare -Wshadow -Wdeclaration-after-statement   -c 
/usr/src/usr.bin/rdist/rdist.cIn file included from 
/usr/src/usr.bin/rdist/message.c:32:
/usr/src/usr.bin/rdist/defs.h:336: error: expected '=', ',', ';', 'asm' or 
'__attribute__' before 'xwrite'In file included from 
/usr/src/usr.bin/rdist/gram.y:34:
/usr/src/usr.bin/rdist/defs.h:336: error: expected '=', ',', ';', 'asm' or 
'__attribute__' before 'xwrite'

In file included from /usr/src/usr.bin/rdist/common.c:32:
/usr/src/usr.bin/rdist/defs.h:336: error: expected '=', ',', ';', 'asm' or 
'__attribute__' before 'xwrite'
/usr/src/usr.bin/rdist/common.c:80: warning: no previous prototype for 'xwrite'
In file included from /usr/src/usr.bin/rdist/expand.c:34:
/usr/src/usr.bin/rdist/defs.h:336: error: expected '=', ',', ';', 'asm' or 
'__attribute__' before 'xwrite'
In file included from /usr/src/usr.bin/rdist/distopt.c:32:
/usr/src/usr.bin/rdist/defs.h:336: error: expected '=', ',', ';', 'asm' or 
'__attribute__' before 'xwrite'
In file included from /usr/src/usr.bin/rdist/client.c:34:
/usr/src/usr.bin/rdist/defs.h:336: error: expected '=', ',', ';', 'asm' or 
'__attribute__' before 'xwrite'

In file included from /usr/src/usr.bin/rdist/isexec.c:32:
/usr/src/usr.bin/rdist/defs.h:336: error: expected '=', ',', ';', 'asm' or 
'__attribute__' before 'xwrite'
*** Error 1 in target 'common.o'
*** Error 1 in target 'lookup.o'
*** Error 1 in target 'message.o'
*** Error 1 in target 'gram.o'
In file included from /usr/src/usr.bin/rdist/child.c:32:
/usr/src/usr.bin/rdist/defs.h:336: error: expected '=', ',', ';', 'asm' or 
'__attribute__' before 'xwrite'
In file included from /usr/src/usr.bin/rdist/docmd.c:36:
/usr/src/usr.bin/rdist/defs.h:336: error: expected '=', ',', ';', 'asm' or 
'__attribute__' before 'xwrite'
/usr/src/usr.bin/rdist/child.c: In 

Re: CVS: cvs.openbsd.org: src

[Miod Vallat]

 On Thu, Jul 10, 2014 at 08:29:04AM -0600, Philip Guenther wrote:
  CVSROOT:/cvs
  Module name:src
  Changes by: guent...@cvs.openbsd.org2014/07/10 08:29:03
  
  Modified files:
  usr.bin/rdist  : common.c config-data.h 
  
  Log message:
  Assume POSIX: write() takes size_t and returns ssize_t
 
 Do we need to do anything specific to build rdist after this change?

A further commit to rdist/defs.h fixes this; it should appear in your
repository mirror shortly.

procfs to die [was: CVS: cvs.openbsd.org: src]

[Philip Guenther]

If you're currently using procfs, please respond with exactly what parts of
it are actually needed by the programs you run.  Without a good reason to
keep it, it'll be deleted, as I broke listing of /proc back in January and
no one has noticed, suggesting that no one is actually using it...

Philip Guenther


-- Forwarded message --
From: Philip Guenther guent...@cvs.openbsd.org
Date: Sun, Jun 22, 2014 at 2:15 PM
Subject: CVS: cvs.openbsd.org: src
To: source-chan...@cvs.openbsd.org


CVSROOT:/cvs
Module name:src
Changes by: guent...@cvs.openbsd.org2014/06/22 15:15:51

Modified files:
sys/arch/i386/conf: GENERIC

Log message:
PROCFS has been broken for months without complaints, so stop building it

suggested by sthen@

Re: procfs to die [was: CVS: cvs.openbsd.org: src]

[Matthew Dempsky]

I suspect procfs is only enabled on i386 because that's the only arch
with compat_linux support?  If so, anyone who relies on compat_linux
support should be sure to test and report back if they have problems.

On Sun, Jun 22, 2014 at 2:22 PM, Philip Guenther guent...@gmail.com wrote:
 If you're currently using procfs, please respond with exactly what parts of
 it are actually needed by the programs you run.  Without a good reason to
 keep it, it'll be deleted, as I broke listing of /proc back in January and
 no one has noticed, suggesting that no one is actually using it...

 Philip Guenther


 -- Forwarded message --
 From: Philip Guenther guent...@cvs.openbsd.org
 Date: Sun, Jun 22, 2014 at 2:15 PM
 Subject: CVS: cvs.openbsd.org: src
 To: source-chan...@cvs.openbsd.org


 CVSROOT:/cvs
 Module name:src
 Changes by: guent...@cvs.openbsd.org2014/06/22 15:15:51

 Modified files:
 sys/arch/i386/conf: GENERIC

 Log message:
 PROCFS has been broken for months without complaints, so stop building it

 suggested by sthen@

Re: procfs to die [was: CVS: cvs.openbsd.org: src]

[Adam Thompson]

I do use it occasionally, and I don't run -current so I wouldn't have noticed 
any breakage yet.
I don't rely on it, however, it's a convenience feature that I very 
occasionally use, and only manually when I do.
I can live without it if it dies; it was never a fully-featured implementation 
IMHO anyway.
-Adam

On June 22, 2014 4:22:16 PM CDT, Philip Guenther guent...@gmail.com wrote:
If you're currently using procfs, please respond with exactly what
parts of
it are actually needed by the programs you run.  Without a good reason
to
keep it, it'll be deleted, as I broke listing of /proc back in January
and
no one has noticed, suggesting that no one is actually using it...

Philip Guenther


-- Forwarded message --
From: Philip Guenther guent...@cvs.openbsd.org
Date: Sun, Jun 22, 2014 at 2:15 PM
Subject: CVS: cvs.openbsd.org: src
To: source-chan...@cvs.openbsd.org


CVSROOT:/cvs
Module name:src
Changes by: guent...@cvs.openbsd.org2014/06/22 15:15:51

Modified files:
sys/arch/i386/conf: GENERIC

Log message:
PROCFS has been broken for months without complaints, so stop building
it

suggested by sthen@

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: CVS: cvs.openbsd.org: src

[Bob Beck]

I'm inclined to agree with marc here - we bump minors on api additions
- and yes, it was stubbed there before so it's not really an
addition but it was stubbed to fail and had to be worked around -
bump the minor - not like it's a big deal.

On Tue, Nov 19, 2013 at 12:02 AM, Marc Espie es...@nerim.net wrote:
 On Tue, Nov 19, 2013 at 12:11:17AM -0500, Ted Unangst wrote:
 On Mon, Nov 18, 2013 at 18:49, Philip Guenther wrote:

  btw, no library version change because the function stubs already
  existed.
 
  Hmm, since this is actually offering new functionality (by sem_open()
  and friends no longer always failing), I think it a minor bump would
  be appropriate.  Consider that a program with an autoconf test of
  sem_open() will now return a different answer, just as if sem_open()
  was completely new.  no?

 I hear you, but disagree. We fix program disabling bugs in libraries
 frequently without bumping. I have always thought of library
 versioning being more about program integrity, as in all the pieces
 you expect to find are all there, but it doesn't say anything about
 the inner workings of the pieces.

 As theo says, there are other library bumps later, but you're wrong.

 Use-case: new packages, slightly older snapshots. New packages actually
 make use of sem_open, because of said added functionality. Without a bump,
 pkg_add will allow to add them, and they won't work, because the functionality
 wasn't there...

 It is added functionality. It's not a minor bugfix.

Re: CVS: cvs.openbsd.org: src

[Vadim Zhukov]

2013/11/19 Bob Beck b...@obtuse.com:
 I'm inclined to agree with marc here - we bump minors on api additions
 - and yes, it was stubbed there before so it's not really an
 addition but it was stubbed to fail and had to be worked around -
 bump the minor - not like it's a big deal.

 On Tue, Nov 19, 2013 at 12:02 AM, Marc Espie es...@nerim.net wrote:
 On Tue, Nov 19, 2013 at 12:11:17AM -0500, Ted Unangst wrote:
 On Mon, Nov 18, 2013 at 18:49, Philip Guenther wrote:

  btw, no library version change because the function stubs already
  existed.
 
  Hmm, since this is actually offering new functionality (by sem_open()
  and friends no longer always failing), I think it a minor bump would
  be appropriate.  Consider that a program with an autoconf test of
  sem_open() will now return a different answer, just as if sem_open()
  was completely new.  no?

 I hear you, but disagree. We fix program disabling bugs in libraries
 frequently without bumping. I have always thought of library
 versioning being more about program integrity, as in all the pieces
 you expect to find are all there, but it doesn't say anything about
 the inner workings of the pieces.

 As theo says, there are other library bumps later, but you're wrong.

 Use-case: new packages, slightly older snapshots. New packages actually
 make use of sem_open, because of said added functionality. Without a bump,
 pkg_add will allow to add them, and they won't work, because the 
 functionality
 wasn't there...

 It is added functionality. It's not a minor bugfix.

I know at least one software piece for which changing the behaviour of
sem_open() changes the behaviour of this software itself -
KSharedDataCache from kdelibs (the one I've talked on EuroBSDCon,
btw). It tries at run-time to call sem_open(foo, 1), and if it fails,
goes other way; and particular execution path affects the on-disk
structures, too! In case of KSharedDataCache it isn't really an issue
(cache could be rebuilt in the worst case), but there could be others
in ports with much worse effects. I mean, behavior change in this case
should be probably accompanied with major lib version bump, so we
could at least differentiate packages.

--
  WBR,
  Vadim Zhukov

Re: CVS: cvs.openbsd.org: src

[Philip Guenther]

On Mon, Nov 18, 2013 at 3:19 PM, Ted Unangst t...@tedunangst.com wrote:
 On Mon, Nov 18, 2013 at 16:10, Ted Unangst wrote:
 CVSROOT:  /cvs
 Module name:  src
 Changes by:   t...@cvs.openbsd.org2013/11/18 16:10:48

 Modified files:
 lib/librthread : rthread.h rthread_sem.c

 Log message:
 interprocess semaphores ala sem_open. mostly following in the pattern
 of shm_open. with some additions and fixes from zhuk.

 btw, no library version change because the function stubs already
 existed.

Hmm, since this is actually offering new functionality (by sem_open()
and friends no longer always failing), I think it a minor bump would
be appropriate.  Consider that a program with an autoconf test of
sem_open() will now return a different answer, just as if sem_open()
was completely new.  no?


Philip Guenther

Re: CVS: cvs.openbsd.org: src

[Theo de Raadt]

 On Mon, Nov 18, 2013 at 3:19 PM, Ted Unangst t...@tedunangst.com wrote:
  On Mon, Nov 18, 2013 at 16:10, Ted Unangst wrote:
  CVSROOT:  /cvs
  Module name:  src
  Changes by:   t...@cvs.openbsd.org2013/11/18 16:10:48
 
  Modified files:
  lib/librthread : rthread.h rthread_sem.c
 
  Log message:
  interprocess semaphores ala sem_open. mostly following in the pattern
  of shm_open. with some additions and fixes from zhuk.
 
  btw, no library version change because the function stubs already
  existed.
 
 Hmm, since this is actually offering new functionality (by sem_open()
 and friends no longer always failing), I think it a minor bump would
 be appropriate.  Consider that a program with an autoconf test of
 sem_open() will now return a different answer, just as if sem_open()
 was completely new.  no?

Well... considering recent library cranks, is that really a concern?

Re: CVS: cvs.openbsd.org: src

[Ted Unangst]

On Mon, Nov 18, 2013 at 18:49, Philip Guenther wrote:

 btw, no library version change because the function stubs already
 existed.
 
 Hmm, since this is actually offering new functionality (by sem_open()
 and friends no longer always failing), I think it a minor bump would
 be appropriate.  Consider that a program with an autoconf test of
 sem_open() will now return a different answer, just as if sem_open()
 was completely new.  no?

I hear you, but disagree. We fix program disabling bugs in libraries
frequently without bumping. I have always thought of library
versioning being more about program integrity, as in all the pieces
you expect to find are all there, but it doesn't say anything about
the inner workings of the pieces.

Re: CVS: cvs.openbsd.org: src

[Marc Espie]

On Tue, Nov 19, 2013 at 12:11:17AM -0500, Ted Unangst wrote:
 On Mon, Nov 18, 2013 at 18:49, Philip Guenther wrote:
 
  btw, no library version change because the function stubs already
  existed.
  
  Hmm, since this is actually offering new functionality (by sem_open()
  and friends no longer always failing), I think it a minor bump would
  be appropriate.  Consider that a program with an autoconf test of
  sem_open() will now return a different answer, just as if sem_open()
  was completely new.  no?
 
 I hear you, but disagree. We fix program disabling bugs in libraries
 frequently without bumping. I have always thought of library
 versioning being more about program integrity, as in all the pieces
 you expect to find are all there, but it doesn't say anything about
 the inner workings of the pieces.

As theo says, there are other library bumps later, but you're wrong.

Use-case: new packages, slightly older snapshots. New packages actually
make use of sem_open, because of said added functionality. Without a bump,
pkg_add will allow to add them, and they won't work, because the functionality
wasn't there...

It is added functionality. It's not a minor bugfix.

Re: CVS: cvs.openbsd.org: src

[Theo de Raadt]

 On Tue, Nov 19, 2013 at 12:11:17AM -0500, Ted Unangst wrote:
  On Mon, Nov 18, 2013 at 18:49, Philip Guenther wrote:
  
   btw, no library version change because the function stubs already
   existed.
   
   Hmm, since this is actually offering new functionality (by sem_open()
   and friends no longer always failing), I think it a minor bump would
   be appropriate.  Consider that a program with an autoconf test of
   sem_open() will now return a different answer, just as if sem_open()
   was completely new.  no?
  
  I hear you, but disagree. We fix program disabling bugs in libraries
  frequently without bumping. I have always thought of library
  versioning being more about program integrity, as in all the pieces
  you expect to find are all there, but it doesn't say anything about
  the inner workings of the pieces.
 
 As theo says, there are other library bumps later, but you're wrong.
 
 Use-case: new packages, slightly older snapshots. New packages actually
 make use of sem_open, because of said added functionality. Without a bump,
 pkg_add will allow to add them, and they won't work, because the functionality
 wasn't there...
 
 It is added functionality. It's not a minor bugfix.

The current window you are arguying about is maybe from Oct 24,
definately Oct 22.  For many pkgs, a few other intermediate bumps
mattered.  A libc crank is coming uhm, rather shortly.

Melodrama.

Re: spamd: greyreader failed (Error 2) (was: Re: CVS: cvs.openbsd.org: src)

[Todd C. Miller]

On Mon, 30 Sep 2013 19:26:20 -0700, Constantine A. Murenin wrote:

 Whereas it remains to be seen what kind of bug I'm facing here 
 (Google reveals I'm not alone), it would appear that changes 
 introduced in 5.4-current would no longer cause spamd to report 
 such situation, because the 0 that would still be returned at the 
 end of greyreader() would no longer cause greywatcher() to produce 
 the error message that I have received (it'll still quit, though).

Yes, that was an unrelated change that snuck in there.  Personally,
I've only seen that error on shutdown, where it is spurious.  If
you are getting a read error on the pipe it must mean that the spamd
on the other end died.

 - todd

Re: spamd: greyreader failed (Error 2) (was: Re: CVS: cvs.openbsd.org: src)

[Constantine A. Murenin]

On 2013-W40-2 16:56 -0600, Todd C. Miller wrote:
 On Mon, 30 Sep 2013 19:26:20 -0700, Constantine A. Murenin wrote:
 
  Whereas it remains to be seen what kind of bug I'm facing here 
  (Google reveals I'm not alone), it would appear that changes 
  introduced in 5.4-current would no longer cause spamd to report 
  such situation, because the 0 that would still be returned at the 
  end of greyreader() would no longer cause greywatcher() to produce 
  the error message that I have received (it'll still quit, though).
 
 Yes, that was an unrelated change that snuck in there.  Personally,
 I've only seen that error on shutdown, where it is spurious.  If
 you are getting a read error on the pipe it must mean that the spamd
 on the other end died.

Yes, I gather that's what it means -- the other end of the pipe is gone.  
However, there were no other messages reported.  In my case, it was 
definitely not a shutdown-related error -- the system was not rebooted 
at that time, nor were any mail-related settings modified or any 
services restarted.

I think it would make sense for this part to be reverted and for the 
error message to be brought back; otherwise, there'd pretty much not 
even be a record of when spamd actually stops working here.

C.

spamd: greyreader failed (Error 2) (was: Re: CVS: cvs.openbsd.org: src)

[Constantine A. Murenin]

Hello,

On OpenBSD 5.2 amd64, my spamd (which is used very selectively through 
pf(4)) seems to have died 20 days ago, after continuously running for 
many months, with the following final words in the logs:

Sep 10 09:49:25 Cns spamd[5220]: 87.225.1.10: connected (1/1), lists: 
spamd-greytrap
Sep 10 09:54:47 Cns spamd[29672]: greyreader failed (Error 2)

There were minor changes to grey.c since 5.2.

Back in 5.2, it would appear that at the end of grey.c#greyreader(), 
after the `grey` pipe is exhausted, greyreader() returns at the end 
of the function, and then grey.c#greywatcher() issues the error 
message, as above, unconditionally after greyreader() returns, 
and also exits.

Whereas it remains to be seen what kind of bug I'm facing here 
(Google reveals I'm not alone), it would appear that changes 
introduced in 5.4-current would no longer cause spamd to report 
such situation, because the 0 that would still be returned at the 
end of greyreader() would no longer cause greywatcher() to produce 
the error message that I have received (it'll still quit, though).

http://www.openbsd.org/cgi-bin/cvsweb/src/libexec/spamd/grey.c.diff?r1=1.52;r2=1.53;f=h
http://www.openbsd.org/cgi-bin/cvsweb/src/libexec/spamd/grey.c.diff?r2=1.53r1=1.52f=u

Basically, the below part of the recent commit seems to modify the 
behaviour that was not advertised to have been modified:


@@ -979,7 +979,7 @@ greyreader(void)
sync = 1;
if (grey == NULL) {
syslog_r(LOG_ERR, sdata, No greylist pipe stream!\n);
-   exit(1);
+   return (-1);
}
 
/* grab trap suffixes */
@@ -1140,10 +1140,11 @@ greywatcher(void)
 */
close(pfdev);
setproctitle((%s update), PATH_SPAMD_DB);
-   greyreader();
-   syslog_r(LOG_ERR, sdata, greyreader failed (%m));
-   /* NOTREACHED */
-   _exit(1);
+   if (greyreader() == -1) {
+   syslog_r(LOG_ERR, sdata, greyreader failed (%m));
+   _exit(1);
+   }
+   _exit(0);
}
 
 

http://bxr.su/o/libexec/spamd/grey.c#greywatcher

Is it indeed intentional that greyreader failed (Error 2) will be 
produced no more as a result of the above change?

Any ideas what caused greyreader to fail on my OpenBSD 5.2 in the first place?

Cheers,
Constantine.


On 2013-W34-3 10:13 -0600, Todd C. Miller wrote:
 CVSROOT:  /cvs
 Module name:  src
 Changes by:   mill...@cvs.openbsd.org 2013/08/21 10:13:30

 Modified files:
   usr.sbin/spamdb: Makefile spamdb.c 
   libexec/spamd  : Makefile grey.c grey.h 
   libexec/spamlogd: Makefile spamlogd.c 
 Added files:
   libexec/spamd  : gdcopy.c 

 Log message:
 Remove the use of time_t in the greylist db file and use int64_t instead
 with backwards compatibility for records with 32-bit times.
 OK deraadt@ beck@

Re: CVS: cvs.openbsd.org: src

[Scott McEachern]

On 06/07/13 16:46, Mark Kettenis wrote:

CVSROOT:/cvs
Module name:src
Changes by: kette...@cvs.openbsd.org2013/06/07 14:46:15

Modified files:
sys/uvm: uvm_device.c uvm_device.h
sys/dev/pci/drm: drm.h drmP.h drm_drv.c
sys/dev/pci/drm/i915: i915_gem.c

Log message:
Add proper mmap(2) support for drm(4)/inteldrm(4).  This changes the
DRM_I915_GEM_MMAP and DRM_I915_GEM_MMAP_GTT ioctls to be compatible with
Linux.  This also is the first step that moves us away from accessing all
graphics memory through the GTT, which should make things faster.

ok tedu@ (for the uvm bits)



I just built a new kernel using -current sources, including this change, 
in preparation to build the system.  It didn't work out very well and I 
had to revert to obsd.


The kernel boot display looks normal, going from 25-40 rows properly, 
however, once X starts the puffy OpenBSD 5.3 logo is garbled beyond 
recognition.  The surrounding text of the hostname and name/password 
stuff looks fine.  After logging in and spectrwm starts, the display is 
completely distorted and unusable.


Just thought I'd let you know.  dmesg from the previous (working) kernel:

OpenBSD 5.3-current (GENERIC.MP) #1: Wed Jun  5 05:06:14 EDT 2013
r...@elminster.blackstaff.ca:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 16835637248 (16055MB)
avail mem = 16379756544 (15620MB)
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xeb410 (112 entries)
bios0: vendor American Megatrends Inc. version 0408 date 06/05/2012
bios0: ASUSTeK COMPUTER INC. P8Z77-V PREMIUM
acpi0 at bios0: rev 2
acpi0: sleep states S0 S1 S3 S4 S5
acpi0: tables DSDT FACP APIC FPDT MCFG HPET SSDT SSDT SSDT BGRT
acpi0: wakeup devices PS2K(S4) PS2M(S4) P0P1(S4) PXSX(S4) RP01(S4) 
PXSX(S4) RP02(S4) PXSX(S4) RP03(S4) PXSX(S4) RP04(S4) PXSX(S4) RP05(S4) 
PXSX(S4) RP06(S4) PXSX(S4) [...]

acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Core(TM) i7-3770K CPU @ 3.50GHz, 3606.22 MHz
cpu0: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS

cpu0: 256KB 64b/line 8-way L2 cache
cpu0: smt 0, core 0, package 0
cpu0: apic clock running at 103MHz
cpu1 at mainbus0: apid 2 (application processor)
cpu1: Intel(R) Core(TM) i7-3770K CPU @ 3.50GHz, 3605.67 MHz
cpu1: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS

cpu1: 256KB 64b/line 8-way L2 cache
cpu1: smt 0, core 1, package 0
cpu2 at mainbus0: apid 4 (application processor)
cpu2: Intel(R) Core(TM) i7-3770K CPU @ 3.50GHz, 3605.67 MHz
cpu2: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS

cpu2: 256KB 64b/line 8-way L2 cache
cpu2: smt 0, core 2, package 0
cpu3 at mainbus0: apid 6 (application processor)
cpu3: Intel(R) Core(TM) i7-3770K CPU @ 3.50GHz, 3605.67 MHz
cpu3: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS

cpu3: 256KB 64b/line 8-way L2 cache
cpu3: smt 0, core 3, package 0
cpu4 at mainbus0: apid 1 (application processor)
cpu4: Intel(R) Core(TM) i7-3770K CPU @ 3.50GHz, 3605.67 MHz
cpu4: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS

cpu4: 256KB 64b/line 8-way L2 cache
cpu4: smt 1, core 0, package 0
cpu5 at mainbus0: apid 3 (application processor)
cpu5: Intel(R) Core(TM) i7-3770K CPU @ 3.50GHz, 3605.67 MHz
cpu5: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS

cpu5: 256KB 64b/line 8-way L2 cache
cpu5: smt 1, core 1, package 0
cpu6 at mainbus0: apid 5 (application processor)
cpu6: Intel(R) Core(TM) i7-3770K CPU @ 3.50GHz, 3605.67 MHz
cpu6: 

Re: CVS: cvs.openbsd.org: src

[Ville Valkonen]

Hi, did you compile the recent Xenocara too?
On Jun 8, 2013 9:30 AM, Scott McEachern sc...@blackstaff.ca wrote:

 On 06/07/13 16:46, Mark Kettenis wrote:

 CVSROOT:/cvs
 Module name:src
 Changes by: kette...@cvs.openbsd.org2013/06/07 14:46:15

 Modified files:
 sys/uvm: uvm_device.c uvm_device.h
 sys/dev/pci/drm: drm.h drmP.h drm_drv.c
 sys/dev/pci/drm/i915: i915_gem.c

 Log message:
 Add proper mmap(2) support for drm(4)/inteldrm(4).  This changes the
 DRM_I915_GEM_MMAP and DRM_I915_GEM_MMAP_GTT ioctls to be compatible with
 Linux.  This also is the first step that moves us away from accessing all
 graphics memory through the GTT, which should make things faster.

 ok tedu@ (for the uvm bits)


 I just built a new kernel using -current sources, including this change,
 in preparation to build the system.  It didn't work out very well and I had
 to revert to obsd.

 The kernel boot display looks normal, going from 25-40 rows properly,
 however, once X starts the puffy OpenBSD 5.3 logo is garbled beyond
 recognition.  The surrounding text of the hostname and name/password stuff
 looks fine.  After logging in and spectrwm starts, the display is
 completely distorted and unusable.

 Just thought I'd let you know.  dmesg from the previous (working) kernel:

 OpenBSD 5.3-current (GENERIC.MP) #1: Wed Jun  5 05:06:14 EDT 2013
 r...@elminster.blackstaff.ca:/**usr/src/sys/arch/amd64/**compile/
 GENERIC.MP
 real mem = 16835637248 (16055MB)
 avail mem = 16379756544 (15620MB)
 mainbus0 at root
 bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xeb410 (112 entries)
 bios0: vendor American Megatrends Inc. version 0408 date 06/05/2012
 bios0: ASUSTeK COMPUTER INC. P8Z77-V PREMIUM
 acpi0 at bios0: rev 2
 acpi0: sleep states S0 S1 S3 S4 S5
 acpi0: tables DSDT FACP APIC FPDT MCFG HPET SSDT SSDT SSDT BGRT
 acpi0: wakeup devices PS2K(S4) PS2M(S4) P0P1(S4) PXSX(S4) RP01(S4)
 PXSX(S4) RP02(S4) PXSX(S4) RP03(S4) PXSX(S4) RP04(S4) PXSX(S4) RP05(S4)
 PXSX(S4) RP06(S4) PXSX(S4) [...]
 acpitimer0 at acpi0: 3579545 Hz, 24 bits
 acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
 cpu0 at mainbus0: apid 0 (boot processor)
 cpu0: Intel(R) Core(TM) i7-3770K CPU @ 3.50GHz, 3606.22 MHz
 cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,**MCE,CX8,APIC,SEP,MTRR,PGE,MCA,**
 CMOV,PAT,PSE36,CFLUSH,DS,ACPI,**MMX,FXSR,SSE,SSE2,SS,HTT,TM,**
 PBE,SSE3,PCLMUL,DTES64,MWAIT,**DS-CPL,VMX,EST,TM2,SSSE3,CX16,**
 xTPR,PDCM,PCID,SSE4.1,SSE4.2,**POPCNT,DEADLINE,AES,XSAVE,AVX,**
 F16C,RDRAND,NXE,LONG,LAHF,**PERF,ITSC,FSGSBASE,SMEP,ERMS
 cpu0: 256KB 64b/line 8-way L2 cache
 cpu0: smt 0, core 0, package 0
 cpu0: apic clock running at 103MHz
 cpu1 at mainbus0: apid 2 (application processor)
 cpu1: Intel(R) Core(TM) i7-3770K CPU @ 3.50GHz, 3605.67 MHz
 cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,**MCE,CX8,APIC,SEP,MTRR,PGE,MCA,**
 CMOV,PAT,PSE36,CFLUSH,DS,ACPI,**MMX,FXSR,SSE,SSE2,SS,HTT,TM,**
 PBE,SSE3,PCLMUL,DTES64,MWAIT,**DS-CPL,VMX,EST,TM2,SSSE3,CX16,**
 xTPR,PDCM,PCID,SSE4.1,SSE4.2,**POPCNT,DEADLINE,AES,XSAVE,AVX,**
 F16C,RDRAND,NXE,LONG,LAHF,**PERF,ITSC,FSGSBASE,SMEP,ERMS
 cpu1: 256KB 64b/line 8-way L2 cache
 cpu1: smt 0, core 1, package 0
 cpu2 at mainbus0: apid 4 (application processor)
 cpu2: Intel(R) Core(TM) i7-3770K CPU @ 3.50GHz, 3605.67 MHz
 cpu2: FPU,VME,DE,PSE,TSC,MSR,PAE,**MCE,CX8,APIC,SEP,MTRR,PGE,MCA,**
 CMOV,PAT,PSE36,CFLUSH,DS,ACPI,**MMX,FXSR,SSE,SSE2,SS,HTT,TM,**
 PBE,SSE3,PCLMUL,DTES64,MWAIT,**DS-CPL,VMX,EST,TM2,SSSE3,CX16,**
 xTPR,PDCM,PCID,SSE4.1,SSE4.2,**POPCNT,DEADLINE,AES,XSAVE,AVX,**
 F16C,RDRAND,NXE,LONG,LAHF,**PERF,ITSC,FSGSBASE,SMEP,ERMS
 cpu2: 256KB 64b/line 8-way L2 cache
 cpu2: smt 0, core 2, package 0
 cpu3 at mainbus0: apid 6 (application processor)
 cpu3: Intel(R) Core(TM) i7-3770K CPU @ 3.50GHz, 3605.67 MHz
 cpu3: FPU,VME,DE,PSE,TSC,MSR,PAE,**MCE,CX8,APIC,SEP,MTRR,PGE,MCA,**
 CMOV,PAT,PSE36,CFLUSH,DS,ACPI,**MMX,FXSR,SSE,SSE2,SS,HTT,TM,**
 PBE,SSE3,PCLMUL,DTES64,MWAIT,**DS-CPL,VMX,EST,TM2,SSSE3,CX16,**
 xTPR,PDCM,PCID,SSE4.1,SSE4.2,**POPCNT,DEADLINE,AES,XSAVE,AVX,**
 F16C,RDRAND,NXE,LONG,LAHF,**PERF,ITSC,FSGSBASE,SMEP,ERMS
 cpu3: 256KB 64b/line 8-way L2 cache
 cpu3: smt 0, core 3, package 0
 cpu4 at mainbus0: apid 1 (application processor)
 cpu4: Intel(R) Core(TM) i7-3770K CPU @ 3.50GHz, 3605.67 MHz
 cpu4: FPU,VME,DE,PSE,TSC,MSR,PAE,**MCE,CX8,APIC,SEP,MTRR,PGE,MCA,**
 CMOV,PAT,PSE36,CFLUSH,DS,ACPI,**MMX,FXSR,SSE,SSE2,SS,HTT,TM,**
 PBE,SSE3,PCLMUL,DTES64,MWAIT,**DS-CPL,VMX,EST,TM2,SSSE3,CX16,**
 xTPR,PDCM,PCID,SSE4.1,SSE4.2,**POPCNT,DEADLINE,AES,XSAVE,AVX,**
 F16C,RDRAND,NXE,LONG,LAHF,**PERF,ITSC,FSGSBASE,SMEP,ERMS
 cpu4: 256KB 64b/line 8-way L2 cache
 cpu4: smt 1, core 0, package 0
 cpu5 at mainbus0: apid 3 (application processor)
 cpu5: Intel(R) Core(TM) i7-3770K CPU @ 3.50GHz, 3605.67 MHz
 cpu5: FPU,VME,DE,PSE,TSC,MSR,PAE,**MCE,CX8,APIC,SEP,MTRR,PGE,MCA,**
 CMOV,PAT,PSE36,CFLUSH,DS,ACPI,**MMX,FXSR,SSE,SSE2,SS,HTT,TM,**
 PBE,SSE3,PCLMUL,DTES64,MWAIT,**DS-CPL,VMX,EST,TM2,SSSE3,CX16,**
 

Re: CVS: cvs.openbsd.org: src

[Scott McEachern]

On 06/08/13 02:38, Ville Valkonen wrote:

Hi, did you compile the recent Xenocara too?


No, I didn't get that far.  Just the kernel.  That's how I know it 
wasn't the recent xenocara updates that caused the problem and believe 
this specific commit is the culprit.


However, you did get me thinking...

I'll skip using X and go console-only, build the new xenocara and see if 
the problem goes away.  I'll bet that kernel commit requires the new X.  
I'll post the results in a bit.


--
Scott McEachern

https://www.blackstaff.ca

Those who would give up essential liberty to purchase a little temporary safety 
deserve neither liberty nor safety. -- Benjamin Franklin

Re: CVS: cvs.openbsd.org: src

[Jonathan Gray]

On Sat, Jun 08, 2013 at 03:06:26AM -0400, Scott McEachern wrote:
 On 06/08/13 02:38, Ville Valkonen wrote:
 Hi, did you compile the recent Xenocara too?
 
 No, I didn't get that far.  Just the kernel.  That's how I know it
 wasn't the recent xenocara updates that caused the problem and
 believe this specific commit is the culprit.
 
 However, you did get me thinking...
 
 I'll skip using X and go console-only, build the new xenocara and
 see if the problem goes away.  I'll bet that kernel commit requires
 the new X.  I'll post the results in a bit.

You'll need to build at least libdrm as mentioned here:
http://www.openbsd.org/faq/current.html#20130607b

The X builds in the snapshots aren't updated as often
as the rest of the sets so it may take some time for
snapshots to catch up.

Re: CVS: cvs.openbsd.org: src

[Scott McEachern]

On 06/08/13 03:14, Jonathan Gray wrote:

On Sat, Jun 08, 2013 at 03:06:26AM -0400, Scott McEachern wrote:

On 06/08/13 02:38, Ville Valkonen wrote:

Hi, did you compile the recent Xenocara too?

No, I didn't get that far.  Just the kernel.  That's how I know it
wasn't the recent xenocara updates that caused the problem and
believe this specific commit is the culprit.

However, you did get me thinking...

I'll skip using X and go console-only, build the new xenocara and
see if the problem goes away.  I'll bet that kernel commit requires
the new X.  I'll post the results in a bit.

You'll need to build at least libdrm as mentioned here:
http://www.openbsd.org/faq/current.html#20130607b

The X builds in the snapshots aren't updated as often
as the rest of the sets so it may take some time for
snapshots to catch up.



Yep, just read following current and did a facepalm.  I'm building a 
new system now.  I'm sure everything will be fine.


Sorry for the noise...

--
Scott McEachern

https://www.blackstaff.ca

Those who would give up essential liberty to purchase a little temporary safety 
deserve neither liberty nor safety. -- Benjamin Franklin

Re: CVS: cvs.openbsd.org: src

[Philip Guenther]

On Sun, Aug 12, 2012 at 10:14 AM, Miod Vallat m...@cvs.openbsd.org
wrote in a commit message:
...
 Passes the regress tests, and now devel/libsigsegv configure siglongjmp test
 will not spin (this test is however flawed as it expects a signal handler
 declared as running on the sigaltstack and `returning' through siglongjmp to
 be invoked on the signal stack the next time the signal is raised).

I think that's a bug in our handling of the SS_ONSTACK flag.  Right
now, we set that flag when switching to the stack while calling a
signal handler marked for alt-stack handling and *only* clear it in
sigreturn() of the sigcontext from when it first went onto the stack.
The means that if a thread longjumps off the alt-stack, it has no way
to ever clear the flag and utilize the alt-stack again.

FreeBSD and NetBSD switched at some point to the SS_ONSTACK flag being
dynamically determined from the thread's current stack pointer, which
makes the handling of the alt-stack more flexible without creating any
contradictions.  We should pull that change over, IMO.


Philip Guenther

Re: CVS: cvs.openbsd.org: src

[Gilles Chehade]

On Tue, Mar 13, 2012 at 05:07:58PM -0600, Gilles Chehade wrote:
 CVSROOT:  /cvs
 Module name:  src
 Changes by:   gil...@cvs.openbsd.org  2012/03/13 17:07:58
 
 Modified files:
   usr.sbin/smtpd : scheduler_ramqueue.c 
 
 Log message:
 When moving back envelope from offload tree to msg tree ... remove the
 envelope from offload tree not msg tree, this corrupts the ramqueue in
 ways that I couldn't imagine before wasting so many hours tracking it.
 
 Fixes crash on my server under load, no crash after about 20K mails
 processed from up to 150 concurrent sessions.
 

Now would be an interesting time to start testing seriously OpenSMTPD.

We know it still lacks features but it should provide what's needed for
the base system and should be reliable. Just test and you will see if
your needs are met or not.

Please report all bugs, crashes and features missing to gilles@, eric@
and chl@; we will focus on bugs and crashes at first but will keep
track of the feature requests.


-- 
Gilles Chehade

https://www.poolp.org   @poolpOrg

Re: CVS: cvs.openbsd.org: src

[Gilles Chehade]

On Wed, Aug 31, 2011 at 12:56:30PM -0600, Gilles Chehade wrote:
 
 Log message:
 add support for per-line DATA callbacks, this allows filters to take their
 decisions *while* the message is being received by the client.
 

Until filters are enabled, this should not impact anyone ... however it is in
the execution path of *all* incoming messages (both network and enqueue).

It's been tested for days and should work just fine for everyone.

If you run into an issue, please let me know *asap* before I stack more code
on top of it ;-)

-- 
Gilles Chehade

http://www.poolp.org/http://u.poolp.org/~gilles/

Re: CVS: cvs.openbsd.org: src

[David Gwynne]

seems to work fine on my big box.

On 29/11/2010, at 5:43 PM, Philip Guenther wrote:

 On Sun, 28 Nov 2010, Philip Guenther wrote:
 On Sun, 28 Nov 2010, Philip Guenther wrote:
 On Sunday, November 28, 2010, David Gwynne d...@cvs.openbsd.org wrote:
 ...
 Log message:
 bump the number of supported cpus from 32 up to 64. lets me attach and
use
 all 48 cores in one of my boxes.

 requested by deraadt@
 made possible by the recent pmap diff by kettenis@

 Doesn't pm_cpus in the pmap need to change to a u_int64_t and locore.S
 and pmap.c (at least) change to match?

 Here's a diff to do that.

 It also corrects the x86_atomic_*_{l,ul}() macros to actually expand to
 the functions that operate on longs instead of ints (64- and 32-bits,
 respectively) and removes the unused x86_multicast_ipi() function.
 Finally, tlb_shoot_wait has been operated on with 32bit atomic ops, so
 make it an (unsigned) int instead of a long.  (This would have never
 worked on a big-endian platform.)

 Compile tested only so far (about to get on plane).

 Revised diff that doesn't include my bogus flailing on x86_atomic_cas_ul()
 (which does operate on unsigned longs) or tlb_shoot_wait.

 I'm running this now on my lowly little 4 core amd64.

 Philip Guenther


 diff -ru t/amd64/intr.c ./amd64/intr.c
 --- t/amd64/intr.cSun Nov 28 20:27:17 2010
 +++ ./amd64/intr.cSun Nov 28 18:48:08 2010
 @@ -498,7 +498,7 @@

   simple_lock(ci-ci_slock);
   pic-pic_hwmask(pic, ih-ih_pin);
 - x86_atomic_clearbits_l(ci-ci_ipending, (1  ih-ih_slot));
 + x86_atomic_clearbits_u32(ci-ci_ipending, (1  ih-ih_slot));

   /*
* Remove the handler from the chain.
 diff -ru t/amd64/ipi.c ./amd64/ipi.c
 --- t/amd64/ipi.c Sun Nov 28 20:27:17 2010
 +++ ./amd64/ipi.c Sun Nov 28 18:48:46 2010
 @@ -50,7 +50,7 @@
 {
   int ret;

 - x86_atomic_setbits_l(ci-ci_ipis, ipimask);
 + x86_atomic_setbits_u32(ci-ci_ipis, ipimask);

   /* Don't send IPI to cpu which isn't (yet) running. */
   if (!(ci-ci_flags  CPUF_RUNNING))
 @@ -88,7 +88,7 @@
   continue;
   if ((ci-ci_flags  CPUF_RUNNING) == 0)
   continue;
 - x86_atomic_setbits_l(ci-ci_ipis, ipimask);
 + x86_atomic_setbits_u32(ci-ci_ipis, ipimask);
   count++;
   }
   if (!count)
 @@ -98,23 +98,6 @@
 }

 void
 -x86_multicast_ipi(int cpumask, int ipimask)
 -{
 - struct cpu_info *ci;
 - CPU_INFO_ITERATOR cii;
 -
 - cpumask = ~(1U  cpu_number());
 - if (cpumask == 0)
 - return;
 -
 - CPU_INFO_FOREACH(cii, ci) {
 - if ((cpumask  (1U  ci-ci_cpuid)) == 0)
 - continue;
 - x86_send_ipi(ci, ipimask);
 - }
 -}
 -
 -void
 x86_ipi_handler(void)
 {
   extern struct evcount ipi_count;
 @@ -122,7 +105,7 @@
   u_int32_t pending;
   int bit;

 - pending = x86_atomic_testset_ul(ci-ci_ipis, 0);
 + pending = x86_atomic_testset_u32(ci-ci_ipis, 0);

   for (bit = 0; bit  X86_NIPI  pending; bit++) {
   if (pending  (1bit)) {
 diff -ru t/amd64/locore.S ./amd64/locore.S
 --- t/amd64/locore.S  Sun Nov 28 20:27:17 2010
 +++ ./amd64/locore.S  Sun Nov 28 19:00:57 2010
 @@ -762,7 +762,7 @@
   /* clear the old pmap's bit for the cpu */
   movqPCB_PMAP(%r13),%rcx
   lock
 - btrl%edi,PM_CPUS(%rcx)
 + btrq%rdi,PM_CPUS(%rcx)

   /* Save stack pointers. */
   movq%rsp,PCB_RSP(%r13)
 @@ -800,9 +800,11 @@
   /* set the new pmap's bit for the cpu */
   movlCPUVAR(CPUID),%edi
   movqPCB_PMAP(%r13),%rcx
 - movlPM_CPUS(%rcx),%eax
 +#ifdef DIAGNOSTIC
 + movqPM_CPUS(%rcx),%rax
 +#endif
   lock
 - btsl%edi,PM_CPUS(%rcx)
 + btsq%rdi,PM_CPUS(%rcx)
 #ifdef DIAGNOSTIC
   jc  _C_LABEL(switch_pmcpu_set)
 #endif
 diff -ru t/amd64/pmap.c ./amd64/pmap.c
 --- t/amd64/pmap.cSun Nov 28 20:36:05 2010
 +++ ./amd64/pmap.cSun Nov 28 20:32:48 2010
 @@ -351,7 +351,7 @@
 pmap_is_active(struct pmap *pmap, int cpu_id)
 {
   return (pmap == pmap_kernel() ||
 - (pmap-pm_cpus  (1U  cpu_id)) != 0);
 + (pmap-pm_cpus  (1ULL  cpu_id)) != 0);
 }

 static __inline u_int
 @@ -1064,7 +1064,7 @@

 #ifdef DIAGNOSTIC
   if (pmap-pm_cpus != 0)
 - printf(pmap_destroy: pmap %p cpus=0x%lx\n,
 + printf(pmap_destroy: pmap %p cpus=0x%llx\n,
   (void *)pmap, pmap-pm_cpus);
 #endif

 @@ -1127,7 +1127,7 @@
   /*
* mark the pmap in use by this processor.
*/
 - x86_atomic_setbits_ul(pmap-pm_cpus, (1U  cpu_number()));
 + x86_atomic_setbits_u64(pmap-pm_cpus, (1ULL  cpu_number()));
   }
 }

 @@ -1143,7 +1143,7 @@
   /*
* mark the pmap no longer in use by this processor.
*/
 - x86_atomic_clearbits_ul(pmap-pm_cpus, (1U  cpu_number()));
 + x86_atomic_clearbits_u64(pmap-pm_cpus,