smtpd: prefer clock_gettime()

[Philip Guenther]

...over gettimeofday()+TIMEVAL_TO_TIMESPEC()

Note that smtpd already uses clock_gettime() so this isn't an issue for 
-portable.

ok?

Index: smtpd/queue_fs.c
===
RCS file: /data/src/openbsd/src/usr.sbin/smtpd/queue_fs.c,v
retrieving revision 1.14
diff -u -p -r1.14 queue_fs.c
--- smtpd/queue_fs.c30 Dec 2015 11:40:30 -  1.14
+++ smtpd/queue_fs.c4 Feb 2017 08:45:46 -
@@ -729,7 +729,6 @@ queue_fs_init(struct passwd *pw, int ser
char*paths[] = { PATH_QUEUE, PATH_CORRUPT, PATH_INCOMING };
char path[PATH_MAX];
int  ret;
-   struct timeval   tv;
 
/* remove incoming/ if it exists */
if (server)
@@ -746,9 +745,8 @@ queue_fs_init(struct passwd *pw, int ser
ret = 0;
}
 
-   if (gettimeofday(&tv, NULL) == -1)
-   err(1, "gettimeofday");
-   TIMEVAL_TO_TIMESPEC(&tv, &startup);
+   if (clock_gettime(CLOCK_REALTIME, &startup))
+   err(1, "clock_gettime");
 
tree_init(&evpcount);
 

Re: [patch] vmd.c: Keep the ownership when rebooting a VM

[Mike Larkin]

On Sun, Sep 24, 2017 at 06:01:00PM +0200, Jesper Wallin wrote:
> Hi all,
> 
> If a machine is configured in vm.conf to have the owner of a regular
> user, the ownership of the machine is lost upon reboot and root becomes
> the new owner.  When restarting the machine, the tty is kept open and
> the permissions of the tty are untouched.  The user can therefore access
> the console, but it's not possible to stop the machine since the vmd
> owner is root.
> 
> The patch below simply leave vm->vm_uid untouched if the keeptty is set.
> 
> 
> Jesper Wallin
> 
> 
> Index: vmd.c
> ===
> RCS file: /cvs/src/usr.sbin/vmd/vmd.c,v
> retrieving revision 1.69
> diff -u -p -r1.69 vmd.c
> --- vmd.c 8 Sep 2017 06:24:31 -   1.69
> +++ vmd.c 24 Sep 2017 15:04:31 -
> @@ -413,7 +413,7 @@ vmd_dispatch_vmm(int fd, struct privsep_
>   log_debug("%s: about to stop vm id %d with tty open",
>   __func__, vm->vm_vmid);
>   vm_stop(vm, 1);
> - config_setvm(ps, vm, (uint32_t)-1, 0);
> + config_setvm(ps, vm, (uint32_t)-1, vm->vm_uid);
>   }
>   break;
>   case IMSG_VMDOP_GET_INFO_VM_DATA:
> @@ -1061,9 +1061,10 @@ vm_stop(struct vmd_vm *vm, int keeptty)
>   close(vm->vm_kernel);
>   vm->vm_kernel = -1;
>   }
> - vm->vm_uid = 0;
> - if (!keeptty)
> + if (!keeptty) {
>   vm_closetty(vm);
> + vm->vm_uid = 0;
> + }
>  }
>  
>  void
> 

committed, thanks.

Re: efiboot: Restore GOP mode on SetMode() failure

[YASUOKA Masahiko]

Hi,

> See my updated diff for reusing the gopi struct, please.

ok, but the diff seems to be against wrong revision.  You seems to
have other diffs, moving gop and gopi to global at least.

Can you send it entirely?

On Sat, 7 Oct 2017 02:09:29 +0200
Klemens Nanni  wrote:
> On Fri, Oct 06, 2017 at 05:15:20AM +, YASUOKA Masahiko wrote:
>> On Tue, 3 Oct 2017 18:15:33 -0500
>> Andrew Daugherity  wrote:
>> > I tested this diff in combination with your "Implement machine gop command"
>> > diff on a Dell PowerEdge R230 and a VirtualBox VM (EFI enabled).  No
>> > regressions, however 'machine gop' doesn't work quite how I expected it to
>> > -- it seems the video mode set with it only applies to the bootloader, and
>> > once the kernel loads, it sets a different mode (possibly a bad one).  I
>> > was hoping the kernel would use the mode I just set.
>> 
>> I also expected that the kernel uses the mode to which the gop command
>> set.  I think it's more useful.
>> 
>> The diff is updated.
>>
>> comments?
> See my updated diff for reusing the gopi struct, please.
> 
> Searching for and setting a better mode only if the user didn't pick one
> manually before is definitely a good idea, thanks.
> 
> Udated diff implementing `machine gop [n]' attached.
> 
>> Index: sys/arch/amd64/stand/efiboot/efiboot.c
>> ===
>> RCS file: /cvs/src/sys/arch/amd64/stand/efiboot/efiboot.c,v
>> retrieving revision 1.24
>> diff -u -p -r1.24 efiboot.c
>> --- sys/arch/amd64/stand/efiboot/efiboot.c   6 Oct 2017 04:52:22 -   
>> 1.24
>> +++ sys/arch/amd64/stand/efiboot/efiboot.c   6 Oct 2017 05:09:29 -
>> @@ -51,6 +51,7 @@ static EFI_GUID imgp_guid = LOADED_IMA
>>  static EFI_GUID  blkio_guid = BLOCK_IO_PROTOCOL;
>>  static EFI_GUID  devp_guid = DEVICE_PATH_PROTOCOL;
>>  u_long   efi_loadaddr;
>> +static int   efi_gopmode = -1;
>>  
>>  static int   efi_device_path_depth(EFI_DEVICE_PATH *dp, int);
>>  static int   efi_device_path_ncmp(EFI_DEVICE_PATH *, EFI_DEVICE_PATH *,
>> @@ -722,7 +723,7 @@ efi_makebootargs(void)
>>  EFI_GRAPHICS_OUTPUT_MODE_INFORMATION
>>  *gopi;
>>  bios_efiinfo_t   ei;
>> -int  curmode, bestmode = -1;
>> +int  curmode;
>>  UINTNsz, gopsiz, bestsiz = 0;
>>  EFI_GRAPHICS_OUTPUT_MODE_INFORMATION
>>  *info;
>> @@ -748,20 +749,23 @@ efi_makebootargs(void)
>>  status = EFI_CALL(BS->LocateProtocol, &gop_guid, NULL,
>>  (void **)&gop);
>>  if (!EFI_ERROR(status)) {
>> -for (i = 0; i < gop->Mode->MaxMode; i++) {
>> -status = EFI_CALL(gop->QueryMode, gop, i, &sz, &info);
>> -if (EFI_ERROR(status))
>> -continue;
>> -gopsiz = info->HorizontalResolution *
>> -info->VerticalResolution;
>> -if (gopsiz > bestsiz) {
>> -bestmode = i;
>> -bestsiz = gopsiz;
>> +if (efi_gopmode < 0) {
>> +for (i = 0; i < gop->Mode->MaxMode; i++) {
>> +status = EFI_CALL(gop->QueryMode, gop, i, &sz,
>> +&info);
>> +if (EFI_ERROR(status))
>> +continue;
>> +gopsiz = info->HorizontalResolution *
>> +info->VerticalResolution;
>> +if (gopsiz > bestsiz) {
>> +efi_gopmode = i;
>> +bestsiz = gopsiz;
>> +}
>>  }
>>  }
>> -if (bestmode >= 0) {
>> +if (efi_gopmode >= 0 && efi_gopmode != gop->Mode->Mode) {
>>  curmode = gop->Mode->Mode;
>> -if (efi_gop_setmode(gop, bestmode) != EFI_SUCCESS)
>> +if (efi_gop_setmode(gop, efi_gopmode) != EFI_SUCCESS)
>>  (void)efi_gop_setmode(gop, curmode);
>>  }
>>  
>> @@ -882,5 +886,49 @@ int
>>  Xpoweroff_efi(void)
>>  {
>>  EFI_CALL(RS->ResetSystem, EfiResetShutdown, EFI_SUCCESS, 0, NULL);
>> +return (0);
>> +}
>> +
>> +int
>> +Xgop_efi(void)
>> +{
>> +EFI_STATUS   status;
>> +EFI_GRAPHICS_OUTPUT *gop;
>> +EFI_GRAPHICS_OUTPUT_MODE_INFORMATION
>> +*info;
>> +int  i, mode = -1;
>> +UINTNsz;
>> +
>> +status = EFI_CALL(BS->LocateProtocol, &gop_guid, NULL,
>> +(void **)&gop);
>> +if (EFI_ERROR(status))
>> +return (0);
>> +
>> +if (cmd.argc >= 2) {
>> +mode = strtol(cmd.argv[1], NULL, 10);
>> + 

Re: efiboot: Restore GOP mode on SetMode() failure

[Klemens Nanni]

On Fri, Oct 06, 2017 at 05:15:20AM +, YASUOKA Masahiko wrote:
> On Tue, 3 Oct 2017 18:15:33 -0500
> Andrew Daugherity  wrote:
> > I tested this diff in combination with your "Implement machine gop command"
> > diff on a Dell PowerEdge R230 and a VirtualBox VM (EFI enabled).  No
> > regressions, however 'machine gop' doesn't work quite how I expected it to
> > -- it seems the video mode set with it only applies to the bootloader, and
> > once the kernel loads, it sets a different mode (possibly a bad one).  I
> > was hoping the kernel would use the mode I just set.
> 
> I also expected that the kernel uses the mode to which the gop command
> set.  I think it's more useful.
> 
> The diff is updated.
>
> comments?
See my updated diff for reusing the gopi struct, please.

Searching for and setting a better mode only if the user didn't pick one
manually before is definitely a good idea, thanks.

Udated diff implementing `machine gop [n]' attached.

> Index: sys/arch/amd64/stand/efiboot/efiboot.c
> ===
> RCS file: /cvs/src/sys/arch/amd64/stand/efiboot/efiboot.c,v
> retrieving revision 1.24
> diff -u -p -r1.24 efiboot.c
> --- sys/arch/amd64/stand/efiboot/efiboot.c6 Oct 2017 04:52:22 -   
> 1.24
> +++ sys/arch/amd64/stand/efiboot/efiboot.c6 Oct 2017 05:09:29 -
> @@ -51,6 +51,7 @@ static EFI_GUID  imgp_guid = LOADED_IMA
>  static EFI_GUID   blkio_guid = BLOCK_IO_PROTOCOL;
>  static EFI_GUID   devp_guid = DEVICE_PATH_PROTOCOL;
>  u_longefi_loadaddr;
> +static intefi_gopmode = -1;
>  
>  static intefi_device_path_depth(EFI_DEVICE_PATH *dp, int);
>  static intefi_device_path_ncmp(EFI_DEVICE_PATH *, EFI_DEVICE_PATH *,
> @@ -722,7 +723,7 @@ efi_makebootargs(void)
>   EFI_GRAPHICS_OUTPUT_MODE_INFORMATION
>   *gopi;
>   bios_efiinfo_t   ei;
> - int  curmode, bestmode = -1;
> + int  curmode;
>   UINTNsz, gopsiz, bestsiz = 0;
>   EFI_GRAPHICS_OUTPUT_MODE_INFORMATION
>   *info;
> @@ -748,20 +749,23 @@ efi_makebootargs(void)
>   status = EFI_CALL(BS->LocateProtocol, &gop_guid, NULL,
>   (void **)&gop);
>   if (!EFI_ERROR(status)) {
> - for (i = 0; i < gop->Mode->MaxMode; i++) {
> - status = EFI_CALL(gop->QueryMode, gop, i, &sz, &info);
> - if (EFI_ERROR(status))
> - continue;
> - gopsiz = info->HorizontalResolution *
> - info->VerticalResolution;
> - if (gopsiz > bestsiz) {
> - bestmode = i;
> - bestsiz = gopsiz;
> + if (efi_gopmode < 0) {
> + for (i = 0; i < gop->Mode->MaxMode; i++) {
> + status = EFI_CALL(gop->QueryMode, gop, i, &sz,
> + &info);
> + if (EFI_ERROR(status))
> + continue;
> + gopsiz = info->HorizontalResolution *
> + info->VerticalResolution;
> + if (gopsiz > bestsiz) {
> + efi_gopmode = i;
> + bestsiz = gopsiz;
> + }
>   }
>   }
> - if (bestmode >= 0) {
> + if (efi_gopmode >= 0 && efi_gopmode != gop->Mode->Mode) {
>   curmode = gop->Mode->Mode;
> - if (efi_gop_setmode(gop, bestmode) != EFI_SUCCESS)
> + if (efi_gop_setmode(gop, efi_gopmode) != EFI_SUCCESS)
>   (void)efi_gop_setmode(gop, curmode);
>   }
>  
> @@ -882,5 +886,49 @@ int
>  Xpoweroff_efi(void)
>  {
>   EFI_CALL(RS->ResetSystem, EfiResetShutdown, EFI_SUCCESS, 0, NULL);
> + return (0);
> +}
> +
> +int
> +Xgop_efi(void)
> +{
> + EFI_STATUS   status;
> + EFI_GRAPHICS_OUTPUT *gop;
> + EFI_GRAPHICS_OUTPUT_MODE_INFORMATION
> + *info;
> + int  i, mode = -1;
> + UINTNsz;
> +
> + status = EFI_CALL(BS->LocateProtocol, &gop_guid, NULL,
> + (void **)&gop);
> + if (EFI_ERROR(status))
> + return (0);
> +
> + if (cmd.argc >= 2) {
> + mode = strtol(cmd.argv[1], NULL, 10);
> + if (0 <= mode && mode < gop->Mode->MaxMode) {
> + status = EFI_CALL(gop->QueryMode, gop, mode,
> + &sz, &info);
> + if (!EFI_ERROR(status)) {
> + if (efi_gop_setmode(gop, mode)
> + == EFI_SUCCES

Re: efiboot: Restore GOP mode on SetMode() failure

[Klemens Nanni]

On Tue, Oct 03, 2017 at 11:15:33PM +, Andrew Daugherity wrote:
> I tested this diff in combination with your "Implement machine gop command"
> diff on a Dell PowerEdge R230 and a VirtualBox VM (EFI enabled).  No
> regressions, however 'machine gop' doesn't work quite how I expected it to
> -- it seems the video mode set with it only applies to the bootloader, and
> once the kernel loads, it sets a different mode (possibly a bad one).  I
> was hoping the kernel would use the mode I just set.
Thanks a lot for testing! I'm working on the kernel part.

> Sometimes the 800x600 and 640x480 modes either have parts of the screen cut
> off, or show a blank screen (but the resolution does change).  Not a huge
> deal, since the default 1024x768 mode works fine; also, the FreeBSD loader
> has the same issue.
This is probably due to buggy firmware implementations. I've seen such
behaviour on many (all?) boards.

> It seems that the 'machine video' setting (e.g. 80x25, 100x31, etc.) is
> independent of 'machine gop', and they can trample each other: changing the
> "gop" mode does not resize the "video" mode, but changing the "video" mode
> always resets the "gop" mode to 1024x768.
I cannot reproduce this on a DELL Latitiude E5550, setting modes for
both protocols works fine without one breaking or resetting the other.
I'll test other boards when possible.

boot> machine video
Mode 0: 80 x 25
Mode 1: 80 x 50
Mode 2: 100 x 31
Mode 3: 240 x 56

Current Mode = 2
boot> machine gop
Mode 0: 1280 x 1024 (stride = 1280)
Mode 1: 1024 x 768 (stride = 1024)
Mode 2: 640 x 480 (stride = 640)
Mode 3: 800 x 600 (stride = 800)
Mode 4: 1920 x 1080 (stride = 1920)

Current Mode = 3
boot> machine video 3
Current Mode = 3
boot> machine gop 4
Current Mode = 4


> Here are the available modes in VirtualBox:
> 
> >> OpenBSD/amd64 BOOTX64 3.35
> boot> machine video
> Mode 0: 80 x 25
> Mode 2: 100 x 31
> Mode 3: 128 x 40
> 
> Current Mode = 2
> boot> machine gop
> Mode 0: 640 x 480 (stride = 640)
> Mode 1: 800 x 600 (stride = 800)
> Mode 2: 1024 x 768 (stride = 1024)
> Mode 3: 1280 x 1024 (stride = 1280)
> Mode 4: 1440 x 900 (stride = 1440)
> Mode 5: 1920 x 1200 (stride = 1920)
> 
> Current Mode = 2
> 
> All of them work properly, with the caveats described above.  Once the
> kernel loads, it switches to 1920x1200 with a windowboxed 100x31 console.
Same windowboxed behaviour here on all tested machines.

> The Dell R230 only has video mode 0 (80x25); the gop modes listed vary
> depending on whether the BIOS setting "Load Legacy Video Option ROM" is
> enabled.  With it enabled, it only lists modes 0-2, defaulting to 2
> (1024x768).  With it disabled, there are additional modes for 1280x960 and
> 1280x1024 (our rackmount KVM monitor is 1280x1024 native, but specifies a
> preferred mode of 1024x768 in its EDID).
> 
> All these modes work properly in the bootloader (640x480 & 800x600 have the
> same issues as VirtualBox, but everything else is fine), but once the
> OpenBSD kernel loads, it sets the resolution to 1024x768, and scrambles the
> video output (regardless of gop mode) as mentioned at [1][2] if the legacy
> video ROM is disabled. Since that posting, the spontaneous reboot has been
> fixed, and serial console support was added to the EFI bootloader, so I was
> able to install OpenBSD in EFI mode, and recently randomly discovered that
> toggling this BIOS setting "fixes" the OpenBSD console.
> 
> This setting is described in the manual [3, p. 44] as:
> Load Legacy Video Option ROM
> -
> “Enables you to determine whether the system BIOS loads the legacy video
> (INT 10H) option ROM from the video controller. Selecting[sic] Enabled [if]
> the operating system does not support UEFI video output standards. This
> field is available only for UEFI boot mode. You cannot set the option to
> Enabled if UEFI Secure Boot mode is enabled."
> 
> With it enabled, the kernel sets a 1024x768 mode (100x31 letterboxed) and
> displays mostly correctly (some stray garbage on the leftmost 2 pixels).
> With it disabled (the default), video is scrambled to a thin purple line
> and efifb(4) is listed as not configured; X still works in either case.
> FreeBSD & Linux consoles are fine even with the legacy video ROM disabled.
> I've included the dmesgs for both cases.
Sounds like FreeBSD and Linux fall back to the old Universal Graphics
Adapter Protocal, which still relies on VGA. We only support GOP, which
is the hardware independent successor of UGA.

> Thanks,
> 
> Andrew
> 
> [1] https://marc.info/?l=openbsd-misc&m=146343624320665&w=2
> [2] https://marc.info/?l=openbsd-misc&m=148723613906289&w=2
> [3] http://topics-cdn.dell.com/pdf/poweredge-r230_owner's%20manual_en-us.pdf

Re: efiboot: Reuse GOP info struct

[Klemens Nanni]

Updated diff below now that the first bits got committed.


gopi can be used safely instead of an extra info struct, so munge it.

Declaring the gop and gopi strucutures globally makes things easier in
preparation for the next commit.

Both changes also improve consistency with regard to other structures
like ei, di and conout as well.

---
 sys/arch/amd64/stand/efiboot/efiboot.c | 26 --
 1 file changed, 12 insertions(+), 14 deletions(-)

diff --git a/sys/arch/amd64/stand/efiboot/efiboot.c 
b/sys/arch/amd64/stand/efiboot/efiboot.c
index 2774dfb0ca1..283f9ab356e 100644
--- a/sys/arch/amd64/stand/efiboot/efiboot.c
+++ b/sys/arch/amd64/stand/efiboot/efiboot.c
@@ -60,7 +60,7 @@ static voidefi_memprobe_internal(void);
 static void efi_video_init(void);
 static void efi_video_reset(void);
 static EFI_STATUS
-efi_gop_setmode(EFI_GRAPHICS_OUTPUT *gop, int mode);
+efi_gop_setmode(int mode);
 EFI_STATUS  efi_main(EFI_HANDLE, EFI_SYSTEM_TABLE *);
 
 void (*run_i386)(u_long, u_long, int, int, int, int, int, int, int, int)
@@ -703,13 +703,16 @@ efi_com_putc(dev_t dev, int c)
  * {EFI_,}_ACPI_20_TABLE_GUID or EFI_ACPI_TABLE_GUID means
  * ACPI 2.0 or above.
  */
-static EFI_GUID acpi_guid = ACPI_20_TABLE_GUID;
-static EFI_GUID smbios_guid = SMBIOS_TABLE_GUID;
+static EFI_GUID acpi_guid = ACPI_20_TABLE_GUID;
+static EFI_GUID smbios_guid = SMBIOS_TABLE_GUID;
+static EFI_GRAPHICS_OUTPUT *gop;
+static EFI_GRAPHICS_OUTPUT_MODE_INFORMATION
+   *gopi;
 
 #defineefi_guidcmp(_a, _b) memcmp((_a), (_b), sizeof(EFI_GUID))
 
 static EFI_STATUS
-efi_gop_setmode(EFI_GRAPHICS_OUTPUT *gop, int mode)
+efi_gop_setmode(int mode)
 {
EFI_STATUS  status;
 
@@ -725,14 +728,9 @@ efi_makebootargs(void)
 {
int  i;
EFI_STATUS   status;
-   EFI_GRAPHICS_OUTPUT *gop;
-   EFI_GRAPHICS_OUTPUT_MODE_INFORMATION
-   *gopi;
bios_efiinfo_t   ei;
int  curmode, bestmode = -1;
UINTNsz, gopsiz, bestsiz = 0;
-   EFI_GRAPHICS_OUTPUT_MODE_INFORMATION
-   *info;
 
memset(&ei, 0, sizeof(ei));
/*
@@ -756,11 +754,11 @@ efi_makebootargs(void)
(void **)&gop);
if (!EFI_ERROR(status)) {
for (i = 0; i < gop->Mode->MaxMode; i++) {
-   status = EFI_CALL(gop->QueryMode, gop, i, &sz, &info);
+   status = EFI_CALL(gop->QueryMode, gop, i, &sz, &gopi);
if (EFI_ERROR(status))
continue;
-   gopsiz = info->HorizontalResolution *
-   info->VerticalResolution;
+   gopsiz = gopi->HorizontalResolution *
+   gopi->VerticalResolution;
if (gopsiz > bestsiz) {
bestmode = i;
bestsiz = gopsiz;
@@ -768,8 +766,8 @@ efi_makebootargs(void)
}
if (bestmode >= 0) {
curmode = gop->Mode->Mode;
-   if (efi_gop_setmode(gop, bestmode) != EFI_SUCCESS)
-   (void)efi_gop_setmode(gop, curmode);
+   if (efi_gop_setmode(bestmode) != EFI_SUCCESS)
+   (void)efi_gop_setmode(curmode);
}
 
gopi = gop->Mode->Info;
-- 
2.14.2

Re: maxproc limits

[Stuart Henderson]

On 2017/10/06 13:51, Ted Unangst wrote:
> Stuart Henderson wrote:
> > I have been bumping into maxproc limits a lot recently on my
> > workstation. While I do have quite a lot of processes at times, I don't
> > think I have quite been tripping into the limits of number of actual
> > processes.
> > 
> > It seems that perhaps threads are counted towards these. Is that
> > expected/desirable? If so, would it be sane to raise the defaults
> > in login.conf and NPROCESS? 1310 isn't a lot when chromium is
> > using 500+.
> 
> kern.maxthread defaults to 1950. i have no idea what logic the formula is
> attempting to express. each user will run one multithreaded process of 8
> threads? huh?
> 
> conf/param.c:intmaxthread = NPROCESS + 8 * MAXUSERS;
> 

Ah, I missed the separate kern.maxthread. I'll at least bump that
locally then (I had already bumped maxproc). I have some java crap
as well, when that's running alongside chromium there aren't many
free.

Re: maxproc limits

[Theo de Raadt]

> Stuart Henderson wrote:
> > I have been bumping into maxproc limits a lot recently on my
> > workstation. While I do have quite a lot of processes at times, I don't
> > think I have quite been tripping into the limits of number of actual
> > processes.
> > 
> > It seems that perhaps threads are counted towards these. Is that
> > expected/desirable? If so, would it be sane to raise the defaults
> > in login.conf and NPROCESS? 1310 isn't a lot when chromium is
> > using 500+.
> 
> kern.maxthread defaults to 1950. i have no idea what logic the formula is
> attempting to express. each user will run one multithreaded process of 8
> threads? huh?
> 
> conf/param.c:intmaxthread = NPROCESS + 8 * MAXUSERS;

Logic?  It doesn't need to be logical.  It is attempting to invent
some sort of limit.

If there isn't some sort of limit on resource allocation, all sorts
of worse problems can pop up.

Re: maxproc limits

[Ted Unangst]

Stuart Henderson wrote:
> I have been bumping into maxproc limits a lot recently on my
> workstation. While I do have quite a lot of processes at times, I don't
> think I have quite been tripping into the limits of number of actual
> processes.
> 
> It seems that perhaps threads are counted towards these. Is that
> expected/desirable? If so, would it be sane to raise the defaults
> in login.conf and NPROCESS? 1310 isn't a lot when chromium is
> using 500+.

kern.maxthread defaults to 1950. i have no idea what logic the formula is
attempting to express. each user will run one multithreaded process of 8
threads? huh?

conf/param.c:intmaxthread = NPROCESS + 8 * MAXUSERS;

Re: bc(1) examples

[Klemens Nanni]

On Fri, Oct 06, 2017 at 12:12:01PM +, Jan Stary wrote:
> Isn't "4 * a(1)" a more natural incarnation of pi than "2 * a(2^1)"?
That's indeed the most simple formula with regard to (inverse)
trigonometric functions.

maxproc limits

[Stuart Henderson]

I have been bumping into maxproc limits a lot recently on my
workstation. While I do have quite a lot of processes at times, I don't
think I have quite been tripping into the limits of number of actual
processes.

It seems that perhaps threads are counted towards these. Is that
expected/desirable? If so, would it be sane to raise the defaults
in login.conf and NPROCESS? 1310 isn't a lot when chromium is
using 500+.

Re: make includes: use find -exec {} +

[Christian Weisgerber]

Christian Weisgerber:

> Admittedly, this is cosmetic:
> Use the modern POSIX idiom "-exec ... {} +" instead of find|xargs.

tb@ kindly pointed out to me that Klemens Nanni submitted a better
patch for this four months ago; "-exec +" allows us to combine the
two find invocations into one:
https://marc.info/?l=openbsd-tech&m=149649423503939

ok?

Index: include/Makefile
===
RCS file: /cvs/src/include/Makefile,v
retrieving revision 1.219
diff -u -p -r1.219 Makefile
--- include/Makefile17 Apr 2017 15:53:21 -  1.219
+++ include/Makefile6 Oct 2017 14:25:47 -
@@ -100,10 +100,9 @@ includes:
cd ${.CURDIR}/$$i && ${RUN_MAKE}; \
done
chown -RP ${BINOWN}:${BINGRP} ${DESTDIR}/usr/include
-   find ${DESTDIR}/usr/include -type f -print0 | \
-   xargs -0r chmod a=r
-   find ${DESTDIR}/usr/include \( -type d -o -type l \) -print0 | \
-   xargs -0r chmod -h u=rwx,go=rx
+   find ${DESTDIR}/usr/include \
+   -type f -exec chmod a=r {} + -o \
+   \( -type d -o -type l \) -exec chmod -h u=rwx,go=rx {} +
 
 copies:
@echo copies: ${LDIRS}
Index: share/zoneinfo/Makefile
===
RCS file: /cvs/src/share/zoneinfo/Makefile,v
retrieving revision 1.11
diff -u -p -r1.11 Makefile
--- share/zoneinfo/Makefile 24 Nov 2016 14:38:30 -  1.11
+++ share/zoneinfo/Makefile 6 Oct 2017 14:30:23 -
@@ -81,8 +81,9 @@ realinstall: ${DATA} ${REDO} ${YEARISTYP
(cd ${.CURDIR}/datfiles; \
${ZIC} -y ${YEARISTYPECOPY} -d ${TZDIR} -p ${POSIXRULES})
chown -R ${BINOWN}:${BINGRP} ${TZDIR}
-   find ${TZDIR} -type f -print0 | xargs -0r chmod a=r
-   find ${TZDIR} -type d -print0 | xargs -0r chmod a=rx
+   find ${TZDIR} \
+   -type f -exec chmod a=r {} + -o \
+   -type d -exec chmod a=rx {} +
${INSTALL} -c -o root -g bin -m 644 ${.CURDIR}/datfiles/iso3166.tab \
${DESTDIR}/usr/share/misc
${INSTALL} -c -o root -g bin -m 644 ${.CURDIR}/datfiles/zone.tab \

-- 
Christian "naddy" Weisgerber  na...@mips.inka.de

Re: bc -l wording

[Andreas Kusalananda Kähäri]

For what it's worth, POSIX has

-l
(The letter ell.) Define the math functions and initialize scale
to 20, instead of the default zero; see the EXTENDED DESCRIPTION
section.

http://pubs.opengroup.org/onlinepubs/9699919799.2016edition/utilities/bc.html

Cheers,


On Fri, Oct 06, 2017 at 02:27:33PM +0200, Jan Stary wrote:
> Currently, the bc(1) manpage describes "-l" as
> 
>   Allow specification of an arbitrary precision math library
> 
> I am not a native speaker, but "specification of a library"
> seems unclear here. It loads /usr/share/misc/bc.library,
> not that the user could "specify" some other library to load.
> 
> Later in the manpage, "the functions available in _the_ library"
> are described, and FILES makes it explicit that this is the one.
> 
> Perhaps a native speaker will come up with some better wording.
> 
>   Jan
> 
> 
> 
> Index: bc.1
> ===
> RCS file: /cvs/src/usr.bin/bc/bc.1,v
> retrieving revision 1.32
> diff -u -p -r1.32 bc.1
> --- bc.1  17 Nov 2015 05:45:35 -  1.32
> +++ bc.1  6 Oct 2017 12:20:10 -
> @@ -76,7 +76,7 @@ If multiple
>  options are specified, they are processed in the order given,
>  separated by newlines.
>  .It Fl l
> -Allow specification of an arbitrary precision math library.
> +Load an arbitrary precision math library.
>  The definitions in the library are available to command line
>  expressions.
>  .El
> 

-- 
Andreas Kusalananda Kähäri,
National Bioinformatics Infrastructure Sweden (NBIS),
Uppsala University, Sweden.

TSC timecounters

[Mike Belopuhov]

Hi,

An experimental change to use TSC as a timecounter source on a variety
of modern Intel and AMD CPUs has been just committed and enabled on
OpenBSD/amd64 thanks to the work done by Adam Steen.

The rationale is, quoting the commit message:

  If frequency of an invariant (non-stop) time stamp counter is measured
  using an independent working timecounter that has a known frequency, we
  can assume that the measured TSC frequency is as good as the resolution
  of the timecounter that we use to perform the measurement. This lets us
  switch from this high quality but expensive source to the cheaper TSC
  without sacrificing precision on a wide range of modern CPUs.

You can query and change the current timecounter source in the runtime
via sysctl:

  % sysctl kern.timecounter.{choice,hardware}
  kern.timecounter.choice=i8254(0) tsc(2000) acpihpet0(1000) acpitimer0(1000) 
dummy(-100)
  kern.timecounter.hardware=tsc

Please make sure your NTP drift (/var/db/ntpd.drift) stays within -20..+20
or at least is not worse than it is right now.

And finally, please make sure to run a "make config" when building the
kernel to update offset tables because of the cpu_info structure changes.

Regards,
Mike

Re: make includes: use find -exec {} +

[Klemens Nanni]

On Thu, Oct 05, 2017 at 08:08:32PM +, Christian Weisgerber wrote:
> Admittedly, this is cosmetic:
> Use the modern POSIX idiom "-exec ... {} +" instead of find|xargs.
> ok?
> 
> Index: include/Makefile
> ===
> RCS file: /cvs/src/include/Makefile,v
> retrieving revision 1.219
> diff -u -p -r1.219 Makefile
> --- include/Makefile  17 Apr 2017 15:53:21 -  1.219
> +++ include/Makefile  5 Oct 2017 19:35:58 -
> @@ -100,10 +100,9 @@ includes:
>   cd ${.CURDIR}/$$i && ${RUN_MAKE}; \
>   done
>   chown -RP ${BINOWN}:${BINGRP} ${DESTDIR}/usr/include
> - find ${DESTDIR}/usr/include -type f -print0 | \
> - xargs -0r chmod a=r
> - find ${DESTDIR}/usr/include \( -type d -o -type l \) -print0 | \
> - xargs -0r chmod -h u=rwx,go=rx
> + find ${DESTDIR}/usr/include -type f -exec chmod a=r {} +
> + find ${DESTDIR}/usr/include \( -type d -o -type l \) -exec \
> + chmod -h u=rwx,go=rx {} +
>  
>  copies:
>   @echo copies: ${LDIRS}
> -- 
> Christian "naddy" Weisgerber  na...@mips.inka.de
> 
FWIW, I've suggested this a while ago already:
https://marc.info/?l=openbsd-tech&m=149649423503939&w=2

bc -l wording

[Jan Stary]

Currently, the bc(1) manpage describes "-l" as

Allow specification of an arbitrary precision math library

I am not a native speaker, but "specification of a library"
seems unclear here. It loads /usr/share/misc/bc.library,
not that the user could "specify" some other library to load.

Later in the manpage, "the functions available in _the_ library"
are described, and FILES makes it explicit that this is the one.

Perhaps a native speaker will come up with some better wording.

Jan



Index: bc.1
===
RCS file: /cvs/src/usr.bin/bc/bc.1,v
retrieving revision 1.32
diff -u -p -r1.32 bc.1
--- bc.117 Nov 2015 05:45:35 -  1.32
+++ bc.16 Oct 2017 12:20:10 -
@@ -76,7 +76,7 @@ If multiple
 options are specified, they are processed in the order given,
 separated by newlines.
 .It Fl l
-Allow specification of an arbitrary precision math library.
+Load an arbitrary precision math library.
 The definitions in the library are available to command line
 expressions.
 .El

bc(1) examples

[Jan Stary]

Isn't "4 * a(1)" a more natural incarnation of pi than "2 * a(2^1)"?

Jan


Index: bc.1
===
RCS file: /cvs/src/usr.bin/bc/bc.1,v
retrieving revision 1.32
diff -u -p -r1.32 bc.1
--- bc.117 Nov 2015 05:45:35 -  1.32
+++ bc.16 Oct 2017 12:10:47 -
@@ -332,7 +332,7 @@ the exponential function and
 prints approximate values of the exponential function of
 the first ten integers.
 .Bd -literal -offset indent
-$ bc -l -e 'scale = 500; 2 * a(2^1)' -e quit
+$ bc -l -e 'scale = 500; 4 * a(1)' -e quit
 .Ed
 .Pp
 prints an approximation of pi.

Re: [patch] vmd.c: Keep the ownership when rebooting a VM

[Mike Larkin]

On Thu, Oct 05, 2017 at 10:23:58PM +0200, Jesper Wallin wrote:
> Hi again,
> 
> Bumping this, as I assume it wasn't prioritized during the beta.
> 

We were locked. I'm working backward through emails, should get to this
in the next day or so.

-ml

> On Sun, Sep 24, 2017 at 06:01:00PM +0200, Jesper Wallin wrote:
> > Hi all,
> > 
> > If a machine is configured in vm.conf to have the owner of a regular
> > user, the ownership of the machine is lost upon reboot and root becomes
> > the new owner.  When restarting the machine, the tty is kept open and
> > the permissions of the tty are untouched.  The user can therefore access
> > the console, but it's not possible to stop the machine since the vmd
> > owner is root.
> > 
> > The patch below simply leave vm->vm_uid untouched if the keeptty is set.
> > 
> > 
> > Jesper Wallin
> > 
> > 
> > Index: vmd.c
> > ===
> > RCS file: /cvs/src/usr.sbin/vmd/vmd.c,v
> > retrieving revision 1.69
> > diff -u -p -r1.69 vmd.c
> > --- vmd.c   8 Sep 2017 06:24:31 -   1.69
> > +++ vmd.c   24 Sep 2017 15:04:31 -
> > @@ -413,7 +413,7 @@ vmd_dispatch_vmm(int fd, struct privsep_
> > log_debug("%s: about to stop vm id %d with tty open",
> > __func__, vm->vm_vmid);
> > vm_stop(vm, 1);
> > -   config_setvm(ps, vm, (uint32_t)-1, 0);
> > +   config_setvm(ps, vm, (uint32_t)-1, vm->vm_uid);
> > }
> > break;
> > case IMSG_VMDOP_GET_INFO_VM_DATA:
> > @@ -1061,9 +1061,10 @@ vm_stop(struct vmd_vm *vm, int keeptty)
> > close(vm->vm_kernel);
> > vm->vm_kernel = -1;
> > }
> > -   vm->vm_uid = 0;
> > -   if (!keeptty)
> > +   if (!keeptty) {
> > vm_closetty(vm);
> > +   vm->vm_uid = 0;
> > +   }
> >  }
> >  
> >  void
>