vmm/i386 __func__

[Michael W. Bombardieri]

Hi,

Some printf() statements in vmm.c already used __func__
but some didn't. This diff adds more __func__.

Also, one printf() statement was missing a space:
   "vcpu_run_vmx: can't readprocbased ctls on exit"

- Michael


Index: vmm.c
===
RCS file: /cvs/src/sys/arch/i386/i386/vmm.c,v
retrieving revision 1.27
diff -u -p -u -r1.27 vmm.c
--- vmm.c   12 Apr 2017 05:46:59 -  1.27
+++ vmm.c   14 Apr 2017 04:11:33 -
@@ -540,7 +540,7 @@ vm_resetcpu(struct vm_resetcpu_params *v
vm->vm_id, vcpu->vc_id);
 
if (vcpu_reset_regs(vcpu, >vrp_init_state)) {
-   printf("vm_resetcpu: failed\n");
+   printf("%s: failed\n", __func__);
 #ifdef VMM_DEBUG
dump_vcpu(vcpu);
 #endif /* VMM_DEBUG */
@@ -1102,7 +1102,7 @@ vm_impl_init_vmx(struct vm *vm, struct p
/* Create a new pmap for this VM */
pmap = pmap_create();
if (!pmap) {
-   printf("vm_impl_init_vmx: pmap_create failed\n");
+   printf("%s: pmap_create failed\n", __func__);
return (ENOMEM);
}
 
@@ -1118,7 +1118,7 @@ vm_impl_init_vmx(struct vm *vm, struct p
VM_MAP_ISVMSPACE | VM_MAP_PAGEABLE);
 
if (!vm->vm_map) {
-   printf("vm_impl_init_vmx: uvm_map_create failed\n");
+   printf("%s: uvm_map_create failed\n", __func__);
pmap_destroy(pmap);
return (ENOMEM);
}
@@ -1131,7 +1131,7 @@ vm_impl_init_vmx(struct vm *vm, struct p
PROT_READ | PROT_WRITE | PROT_EXEC,
>p_vmspace->vm_map, vmr->vmr_va, vmr->vmr_size);
if (ret) {
-   printf("vm_impl_init_vmx: uvm_share failed (%d)\n",
+   printf("%s: uvm_share failed (%d)\n", __func__,
ret);
/* uvm_map_deallocate calls pmap_destroy for us */
uvm_map_deallocate(vm->vm_map);
@@ -1143,7 +1143,7 @@ vm_impl_init_vmx(struct vm *vm, struct p
/* Convert the low 512GB of the pmap to EPT */
ret = pmap_convert(pmap, PMAP_TYPE_EPT);
if (ret) {
-   printf("vm_impl_init_vmx: pmap_convert failed\n");
+   printf("%s: pmap_convert failed\n", __func__);
/* uvm_map_deallocate calls pmap_destroy for us */
uvm_map_deallocate(vm->vm_map);
vm->vm_map = NULL;
@@ -1181,7 +1181,7 @@ vm_impl_init_svm(struct vm *vm, struct p
/* Create a new pmap for this VM */
pmap = pmap_create();
if (!pmap) {
-   printf("vm_impl_init_svm: pmap_create failed\n");
+   printf("%s: pmap_create failed\n", __func__);
return (ENOMEM);
}
 
@@ -1199,7 +1199,7 @@ vm_impl_init_svm(struct vm *vm, struct p
VM_MAP_ISVMSPACE | VM_MAP_PAGEABLE);
 
if (!vm->vm_map) {
-   printf("vm_impl_init_svm: uvm_map_create failed\n");
+   printf("%s: uvm_map_create failed\n", __func__);
pmap_destroy(pmap);
return (ENOMEM);
}
@@ -1212,7 +1212,7 @@ vm_impl_init_svm(struct vm *vm, struct p
PROT_READ | PROT_WRITE | PROT_EXEC,
>p_vmspace->vm_map, vmr->vmr_va, vmr->vmr_size);
if (ret) {
-   printf("vm_impl_init_svm: uvm_share failed (%d)\n",
+   printf("%s: uvm_share failed (%d)\n", __func__,
ret);
/* uvm_map_deallocate calls pmap_destroy for us */
uvm_map_deallocate(vm->vm_map);
@@ -3447,8 +3447,8 @@ vcpu_run_vmx(struct vcpu *vcpu, struct v
/* Is there an interrupt pending injection? */
if (irq != 0x) {
if (!vcpu->vc_irqready) {
-   printf("vcpu_run_vmx: error - irq injected"
-   " while not ready\n");
+   printf("%s: error - irq injected"
+   " while not ready\n", __func__);
ret = EINVAL;
break;
}
@@ -3457,8 +3457,8 @@ vcpu_run_vmx(struct vcpu *vcpu, struct v
eii |= (1ULL << 31);/* Valid */
eii |= (0ULL << 8); /* Hardware Interrupt */
if (vmwrite(VMCS_ENTRY_INTERRUPTION_INFO, eii)) {
-   printf("vcpu_run_vmx: can't vector "
-   "interrupt to guest\n");
+   printf("%s: can't vector "
+   "interrupt to guest\n", __func__);
ret = EINVAL;
break;
}
@@ -3469,15 +3469,15 @@ vcpu_run_vmx(struct 

sysctl.3: Fix file path

[Klemens Nanni]

Index: lib/libc/gen/sysctl.3
===
RCS file: /cvs/src/lib/libc/gen/sysctl.3,v
retrieving revision 1.277
diff -u -p -r1.277 sysctl.3
--- lib/libc/gen/sysctl.3   16 Mar 2017 14:57:15 -  1.277
+++ lib/libc/gen/sysctl.3   14 Apr 2017 00:43:44 -
@@ -1056,7 +1056,7 @@ Most architectures define at least the f
.El
.Pp
Consult the example file
-.Pa /etc/example/sysctl.conf
+.Pa /etc/examples/sysctl.conf
for a non-exhaustive list of
.Li machdep
 variables.

Re: snmpd agentx fixes

[Rivo Nurges]

Hi!

I have upgraded about 20 boxes to current with the patch and everything works.

Rivo

On 10/04/2017, 03:27, "Jeremie Courreges-Anglas"  wrote:


Hi,

when implementing support for multiple listening sockets, I broke AgentX
support in a rather silly way.  AgentX support is only used by relayd in
base.

Rivo Nurges (in cc) contacted me about this.  Thanks to him and reyk@
for helping me reproduce the issue.

The config below helps reproduce the problem.

# cat /etc/snmpd.conf
socket "/var/run/agentx.sock" agentx
# cat /etc/relayd.conf
snmp
table  { 127.0.0.1 }
relay "bar" {
listen on 0.0.0.0 port 1234
forward to  check icmp
}
#

There are two diffs below.

The first part is the fix for the multiple socket support.  The issue is
that in control.c SNMP data is sent down the... AgentX socket.  This
obviously doesn't fly.  We need to know which socket to use when sending
SNMP replies, so let's store it in the snmp_message context (which
already stores the remote and local addresses).  Too obvious?

The first problem tends to hide another bug: an uninitialized variable
in trap.c.  This fix was written by Rivo Nurges.

Thoughts / ok?


Index: control.c
===
RCS file: /d/cvs/src/usr.sbin/snmpd/control.c,v
retrieving revision 1.41
diff -u -p -r1.41 control.c
--- control.c   9 Jan 2017 14:49:22 -   1.41
+++ control.c   9 Apr 2017 18:28:23 -
@@ -592,7 +592,7 @@ control_dispatch_agentx(int fd, short ev
}
}
  dispatch:
-   snmpe_dispatchmsg(msg, fd);
+   snmpe_dispatchmsg(msg);
break;
}
 
Index: snmpd.h
===
RCS file: /d/cvs/src/usr.sbin/snmpd/snmpd.h,v
retrieving revision 1.74
diff -u -p -r1.74 snmpd.h
--- snmpd.h 9 Jan 2017 14:49:22 -   1.74
+++ snmpd.h 9 Apr 2017 18:28:23 -
@@ -401,6 +401,7 @@ struct pfr_buffer {
 #define MSG_REPORT(m)  (((m)->sm_flags & SNMP_MSGFLAG_REPORT) 
!= 0)
 
 struct snmp_message {
+   int  sm_sock;
struct sockaddr_storage  sm_ss;
socklen_tsm_slen;
char sm_host[HOST_NAME_MAX+1];
@@ -660,7 +661,7 @@ struct kif_arp  *karp_getaddr(struct sock
 /* snmpe.c */
 voidsnmpe(struct privsep *, struct privsep_proc *);
 voidsnmpe_shutdown(void);
-voidsnmpe_dispatchmsg(struct snmp_message *, int);
+voidsnmpe_dispatchmsg(struct snmp_message *);
 
 /* trap.c */
 voidtrap_init(void);
Index: snmpe.c
===
RCS file: /d/cvs/src/usr.sbin/snmpd/snmpe.c,v
retrieving revision 1.46
diff -u -p -r1.46 snmpe.c
--- snmpe.c 18 Nov 2016 16:16:39 -  1.46
+++ snmpe.c 9 Apr 2017 18:28:23 -
@@ -42,7 +42,7 @@
 voidsnmpe_init(struct privsep *, struct privsep_proc *, void *);
 int snmpe_parse(struct snmp_message *);
 int snmpe_parsevarbinds(struct snmp_message *);
-voidsnmpe_response(int, struct snmp_message *);
+voidsnmpe_response(struct snmp_message *);
 unsigned long
 snmpe_application(struct ber_element *);
 voidsnmpe_sig_handler(int sig, short, void *);
@@ -489,6 +489,7 @@ snmpe_recvmsg(int fd, short sig, void *a
if ((msg = calloc(1, sizeof(*msg))) == NULL)
return;
 
+   msg->sm_sock = fd;
msg->sm_slen = sizeof(msg->sm_ss);
if ((len = recvfromto(fd, msg->sm_data, sizeof(msg->sm_data), 0,
(struct sockaddr *)>sm_ss, >sm_slen,
@@ -520,7 +521,7 @@ snmpe_recvmsg(int fd, short sig, void *a
if (snmpe_parse(msg) == -1) {
if (msg->sm_usmerr != 0 && MSG_REPORT(msg)) {
usm_make_report(msg);
-   snmpe_response(fd, msg);
+   snmpe_response(msg);
return;
} else {
snmp_msgfree(msg);
@@ -528,22 +529,22 @@ snmpe_recvmsg(int fd, short sig, void *a
}
}
 
-   snmpe_dispatchmsg(msg, fd);
+   snmpe_dispatchmsg(msg);
 }
 
 void
-snmpe_dispatchmsg(struct snmp_message *msg, int sock)
+snmpe_dispatchmsg(struct snmp_message *msg)
 {
if (snmpe_parsevarbinds(msg) == 1)
return;
 
/* not dispatched to subagent; respond directly */
msg->sm_context = SNMP_C_GETRESP;
-   snmpe_response(sock, 

Re: patch: mv(1): Add -p flag to preserve time stamps for moved directories

[bytevolcano]

On Tue, 11 Apr 2017 16:41:16 -0600
"Theo de Raadt"  wrote:

> > Note that I have noatime on this FS.  
> 
> Maybe we should remove this broken feature.
> 

I would love to know what is broken about it, so I can investigate
this and disable it on my systems if it's too risky for me to keep.

I almost never need the atime stamps, and none of the applications I
have run are broken by noatime, so I disable it where I do not need (or
want) atime updated every time a file is read.

My only reasons for having noatime there in the first place is to save
write cycles on the SSDs I use, and to improve performance on an older
system I run OpenBSD on. That being said, I do make backups regularly,
so I am happy to sacrifice some performance if need be.

Fwd: Output of netstat -m shows lower value with higher kern.maxclusters

[Marc Peters]

Forwarding this also to tech@. Any ideas, anyone?


 Weitergeleitete Nachricht 
Betreff: Output of netstat -m shows lower value with higher kern.maxclusters
Datum: Wed, 12 Apr 2017 13:47:15 +0200
Von: Marc Peters 
An: Openbsd-Misc 

Hi,

after i updated from 6.0 to 6.1, i saw that kern.maxclusters was raised
and removed our local change to kern.maxclusters.

Although the value is now way higher, the output shows a lower number
than before:

before the upgrade:
~ # sysctl kern.maxclusters
kern.maxclusters=24578

~ # netstat -m
314 mbufs in use:
298 mbufs allocated to data
6 mbufs allocated to packet headers
10 mbufs allocated to socket names and addresses
296/2192/24584 mbuf 2048 byte clusters in use (current/peak/max)
0/8/24584 mbuf 4096 byte clusters in use (current/peak/max)
0/8/24584 mbuf 8192 byte clusters in use (current/peak/max)
0/14/24584 mbuf 9216 byte clusters in use (current/peak/max)
0/10/24580 mbuf 12288 byte clusters in use (current/peak/max)
0/8/24584 mbuf 16384 byte clusters in use (current/peak/max)
0/8/24584 mbuf 65536 byte clusters in use (current/peak/max)
1948 Kbytes allocated to network (34% in use)
0 requests for memory denied
0 requests for memory delayed
0 calls to protocol drain routines


after the upgrade:
~ # sysctl kern.maxclusters
kern.maxclusters=262144

~ # netstat -m
40 mbufs in use:
24 mbufs allocated to data
5 mbufs allocated to packet headers
11 mbufs allocated to socket names and addresses
21/168/64 mbuf 2048 byte clusters in use (current/peak/max)
0/0/120 mbuf 2112 byte clusters in use (current/peak/max)
0/8/64 mbuf 4096 byte clusters in use (current/peak/max)
0/0/64 mbuf 8192 byte clusters in use (current/peak/max)
0/0/112 mbuf 9216 byte clusters in use (current/peak/max)
0/0/80 mbuf 12288 byte clusters in use (current/peak/max)
0/0/64 mbuf 16384 byte clusters in use (current/peak/max)
0/0/64 mbuf 65536 byte clusters in use (current/peak/max)
420 Kbytes allocated to network (12% in use)
0 requests for memory denied
0 requests for memory delayed
0 calls to protocol drain routines


Is this just an output issue, or are the numbers now related to other
values?

Cheers,
Marc

dmesg:
OpenBSD 6.1 (GENERIC.MP) #20: Sat Apr  1 13:45:56 MDT 2017
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 25742729216 (24550MB)
avail mem = 24957874176 (23801MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xdf7fe000 (127 entries)
bios0: vendor HP version "P68" date 07/02/2013
bios0: HP ProLiant DL360 G7
acpi0 at bios0: rev 2
acpi0: sleep states S0 S4 S5
acpi0: tables DSDT FACP SPCR MCFG HPET  SPMI ERST APIC SRAT 
BERT HEST DMAR SSDT SSDT SSDT SSDT SSDT
acpi0: wakeup devices
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimcfg0 at acpi0 addr 0xe000, bus 0-63
acpihpet0 at acpi0: 14318179 Hz
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Xeon(R) CPU X5687 @ 3.60GHz, 3600.61 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,DCA,SSE4.1,SSE4.2,POPCNT,AES,NXE,PAGE1GB,RDTSCP,LONG,LAHF,PERF,ITSC,SENSOR,ARAT
cpu0: 256KB 64b/line 8-way L2 cache
cpu0: TSC frequency 3600606060 Hz
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges
cpu0: apic clock running at 133MHz
cpu0: mwait min=64, max=64, C-substates=0.2.1.1, IBE
cpu1 at mainbus0: apid 32 (application processor)
cpu1: Intel(R) Xeon(R) CPU X5687 @ 3.60GHz, 3600.14 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,DCA,SSE4.1,SSE4.2,POPCNT,AES,NXE,PAGE1GB,RDTSCP,LONG,LAHF,PERF,ITSC,SENSOR,ARAT
cpu1: 256KB 64b/line 8-way L2 cache
cpu1: smt 0, core 0, package 1
cpu2 at mainbus0: apid 20 (application processor)
cpu2: Intel(R) Xeon(R) CPU X5687 @ 3.60GHz, 3600.13 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,DCA,SSE4.1,SSE4.2,POPCNT,AES,NXE,PAGE1GB,RDTSCP,LONG,LAHF,PERF,ITSC,SENSOR,ARAT
cpu2: 256KB 64b/line 8-way L2 cache
cpu2: smt 0, core 10, package 0
cpu3 at mainbus0: apid 52 (application processor)
cpu3: Intel(R) Xeon(R) CPU X5687 @ 3.60GHz, 3600.13 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,DCA,SSE4.1,SSE4.2,POPCNT,AES,NXE,PAGE1GB,RDTSCP,LONG,LAHF,PERF,ITSC,SENSOR,ARAT
cpu3: 256KB 64b/line 8-way L2 cache
cpu3: smt 0, core 10, package 1
cpu4 

arm64 hangs

[Mark Kettenis]

So Theo's favourite way to trigger crashes on arm64 is to run "make
-j20" in /usr/src/lib/libc.  If I do this, I don't really see any
crashes.  However somewhere halfthrough my machine just hangs.  Now
that I can break into ddb, it quickly became obvious why.  There are
lots of processes waiting on the "vp" channel.  That's the pool used
by the pmap to build page tables and keep track of mappings.  There is
still plenty of free memory when the hang happens, so the reason the
pool allocations fail must be related to a kva shortage of some sorts.

The items in the vp pool are large: 8192 bytes, 2 pages.  So the pool
uses the (interrupt-safe) multi-page allocator.  That allocator uses
the kmem_map, which only covers a rather limited part of kva space.
And when we run out, we effectively deadlock, since we have no real
push back mechanism.  We could make the kmem_map bigger, but since the
page tables can grow without a clear bound that doesn't really solve
anything.  

A better approach would be to use the non-interrupt-safe multi-page
pool allocator here.  That should be ok since we don't actually enter
userland mappings from interrupt context.  It may have some
implications for SMP though.  At the very least, future SMP work will
have to be aware that the non-interrupt-safe pool allocator may take
the kernel lock when allocating new pool pages.

Thoughts?  ok?

P.S. The current pmap_vp_enter() code suggests that it may be called
for the kernel pmap.  That isn't actually true and drahn@ had a fix
for this in his SMP patch serious.  That diff also switched from
PR_WAITOK to PR_NOWAIT, which I think is a good move.  However, doing
that without addressing the kva issue leads to a scenario where the
kernel just spins refaulting if it runs out of kva space.

Index: arch/arm64/arm64/pmap.c
===
RCS file: /cvs/src/sys/arch/arm64/arm64/pmap.c,v
retrieving revision 1.31
diff -u -p -r1.31 pmap.c
--- arch/arm64/arm64/pmap.c 4 Apr 2017 12:56:24 -   1.31
+++ arch/arm64/arm64/pmap.c 13 Apr 2017 10:05:24 -
@@ -1474,8 +1474,8 @@ pmap_init(void)
pool_init(_pted_pool, sizeof(struct pte_desc), 0, IPL_VM, 0,
"pted", NULL);
pool_setlowat(_pted_pool, 20);
-   pool_init(_vp_pool, sizeof(struct pmapvp2), PAGE_SIZE, IPL_VM, 0,
-   "vp", NULL);
+   pool_init(_vp_pool, sizeof(struct pmapvp2), PAGE_SIZE, IPL_VM,
+   PR_WAITOK, "vp", NULL);
/* pool_setlowat(_vp_pool, 20); */
 
pmap_initialized = 1;

Re: pr_input with af

[Mike Belopuhov]

On 13 April 2017 at 00:53, Alexander Bluhm  wrote:
> Hi,
>
> I would like to pass down the address family through the pr_input
> calls.  There are functions like tcp_input() and udp_input() which
> read the version from the IP header.  This layer violation could
> be avoided if they know the af.  Functions like carp_proto_input
> and carp6_proto_input could be unified.
>
> This is only the machanical part that adds an af parameter.
>
> ok?
>
> bluhm
>

No objections here, I think this is a good idea.

VCard and VCalendar MIME types

[Franco Fichtner]

Hi,

Apologies for not posting this inline for fear of mail
client whitespace mangling.

https://github.com/fichtner/openbsd/commit/05ab4bd.patch

ok?


Cheers,
Franco