Re: ping -R causes panic

[George Brown]

I can reproduce this after updating to the Sept 18th snapshot, I did not
observe this on my Aug 20 snapshot install if that aids in narrowing
down when this was introduced.

I suspect reporting this to bugs rather than misc may be a better course
of action.

https://www.openbsd.org/report.html

On 20 September 2017 at 12:26, Kapetanakis Giannis
 wrote:
> I got this panic today after ping -R
> I don't run pfsync
>
> # ping -R www.google.com
> panic: kernel diagnostic assertion "m0->m_flags & M_PKTHDR" failed: file 
> "/usr/src/sys/kern/uipc_mbuf.c", line 1344splassert: pfsync_update_state: 
> want 1 have 256
>
> pStopped at  db_enter+0x5:   popq%rbp
> TIDPIDUID PRFLAGS PFLAGS  CPU  COMMAND
> *299140  12380 510x33  02  ping
>  422116  15532  0 0x14000  0x2001  softnet
> db_enter() at db_enter+0x5
> panic() at panic+0x128
> __assert(81020a74,80002692f4a0,0,1) at __assert+0x24
> m_dup_pkt(ff010c77caf8,1,ff00baab064b) at m_dup_pkt+0x225
> ip_pcbopts(1,ff00baab0600) at ip_pcbopts+0x138
> sosetopt(ff010947b018,800026798d68,80002692f5f0,ff00baab0600) 
> a
> t sosetopt+0xd0
> sys_setsockopt(80002692f680,690,800026798d68) at sys_setsockopt+0x13d
> syscall() at syscall+0x270
> --- syscall (number 105) ---
> end of kernel
> end trace frame: 0x7f7bf230, count: 7
> 0xc362b93239a:
>
>
> OpenBSD 6.2-beta (GENERIC.MP) #86: Sun Sep 10 10:07:51 MDT 2017
> dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> real mem = 4273274880 (4075MB)
> avail mem = 4136747008 (3945MB)
> mpath0 at root
> scsibus0 at mpath0: 256 targets
> mainbus0 at root
> bios0 at mainbus0: SMBIOS rev. 2.5 @ 0xcfb9c000 (67 entries)
> bios0: vendor Dell Inc. version "2.7.0" date 10/30/2010
> bios0: Dell Inc. PowerEdge 1950
> acpi0 at bios0: rev 2
> acpi0: sleep states S0 S4 S5
> acpi0: tables DSDT FACP APIC SPCR HPET MCFG WD__ SLIC ERST HEST BERT EINJ TCPA
> acpi0: wakeup devices PCI0(S5)
> acpitimer0 at acpi0: 3579545 Hz, 24 bits
> acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
> cpu0 at mainbus0: apid 0 (boot processor)
> cpu0: Intel(R) Xeon(R) CPU E5405 @ 2.00GHz, 1995.26 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,DTES64,MWAIT,DS-CPL,VMX,TM2,SSSE3,CX16,xTPR,PDCM,DCA,SSE4.1,NXE,LONG,LAHF,PERF,SENSOR
> cpu0: 6MB 64b/line 16-way L2 cache
> cpu0: smt 0, core 0, package 0
> mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
> cpu0: apic clock running at 332MHz
> cpu0: mwait min=64, max=64, C-substates=0.2.2.2, IBE
> cpu1 at mainbus0: apid 2 (application processor)
> cpu1: Intel(R) Xeon(R) CPU E5405 @ 2.00GHz, 1995.01 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,DTES64,MWAIT,DS-CPL,VMX,TM2,SSSE3,CX16,xTPR,PDCM,DCA,SSE4.1,NXE,LONG,LAHF,PERF,SENSOR
> cpu1: 6MB 64b/line 16-way L2 cache
> cpu1: smt 0, core 2, package 0
> cpu2 at mainbus0: apid 1 (application processor)
> cpu2: Intel(R) Xeon(R) CPU E5405 @ 2.00GHz, 1995.01 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,DTES64,MWAIT,DS-CPL,VMX,TM2,SSSE3,CX16,xTPR,PDCM,DCA,SSE4.1,NXE,LONG,LAHF,PERF,SENSOR
> cpu2: 6MB 64b/line 16-way L2 cache
> cpu2: smt 0, core 1, package 0
> cpu3 at mainbus0: apid 3 (application processor)
> cpu3: Intel(R) Xeon(R) CPU E5405 @ 2.00GHz, 1995.01 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,DTES64,MWAIT,DS-CPL,VMX,TM2,SSSE3,CX16,xTPR,PDCM,DCA,SSE4.1,NXE,LONG,LAHF,PERF,SENSOR
> cpu3: 6MB 64b/line 16-way L2 cache
> cpu3: smt 0, core 3, package 0
> ioapic0 at mainbus0: apid 4 pa 0xfec0, version 20, 24 pins
> , remapped to apid 4
> acpihpet0 at acpi0: 14318179 Hz
> acpimcfg0 at acpi0 addr 0xe000, bus 0-255
> acpiprt0 at acpi0: bus 0 (PCI0)
> acpiprt1 at acpi0: bus 4 (PEX2)
> acpiprt2 at acpi0: bus 5 (UPST)
> acpiprt3 at acpi0: bus 6 (DWN1)
> acpiprt4 at acpi0: bus 8 (DWN2)
> acpiprt5 at acpi0: bus 1 (PEX3)
> acpiprt6 at acpi0: bus -1 (PE2P)
> acpiprt7 at acpi0: bus 10 (PEX4)
> acpiprt8 at acpi0: bus -1 (PE2P)
> acpiprt9 at acpi0: bus 12 (PEX6)
> acpiprt10 at acpi0: bus 2 (SBEX)
> acpiprt11 at acpi0: bus 14 (COMP)
> acpicpu0 at acpi0: C1(@1 halt!)
> acpicpu1 at acpi0: C1(@1 halt!)
> acpicpu2 at acpi0: C1(@1 halt!)
> acpicpu3 at acpi0: C1(@1 halt!)
> "PNP0C33" at acpi0 not configured
> "PNP0700" at acpi0 not configured
> "IPI0001" at acpi0 not configured
> ipmi at mainbus0 not configured
> pci0 at mainbus0 bus 0
> pchb0 at pci0 dev 0 function 0 "Intel 5000X Host" rev 0x12
> ppb0 at pci0 dev 2 function 0 "Intel 5000 PCIE" rev 0x12
> pci1 at ppb0 bus 4
> ppb1 at pci1 dev 0 function 0 "Intel 6321ESB PCIE" rev 0x01
> pci2 at ppb1 bus 5
> 

Re: log up or down interface end change physical address

[George Brown]

There's ifstated - http://man.openbsd.org/ifstated

On 21 September 2017 at 14:29, Krzysztof Strzeszewski  wrote:
> Hi,
>
> How to log up or down (connect or not connect cable) interface end change
> physical address on OpenBSD?
>
>
> --
> Regards,
> Krzysztof Strzeszewski
>

Query regarding exec in mandocdb.c

[George Brown]

In mandocdb.c it appears cmp(1) and rm(1) are executed in a child
process. It seems that if the logic from these programs were duplicated
the pledge in mandocdb.c could be further restricted and even not bother
with forking.

Would such a change be pointless churn however? Both cmp(1) and rm(1)
are simple programs and are pledge'd themselves. Not to mention the
creation of the mandoc database is in itself a short lived process.

To be clear I'm not proposing a change (indeed I have no diff) but
rather I am simply curious to the opinion of others in the OpenBSD
community.

Kind regards,
George

Re: Query regarding exec in mandocdb.c

[George Brown]

Thank you for the replies Ingo and the diffs!

George Brown


On 26 August 2017 at 17:04, Ingo Schwarze <schwa...@usta.de> wrote:
> Hi George,
>
> George Brown wrote on Thu, Aug 24, 2017 at 02:01:05PM +0100:
>
>> In mandocdb.c it appears cmp(1) and rm(1) are executed in a child
>> process. It seems that if the logic from these programs were duplicated
>> the pledge in mandocdb.c could be further restricted and even not bother
>> with forking.
>
> Done as well, see the commit below.
>
> Thanks again for the suggestion,
>   Ingo
>
>
> Log Message:
> ---
> Do not fork and exec cmp(1); instead, simply fstat(2), mmap(2), and
> compare the files directly, allowing a much stricter pledge(2), at
> very little cost: merely 15 additional lines of very simple code.
> Suggested by George Brown <321 dot george at gmail dot com> on misc@.
>
> Modified Files:
> --
> mandoc:
> mandocdb.c
>
> Revision Data
> -
> Index: mandocdb.c
> ===
> RCS file: /home/cvs/mandoc/mandoc/mandocdb.c,v
> retrieving revision 1.254
> retrieving revision 1.255
> diff -Lmandocdb.c -Lmandocdb.c -u -p -r1.254 -r1.255
> --- mandocdb.c
> +++ mandocdb.c
> @@ -19,8 +19,8 @@
>  #include "config.h"
>
>  #include 
> +#include 
>  #include 
> -#include 
>
>  #include 
>  #include 
> @@ -319,7 +319,7 @@ mandocdb(int argc, char *argv[])
> int   ch, i;
>
>  #if HAVE_PLEDGE
> -   if (pledge("stdio rpath wpath cpath fattr flock proc exec", NULL) == 
> -1) {
> +   if (pledge("stdio rpath wpath cpath", NULL) == -1) {
> warn("pledge");
> return (int)MANDOCLEVEL_SYSERR;
> }
> @@ -440,15 +440,6 @@ mandocdb(int argc, char *argv[])
>  * The existing database is usable.  Process
>  * all files specified on the command-line.
>  */
> -#if HAVE_PLEDGE
> -   if (!nodb) {
> -   if (pledge("stdio rpath wpath cpath fattr 
> flock", NULL) == -1) {
> -   warn("pledge");
> -   exitcode = (int)MANDOCLEVEL_SYSERR;
> -   goto out;
> -   }
> -   }
> -#endif
> use_all = 1;
> for (i = 0; i < argc; i++)
> filescan(argv[i]);
> @@ -2119,9 +2110,10 @@ dbprune(struct dba *dba)
>  static void
>  dbwrite(struct dba *dba)
>  {
> -   char tfn[33];
> -   int  status;
> -   pid_tchild;
> +   struct stat  sb1, sb2;
> +   char tfn[33], *cp1, *cp2;
> +   off_ti;
> +   int  fd1, fd2;
>
> /*
>  * Do not write empty databases, and delete existing ones
> @@ -2160,39 +2152,59 @@ dbwrite(struct dba *dba)
> say("", "&%s", tfn);
> return;
> }
> -
> +   cp1 = cp2 = NULL;
> +   fd1 = fd2 = -1;
> (void)strlcat(tfn, "/" MANDOC_DB, sizeof(tfn));
> if (dba_write(tfn, dba) == -1) {
> -   exitcode = (int)MANDOCLEVEL_SYSERR;
> say(tfn, "_write");
> -   goto out;
> -   }
> -
> -   switch (child = fork()) {
> -   case -1:
> -   exitcode = (int)MANDOCLEVEL_SYSERR;
> -   say("", " cmp");
> -   return;
> -   case 0:
> -   execlp("cmp", "cmp", "-s", tfn, MANDOC_DB, (char *)NULL);
> -   say("", " cmp");
> -   exit(0);
> -   default:
> -   break;
> -   }
> -   if (waitpid(child, , 0) == -1) {
> -   exitcode = (int)MANDOCLEVEL_SYSERR;
> -   say("", " cmp");
> -   } else if (WIFSIGNALED(status)) {
> -   exitcode = (int)MANDOCLEVEL_SYSERR;
> -   say("", "cmp died from signal %d", WTERMSIG(status));
> -   } else if (WEXITSTATUS(status)) {
> -   exitcode = (int)MANDOCLEVEL_SYSERR;
> -   say(MANDOC_DB,
> -   "Data changed, but cannot replace database");
> +   goto err;
> }
> +   if ((fd1 = open(MANDOC_DB, O_RDONLY, 0)) == -1) 

Continuation of stopped process in tmux

[George Brown]

It appears in handling SIGCHLD if the child is stopped due to SIGTSTP
or SIGSTOP then it is continued. Indeed screen appears to do the same.
Could someone kindly explain to me why this is done?

I ask as dvtm (another terminal multiplexer) hits an issue on MacOS
where what would be called "panes" in tmux parlance hang on the shell
exit due to being stopped. As to why the shells end up stopped on MacOS
is something I've yet to fiugre out.

Many thanks,
George

Usage of .note.openbsd.ident

[George Brown]

It seems this ELF note was used for the now dead compat_linux feature.
Aside from compat systems in other operating systems that may wish to
identify OpenBSD binaries does this note have any other active uses?

Re: Usage of .note.openbsd.ident

[George Brown]

Thank you for the reply, I was just curious.

On Thu, 27 May 2021 at 04:21, Philip Guenther  wrote:
>
> On Fri, May 21, 2021 at 5:28 AM George Brown <321.geo...@gmail.com> wrote:
>>
>> It seems this ELF note was used for the now dead compat_linux feature.
>> Aside from compat systems in other operating systems that may wish to
>> identify OpenBSD binaries does this note have any other active uses?
>
>
> The point of the note (and/or the OS/ABI field in the ELF header) is to 
> permit portable ELF tools to identify how to interpret OS-specific values, 
> those in the OS-ranges for types, for example.  Not inserting _some_ 
> identifying factor is basically doing an embrace-and-extend on ELF and 
> actively hostile to portability of tooling.
>
> If you find that ELF note obnoxious, just fix the linkers to instead set the 
> ELF ABI field correctly.  As I understand it, the 'go' tool chain has done 
> that for years.  It's really the better choice for this, would take less 
> space and be faster to process.
>
>
> Philip Guenther
>