Re: using a thread-local buffer for strerror()
On 2021-12-18, John Scott wrote: > I don't use OpenBSD, but I've played with it and am interested in making > my code portable to it. A trend which the GNU C Library recently got on > board with is to use a thread-local storage buffer for strerror() which > makes it safe to use across multiple threads. I was wondering if there > is a particular reason OpenBSD has not taken this approach, perhaps just > because it hasn't been raised, or if it doesn't support thread-local > storage. There isn't native support for TLS in OpenBSD. There is emulated support on architectures using clang as the system compiler but there are also a few architectures stilli using gcc (emutls was added in newer versions, but the base OS sticks with an older GPLv2 version for those arches still using gcc - newer versions are available in ports but obviously that's no good for system libraries). > From the strerror() code [1] it seems that, if OpenBSD supports a C11 > compiler, it should be as easy as adding the _Thread_local (or otherwise > the GCC/Clang-specific __thread) keyword to the static buffer. Perhaps it could be added for clang architectures easily enough, but it's often better to reduce differences between arches where possible to reduce the chance of code working on the more common archs but failing (perhaps in a bad way) on others.
Re: suspend/resume kills X
On Sat, Dec 18, 2021 at 12:25:26PM +0100, Jan Stary wrote:
> On Dec 18 08:49:33, h...@stare.cz wrote:
> > This is current/amd64 on a PC (dmesg below).
> >
> > After boot, I log into X, running cwm,
> > an xterm, and a script(1) of this.
> >
> > |-+= 14944 root /usr/X11R6/bin/xenodm
> > | |-+= 56178 _x11 /usr/X11R6/bin/X :0 vt05 -auth
> > /etc/X11/xenodm/authdir/authf
> > | | \--- 57333 root X: [priv] (Xorg)
> > | \-+= 91925 root xenodm: :0 (xenodm)
> > | \-+= 68368 hans /bin/sh /etc/X11/xenodm/Xsession
> > | \-+- 25576 hans /bin/sh /home/hans/.xsession
> > | \-+- 91387 hans cwm
> > | \-+= 20802 hans /usr/X11R6/bin/xterm
> > | \-+= 19542 hans -ksh (ksh)
> > | \-+= 28689 hans script /tmp/suspend
> > | \-+- 11621 hans script /tmp/suspend
> > | \-+= 52575 hans /bin/ksh -i
> > | \-+= 27287 hans pstree
> > | \-+- 12714 hans sh -c ps -kaxwwo user,pid,ppid,pgid,comm
> > | \--- 07440 hans ps -kaxwwo user
> >
> >
> > >From that same xterm, I suspend with zzz.
> > The messages of devices being detached are also below.
> >
> > Upon resume (messages also below), the xenodm login screen
> > is there again - the session has been killed.
> > None of the above processes is running.
> > The xenodm login does not take keyboard input.
>
> The same thing happens when zzz is called from cron
> while I am in X.
>
> But it does not happen whne I am switched to the console:
> both zzz from the command line and zzz from cron
> resume back to the console just fine;
> swithing back to X then, it's all still there.
>
> What is it that makes the difference,
> apparently resulting in killing the X session?
>
> Jan
This sounds a lot like the following known bug:
https://marc.info/?l=openbsd-bugs=148447759618744=2
https://marc.info/?l=openbsd-bugs=149005961017985=2
I work around it by switching to a different virtual console before
suspending.
This is the command I use to lock my X session, switch vts, and sleep:
xlock -startCmd 'wsconsctl -f /dev/ttyCcfg display.focus=0 && zzz'
For that to work, I need to have access to /dev/ttyCcfg. I added
/dev/ttyCcfg to /etc/X11/xenodm/{Give,Take}Console (handled the same
way as the other devices files in those scripts) to solve that. I can't
comment on the security implications of doing that.
--
James
using a thread-local buffer for strerror()
Hi, I don't use OpenBSD, but I've played with it and am interested in making my code portable to it. A trend which the GNU C Library recently got on board with is to use a thread-local storage buffer for strerror() which makes it safe to use across multiple threads. I was wondering if there is a particular reason OpenBSD has not taken this approach, perhaps just because it hasn't been raised, or if it doesn't support thread-local storage. >From the strerror() code [1] it seems that, if OpenBSD supports a C11 compiler, it should be as easy as adding the _Thread_local (or otherwise the GCC/Clang-specific __thread) keyword to the static buffer. Whether thread-local storage is allowed was clarified in POSIX [2] by a Technical Corrigendum although I have not referred to an official copy; they affirmed it can be used, so if this change were to be made in OpenBSD, it should not break conforming applications. Off-topic, but since I know someone will ask: I dislike strerror_r() and strerror_l() because they are allowed to fail, and since POSIX places no restrictions, that means they are allowed to fail for any reason. Even on failure, plain strerror() is always required to return a valid NUL- terminated string of some sort, which makes it convenient. In order to use perror(), one has to assign the error number to errno, which in the case of functions like POSIX threads seems to somewhat defeat the point of the design of the interfaces in my opinion. Thanks, John [1] https://cvsweb.openbsd.org/cgi-bin/cvsweb/~checkout~/src/lib/libc/string/strerror.c [2] https://www.austingroupbugs.net/view.php?id=656 signature.asc Description: This is a digitally signed message part
Re: Profiling ifconfig
On 2021-12-17, Vladimir Nikishkin wrote: > 78429 ifconfig 1639744429.761947 CALL ioctl(3,SIOCSIFFLAGS,0x7f7bda80) > 78429 ifconfig 1639744660.684179 RET ioctl 0 > ``` > > I have no idea what this means, to be honest. > ioctl(3,SIOCSIFFLAGS,0x7f7bda80) seems to be the one running for > 231 second. Yes. > I looked at the code of if_vio.c, and it seems to be taking time at > calling vio_init (as there is not much more in this ioctl), however, I > do not know much about debugging kernel drivers, so suggestions welcome >:). > > Is there a way to recompile it with profiling/tracing information, or > maybe just putting printfs manually around the most interesting lines > would be more productive? Adding printf is pretty much perfect for this. General compile steps: cd /sys/arch/amd64/compile/GENERIC.MP make obj make config make sudo make install Recommend you save a known-good kernel e.g. in /bsd.ok, so you can"boot bsd.ok" at the boot loader prompt if you need it.
Re: suspend/resume kills X
On Dec 18 08:49:33, h...@stare.cz wrote: > This is current/amd64 on a PC (dmesg below). > > After boot, I log into X, running cwm, > an xterm, and a script(1) of this. > > |-+= 14944 root /usr/X11R6/bin/xenodm > | |-+= 56178 _x11 /usr/X11R6/bin/X :0 vt05 -auth > /etc/X11/xenodm/authdir/authf > | | \--- 57333 root X: [priv] (Xorg) > | \-+= 91925 root xenodm: :0 (xenodm) > | \-+= 68368 hans /bin/sh /etc/X11/xenodm/Xsession > | \-+- 25576 hans /bin/sh /home/hans/.xsession > | \-+- 91387 hans cwm > | \-+= 20802 hans /usr/X11R6/bin/xterm > | \-+= 19542 hans -ksh (ksh) > | \-+= 28689 hans script /tmp/suspend > | \-+- 11621 hans script /tmp/suspend > | \-+= 52575 hans /bin/ksh -i > | \-+= 27287 hans pstree > | \-+- 12714 hans sh -c ps -kaxwwo user,pid,ppid,pgid,comm > | \--- 07440 hans ps -kaxwwo user > > > >From that same xterm, I suspend with zzz. > The messages of devices being detached are also below. > > Upon resume (messages also below), the xenodm login screen > is there again - the session has been killed. > None of the above processes is running. > The xenodm login does not take keyboard input. The same thing happens when zzz is called from cron while I am in X. But it does not happen whne I am switched to the console: both zzz from the command line and zzz from cron resume back to the console just fine; swithing back to X then, it's all still there. What is it that makes the difference, apparently resulting in killing the X session? Jan > Console works, so I login there and restart xenodm > - then the X login screen does take my login. > > The last thing Xorg.log says (also below) > after a seemingly normal X start is: > > AIGLX: Suspending AIGLX clients for VT switch > > Why would the entire X session get killed? > Why would the X keyboard no longer work? > What can I do to help debug this? > > Jan > > > boot: > > OpenBSD 7.0-current (GENERIC.MP) #0: Wed Dec 15 17:20:28 CET 2021 > h...@box.stare.cz:/usr/src/sys/arch/amd64/compile/GENERIC.MP > real mem = 10567155712 (10077MB) > avail mem = 10147008512 (9676MB) > random: good seed from bootblocks > mpath0 at root > scsibus0 at mpath0: 256 targets > mainbus0 at root > bios0 at mainbus0: SMBIOS rev. 2.4 @ 0xf0100 (36 entries) > bios0: vendor Award Software International, Inc. version "F3" date 03/31/2011 > bios0: Gigabyte Technology Co., Ltd. H67MA-USB3-B3 > acpi0 at bios0: ACPI 1.0 > acpi0: sleep states S0 S3 S4 S5 > acpi0: tables DSDT FACP HPET MCFG ASPT SSPT EUDS MATS TAMG APIC SSDT > acpi0: wakeup devices PCI0(S5) PEX0(S5) PEX1(S5) PEX2(S5) PEX3(S5) PEX4(S5) > PEX5(S5) PEX6(S5) PEX7(S5) HUB0(S5) UAR1(S3) USBE(S3) USE2(S3) AZAL(S5) > acpitimer0 at acpi0: 3579545 Hz, 24 bits > acpihpet0 at acpi0: 14318179 Hz > acpimcfg0 at acpi0 > acpimcfg0: addr 0xf400, bus 0-63 > acpimadt0 at acpi0 addr 0xfee0: PC-AT compat > cpu0 at mainbus0: apid 0 (boot processor) > cpu0: Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz, 3392.82 MHz, 06-2a-07 > 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,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN > cpu0: 256KB 64b/line 8-way L2 cache > cpu0: smt 0, core 0, package 0 > mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges > cpu0: apic clock running at 99MHz > cpu0: mwait min=64, max=64, C-substates=0.2.1.1, IBE > cpu1 at mainbus0: apid 2 (application processor) > cpu1: Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz, 3392.31 MHz, 06-2a-07 > 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,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN > cpu1: 256KB 64b/line 8-way L2 cache > cpu1: smt 0, core 1, package 0 > cpu2 at mainbus0: apid 4 (application processor) > cpu2: Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz, 3392.31 MHz, 06-2a-07 > 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,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN > cpu2: 256KB 64b/line 8-way L2 cache > cpu2: smt 0, core 2, package 0 > cpu3 at mainbus0: apid 6 (application processor) > cpu3: Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz, 3392.31 MHz, 06-2a-07 > cpu3: >
