vmm/i386 __func__
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->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->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->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_v
sysctl.3: Fix file path
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
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 *)&msg->sm_ss, &msg->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, msg);
Re: patch: mv(1): Add -p flag to preserve time stamps for moved directories
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
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 at mainbus0: apid 2 (application proce
arm64 hangs
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(&pmap_pted_pool, sizeof(struct pte_desc), 0, IPL_VM, 0, "pted", NULL); pool_setlowat(&pmap_pted_pool, 20); - pool_init(&pmap_vp_pool, sizeof(struct pmapvp2), PAGE_SIZE, IPL_VM, 0, - "vp", NULL); + pool_init(&pmap_vp_pool, sizeof(struct pmapvp2), PAGE_SIZE, IPL_VM, + PR_WAITOK, "vp", NULL); /* pool_setlowat(&pmap_vp_pool, 20); */ pmap_initialized = 1;
Re: pr_input with af
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
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