sshd_config(5) : mention CIDR addressing for AllowUsers and DenyUsers

[Lars Noodén]

It looks like sshd(8) has permitted for a while both AllowUsers and
DenyUsers in sshd_config(5) to use addresses in CIDR address/masklen
format.  If so, it would be useful to mention in the manual page.

/Lars

Index: sshd_config.5
===
RCS file: /cvs/src/usr.bin/ssh/sshd_config.5,v
retrieving revision 1.220
diff -u -p -u -p -r1.220 sshd_config.5
--- sshd_config.5   17 Feb 2016 08:57:34 -  1.220
+++ sshd_config.5   13 Mar 2016 07:10:27 -
@@ -173,6 +173,8 @@ By default, login is allowed for all use
 If the pattern takes the form USER@HOST then USER and HOST
 are separately checked, restricting logins to particular
 users from particular hosts.
+HOST criteria may additionally contain addresses to match in CIDR
+address/masklen format.
 The allow/deny directives are processed in the following order:
 .Cm DenyUsers ,
 .Cm AllowUsers ,
@@ -561,6 +563,8 @@ By default, login is allowed for all use
 If the pattern takes the form USER@HOST then USER and HOST
 are separately checked, restricting logins to particular
 users from particular hosts.
+HOST criteria may additionally contain addresses to match in CIDR
+address/masklen format.
 The allow/deny directives are processed in the following order:
 .Cm DenyUsers ,
 .Cm AllowUsers ,

Re: New scheduler for OpenBSD

[Juan Francisco Cantero Hurtado]

On Sat, Mar 12, 2016 at 08:35:31PM +0100, Juan Francisco Cantero Hurtado wrote:
> On Sat, Mar 12, 2016 at 05:36:21PM +0100, Michal Mazurek wrote:
> > Gregor Best attempted to improve the scheduler in 2011:
> > http://comments.gmane.org/gmane.os.openbsd.tech/27059
> > Here is another attempt, it takes up where the previous one left off.
> > 
> > This is also mostly based on the main idea behind Linux CFS or
> > BFS. I found BFS to be described more clearly:
> > http://ck.kolivas.org/patches/bfs/4.0/4.3/4.3-sched-bfs-467.patch
> > 
> > 
> > Some notes:
> > 
> > Chrome is still not very usable.
> 
> Chrome is not the best benchmark for the scheduler ATM.
> 
> Until the work in malloc to enhance the support for multithreaded
> programs is finished, forget Chrome and Firefox.
> 
> > 
> > Much more work is needed, e.g. there is some MD code on sparc64 and
> > alpha that depends on spc_schedticks that needs to be understood and
> > rewritten.
> > 
> > Maybe using RB trees to queue what is usually no more than 5 elements
> > is overkill.
> > 
> > p_usrpri and p_priority will go away, so userland utilities like 'ps'
> > will need to be changed.
> > 
> > I also want to try and see if implementing one shared queue, instead of
> > keeping one queue per cpu will improve performance even further. Right
> > now there are some heuristics to determine whether a process should
> > switch cpus. This doesn't work very well yet, in my tests with the
> > attached code sometimes one queue was a second behind another. From
> > what I understand that's the idea behind BFS and the reason why it
> > doesn't scale to 4096 CPUs. I see that OpenBSD supports 256 CPUs on
> > sparc64:
> > ./arch/sparc64/include/cpu.h:#define MAXCPUS256
> > 
> > Nice is not yet supported, but it's easy to add (uncomment and modify
> > 'offset' in sched_deadline(). I didn't want to add it yet to test just
> > how fair this method is. Currently all processes are equal.
> > 
> > Other operating systems provide a couple of different schedulers to
> > choose from, this diff overwrites the 4bsd scheduler with the new code
> > and leaves no choice.
> > 
> > With the new code I got some visible improvements when compiling the
> > kernel:
> > old: 1m46.74s real 5m08.48s user 1m27.37s system
> > old: 1m46.61s real 5m06.93s user 1m28.13s system
> > old: 1m49.91s real 5m19.71s user 1m28.25s system
> > new: 1m38.05s real 5m12.16s user 0m55.86s system
> > new: 1m38.70s real 5m12.36s user 0m57.82s system
> > new: 1m39.10s real 5m16.06s user 0m56.91s system
> 
> That is going to make happy to people running bulk builds :)
> 
> > 
> > I would be interested in hearing if the new code broke something for
> > anyone.
> > 
> > Is there a chance for a scheduler rewrite like this to be commited?

>From time to time, I run a batch video conversion. I tried the same
commands with and without your patch. Your patch is slowing down the
frames-per-second about 30%.

Here are the commands:
$ download some 20-30 minutes videos in mp4 format (youtube is fine for
this)
$ install the packages ffmpeg and libx264
$ mkdir output
$ for i in *.mp4; do ffmpeg -y -i "$i" -vf 'scale=320:-1' -map 0:v:0 -map 0:a:0 
-sws_flags spline -map_metadata -1 -c:v libx264 -profile:v baseline -b:v 360k 
-c:a aac -strict -2 -ar 44100 -ac 2 -b:a 128k -movflags faststart "output/$i"; 
done



-- 
Juan Francisco Cantero Hurtado http://juanfra.info

adventure patch

[Edgar Pettijohn]

Tried to start this project last week, but kept f'ing it up.

Index: src/games/adventure/crc.c
===
RCS file: /cvs/src/games/adventure/crc.c,v
retrieving revision 1.7
diff -u -p -u -r1.7 crc.c
--- src/games/adventure/crc.c27 Oct 2009 23:59:23 -1.7
+++ src/games/adventure/crc.c13 Mar 2016 02:36:23 -
@@ -33,6 +33,8 @@
  * SUCH DAMAGE.
  */

+#include 
+
 #include "extern.h"

 unsigned long crctab[] = {
Index: src/games/adventure/done.c
===
RCS file: /cvs/src/games/adventure/done.c,v
retrieving revision 1.8
diff -u -p -u -r1.8 done.c
--- src/games/adventure/done.c27 Oct 2009 23:59:23 -1.8
+++ src/games/adventure/done.c13 Mar 2016 02:38:24 -
@@ -37,8 +37,10 @@

 /*Re-coding of advent in C: termination routines*/

+#include 
 #include 
 #include 
+
 #include "hdr.h"
 #include "extern.h"

Index: src/games/adventure/init.c
===
RCS file: /cvs/src/games/adventure/init.c,v
retrieving revision 1.14
diff -u -p -u -r1.14 init.c
--- src/games/adventure/init.c3 Jan 2016 14:38:16 -1.14
+++ src/games/adventure/init.c13 Mar 2016 02:48:52 -
@@ -38,6 +38,7 @@
 /*Re-coding of advent in C: data initialization*/

 #include 
+
 #include 
 #include 
 #include 
Index: src/games/adventure/io.c
===
RCS file: /cvs/src/games/adventure/io.c,v
retrieving revision 1.20
diff -u -p -u -r1.20 io.c
--- src/games/adventure/io.c22 Aug 2015 14:47:40 -1.20
+++ src/games/adventure/io.c13 Mar 2016 02:49:03 -
@@ -38,9 +38,11 @@
 /*Re-coding of advent in C: file i/o and user i/o*/

 #include 
+#include 
 #include 
 #include 
 #include 
+
 #include "hdr.h"
 #include "extern.h"

Index: src/games/adventure/main.c
===
RCS file: /cvs/src/games/adventure/main.c,v
retrieving revision 1.22
diff -u -p -u -r1.22 main.c
--- src/games/adventure/main.c7 Jan 2016 16:00:31 -1.22
+++ src/games/adventure/main.c13 Mar 2016 02:49:17 -
@@ -41,7 +41,9 @@
 #include 
 #include 
 #include 
+#include 
 #include 
+
 #include "hdr.h"
 #include "extern.h"

Index: src/games/adventure/save.c
===
RCS file: /cvs/src/games/adventure/save.c,v
retrieving revision 1.10
diff -u -p -u -r1.10 save.c
--- src/games/adventure/save.c8 Dec 2014 21:56:27 -1.10
+++ src/games/adventure/save.c13 Mar 2016 02:49:25 -
@@ -35,8 +35,10 @@
  * SUCH DAMAGE.
  */

+#include 
 #include 
 #include 
+
 #include "hdr.h"
 #include "extern.h"

Index: src/games/adventure/subr.c
===
RCS file: /cvs/src/games/adventure/subr.c,v
retrieving revision 1.10
diff -u -p -u -r1.10 subr.c
--- src/games/adventure/subr.c27 Oct 2009 23:59:23 -1.10
+++ src/games/adventure/subr.c13 Mar 2016 02:50:28 -
@@ -37,8 +37,11 @@

 /*Re-coding of advent in C: subroutines from main*/

+#include 
 #include 
 #include 
+#include 
+
 #include "hdr.h"
 #include "extern.h"

Index: src/games/adventure/vocab.c
===
RCS file: /cvs/src/games/adventure/vocab.c,v
retrieving revision 1.14
diff -u -p -u -r1.14 vocab.c
--- src/games/adventure/vocab.c13 Jul 2014 19:40:57 -  1.14
+++ src/games/adventure/vocab.c13 Mar 2016 02:50:36 -
@@ -38,8 +38,11 @@
 /*Re-coding of advent in C: data structure routines*/

 #include 
+#include 
 #include 
 #include 
+#include 
+
 #include "hdr.h"
 #include "extern.h"

Index: src/games/adventure/wizard.c
===
RCS file: /cvs/src/games/adventure/wizard.c,v
retrieving revision 1.18
diff -u -p -u -r1.18 wizard.c
--- src/games/adventure/wizard.c3 Jan 2016 14:38:16 -  1.18
+++ src/games/adventure/wizard.c13 Mar 2016 02:50:44 -
@@ -38,6 +38,7 @@
 /*Re-coding of advent in C: privileged operations*/

 #include 
+#include 
 #include 
 #include 
 #include 
Index: src/games/adventure/extern.h
===
RCS file: /cvs/src/games/adventure/extern.h,v
retrieving revision 1.9
diff -u -p -u -r1.9 extern.h
--- src/games/adventure/extern.h1 Jan 2016 15:56:04 -1.9
+++ src/games/adventure/extern.h13 Mar 2016 02:34:17 -
@@ -30,9 +30,6 @@
  * THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
  */

-#include 
-#include 
-
 /* crc.c */
 void crc_start(void);
 unsigned long crc(const char *, int);
Index: src/games/adventure/hdr.h
===
RCS file: /cvs/src/games/adventure/hdr.h,v
retrieving 

Re: Remove lint(1) reference from gcc-local(1)

[Philip Guenther]

On Sat, Mar 12, 2016 at 2:59 PM, Michael McConville  wrote:
> As jmc@ asked when I shared this with him, is there a remaining use of
> our custom gcc -CC flag now that lint(1) is gone? It seems like it could
> be useful for general macro debugging, but I'm not sure. Even if not,
> removing it might be more effort than it's worth.
>
> I'm interested to hear what people think about that. Either way, ok for
> removing the lint(1) reference?

kill it.
ok guenther@

Remove lint(1) reference from gcc-local(1)

[Michael McConville]

As jmc@ asked when I shared this with him, is there a remaining use of
our custom gcc -CC flag now that lint(1) is gone? It seems like it could
be useful for general macro debugging, but I'm not sure. Even if not,
removing it might be more effort than it's worth.

I'm interested to hear what people think about that. Either way, ok for
removing the lint(1) reference?


Index: share/man/man1/gcc-local.1
===
RCS file: /cvs/src/share/man/man1/gcc-local.1,v
retrieving revision 1.47
diff -u -p -r1.47 gcc-local.1
--- share/man/man1/gcc-local.1  23 Dec 2015 08:42:42 -  1.47
+++ share/man/man1/gcc-local.1  12 Mar 2016 22:54:50 -
@@ -237,8 +237,6 @@ recognizes the preprocessor flag
 that lets comments in macros pass through to the output (except in
 .Fl traditional
 mode).
-This is used to allow annotations in macros for
-lint.
 .It
 The warning option
 .Fl Wsystem-headers ,

Fix examples for EVP_PKEY_CTX_set_rsa_padding

[Brent Cook]

Noted here, https://github.com/libressl-portable/portable/issues/161, we
document a non-existent constant in the examples
for EVP_PKEY_CTX_set_rsa_padding. Is this the correct one to use?

Index: EVP_PKEY_decrypt.pod
===
RCS file: /cvs/src/lib/libssl/src/doc/crypto/EVP_PKEY_decrypt.pod,v
retrieving revision 1.3
diff -u -p -u -p -r1.3 EVP_PKEY_decrypt.pod
--- EVP_PKEY_decrypt.pod13 Jul 2014 15:42:42 -  1.3
+++ EVP_PKEY_decrypt.pod12 Mar 2016 21:28:57 -
@@ -60,7 +60,7 @@ Decrypt data using OAEP (for RSA keys):
/* Error occurred */
  if (EVP_PKEY_decrypt_init(ctx) <= 0)
/* Error */
- if (EVP_PKEY_CTX_set_rsa_padding(ctx, RSA_OAEP_PADDING) <= 0)
+ if (EVP_PKEY_CTX_set_rsa_padding(ctx, RSA_PKCS1_OAEP_PADDING) <= 0)
/* Error */

  /* Determine buffer length */
Index: EVP_PKEY_encrypt.pod
===
RCS file: /cvs/src/lib/libssl/src/doc/crypto/EVP_PKEY_encrypt.pod,v
retrieving revision 1.3
diff -u -p -u -p -r1.3 EVP_PKEY_encrypt.pod
--- EVP_PKEY_encrypt.pod13 Jul 2014 15:42:42 -  1.3
+++ EVP_PKEY_encrypt.pod12 Mar 2016 21:28:57 -
@@ -60,7 +60,7 @@ Encrypt data using OAEP (for RSA keys):
/* Error occurred */
  if (EVP_PKEY_encrypt_init(ctx) <= 0)
/* Error */
- if (EVP_PKEY_CTX_set_rsa_padding(ctx, RSA_OAEP_PADDING) <= 0)
+ if (EVP_PKEY_CTX_set_rsa_padding(ctx, RSA_PKCS1_OAEP_PADDING) <= 0)
/* Error */

  /* Determine buffer length */

Re: remove 'returns no value' from man pages

[Michael McConville]

Marc Espie wrote:
> On Fri, Mar 11, 2016 at 05:18:52PM -0800, Michael McConville wrote:
> > This is specified only irregularly, and people who don't know what a
> > void return type means are beyond help anyway.
> > 
> > This also adds a sentence specifying that X509_free(3) is NULL-safe, now
> > that we've removed all NULL-checks for it. I should sweep through and
> > add the sentence the rest of the NULL-safe LibreSSL *_free() functions
> > soon.
> > 
> > ok?
> 
> I would keep the one about rewind, maybe make it even stronger.
> 
> Using rewind is icky.   It deliberately hides an error message.

Sounds good - I'll leave that one and remove the rest. Let me know if
you have a proposed wording for the additional rewind(3) warning.

Re: New scheduler for OpenBSD

[Juan Francisco Cantero Hurtado]

On Sat, Mar 12, 2016 at 05:36:21PM +0100, Michal Mazurek wrote:
> Gregor Best attempted to improve the scheduler in 2011:
> http://comments.gmane.org/gmane.os.openbsd.tech/27059
> Here is another attempt, it takes up where the previous one left off.
> 
> This is also mostly based on the main idea behind Linux CFS or
> BFS. I found BFS to be described more clearly:
> http://ck.kolivas.org/patches/bfs/4.0/4.3/4.3-sched-bfs-467.patch
> 
> 
> Some notes:
> 
> Chrome is still not very usable.

Chrome is not the best benchmark for the scheduler ATM.

Until the work in malloc to enhance the support for multithreaded
programs is finished, forget Chrome and Firefox.

> 
> Much more work is needed, e.g. there is some MD code on sparc64 and
> alpha that depends on spc_schedticks that needs to be understood and
> rewritten.
> 
> Maybe using RB trees to queue what is usually no more than 5 elements
> is overkill.
> 
> p_usrpri and p_priority will go away, so userland utilities like 'ps'
> will need to be changed.
> 
> I also want to try and see if implementing one shared queue, instead of
> keeping one queue per cpu will improve performance even further. Right
> now there are some heuristics to determine whether a process should
> switch cpus. This doesn't work very well yet, in my tests with the
> attached code sometimes one queue was a second behind another. From
> what I understand that's the idea behind BFS and the reason why it
> doesn't scale to 4096 CPUs. I see that OpenBSD supports 256 CPUs on
> sparc64:
> ./arch/sparc64/include/cpu.h:#define MAXCPUS256
> 
> Nice is not yet supported, but it's easy to add (uncomment and modify
> 'offset' in sched_deadline(). I didn't want to add it yet to test just
> how fair this method is. Currently all processes are equal.
> 
> Other operating systems provide a couple of different schedulers to
> choose from, this diff overwrites the 4bsd scheduler with the new code
> and leaves no choice.
> 
> With the new code I got some visible improvements when compiling the
> kernel:
> old: 1m46.74s real 5m08.48s user 1m27.37s system
> old: 1m46.61s real 5m06.93s user 1m28.13s system
> old: 1m49.91s real 5m19.71s user 1m28.25s system
> new: 1m38.05s real 5m12.16s user 0m55.86s system
> new: 1m38.70s real 5m12.36s user 0m57.82s system
> new: 1m39.10s real 5m16.06s user 0m56.91s system

That is going to make happy to people running bulk builds :)

> 
> I would be interested in hearing if the new code broke something for
> anyone.
> 
> Is there a chance for a scheduler rewrite like this to be commited?
> 
> 
> Index: sys/kern/init_main.c
> ===
> RCS file: /cvs/src/sys/kern/init_main.c,v
> retrieving revision 1.248
> diff -u -p -r1.248 init_main.c
> --- sys/kern/init_main.c  3 Jan 2016 00:15:59 -   1.248
> +++ sys/kern/init_main.c  12 Mar 2016 15:48:36 -
> @@ -265,6 +265,8 @@ main(void *framep)
>*/
>   pr = 
>   process_initialize(pr, p);
> + p->p_deadline = 0;
> + p->p_rrticks = 10;
>  
>   LIST_INSERT_HEAD(, pr, ps_list);
>   atomic_setbits_int(>ps_flags, PS_SYSTEM);
> @@ -554,6 +556,7 @@ main(void *framep)
>  /*
>   * proc0: nothing to do, back to sleep
>   */
> + printf("*** modified scheduler ***\n");
>  while (1)
>  tsleep(, PVM, "scheduler", 0);
>   /* NOTREACHED */
> Index: sys/kern/kern_clock.c
> ===
> RCS file: /cvs/src/sys/kern/kern_clock.c,v
> retrieving revision 1.88
> diff -u -p -r1.88 kern_clock.c
> --- sys/kern/kern_clock.c 11 Jun 2015 16:03:04 -  1.88
> +++ sys/kern/kern_clock.c 12 Mar 2016 15:48:36 -
> @@ -180,7 +180,7 @@ hardclock(struct clockframe *frame)
>   if (stathz == 0)
>   statclock(frame);
>  
> - if (--ci->ci_schedstate.spc_rrticks <= 0)
> + if (p && (--(p->p_rrticks) <= 0))
>   roundrobin(ci);
>  
>   /*
> @@ -398,15 +398,7 @@ statclock(struct clockframe *frame)
>  
>   if (p != NULL) {
>   p->p_cpticks++;
> - /*
> -  * If no schedclock is provided, call it here at ~~12-25 Hz;
> -  * ~~16 Hz is best
> -  */
> - if (schedhz == 0) {
> - if ((++curcpu()->ci_schedstate.spc_schedticks & 3) ==
> - 0)
> - schedclock(p);
> - }
> + ++curcpu()->ci_schedstate.spc_schedticks;
>   }
>  }
>  
> Index: sys/kern/kern_fork.c
> ===
> RCS file: /cvs/src/sys/kern/kern_fork.c,v
> retrieving revision 1.184
> diff -u -p -r1.184 kern_fork.c
> --- sys/kern/kern_fork.c  9 Oct 2015 01:10:27 -   1.184
> +++ sys/kern/kern_fork.c  12 Mar 2016 15:48:36 -
> @@ -498,6 +498,7 @@ fork1(struct proc 

Re: teach kdump(1) about more ioctls

[Philip Guenther]

On Sat, Mar 12, 2016 at 2:47 AM, Martin Natano  wrote:
> There are bunch of ioctl definitions kdump(1) doesn't know about yet,
> with the result, that kdump prints the numerical value of the ioctl and
> not the name of the definition.
>
> This patch adds support for ipmi, vscsi, pvbus, udl, fuse, trunk, pipex
> and memrange.
>
> OK?

Looks good; assuming you've verified there are no ioctl conflicts on
both ILP32 and LP64, this is ok guenther@

httpd(8) SEE ALSO

[hans]

Should httpd(8) also mention services(5)?

Jan


Index: httpd.conf.5
===
RCS file: /cvs/src/usr.sbin/httpd/httpd.conf.5,v
retrieving revision 1.68
diff -u -p -r1.68 httpd.conf.5
--- httpd.conf.519 Jul 2015 05:17:27 -  1.68
+++ httpd.conf.512 Mar 2016 18:45:34 -
@@ -593,6 +593,7 @@ server "www.example.com" {
 .Ed
 .Sh SEE ALSO
 .Xr htpasswd 1 ,
+.Xr services 5 ,
 .Xr patterns 7 ,
 .Xr httpd 8 ,
 .Xr slowcgi 8

Re: httpd(8) SEE ALSO

[Theo de Raadt]

No, that is the roadmap that leads to ls(1) and ed(1) having
Xr to 50 other pages.  

> Should httpd(8) also mention services(5)?
> 
>   Jan
> 
> 
> Index: httpd.conf.5
> ===
> RCS file: /cvs/src/usr.sbin/httpd/httpd.conf.5,v
> retrieving revision 1.68
> diff -u -p -r1.68 httpd.conf.5
> --- httpd.conf.5  19 Jul 2015 05:17:27 -  1.68
> +++ httpd.conf.5  12 Mar 2016 18:45:34 -
> @@ -593,6 +593,7 @@ server "www.example.com" {
>  .Ed
>  .Sh SEE ALSO
>  .Xr htpasswd 1 ,
> +.Xr services 5 ,
>  .Xr patterns 7 ,
>  .Xr httpd 8 ,
>  .Xr slowcgi 8
> 

New scheduler for OpenBSD

[Michal Mazurek]

Gregor Best attempted to improve the scheduler in 2011:
http://comments.gmane.org/gmane.os.openbsd.tech/27059
Here is another attempt, it takes up where the previous one left off.

This is also mostly based on the main idea behind Linux CFS or
BFS. I found BFS to be described more clearly:
http://ck.kolivas.org/patches/bfs/4.0/4.3/4.3-sched-bfs-467.patch


Some notes:

Chrome is still not very usable.

Much more work is needed, e.g. there is some MD code on sparc64 and
alpha that depends on spc_schedticks that needs to be understood and
rewritten.

Maybe using RB trees to queue what is usually no more than 5 elements
is overkill.

p_usrpri and p_priority will go away, so userland utilities like 'ps'
will need to be changed.

I also want to try and see if implementing one shared queue, instead of
keeping one queue per cpu will improve performance even further. Right
now there are some heuristics to determine whether a process should
switch cpus. This doesn't work very well yet, in my tests with the
attached code sometimes one queue was a second behind another. From
what I understand that's the idea behind BFS and the reason why it
doesn't scale to 4096 CPUs. I see that OpenBSD supports 256 CPUs on
sparc64:
./arch/sparc64/include/cpu.h:#define MAXCPUS256

Nice is not yet supported, but it's easy to add (uncomment and modify
'offset' in sched_deadline(). I didn't want to add it yet to test just
how fair this method is. Currently all processes are equal.

Other operating systems provide a couple of different schedulers to
choose from, this diff overwrites the 4bsd scheduler with the new code
and leaves no choice.

With the new code I got some visible improvements when compiling the
kernel:
old: 1m46.74s real 5m08.48s user 1m27.37s system
old: 1m46.61s real 5m06.93s user 1m28.13s system
old: 1m49.91s real 5m19.71s user 1m28.25s system
new: 1m38.05s real 5m12.16s user 0m55.86s system
new: 1m38.70s real 5m12.36s user 0m57.82s system
new: 1m39.10s real 5m16.06s user 0m56.91s system

I would be interested in hearing if the new code broke something for
anyone.

Is there a chance for a scheduler rewrite like this to be commited?


Index: sys/kern/init_main.c
===
RCS file: /cvs/src/sys/kern/init_main.c,v
retrieving revision 1.248
diff -u -p -r1.248 init_main.c
--- sys/kern/init_main.c3 Jan 2016 00:15:59 -   1.248
+++ sys/kern/init_main.c12 Mar 2016 15:48:36 -
@@ -265,6 +265,8 @@ main(void *framep)
 */
pr = 
process_initialize(pr, p);
+   p->p_deadline = 0;
+   p->p_rrticks = 10;
 
LIST_INSERT_HEAD(, pr, ps_list);
atomic_setbits_int(>ps_flags, PS_SYSTEM);
@@ -554,6 +556,7 @@ main(void *framep)
 /*
  * proc0: nothing to do, back to sleep
  */
+   printf("*** modified scheduler ***\n");
 while (1)
 tsleep(, PVM, "scheduler", 0);
/* NOTREACHED */
Index: sys/kern/kern_clock.c
===
RCS file: /cvs/src/sys/kern/kern_clock.c,v
retrieving revision 1.88
diff -u -p -r1.88 kern_clock.c
--- sys/kern/kern_clock.c   11 Jun 2015 16:03:04 -  1.88
+++ sys/kern/kern_clock.c   12 Mar 2016 15:48:36 -
@@ -180,7 +180,7 @@ hardclock(struct clockframe *frame)
if (stathz == 0)
statclock(frame);
 
-   if (--ci->ci_schedstate.spc_rrticks <= 0)
+   if (p && (--(p->p_rrticks) <= 0))
roundrobin(ci);
 
/*
@@ -398,15 +398,7 @@ statclock(struct clockframe *frame)
 
if (p != NULL) {
p->p_cpticks++;
-   /*
-* If no schedclock is provided, call it here at ~~12-25 Hz;
-* ~~16 Hz is best
-*/
-   if (schedhz == 0) {
-   if ((++curcpu()->ci_schedstate.spc_schedticks & 3) ==
-   0)
-   schedclock(p);
-   }
+   ++curcpu()->ci_schedstate.spc_schedticks;
}
 }
 
Index: sys/kern/kern_fork.c
===
RCS file: /cvs/src/sys/kern/kern_fork.c,v
retrieving revision 1.184
diff -u -p -r1.184 kern_fork.c
--- sys/kern/kern_fork.c9 Oct 2015 01:10:27 -   1.184
+++ sys/kern/kern_fork.c12 Mar 2016 15:48:36 -
@@ -498,6 +498,7 @@ fork1(struct proc *curp, int flags, void
/*
 * Make child runnable and add to run queue.
 */
+   sched_deadline(p);
if ((flags & FORK_IDLE) == 0) {
SCHED_LOCK(s);
p->p_stat = SRUN;
Index: sys/kern/kern_resource.c
===
RCS file: /cvs/src/sys/kern/kern_resource.c,v
retrieving revision 1.55
diff -u -p -r1.55 kern_resource.c
--- sys/kern/kern_resource.c5 Dec 

Re: remove 'returns no value' from man pages

[Marc Espie]

On Fri, Mar 11, 2016 at 05:18:52PM -0800, Michael McConville wrote:
> This is specified only irregularly, and people who don't know what a
> void return type means are beyond help anyway.
> 
> This also adds a sentence specifying that X509_free(3) is NULL-safe, now
> that we've removed all NULL-checks for it. I should sweep through and
> add the sentence the rest of the NULL-safe LibreSSL *_free() functions
> soon.
> 
> ok?

I would keep the one about rewind, maybe make it even stronger.

Using rewind is icky.   It deliberately hides an error message.

rtwn(4) timeouts

[Stefan Sperling]

The urtwn(4) driver uses usbd_is_dying() calls in its timeouts.

usbd_is_dying() can't be part of the common rtwn(4) driver code once we
merge code from urtwn(4). So timeouts must move back to the bus-specific
part of the driver.

The common driver code now indicates when timeouts must be scheduled
or cancelled, and provides funtions to be called from timeouts.
The bus-specific parts are now responsible for managing timouts and
calling the common code when a timout fires.

This way, the future USB code will be able to use usbd_is_dying() in
its timeouts, like this:

urtwn_calib_to()
{
if (usbd_is_dying())
return;

rtwn_calib();
}

While the PCI code is quite boring in comparison:

rtwn_calib_to()
{
rtwn_calib();
}

Tested on
MAC/BB RTL8188CE, RF 6052 1T1R (PCI)

Index: ic/rtwn.c
===
RCS file: /cvs/src/sys/dev/ic/rtwn.c,v
retrieving revision 1.4
diff -u -p -r1.4 rtwn.c
--- ic/rtwn.c   11 Mar 2016 14:06:37 -  1.4
+++ ic/rtwn.c   12 Mar 2016 15:06:32 -
@@ -90,8 +90,6 @@ int   rtwn_media_change(struct ifnet *);
 intrtwn_ra_init(struct rtwn_softc *);
 void   rtwn_tsf_sync_enable(struct rtwn_softc *);
 void   rtwn_set_led(struct rtwn_softc *, int, int);
-void   rtwn_calib_to(void *);
-void   rtwn_next_scan(void *);
 intrtwn_newstate(struct ieee80211com *, enum ieee80211_state, int);
 void   rtwn_updateedca(struct ieee80211com *);
 intrtwn_set_key(struct ieee80211com *, struct ieee80211_node *,
@@ -150,9 +148,6 @@ rtwn_attach(struct device *pdev, struct 
 
sc->sc_pdev = pdev;
 
-   timeout_set(>calib_to, rtwn_calib_to, sc);
-   timeout_set(>scan_to, rtwn_next_scan, sc);
-
task_set(>init_task, rtwn_init_task, sc);
 
error = rtwn_read_chipid(sc);
@@ -251,10 +246,8 @@ rtwn_detach(struct rtwn_softc *sc, int f
 
s = splnet();
 
-   if (timeout_initialized(>scan_to))
-   timeout_del(>scan_to);
-   if (timeout_initialized(>calib_to))
-   timeout_del(>calib_to);
+   sc->sc_ops.cancel_scan(sc->sc_ops.cookie);
+   sc->sc_ops.cancel_calib(sc->sc_ops.cookie);
 
task_del(systq, >init_task);
 
@@ -678,9 +671,8 @@ rtwn_set_led(struct rtwn_softc *sc, int 
 }
 
 void
-rtwn_calib_to(void *arg)
+rtwn_calib(struct rtwn_softc *sc)
 {
-   struct rtwn_softc *sc = arg;
struct r92c_fw_cmd_rssi cmd;
 
if (sc->avg_pwdb != -1) {
@@ -695,15 +687,19 @@ rtwn_calib_to(void *arg)
/* Do temperature compensation. */
rtwn_temp_calib(sc);
 
-   timeout_add_sec(>calib_to, 2);
+   sc->sc_ops.next_calib(sc->sc_ops.cookie);
 }
 
 void
-rtwn_next_scan(void *arg)
+rtwn_next_scan(struct rtwn_softc *sc)
 {
-   struct rtwn_softc *sc = arg;
+   struct ieee80211com *ic = >sc_ic;
+   int s;
 
-   sc->sc_ops.next_scan(sc->sc_ops.cookie);
+   s = splnet();
+   if (ic->ic_state == IEEE80211_S_SCAN)
+   ieee80211_next_scan(>ic_if);
+   splx(s);
 }
 
 int
@@ -725,7 +721,7 @@ rtwn_newstate(struct ieee80211com *ic, e
 
if (ostate == IEEE80211_S_RUN) {
/* Stop calibration. */
-   timeout_del(>calib_to);
+   sc->sc_ops.cancel_calib(sc->sc_ops.cookie);
 
/* Turn link LED off. */
rtwn_set_led(sc, RTWN_LED_LINK, 0);
@@ -781,7 +777,7 @@ rtwn_newstate(struct ieee80211com *ic, e
rtwn_write_1(sc, R92C_TXPAUSE,
rtwn_read_1(sc, R92C_TXPAUSE) | 0x0f);
rtwn_set_chan(sc, ic->ic_bss->ni_chan, NULL);
-   timeout_add_msec(>scan_to, 200);
+   sc->sc_ops.next_scan(sc->sc_ops.cookie);
break;
 
case IEEE80211_S_AUTH:
@@ -859,7 +855,7 @@ rtwn_newstate(struct ieee80211com *ic, e
sc->thcal_state = 0;
sc->thcal_lctemp = 0;
/* Start periodic calibration. */
-   timeout_add_sec(>calib_to, 2);
+   sc->sc_ops.next_calib(sc->sc_ops.cookie);
break;
}
(void)sc->sc_newstate(ic, nstate, arg);
@@ -2556,8 +2552,8 @@ rtwn_stop(struct ifnet *ifp)
s = splnet();
ieee80211_new_state(ic, IEEE80211_S_INIT, -1);
 
-   timeout_del(>scan_to);
-   timeout_del(>calib_to);
+   sc->sc_ops.cancel_scan(sc->sc_ops.cookie);
+   sc->sc_ops.cancel_calib(sc->sc_ops.cookie);
 
task_del(systq, >init_task);
 
Index: ic/rtwnvar.h
===
RCS file: /cvs/src/sys/dev/ic/rtwnvar.h,v
retrieving revision 1.3
diff -u -p -r1.3 rtwnvar.h
--- ic/rtwnvar.h11 Mar 2016 14:06:37 -  1.3
+++ ic/rtwnvar.h12 Mar 2016 15:05:06 -
@@ -27,13 +27,16 @@ struct rtwn_ops {
void(*write_1)(void *, uint16_t, uint8_t);
void(*write_2)(void *, 

Re: remove 'returns no value' from man pages

[Ingo Schwarze]

Hi Michael,

Michael McConville wrote on Fri, Mar 11, 2016 at 05:18:52PM -0800:

> This is specified only irregularly, and people who don't know what a
> void return type means are beyond help anyway.

I don't feel strongly either way, but i certainly don't object.
Usually shorter with the same information is better, and consistency
is good, so you should probably do this.

Yours,
  Ingo

Re: head(1) -c

[Ingo Schwarze]

Hi,

Daniel Dickman wrote on Thu, Mar 10, 2016 at 02:11:49PM -0500:

> ps. if I'm reading things right, "head -c" will be in Posix, Issue 8.
> http://austingroupbugs.net/view.php?id=407#c743

Oh indeed, thanks for digging up that decision, useful indeed.

Well, that definitely settles the matter.  POSIX will definitely
require erroring out when both -n and -c are given (according to
the text "Accepted as Marked").  Clearly, we must not gratuitiously
differ.  It is not a big surprise that POSIX decided that way
given that POSIX also requires erroring out for tail -c -n.

So, the latest diff jca@ sent which silently ignores the error
is still not ok.  It must be changed to error out.

Yours,
  Ingo

teach kdump(1) about more ioctls

[Martin Natano]

There are bunch of ioctl definitions kdump(1) doesn't know about yet,
with the result, that kdump prints the numerical value of the ioctl and
not the name of the definition.

This patch adds support for ipmi, vscsi, pvbus, udl, fuse, trunk, pipex
and memrange.

OK?

natano


Index: Makefile
===
RCS file: /cvs/src/usr.bin/kdump/Makefile,v
retrieving revision 1.31
diff -u -p -r1.31 Makefile
--- Makefile28 Feb 2016 15:46:19 -  1.31
+++ Makefile12 Mar 2016 10:40:30 -
@@ -12,16 +12,23 @@ ioctl.c: ${.CURDIR}/Makefile ${.CURDIR}/
CC="${CC}" \
/bin/sh ${.CURDIR}/mkioctls ${SYS_DIR}/sys/ioctl.h \
${SYS_DIR}/dev/biovar.h \
+   ${SYS_DIR}/dev/ipmi.h \
${SYS_DIR}/dev/systrace.h \
${SYS_DIR}/dev/wscons/wsconsio.h \
${SYS_DIR}/dev/vndioctl.h \
+   ${SYS_DIR}/dev/vscsivar.h \
${SYS_DIR}/dev/pci/drm/i915_drm.h \
+   ${SYS_DIR}/dev/pv/pvvar.h \
+   ${SYS_DIR}/dev/usb/udlio.h \
${SYS_DIR}/dev/usb/usb.h \
+   ${SYS_DIR}/miscfs/fuse/fusefs.h \
${SYS_DIR}/net/bpf.h \
${SYS_DIR}/net/if_ppp.h \
${SYS_DIR}/net/if_pppoe.h \
+   ${SYS_DIR}/net/if_trunk.h \
${SYS_DIR}/net/if_tun.h \
${SYS_DIR}/net/pfvar.h \
+   ${SYS_DIR}/net/pipex.h \
${SYS_DIR}/net80211/ieee80211_ioctl.h \
${SYS_DIR}/netinet6/in6_var.h \
${SYS_DIR}/sys/tty.h \
@@ -33,6 +40,7 @@ ioctl.c: ${.CURDIR}/Makefile ${.CURDIR}/
${SYS_DIR}/sys/dkio.h \
${SYS_DIR}/sys/filio.h \
${SYS_DIR}/sys/gpio.h \
+   ${SYS_DIR}/sys/memrange.h \
${SYS_DIR}/sys/mtio.h \
${SYS_DIR}/sys/pciio.h \
${SYS_DIR}/sys/radioio.h \
Index: mkioctls
===
RCS file: /cvs/src/usr.bin/kdump/mkioctls,v
retrieving revision 1.35
diff -u -p -r1.35 mkioctls
--- mkioctls5 Jan 2016 19:41:15 -   1.35
+++ mkioctls12 Mar 2016 10:40:30 -
@@ -36,6 +36,7 @@ BEGIN {
print "#include "
print "#include "
print "#include "
+   print "#include "
print "#include "
print "#include "
print "#include "
@@ -54,8 +55,10 @@ BEGIN {
print "#include "
print "#include "
print "#include "
+   print "#include "
print "#include "
print "#include "
+   print "#include "
print "#include "
print "#include "
print "#include "
@@ -66,6 +69,7 @@ BEGIN {
print "#include "
print "#include "
print "#include "
+   print "#include "
print "#include "
print "#include "
print "#include "
@@ -75,10 +79,15 @@ BEGIN {
print "#include "
print "#include "
print "#include "
+   print "#include "
print "#include "
print "#include "
print "#include "
+   print "#include "
+   print "#include "
print "#include "
+   print "#include "
+   print "#include "
print "#include "
print "#include "
print "#include \"kdump.h\""
@@ -92,7 +101,7 @@ BEGIN {
print ""
 }
 
-/^[]*#[]*define[   
]+(ATAIO|AUDIO_|BIOC|CDIO|CHIO|DIOC|DRM|GPIO|TIO|FIO|MTIOC|LIOC|SIO|OSIO|SESIOC_|SIOC|PCIOC|PPPIOC|PPPOE|RIOC|RND|STRIOC|SCIOC|OSCIOC|TUN|USB|VIDIOC|VNDIOC|WSKBD|WSMOUSE|WSDISPLAY|WSMUX|PTM)[A-Z_0-9]*[
   ]+(DRM)?_IO/ {
+/^[]*#[]*define[   
]+(ATAIO|AUDIO_|BIOC|CDIO|CHIO|DIOC|DRM|GPIO|IPMICTL|TIO|FIO|MEMRANGE|MTIOC|LIOC|SIO|OSIO|SESIOC_|SIOC|PCIOC|PIPEX|PPPIOC|PPPOE|PVBUSIOC|RIOC|RND|STRIOC|SCIOC|OSCIOC|TUN|UDLIO|USB|VIDIOC|VNDIOC|VSCSI|WSKBD|WSMOUSE|WSDISPLAY|WSMUX|PTM)[A-Z_0-9]*[
   ]+(DRM)?_IO/ {
 
# find where the name starts
for (i = 1; i <= NF; i++)

reducing kmem pressure: make sbrk() allocate amap slots lazily

[Stefan Kempf]

When sbrk() allocates a range of virtual memory, it immediately allocates
a vm_amap and an am_slots array inside the amap There's one slot per page
allocated, and a slot is 16 bytes in size (on 64 bit CPUs, 12 on 32 bit
CPUs).

Preallocating slots makes sense mostly when we know that the memory range
is going to be populated by physical pages.

However, when doing sbrk(), physical pages are only allocated when
actually accessing the range allocated. Why should we pre-allocate
amap slots?

Removing the UVM_FLAG_OVERLAY flag turns this into lazy slot allocation
in chunks of 16 slots.

The diff below reduce kmem pressure (and hangs because of it) especially
in combination with the amap pool diff here:
https://marc.info/?l=openbsd-tech=145763420910948=2

Tests that make sure that things don't break with this are welcome.

Index: uvm/uvm_unix.c
===
RCS file: /cvs/src/sys/uvm/uvm_unix.c,v
retrieving revision 1.56
diff -u -p -r1.56 uvm_unix.c
--- uvm/uvm_unix.c  5 May 2015 02:13:46 -   1.56
+++ uvm/uvm_unix.c  12 Mar 2016 10:24:24 -
@@ -87,7 +87,7 @@ sys_obreak(struct proc *p, void *v, regi
UVM_MAPFLAG(PROT_READ | PROT_WRITE,
PROT_READ | PROT_WRITE | PROT_EXEC, MAP_INHERIT_COPY,
MADV_NORMAL, UVM_FLAG_AMAPPAD|UVM_FLAG_FIXED|
-   UVM_FLAG_OVERLAY|UVM_FLAG_COPYONW));
+   UVM_FLAG_COPYONW));
if (error) {
uprintf("sbrk: grow %ld failed, error = %d\n",
new - old, error);

Re: hang with processes in fltamap: how can I identify running out of RAM?

[Stefan Kempf]

Stuart Henderson wrote:
> On 2016/03/10 19:18, Stefan Kempf wrote:
> > There's still at least one issue with the diff. Again in amap_extend().
> > The slotalloc computation was still off :-(
> 
> It's not perfect but this is very significantly better. I've put
> it under load and the machine is still ok.

Cool. I have an idea why still processes become unresponsivene. See
the comments to the vmstats outputs.
 
> Here's a snapshot of a top display:
> 
> 46 processes: 1 running, 43 idle, 2 on processor  up  6:27
> CPU0 states:  0.0% user,  0.0% nice, 69.2% system,  0.0% interrupt, 30.8% idle
> CPU1 states:  0.0% user,  0.0% nice, 92.3% system,  0.0% interrupt,  7.7% idle
> Memory: Real: 3211M/5422M act/tot Free: 6540M Cache: 153M Swap: 0K/2640M
> 
>   PID USERNAME PRI NICE  SIZE   RES STATE WAIT  TIMECPU COMMAND
> 61052 sthen-180 2472M 1505M onproc-63:51 54.39% perl
> 86140 sthen-180 2308M 1732M run   -57:39 52.54% perl
> 47388 sthen 280 1284K 2480K onproc- 0:45  1.03% top
> 59819 _pflogd40  684K  260K sleep bpf   0:15  0.73% pflogd
> 89941 sthen  20 3552K 1780K sleep select0:13  0.15% sshd
> 46513 _ntp   2  -20 1240K 1456K sleep poll  0:08  0.05% ntpd
> 89307 root   2  -20  812K 1596K idle  poll  3:44  0.00% ntpd
> 78543 sthen  20 2536K 1784K sleep poll  0:10  0.00% systat
> 21968 sthen  20 3568K 1772K idle  select0:08  0.00% sshd
> 10538 sthen  20 9220K 8400K sleep kqread0:05  0.00% tmux
> 45455 sthen  20 3564K 1716K sleep select0:01  0.00% sshd
> 1 root  100  440K4K idle  wait  0:01  0.00% init
> 74816 sthen  20 3564K 1736K sleep select0:01  0.00% sshd
> 39769 _syslogd   20 1036K 1144K idle  kqread0:00  0.00% syslogd
> 
> At this point the big perl processes were flipping between onproc/run
> and sleep with wchan "fltamap".
> 
> The not-so-good bit: I couldn't kill them by signalling with ^C ^\ or
> kill(1), however I was able to get them to stop by killing the tmux they
> were running in. But without the diff this would have been a machine
> hang for sure.
> 
> Below I include vmstat -m output, firstly from around the point of
> the top(1) run above, secondly after the processes had exited.
> 
> Given the area more eyes are definitely wanted but it reads well to
> me, and I'm happy from my testing that this is a huge improvement,
> so: OK sthen.

Thanks. Agreed, any additional review and testing is useful,
also to ensure it doesn't break stuff.

> I have one nit, "systat pool" normally shows only 11 chars so
> you get "amapslotpl1, amapslotpl1, amapslotpl1, ... amapslotpl2" etc.
> I considered renaming to amapslpl1, 2, .. but that's pretty ugly,
> and since vmstat -m displays 12 chars, I propose this:

I think your diff is ok.
 
> Index: pool.c
> ===
> RCS file: /cvs/src/usr.bin/systat/pool.c,v
> retrieving revision 1.10
> diff -u -p -r1.10 pool.c
> --- pool.c16 Jan 2015 00:03:37 -  1.10
> +++ pool.c11 Mar 2016 21:09:35 -
> @@ -51,7 +51,7 @@ struct pool_info *pools = NULL;
>  
>  
>  field_def fields_pool[] = {
> - {"NAME", 11, 32, 1, FLD_ALIGN_LEFT, -1, 0, 0, 0},
> + {"NAME", 12, 32, 1, FLD_ALIGN_LEFT, -1, 0, 0, 0},
>   {"SIZE", 8, 24, 1, FLD_ALIGN_RIGHT, -1, 0, 0, 0},
>   {"REQUESTS", 8, 24, 1, FLD_ALIGN_RIGHT, -1, 0, 0, 0},
>   {"FAIL", 8, 24, 1, FLD_ALIGN_RIGHT, -1, 0, 0, 0},
> 
> 
> |... during run
> 
> $ vmstat -m
> Memory statistics by bucket size
> Size   In Use   Free   Requests  HighWater  Couldfree
>   16 2498318   88821280 12
>   32 1038114   4266 640  0
>   6452460 20 114795 320   4544
>  128   129653 43 508458 160  68133
>  256  132 28   3161  80  0
>  512   120414  2 813289  40  40368
> 1024  307 25  60779  20  23820
> 2048  232 58   1439  10284
> 4096  122  5 110326   5  45531
> 8192  206  0242   5  0
>163844  0  5   5  0
>327689  0 10   5  0
>655363  0511   5  0
>   1310722  0  2   5  0

The 64, 128 and 512 buckets are the biggest consumers.
> 
> Memory statistics by type   Type  Kern
>   Type InUse MemUse HighUse  Limit Requests Limit Limit Size(s)
> [...]
>   UVM amap292647 78645K  78645K 78644K  11989290 0  
> 16,32,64,128,256,512,1024,2048,4096,8192

efiboot 240x56 mode

[Matthieu Herrb]

Hi,

a collegue of mine recently tried to get OpenBSD running on an HP E820
laptop. Apparently this machine is UEFI only and its BIOS only works
in a 240x56 text mode.

So he did the patch below to add support for this mode to efiboot.

I've asked him to provide us a dmesg and acpidump for this machine
too. In the mean time here is his patch. I've tried it on the NUC that
I have been using with efiboot, it doesn't break it.

Index: efiboot.c
===
RCS file: /cvs/OpenBSD/src/sys/arch/amd64/stand/efiboot/efiboot.c,v
retrieving revision 1.11
diff -u -p -u -r1.11 efiboot.c
--- efiboot.c   4 Feb 2016 09:19:39 -   1.11
+++ efiboot.c   12 Mar 2016 09:16:05 -
@@ -357,7 +357,7 @@ static void
 efi_video_init(void)
 {
EFI_CONSOLE_CONTROL_PROTOCOL*conctrl = NULL;
-   int  i, mode80x25, mode100x31;
+   int  i, mode80x25, mode100x31, mode240x56;
UINTNcols, rows;
EFI_STATUS   status;
 
@@ -369,20 +369,25 @@ efi_video_init(void)
EfiConsoleControlScreenText);
mode80x25 = -1;
mode100x31 = -1;
-   for (i = 0; ; i++) {
+   mode240x56 = -1;
+   for (i = 0; i < conout->Mode->MaxMode; i++) {
status = EFI_CALL(conout->QueryMode, conout, i, , );
if (EFI_ERROR(status))
-   break;
+   continue;
if (mode80x25 < 0 && cols == 80 && rows == 25)
mode80x25 = i;
if (mode100x31 < 0 && cols == 100 && rows == 31)
mode100x31 = i;
+   if (mode240x56 < 0 && cols == 240 && rows == 56)
+   mode240x56 = i;
if (i < nitems(efi_video)) {
efi_video[i].cols = cols;
efi_video[i].rows = rows;
}
}
-   if (mode100x31 >= 0)
+   if (mode240x56 >= 0)
+   EFI_CALL(conout->SetMode, conout, mode240x56);
+   else if (mode100x31 >= 0)
EFI_CALL(conout->SetMode, conout, mode100x31);
else if (mode80x25 >= 0)
EFI_CALL(conout->SetMode, conout, mode80x25);

-- 
Matthieu Herrb


signature.asc
Description: PGP signature