Re: Emulated TLS for clang

[Otto Moerbeek]

On Sun, May 07, 2017 at 05:37:47PM +0200, Mark Kettenis wrote:

> So this enables the code.  It makes -femulated-tls the default,
> otherwise it will generated TLS relocations that we can't handle yet.
> It is possible to specify -fno-emulated-tls if you really want to
> generate those.
> 
> A trivial example program that modifies the variable in one thread and
> prints it in another seems to work as expected.
> 
> Note that the libcompiler_rt implementation unconditionally references
> some symbols in libpthread.  So linking with -lpthread is mandatory.
> GCC 4.9 uses weak references, so -lpthread isn't needed there.
> 
> Perhaps those functions should move to libc.  Or we can make the
> libcompiler_rt code a bit smarter.
> 
> Also note that the libcompiler_rt implementation offers the choice
> between posix_memalign() and normal malloc().  With this diff it uses
> malloc().  Perhaps otto@ has an opinion what's better here?

No real opinion. Since the deafult implementation is malloc, I guess
that is better tested. BTW, I do not trust our posix_memalign to play
nice in all cases. It's on my list of things to check.

-Otto

> 
> 
> Index: gnu/llvm/tools/clang/lib/Basic/Targets.cpp
> ===
> RCS file: /cvs/src/gnu/llvm/tools/clang/lib/Basic/Targets.cpp,v
> retrieving revision 1.7
> diff -u -p -r1.7 Targets.cpp
> --- gnu/llvm/tools/clang/lib/Basic/Targets.cpp14 Mar 2017 08:11:34 
> -  1.7
> +++ gnu/llvm/tools/clang/lib/Basic/Targets.cpp7 May 2017 15:25:08 
> -
> @@ -549,8 +549,6 @@ protected:
>  public:
>OpenBSDTargetInfo(const llvm::Triple , const TargetOptions )
>: OSTargetInfo(Triple, Opts) {
> -this->TLSSupported = false;
> -
>switch (Triple.getArch()) {
>  default:
>  case llvm::Triple::x86:
> Index: gnu/llvm/tools/clang/lib/Driver/Tools.cpp
> ===
> RCS file: /cvs/src/gnu/llvm/tools/clang/lib/Driver/Tools.cpp,v
> retrieving revision 1.10
> diff -u -p -r1.10 Tools.cpp
> --- gnu/llvm/tools/clang/lib/Driver/Tools.cpp 24 Jan 2017 08:39:08 -  
> 1.10
> +++ gnu/llvm/tools/clang/lib/Driver/Tools.cpp 7 May 2017 15:25:09 -
> @@ -5370,7 +5370,8 @@ void Clang::ConstructJob(Compilation ,
>Args.AddLastArg(CmdArgs, options::OPT_fno_operator_names);
>// Emulated TLS is enabled by default on Android, and can be enabled 
> manually
>// with -femulated-tls.
> -  bool EmulatedTLSDefault = Triple.isAndroid() || 
> Triple.isWindowsCygwinEnvironment();
> +  bool EmulatedTLSDefault = Triple.isAndroid() || Triple.isOSOpenBSD() ||
> +Triple.isWindowsCygwinEnvironment();
>if (Args.hasFlag(options::OPT_femulated_tls, options::OPT_fno_emulated_tls,
> EmulatedTLSDefault))
>  CmdArgs.push_back("-femulated-tls");
> Index: lib/libcompiler_rt/Makefile
> ===
> RCS file: /cvs/src/lib/libcompiler_rt/Makefile,v
> retrieving revision 1.7
> diff -u -p -r1.7 Makefile
> --- lib/libcompiler_rt/Makefile   17 Apr 2017 15:53:21 -  1.7
> +++ lib/libcompiler_rt/Makefile   7 May 2017 15:25:09 -
> @@ -64,6 +64,7 @@ GEN_SRCS=   absvdi2 \
>   divti3 \
>   divtf3 \
>   divxc3 \
> + emutls \
>   enable_execute_stack \
>   eprintf \
>   extendsfdf2 \

Re: routing socket panic

[Ted Unangst]

Ted Unangst wrote:
> Mike Belopuhov wrote:
> > > So there is something in the tree that doesn't like the mbuf packet
> > > header growth and decides to color outside the lines.
> > > 
> > 
> > After looking into this with Mark, he has found out that the size of
> > an mbuf structure on armv7 and hppa has exceeded MSIZE (256 bytes).
> 
> woah, there's no assert to check that? here's a quickie compile time diff.

ah, there is a CTASSERT macro. thought we had one, but didn't see it.


Index: uipc_mbuf.c
===
RCS file: /cvs/src/sys/kern/uipc_mbuf.c,v
retrieving revision 1.245
diff -u -p -r1.245 uipc_mbuf.c
--- uipc_mbuf.c 7 Feb 2017 07:00:21 -   1.245
+++ uipc_mbuf.c 8 May 2017 01:28:00 -
@@ -161,6 +161,8 @@ mbinit(void)
int i;
unsigned int lowbits;
 
+   CTASSERT(MSIZE >= sizeof(struct mbuf));
+
m_pool_allocator.pa_pagesz = pool_allocator_multi.pa_pagesz;
 
nmbclust_update();

bypass support for iommu on sparc64

[David Gwynne]

on modern sparc64s (think fire or sparc enterprise Mx000 boxes),
setting up and tearing down the translation table entries (TTEs)
is very expensive. so expensive that the cost of doing it for disk
io has a noticable impact on compile times.

now that there's a BUS_DMA_64BIT flag, we can use that to decide
to bypass the iommu for devices that set that flag, therefore
avoiding the cost of handling the TTEs.

the following diff adds support for bypass mappings to the iommu
code on sparc64. it's based on a diff from kettenis@ back in 2009.
the main changes are around coping with the differences between
schizo/psycho and fire/oberon.

the differences between the chips are now represented by a iommu_hw
struct. these differences include how to enable the iommu (now via
a function pointer), and masks for bypass addresses.

ive tested this on oberon (on an m4000) and schizo (on a v880).
however, the bypass code isnt working on fire (v245s). to cope with
that for now, the iommu_hw struct lets drivers mask flag bits that
are handled when creating a dmamap. this means fire boards will
ignore BUS_DMA_64BIT until i can figure out whats wrong with them.

i have not tested this on psycho yet. if anyone has such a machine
and is willing to work with me to figure it out, please talk to me.

Index: dev/iommu.c
===
RCS file: /cvs/src/sys/arch/sparc64/dev/iommu.c,v
retrieving revision 1.74
diff -u -p -r1.74 iommu.c
--- dev/iommu.c 30 Apr 2017 16:45:45 -  1.74
+++ dev/iommu.c 8 May 2017 00:45:05 -
@@ -100,6 +100,25 @@ void iommu_iomap_clear_pages(struct iomm
 void _iommu_dvmamap_sync(bus_dma_tag_t, bus_dma_tag_t, bus_dmamap_t,
 bus_addr_t, bus_size_t, int);
 
+void iommu_hw_enable(struct iommu_state *);
+
+const struct iommu_hw iommu_hw_default = {
+   .ihw_enable = iommu_hw_enable,
+
+   .ihw_dvma_pa= IOTTE_PAMASK,
+
+   .ihw_bypass = 0x3fffUL << 50,
+   .ihw_bypass_nc  = 0,
+   .ihw_bypass_ro  = 0,
+};
+
+void
+iommu_hw_enable(struct iommu_state *is)
+{
+   IOMMUREG_WRITE(is, iommu_tsb, is->is_ptsb);
+   IOMMUREG_WRITE(is, iommu_cr, IOMMUCR_EN | (is->is_tsbsize << 16));
+}
+
 /*
  * Initiate an STC entry flush.
  */
@@ -125,7 +144,8 @@ iommu_strbuf_flush(struct strbuf_ctl *sb
  * - create a private DVMA map.
  */
 void
-iommu_init(char *name, struct iommu_state *is, int tsbsize, u_int32_t iovabase)
+iommu_init(char *name, const struct iommu_hw *ihw, struct iommu_state *is,
+int tsbsize, u_int32_t iovabase)
 {
psize_t size;
vaddr_t va;
@@ -149,13 +169,9 @@ iommu_init(char *name, struct iommu_stat
 * be hard-wired, so we read the start and size from the PROM and
 * just use those values.
 */
-   if (strncmp(name, "pyro", 4) == 0) {
-   is->is_cr = IOMMUREG_READ(is, iommu_cr);
-   is->is_cr &= ~IOMMUCR_FIRE_BE;
-   is->is_cr |= (IOMMUCR_FIRE_SE | IOMMUCR_FIRE_CM_EN |
-   IOMMUCR_FIRE_TE);
-   } else 
-   is->is_cr = IOMMUCR_EN;
+
+   is->is_hw = ihw;
+
is->is_tsbsize = tsbsize;
if (iovabase == (u_int32_t)-1) {
is->is_dvmabase = IOTSB_VSTART(is->is_tsbsize);
@@ -237,15 +253,6 @@ iommu_init(char *name, struct iommu_stat
mtx_init(>is_mtx, IPL_HIGH);
 
/*
-* Set the TSB size.  The relevant bits were moved to the TSB
-* base register in the PCIe host bridges.
-*/
-   if (strncmp(name, "pyro", 4) == 0)
-   is->is_ptsb |= is->is_tsbsize;
-   else
-   is->is_cr |= (is->is_tsbsize << 16);
-
-   /*
 * Now actually start up the IOMMU.
 */
iommu_reset(is);
@@ -262,10 +269,7 @@ iommu_reset(struct iommu_state *is)
 {
int i;
 
-   IOMMUREG_WRITE(is, iommu_tsb, is->is_ptsb);
-
-   /* Enable IOMMU */
-   IOMMUREG_WRITE(is, iommu_cr, is->is_cr);
+   (*is->is_hw->ihw_enable)(is);
 
for (i = 0; i < 2; ++i) {
struct strbuf_ctl *sb = is->is_sb[i];
@@ -280,7 +284,7 @@ iommu_reset(struct iommu_state *is)
printf(", STC%d enabled", i);
}
 
-   if (is->is_flags & IOMMU_FLUSH_CACHE)
+   if (ISSET(is->is_hw->ihw_flags, IOMMU_HW_FLUSH_CACHE))
IOMMUREG_WRITE(is, iommu_cache_invalidate, -1ULL);
 }
 
@@ -433,7 +437,7 @@ iommu_extract(struct iommu_state *is, bu
if (dva >= is->is_dvmabase && dva <= is->is_dvmaend)
tte = is->is_tsb[IOTSBSLOT(dva, is->is_tsbsize)];
 
-   return (tte & IOTTE_PAMASK);
+   return (tte & is->is_hw->ihw_dvma_pa);
 }
 
 /*
@@ -601,8 +605,11 @@ iommu_dvmamap_create(bus_dma_tag_t t, bu
 {
int ret;
bus_dmamap_t map;
+   struct iommu_state *is = sb->sb_iommu;
struct iommu_map_state *ims;
 
+   flags &= ~is->is_hw->ihw_dma_flags;
+
BUS_DMA_FIND_PARENT(t, _dmamap_create);
ret = 

Re: Emulated TLS for clang

[Juan Francisco Cantero Hurtado]

On Sun, May 07, 2017 at 05:37:47PM +0200, Mark Kettenis wrote:
> So this enables the code.  It makes -femulated-tls the default,
> otherwise it will generated TLS relocations that we can't handle yet.
> It is possible to specify -fno-emulated-tls if you really want to
> generate those.
> 
> A trivial example program that modifies the variable in one thread and
> prints it in another seems to work as expected.
> 
> Note that the libcompiler_rt implementation unconditionally references
> some symbols in libpthread.  So linking with -lpthread is mandatory.
> GCC 4.9 uses weak references, so -lpthread isn't needed there.
> 
> Perhaps those functions should move to libc.  Or we can make the
> libcompiler_rt code a bit smarter.
> 
> Also note that the libcompiler_rt implementation offers the choice
> between posix_memalign() and normal malloc().  With this diff it uses
> malloc().  Perhaps otto@ has an opinion what's better here?

lang/racket-minimal builds and passes the tests (which includes tests
for the TLS related functionality).


-- 
Juan Francisco Cantero Hurtado http://juanfra.info

Re: sndio - sio_getcap() clarification

[Andre Smagin]

On Mon, 8 May 2017 00:03:02 +0200
Alexandre Ratchov  wrote:

> On Sun, May 07, 2017 at 02:10:03PM -0400, Andre Smagin wrote:
> > 
> > >From my limited testing it appears that sio_getcap() fails if audio
> > device does not have identical recording and playback capabilities
> > (examples at the end). If that is indeed the case, could it possibly be
> > mentioned in the man page somewhere? Perhaps something like:
> 
> The encoding and sample rate are common to play and record.  I mean
> the audio stack assumes play and record parameters (except channels
> count) are the same in full-duplex.
> 
> What you observe seems to be a driver or libsndio bug.  Could you
> send the output of your program (or "cap") with SNDIO_DEBUG=1
> environment variable exported, and the related dmesg lines?

I see. Would the manpage bit about different capabilities for SIO_REC and
SIO_PLAY modes still be of use? I know I failed to realize at first
that capabilities could be different based on how the device was opened.

Here is the log from my worst offender system:
$ export SNDIO_DEBUG=1
$ export AUDIODEVICE=rsnd/0
$ cap -p config 0
enc: s16le s24le
pchan: 2
rchan:
rate: 44100 48000 96000
$ cap -r 
config 0
enc: s16le
pchan:
rchan: 2
rate: 44100 48000 96000
$ cap
AUDIO_SETPAR: Operation not supported by device
sio_getcap() failed
$ cap 
/dev/audio0: Operation not supported by device
sio_open() failed
$ cap 
/dev/audio0: Operation not supported by device
sio_open() failed
$ cap -p
config 0
enc: s16le s24le
pchan: 2
rchan:
rate: 44100 48000 96000
$ cap
/dev/audio0: Operation not supported by device
sio_open() failed
$ cap 
AUDIO_SETPAR: Operation not supported by device
sio_getcap() failed

On this system, after sio_getcap fails for the first time, any further
sio_getpar and get_getcap requests become unreliable/inconsistent and
occasionally completely lock-up the sound subsystem, so the device cannot
be opened at all - have to reboot at this point. Opening the device
only in SIO_PLAY or SIO_REC mode sometimes sort-of resets it (as you can see
in the log above). Also get this on console for every failed sio_getcap:

audio0: different play and record parameters returned by hardware

>From dmesg (full dmesg at the end):
azalia1 at pci0 dev 20 function 2 "AMD Hudson-2 HD Audio" rev 0x02: apic 5 int 
16
azalia1: codecs: Realtek ALC662
audio0 at azalia1

Second system with the same symptoms, but without noticed
hard lock-ups yet (running "cap -p" or "cap -r" seems to reset it):

$ cap 
/dev/audio0: Operation not supported by device
sio_open() failed
$ cap -r
config 0
enc: s16le
pchan:
rchan: 2
rate: 44100 48000 96000
$ cap -p 
config 0
enc: s16le s24le
pchan: 2
rchan:
rate: 44100 48000 96000
$ cap
AUDIO_SETPAR: Operation not supported by device
sio_getcap() failed
$ cap 
/dev/audio0: Operation not supported by device
sio_open() failed

This one is:
azalia0 at pci0 dev 20 function 2 "ATI SBx00 HD Audio" rev 0x40: apic 2 int 16
azalia0: codecs: Realtek ALC662
audio0 at azalia0

Dmesg for the first system:
OpenBSD 6.1-current (GENERIC.MP) #55: Fri Apr 14 13:54:33 MDT 2017
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 1535582208 (1464MB)
avail mem = 1484423168 (1415MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xebe10 (16 entries)
bios0: vendor American Megatrends Inc. version "4.6.5" date 04/22/2014
bios0: BIOSTAR Group A68N-5000
acpi0 at bios0: rev 2
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP APIC FPDT MCFG HPET SSDT SSDT CRAT SSDT SSDT
acpi0: wakeup devices RTL_(S4) LOM_(S4) SBAZ(S4) OHC1(S4) EHC1(S4) OHC2(S4) 
EHC2(S4) OHC3(S4) EHC3(S4) XHC0(S4) BR11(S4) PWRB(S4)
acpitimer0 at acpi0: 3579545 Hz, 32 bits
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: AMD A4-5000 APU with Radeon(TM) HD Graphics, 1497.40 MHz
cpu0: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,TOPEXT,ITSC,BMI1
cpu0: 32KB 64b/line 2-way I-cache, 32KB 64b/line 8-way D-cache, 2MB 64b/line 
16-way L2 cache
cpu0: ITLB 32 4KB entries fully associative, 8 4MB entries fully associative
cpu0: DTLB 40 4KB entries fully associative, 8 4MB entries fully associative
cpu0: TSC frequency 1497400130 Hz
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
cpu0: apic clock running at 99MHz
cpu0: mwait min=64, max=64, IBE
cpu1 at mainbus0: apid 1 (application processor)
cpu1: AMD A4-5000 APU with Radeon(TM) HD Graphics, 1497.20 MHz
cpu1: 

[patch] ND_COMPUTER_RTIME is not uniformly distributed

[Matthew Martin]

RFC 4861 specifies ReachableTime "should be a uniformly distributed
random value between MIN_RANDOM_FACTOR and MAX_RANDOM_FACTOR times
BaseReachableTime milliseconds." I think the author intended to do the
multiplication by (x>>10) outside the mask, but it's still missing a -1.

- Matthew Martin



diff --git nd6.h nd6.h
index 4274cd4dd07..8eea089a40c 100644
--- nd6.h
+++ nd6.h
@@ -162,8 +162,8 @@ struct  llinfo_nd6 {
 #define MIN_RANDOM_FACTOR  512 /* 1024 * 0.5 */
 #define MAX_RANDOM_FACTOR  1536/* 1024 * 1.5 */
 #define ND_COMPUTE_RTIME(x) \
-   (((MIN_RANDOM_FACTOR * (x >> 10)) + (arc4random() & \
-   ((MAX_RANDOM_FACTOR - MIN_RANDOM_FACTOR) * (x >> 10 /1000)
+   (((arc4random() & (MAX_RANDOM_FACTOR - MIN_RANDOM_FACTOR - 1)) \
+   + MIN_RANDOM_FACTOR) * (x >> 10) / 1000)
 
 TAILQ_HEAD(nd_drhead, nd_defrouter);
 struct nd_defrouter {

Re: sndio - sio_getcap() clarification

[Alexandre Ratchov]

On Sun, May 07, 2017 at 02:10:03PM -0400, Andre Smagin wrote:
> 
> >From my limited testing it appears that sio_getcap() fails if audio
> device does not have identical recording and playback capabilities
> (examples at the end). If that is indeed the case, could it possibly be
> mentioned in the man page somewhere? Perhaps something like:

The encoding and sample rate are common to play and record.  I mean
the audio stack assumes play and record parameters (except channels
count) are the same in full-duplex.

What you observe seems to be a driver or libsndio bug.  Could you
send the output of your program (or "cap") with SNDIO_DEBUG=1
environment variable exported, and the related dmesg lines?

thanks

Re: routing socket panic

[Ted Unangst]

Mike Belopuhov wrote:
> > So there is something in the tree that doesn't like the mbuf packet
> > header growth and decides to color outside the lines.
> > 
> 
> After looking into this with Mark, he has found out that the size of
> an mbuf structure on armv7 and hppa has exceeded MSIZE (256 bytes).

woah, there's no assert to check that? here's a quickie compile time diff.


Index: uipc_mbuf.c
===
RCS file: /cvs/src/sys/kern/uipc_mbuf.c,v
retrieving revision 1.245
diff -u -p -r1.245 uipc_mbuf.c
--- uipc_mbuf.c 7 Feb 2017 07:00:21 -   1.245
+++ uipc_mbuf.c 7 May 2017 21:17:36 -
@@ -152,6 +152,10 @@ static u_int num_extfree_fns;
 const char *mclpool_warnmsg =
 "WARNING: mclpools limit reached; increase kern.maxclusters";
 
+struct mbuf_size_check {
+   char test[2 * (MSIZE >= sizeof(struct mbuf)) - 1];
+};
+
 /*
  * Initialize the mbuf allocator.
  */

Re: [patch] mg: fix overflow on vteeol()

[S. Gilles]

On 2017-05-07T17:31:26+0200, Hiltjo Posthuma wrote:
> Hey,
> 
> mg crashes with certain (unicode) characters and moving the cursor to the
> end of the line.
> 
> The characters are printed to the screen as \nnn in vtpute() and vtcol is
> updated, however vteeol() will write beyond the buffer.

About a year or so ago I ran into this myself (along with some other
issues) when adding unicode support. The thread sort of fizzled out
then[0], but I've been rebasing the diff since[1], and at least one
other person has reported that it works. If bugs related to unicode
are again interesting, I should probably post my patch again.

I don't mean to hijack the thread or try and re-propose my patch,
just to point out a previous effort; if you're working on this, you
can at least see what you don't like about my patch and plan to
avoid it. ;)

[0] https://marc.info/?l=openbsd-tech=145338987910327=2
[1] https://github.com/hboetes/mg/tree/display-wide-characters

-- 
S. Gilles
diff --git a/basic.c b/basic.c
index 85d9f70..123e115 100644
--- a/basic.c
+++ b/basic.c
@@ -18,6 +18,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "def.h"
 
@@ -269,12 +270,25 @@ setgoal(void)
 int
 getgoal(struct line *dlp)
 {
-   int c, i, col = 0;
-   char tmp[5];
+   return getbyteofcol(dlp, 0, curgoal);
+}
 
+/*
+ * Return the byte offset within lp that is targetcol columns beyond
+ * startbyte
+ */
+size_t
+getbyteofcol(const struct line *lp, const size_t startbyte,
+ const size_t targetcol)
+{
+   int c;
+   size_t i, col = 0;
+   char tmp[5];
+   size_t advance_by = 1;
 
-   for (i = 0; i < llength(dlp); i++) {
-   c = lgetc(dlp, i);
+   for (i = startbyte; i < llength(lp); i += advance_by) {
+   advance_by = 1;
+   c = lgetc(lp, i);
if (c == '\t'
 #ifdef NOTAB
&& !(curbp->b_flag & BFNOTAB)
@@ -284,18 +298,86 @@ getgoal(struct line *dlp)
col++;
} else if (ISCTRL(c) != FALSE) {
col += 2;
-   } else if (isprint(c))
+   } else if (isprint(c)) {
col++;
-   else {
+   } else if (!(curbp->b_flag & BFSHOWRAW)) {
+   mbstate_t mbs = { 0 };
+   wchar_t wc = 0;
+   size_t consumed = mbrtowc(, >l_text[i],
+ llength(lp) - i, );
+   int width = -1;
+   if (consumed < (size_t) -2) {
+   width = wcwidth(wc);
+   }
+   if (width >= 0) {
+   col += width;
+   advance_by = consumed;
+   } else {
+   col += snprintf(tmp, sizeof(tmp), "\\%o", c);
+   }
+   } else {
col += snprintf(tmp, sizeof(tmp), "\\%o", c);
}
-   if (col > curgoal)
+   if (col > targetcol)
break;
}
return (i);
 }
 
 /*
+ * Return the column at which specified offset byte would appear, if
+ * this were part of a longer string printed by vtputs, starting at
+ * intial_col
+ */
+size_t
+getcolofbyte(const struct line *lp, const size_t startbyte,
+ const size_t initial_col, const size_t targetoffset)
+{
+   int c;
+   size_t i, col = initial_col;
+   char tmp[5];
+   size_t advance_by = 1;
+
+   for (i = startbyte; i < llength(lp); i += advance_by) {
+   if (i >= targetoffset)
+   break;
+   advance_by = 1;
+   c = lgetc(lp, i);
+   if (c == '\t'
+#ifdef NOTAB
+   && !(curbp->b_flag & BFNOTAB)
+#endif
+   ) {
+   col |= 0x07;
+   col++;
+   } else if (ISCTRL(c) != FALSE) {
+   col += 2;
+   } else if (isprint(c)) {
+   col++;
+   } else if (!(curbp->b_flag & BFSHOWRAW)) {
+   mbstate_t mbs = { 0 };
+   wchar_t wc = 0;
+   size_t consumed = mbrtowc(, >l_text[i],
+ llength(lp) - i, );
+   int width = -1;
+   if (consumed < (size_t) -2) {
+   width = wcwidth(wc);
+   }
+   if (width >= 0) {
+   col += width;
+   advance_by = consumed;
+   } else {
+   col += snprintf(tmp, sizeof(tmp), "\\%o", c);
+   }
+   } else {
+   col += snprintf(tmp, sizeof(tmp), "\\%o", c);
+  

relayd: use __func__ in log messages

[Hiltjo Posthuma]

Hey,

This replaces the prefix in log messages to __func__. Some older code had
the prefix still set to another name. Patch below:


diff --git a/usr.sbin/relayd/ca.c b/usr.sbin/relayd/ca.c
index 45bd5f3224b..de002488d9c 100644
--- a/usr.sbin/relayd/ca.c
+++ b/usr.sbin/relayd/ca.c
@@ -96,11 +96,11 @@ ca_launch(void)
if (rlay->rl_conf.tls_key_len) {
if ((in = BIO_new_mem_buf(rlay->rl_tls_key,
rlay->rl_conf.tls_key_len)) == NULL)
-   fatalx("ca_launch: key");
+   fatalx("%s: key", __func__);
 
if ((pkey = PEM_read_bio_PrivateKey(in,
NULL, NULL, NULL)) == NULL)
-   fatalx("ca_launch: PEM");
+   fatalx("%s: PEM", __func__);
BIO_free(in);
 
rlay->rl_tls_pkey = pkey;
@@ -119,11 +119,11 @@ ca_launch(void)
if (rlay->rl_conf.tls_cakey_len) {
if ((in = BIO_new_mem_buf(rlay->rl_tls_cakey,
rlay->rl_conf.tls_cakey_len)) == NULL)
-   fatalx("ca_launch: key");
+   fatalx("%s: key", __func__);
 
if ((pkey = PEM_read_bio_PrivateKey(in,
NULL, NULL, NULL)) == NULL)
-   fatalx("ca_launch: PEM");
+   fatalx("%s: PEM", __func__);
BIO_free(in);
 
rlay->rl_tls_capkey = pkey;
@@ -181,21 +181,18 @@ ca_dispatch_relay(int fd, struct privsep_proc *p, struct 
imsg *imsg)
IMSG_SIZE_CHECK(imsg, ());
bcopy(imsg->data, , sizeof(cko));
if (cko.cko_proc > env->sc_conf.prefork_relay)
-   fatalx("ca_dispatch_relay: "
-   "invalid relay proc");
+   fatalx("%s: invalid relay proc", __func__);
if (IMSG_DATA_SIZE(imsg) != (sizeof(cko) + cko.cko_flen))
-   fatalx("ca_dispatch_relay: "
-   "invalid key operation");
+   fatalx("%s: invalid key operation", __func__);
if ((pkey = pkey_find(env, cko.cko_id)) == NULL ||
(rsa = EVP_PKEY_get1_RSA(pkey)) == NULL)
-   fatalx("ca_dispatch_relay: "
-   "invalid relay key or id");
+   fatalx("%s: invalid relay key or id", __func__);
 
DPRINTF("%s:%d: key id %d", __func__, __LINE__, cko.cko_id);
 
from = (u_char *)imsg->data + sizeof(cko);
if ((to = calloc(1, cko.cko_tlen)) == NULL)
-   fatalx("ca_dispatch_relay: calloc");
+   fatalx("%s: calloc", __func__);
 
switch (imsg->hdr.type) {
case IMSG_CA_PRIVENC:
@@ -294,16 +291,16 @@ rsae_send_imsg(int flen, const u_char *from, u_char *to, 
RSA *rsa,
 */
imsg_composev(ibuf, cmd, 0, 0, -1, iov, cnt);
if (imsg_flush(ibuf) == -1)
-   log_warn("rsae_send_imsg: imsg_flush");
+   log_warn("%s: imsg_flush", __func__);
 
pfd[0].fd = ibuf->fd;
pfd[0].events = POLLIN;
while (!done) {
switch (poll(pfd, 1, RELAY_TLS_PRIV_TIMEOUT)) {
case -1:
-   fatal("rsae_send_imsg: poll");
+   fatal("%s: poll", __func__);
case 0:
-   log_warnx("rsae_send_imsg: poll timeout");
+   log_warnx("%s: poll timeout", __func__);
break;
default:
break;
diff --git a/usr.sbin/relayd/check_icmp.c b/usr.sbin/relayd/check_icmp.c
index 3ba5179856d..cc98d258280 100644
--- a/usr.sbin/relayd/check_icmp.c
+++ b/usr.sbin/relayd/check_icmp.c
@@ -53,10 +53,10 @@ icmp_setup(struct relayd *env, struct ctl_icmp_event *cie, 
int af)
if (af == AF_INET6)
proto = IPPROTO_ICMPV6;
if ((cie->s = socket(af, SOCK_RAW | SOCK_NONBLOCK, proto)) < 0)
-   fatal("icmp_setup: socket");
+   fatal("%s: socket", __func__);
val = ICMP_RCVBUF_SIZE;
if (setsockopt(cie->s, SOL_SOCKET, SO_RCVBUF, , sizeof(val)) == -1)
-   fatal("icmp_setup: setsockopt");
+   fatal("%s: setsockopt", __func__);
cie->env = env;
cie->af = af;
 }
diff --git a/usr.sbin/relayd/check_script.c b/usr.sbin/relayd/check_script.c
index 9bb494c7275..a97c91e10b2 100644
--- a/usr.sbin/relayd/check_script.c
+++ b/usr.sbin/relayd/check_script.c
@@ -39,7 +39,7 @@ check_script(struct relayd *env, struct host *host)
struct table*table;
 
if ((table = table_find(env, host->conf.tableid)) == NULL)
-   

sndio - sio_getcap() clarification

[Andre Smagin]

>From my limited testing it appears that sio_getcap() fails if audio
device does not have identical recording and playback capabilities
(examples at the end). If that is indeed the case, could it possibly be
mentioned in the man page somewhere? Perhaps something like:

Index: sio_open.3
===
RCS file: /build/openbsd/cvs/src/lib/libsndio/sio_open.3,v
retrieving revision 1.46
diff -u -p -r1.46 sio_open.3
--- sio_open.3  3 Jan 2017 20:29:28 -   1.46
+++ sio_open.3  7 May 2017 17:22:31 -
@@ -285,6 +285,17 @@ parameter combinations in advance can us
 .Fn sio_getcap
 function.
 .Pp
+.Fn sio_getcap
+function can return different results based on whether
+.Dv SIO_PLAY
+or
+.Dv SIO_REC
+mode was selected.
+It can fail for the device with differing recording and
+playback capabilities opened in
+.Dv SIO_PLAY | SIO_REC
+mode.
+.Pp
 The
 .Vt sio_cap
 structure contains the list of parameter configurations.



Examples that I am retrieving with sio_getpar() and sio_getcap()
with a program similar to src/regress/lib/libsndio/cap/cap.c:

rsnd/0 (play) parameters: s24le/48000, 2 play/2 rec channels
rsnd/0 (rec)  parameters: s16le/48000, 2 play/2 rec channels
rsnd/0 (play+rec) parameters: s16le/48000, 2 play/2 rec channels
rsnd/0 (play) capabilities:
Configuration 1 out of 1:
Encodings: s16le s24le
Rates: 44100 48000 96000
Recording channels:
Playback channels: 2
rsnd/0 (rec)  capabilities:
Configuration 1 out of 1:
Encodings: s16le
Rates: 44100 48000 96000
Recording channels: 2
Playback channels:
rsnd/0 (play+rec) capabilities:
Error getting capabilities.


but on a different system with better audio hardware it succeeds:

rsnd/0 (play) parameters: s24le/48000, 2 play/2 rec channels
rsnd/0 (rec)  parameters: s24le/48000, 2 play/2 rec channels
rsnd/0 (play+rec) parameters: s24le/48000, 2 play/2 rec channels
rsnd/0 (play) capabilities:
Configuration 1 out of 1:
Encodings: s16le s24le
Rates: 44100 48000 88200 96000
Recording channels:
Playback channels: 2 4 6 8 10
rsnd/0 (rec)  capabilities:
Configuration 1 out of 1:
Encodings: s16le s24le
Rates: 44100 48000 88200 96000
Recording channels: 2
Playback channels:
rsnd/0 (play+rec) capabilities:
Configuration 1 out of 1:
Encodings: s16le s24le
Rates: 44100 48000 88200 96000
Recording channels: 2
Playback channels: 2 4 6 8 10

Re: routing socket panic

[Mike Belopuhov]

On 7 May 2017 at 15:10, Mike Belopuhov  wrote:

> On Sat, May 06, 2017 at 17:35 +0200, Mark Kettenis wrote:
> > > Date: Fri, 5 May 2017 22:09:03 +0200 (CEST)
> > > From: Mark Kettenis 
> > >
> > > Just got this panic on armv7; got a very similar panic on hppa
> > > yesterday that I didn't have time to look into any further.  This is
> > > completely reproducable.
> > >
> > > setting tty flags
> > > pf enabled
> > > kern.allowkmem: 0 -> 1
> > > starting network
> > > panic: pool_do_get: mbufpl free list modified: page 0xc56a4000; item
> addr 0xc56a4400; offset 0x0=0x0 != 0x24a4c1a
> > > Stopped at  $d: ldrbr15, [r15, r15, ror r15]!
> > > TIDPIDUID PRFLAGS PFLAGS  CPU  COMMAND
> > > *364338  59716  00x13  00  route
> > > panic+0x18
> > > scp=0xc03cae90 rlv=0xc03c761c ($d)
> > > rsp=0xcc574bf0 rfp=0xcc574c2c
> > > pool_do_get+0xc
> > > scp=0xc03c73ac rlv=0xc03c6f1c (pool_get+0x7c)
> > > rsp=0xcc574c30 rfp=0xcc574c8c
> > > r7=0x r6=0x0002 r5=0xc0726408 r4=0x00ac
> > > pool_get+0x10
> > > scp=0xc03c6eb0 rlv=0xc03e075c (m_get+0x2c)
> > > rsp=0xcc574c90 rfp=0xcc574cbc
> > > r8=0x0044 r7=0x r6=0xc56a4300 r5=0x00ac
> > > r4=0x00ac
> > > m_get+0x10
> > > scp=0xc03e0740 rlv=0xc03e1964 (m_copyback+0x1a8)
> > > rsp=0xcc574cc0 rfp=0xcc574cfc
> > > r10=0xc53cb300 r8=0x0044 r7=0x r6=0xc56a4300
> > > r5=0x00ac r4=0x00ac
> > > m_copyback+0x10
> > > scp=0xc03e17cc rlv=0xc044326c (route_output+0x350)
> > > rsp=0xcc574d00 rfp=0xcc574d8c
> > > r10=0xca435000 r9=0x r8=0xc53cb300 r7=0x
> > > r6=0xc56a4300 r5=0x0001 r4=0x0001
> > > route_output+0xc
> > > scp=0xc0442f28 rlv=0xc043ce04 ($a+0x154)
> > > rsp=0xcc574d90 rfp=0xcc574dbc
> > > r10=0xc56a4300 r9=0xcc574ea0 r8=0x r7=0xc5866780
> > > r6=0xca435000 r5=0x0009 r4=0x
> > > raw_usrreq+0xc
> > > scp=0xc043cc00 rlv=0xc03e56ec (sosend+0x290)
> > > rsp=0xcc574dc0 rfp=0xcc574e1c
> > > r10=0x r8=0x r7=0xffd6 r6=0x1f5c
> > > r5=0xca435000 r4=0x
> > > sosend+0xc
> > > scp=0xc03e5468 rlv=0xc03d247c (soo_write+0x2c)
> > > rsp=0xcc574e20 rfp=0xcc574e3c
> > > r10=0xca494140 r9=0x00a4 r8=0xcc574f0c r7=0x0003
> > > r6=0x0001 r5=0xcc574fb4 r4=0xcc574f0c
> > > soo_write+0xc
> > > scp=0xc03d245c rlv=0xc03cfa1c (dofilewritev+0x1a4)
> > > rsp=0xcc574e40 rfp=0xcc574ef4
> > > dofilewritev+0xc
> > > scp=0xc03cf884 rlv=0xc03cfc68 (sys_write+0x80)
> > > rsp=0xcc574ef8 rfp=0xcc574f3c
> > > r10=0x0028 r9=0x0004 r8=0xcc574f74 r7=0x0003
> > > r6=0xca4a3cf4 r5=0xcc574fb4 r4=0xca494158
> > > sys_write+0xc
> > > scp=0xc03cfbf4 rlv=0xc054173c (swi_handler+0x174)
> > > rsp=0xcc574f40 rfp=0xcc574fac
> > > r8=0x0004 r7=0xca4a3cf4 r6=0xcc574fb0 r5=0x0003
> > > r4=0xcc574fb4
> > > swi_handler+0xc
> > > scp=0xc05415d4 rlv=0xc0543fe8 (swi_entry+0x28)
> > > rsp=0xcc574fb0 rfp=0xbffc9264
> > > r10=0x0028 r9=0x04e5abc0 r8=0x04e50f24 r7=0x04e5ac60
> > > r6=0x04e5aef8 r5=0x r4=0x4e10c000
> > > https://www.openbsd.org/ddb.html describes the minimum info required
> in bug
> > > reports.  Insufficient info makes it difficult to find and fix bugs.
> > > ddb> ps
> > >PID TID   PPIDUID  S   FLAGS  WAIT  COMMAND
> > > *59716  364338  77999  0  70x13route
> > >  77999  518782   1669  0  30x10008b  pause sh
> > >   1669   76642  1  0  30x10008b  pause sh
> > >   2702  287769  0  0  3 0x14200  pgzerozerothread
> > >  58941  172655  0  0  3 0x14200  aiodoned  aiodoned
> > >  17148  492245  0  0  3 0x14200  syncerupdate
> > >  86850  185874  0  0  3 0x14200  cleaner   cleaner
> > >  74158  246265  0  0  3 0x14200  reaperreaper
> > >  96587  269786  0  0  3 0x14200  pgdaemon  pagedaemon
> > >  22576  337424  0  0  3 0x14200  bored crynlk
> > >  17600  522232  0  0  3 0x14200  bored crypto
> > >  19634  523615  0  0  3 0x14200  pftm  pfpurge
> > >  58943  420327  0  0  3 0x14200  usbtskusbtask
> > >  73136  234376  0  0  3 0x14200  usbatsk   usbatsk
> > >  47223  147942  0  0  3 0x14200  mmctsksdmmc0
> > >  56815  511243  0  0  3 0x14200  bored softnet
> > >  95568  281092  0  0  3 0x14200  bored systqmp
> > >  69722  514447  0  0  3 0x14200  bored systq
> > >  

Emulated TLS for clang

[Mark Kettenis]

So this enables the code.  It makes -femulated-tls the default,
otherwise it will generated TLS relocations that we can't handle yet.
It is possible to specify -fno-emulated-tls if you really want to
generate those.

A trivial example program that modifies the variable in one thread and
prints it in another seems to work as expected.

Note that the libcompiler_rt implementation unconditionally references
some symbols in libpthread.  So linking with -lpthread is mandatory.
GCC 4.9 uses weak references, so -lpthread isn't needed there.

Perhaps those functions should move to libc.  Or we can make the
libcompiler_rt code a bit smarter.

Also note that the libcompiler_rt implementation offers the choice
between posix_memalign() and normal malloc().  With this diff it uses
malloc().  Perhaps otto@ has an opinion what's better here?


Index: gnu/llvm/tools/clang/lib/Basic/Targets.cpp
===
RCS file: /cvs/src/gnu/llvm/tools/clang/lib/Basic/Targets.cpp,v
retrieving revision 1.7
diff -u -p -r1.7 Targets.cpp
--- gnu/llvm/tools/clang/lib/Basic/Targets.cpp  14 Mar 2017 08:11:34 -  
1.7
+++ gnu/llvm/tools/clang/lib/Basic/Targets.cpp  7 May 2017 15:25:08 -
@@ -549,8 +549,6 @@ protected:
 public:
   OpenBSDTargetInfo(const llvm::Triple , const TargetOptions )
   : OSTargetInfo(Triple, Opts) {
-this->TLSSupported = false;
-
   switch (Triple.getArch()) {
 default:
 case llvm::Triple::x86:
Index: gnu/llvm/tools/clang/lib/Driver/Tools.cpp
===
RCS file: /cvs/src/gnu/llvm/tools/clang/lib/Driver/Tools.cpp,v
retrieving revision 1.10
diff -u -p -r1.10 Tools.cpp
--- gnu/llvm/tools/clang/lib/Driver/Tools.cpp   24 Jan 2017 08:39:08 -  
1.10
+++ gnu/llvm/tools/clang/lib/Driver/Tools.cpp   7 May 2017 15:25:09 -
@@ -5370,7 +5370,8 @@ void Clang::ConstructJob(Compilation ,
   Args.AddLastArg(CmdArgs, options::OPT_fno_operator_names);
   // Emulated TLS is enabled by default on Android, and can be enabled manually
   // with -femulated-tls.
-  bool EmulatedTLSDefault = Triple.isAndroid() || 
Triple.isWindowsCygwinEnvironment();
+  bool EmulatedTLSDefault = Triple.isAndroid() || Triple.isOSOpenBSD() ||
+Triple.isWindowsCygwinEnvironment();
   if (Args.hasFlag(options::OPT_femulated_tls, options::OPT_fno_emulated_tls,
EmulatedTLSDefault))
 CmdArgs.push_back("-femulated-tls");
Index: lib/libcompiler_rt/Makefile
===
RCS file: /cvs/src/lib/libcompiler_rt/Makefile,v
retrieving revision 1.7
diff -u -p -r1.7 Makefile
--- lib/libcompiler_rt/Makefile 17 Apr 2017 15:53:21 -  1.7
+++ lib/libcompiler_rt/Makefile 7 May 2017 15:25:09 -
@@ -64,6 +64,7 @@ GEN_SRCS= absvdi2 \
divti3 \
divtf3 \
divxc3 \
+   emutls \
enable_execute_stack \
eprintf \
extendsfdf2 \

[patch] mg: fix overflow on vteeol()

[Hiltjo Posthuma]

Hey,

mg crashes with certain (unicode) characters and moving the cursor to the
end of the line.

The characters are printed to the screen as \nnn in vtpute() and vtcol is
updated, however vteeol() will write beyond the buffer.

A test file contains the data:

——

It is printed to the screen as: \342\200\224\342... etc.

It is safer to use vtpute() here because it checks if vtcol >= 0.

Below is a patch:


diff --git a/usr.bin/mg/display.c b/usr.bin/mg/display.c
index 7af723ce268..d7c22554753 100644
--- a/usr.bin/mg/display.c
+++ b/usr.bin/mg/display.c
@@ -381,11 +381,8 @@ vtpute(int c)
 void
 vteeol(void)
 {
-   struct video *vp;
-
-   vp = vscreen[vtrow];
while (vtcol < ncol)
-   vp->v_text[vtcol++] = ' ';
+   vtpute(' ');
 }
 
 /*

-- 
Kind regards,
Hiltjo

Re: OpenBSD 6.1: relayd does not start more than 3 processes

[Hiltjo Posthuma]

On Fri, May 05, 2017 at 04:05:09PM +0200, Maxim Bourmistrov wrote:
> 
> > 5 maj 2017 kl. 15:55 skrev Maxim Bourmistrov :
> > 
> > 
> >> 5 maj 2017 kl. 14:41 skrev Hiltjo Posthuma :
> >> 
> >> On Fri, May 05, 2017 at 12:30:56PM +0200, Maxim Bourmistrov wrote:
> >>> 
> >>> Hey,
> >>> on OpenBSD 6.0-stable I have following configuration for relayd:
> >>> 
> >>> snip———
> >>> interval 10
> >>> timeout 1200
> >>> prefork 15
> >>> log all
> >>> ——
> >>> 
> >>> Respective login.conf to spawn more relayd procs:
> >>> 
> >>> relayd:\
> >>>   :maxproc-max=31:\
> >>>   :maxproc-cur=15:\
> >>>   :openfiles=65536:\
> >>>   :tc=daemon:
> >>> 
> >>> 
> >>> With config options above moved to a 6.1 creates following:
> >>> 
> >>> relayd starts but brings up no more that 3 relay-processes.
> >>> Also after start up it refuses to do any checks configured (in my simple 
> >>> test I used check tcp) 
> >>> 
> >>> [mxb-test]-[12:21:41]# relayctl sh su
> >>> Id  TypeNameAvlblty Status
> >>> 1   relay   rabbitmqactive
> >>> 1   table   rabbitmqpool:5672   empty
> >>> 1   host10.5.96.8   unknown
> >>> 2   table   rabbitmqfallback:5672   empty
> >>> 2   host10.5.96.9   unknown
> >>> 
> >>> 
> >>> Changing ’prefork’ from 15 to 3 makes it work.
> >>> 
> >>> Is this a bug?
> >>> 
> >>> Br
> >>> 
> >> 
> >> Hey,
> >> 
> >> This is a random guess since you haven't posted the whole config, but I 
> >> think
> >> it has bitten me too sometime:
> >> 
> >> Do you have the global options such as prefork defined before your
> >> relays and routes or not?
> >> 
> >> The order of the global options matter. If the global options are set after
> >> the table they are not initialized on the tables and can actually crash 
> >> relayd.
> >> This is because the health checking uses a different prefork value and 
> >> checks
> >> the "wrong" amount.
> >> 
> >> I'm not sure, but I think it is not a bug: it is documented in 
> >> relayd.conf(5).
> >> 
> >> Thinking about it: would it be acceptable if `relayd -n` shows a warning if
> >> global options are defined in the wrong order? I can write the patch for it
> >> if it makes sense.
> >> 
> >> I hope this helps you in some way,
> >> 
> >> -- 
> >> Kind regards,
> >> Hiltjo
> > 
> 8< snip snip >8
> 

Hey,

Here is a (rough) patch/idea to check if global options are used after
non-global options such as tables, routes, redirects etc. This makes sure a
value of `timeout`, `prefork` etc that are set on tables are are not different
from the health-checking (which could crash relayd at run-time).

It has bitten a few people and me :)

The patch will show an error in this case when checking the config with
`relayd -n`.

Please let me know if it makes sense.

Above is the thread from @misc. Below is the (rough) patch:


diff --git a/usr.sbin/relayd/parse.y b/usr.sbin/relayd/parse.y
index 57ab789db8f..c768b657d69 100644
--- a/usr.sbin/relayd/parse.y
+++ b/usr.sbin/relayd/parse.y
@@ -375,7 +375,18 @@ sendbuf: NOTHING   {
}
;
 
-main   : INTERVAL NUMBER   {
+main   : /* empty */
+   {
+   if (conf && (conf->sc_rdrcount || conf->sc_tablecount ||
+   conf->sc_protocount || conf->sc_relaycount ||
+   conf->sc_routercount || conf->sc_routecount)) {
+   yyerror("global options used after non-global 
options");
+   YYERROR;
+   }
+   }
+   main_l;
+
+main_l : INTERVAL NUMBER   {
if ((conf->sc_conf.interval.tv_sec = $2) < 0) {
yyerror("invalid interval: %d", $2);
YYERROR;

-- 
Kind regards,
Hiltjo