Re: arm: 8-byte alignment (AAPCS)

On Sat, Apr 02, 2016 at 12:44:15PM -0700, Philip Guenther wrote: > On Sat, Apr 2, 2016 at 5:19 AM, Patrick Wildt wrote: > > the Procedure Call Standard used in EABI requires the stack pointer to > > be 8-byte aligned by > > > > * exception handlers, before calling

Re: anyone using gdb "kvm proc/pcb" ?

I have only used target kvm, and only to inspect variables in the kernel. On 3 Apr 2016 13:50, "Philip Guenther" wrote: > > The gdb in base, when used against a live kernel or crash dump, is > supposed to be able to backtrace individual threads via the kvm proc and > kvm pcb

Re: [patch] ftpd: pledge(2)

On Sat, Apr 02, 2016 at 04:38:10PM +0200, frit...@alokat.org wrote: > Hi, > > this adds pledge(2) to ftpd(8). thanks for your interest. I haven't tested your diff, but just some comments below. > Unfortunately, the main process and its children "[priv pre-auth]" need > a lot of rights. The

Re: arm/fdt: map fdt and use given memory/bootargs

On Fri, Mar 04, 2016 at 03:15:23PM +0100, Patrick Wildt wrote: > Hi, > > this diff makes armv7 map the FDT, if available, and uses it to read > information about the machine's available memory and bootargs. > > I'd like to get some opinions about the way I have implemented some > stuff. For

amd64: teach ddb a few new instructions

This teachs the ddb disassembler on amd64 about the {rd,wr}{fs,gs}base instructions. Well, almost: the actual instructions start with the F3 prefix (aka "repe") but adding another hook in the disassembler logic to require that for these (and suppress the output) seems like overkill. If and

Re: sync time(9)/resettodr(9)/inittodr(9) with reality

On Fri, Apr 1, 2016 at 10:34 PM, Jonathan Gray wrote: > These pages were never updated for the timecounter changes. > > time.9 should move to time_second.9 as well. Looks like fewer lies. ok guenther@

anyone using gdb "kvm proc/pcb" ?

The gdb in base, when used against a live kernel or crash dump, is supposed to be able to backtrace individual threads via the kvm proc and kvm pcb commands. Is anyone actually using these on 5.9 or -current? If so, which archs? I ask as I see some "this can't work" logic between the kernel

Re: nam2blk cleanup

Makes sense to me, raidframe isn't coming back. Nothing seems to depend on the index offsets. On Thu, Mar 17, 2016 at 06:46:14PM +0200, Artturi Alm wrote: > Hi, > > related to past cleanup for some of the sys/arch/x/x/conf.c. > > -Artturi > > > Index: sys/arch/alpha/alpha/autoconf.c >

amd64: simplify reset_segs()

reset_segs() is overly complicated: we pass it the pcb address and new value of the fsbase, but all it does with those is set a field in the former with the latter. It's simpler to just do the assignment in the (two) callers. (If someone came up with use for making GS.base setable by

Re: arm: 8-byte alignment (AAPCS)

On Sat, Apr 02, 2016 at 01:26:18PM -0700, Philip Guenther wrote: > On Sat, Apr 2, 2016 at 12:44 PM, Philip Guenther wrote: > > On Sat, Apr 2, 2016 at 5:19 AM, Patrick Wildt wrote: > >> the Procedure Call Standard used in EABI requires the stack pointer to >

libpthread: tighten various internal references

This diff tightens up internal references to exported functions, plus one pointless syscall. This is done via a namespace.h and wrapper headers like the hidden/* added in the libc source. The files are the libpthread directory as that's the style of arrangement of the rthread source; some day

Re: faq 4.6 - X sets

On Sat, Apr 02, 2016 at 09:54:04AM +0200, Theo Buehler wrote: > On Sat, Apr 02, 2016 at 09:23:33AM +0200, Matthieu Herrb wrote: > > Hi, > > > > I think the section 4.6 of the FAQ about X sets is a bit > > wrong/misleading. > > > > First the straight fact: there is no font servver in xfontXX.tgz

faq7 wscons tweak

Wscons is the only console driver on OpenBSD since a number of years... Index: faq7.html === RCS file: /cvs/www/faq/faq7.html,v retrieving revision 1.115 diff -u -p -u -r1.115 faq7.html --- faq7.html 29 Mar 2016 01:27:39 -

Re: faq7 wscons tweak

On Sat, Apr 02, 2016 at 12:24:04PM +0200, Matthieu Herrb wrote: > Wscons is the only console driver on OpenBSD since a number of > years... ok > Index: faq7.html > === > RCS file: /cvs/www/faq/faq7.html,v > retrieving revision 1.115

faq 4.6 - X sets

Hi, I think the section 4.6 of the FAQ about X sets is a bit wrong/misleading. First the straight fact: there is no font servver in xfontXX.tgz (patch below) Then I think the explanation on why X sets are sometimes needed could be improved, but I failed to come up with a patch. Here are my

Re: faq 4.6 - X sets

On Sat, Apr 02, 2016 at 11:16:43AM +0200, Matthieu Herrb wrote: > On Sat, Apr 02, 2016 at 10:25:40AM +0200, Theo Buehler wrote: > > > > And now with the updated diff... Sorry for the noise. > > I would make the sentence about splitting xbase more terse: I like the suggestion of making that

Re: faq 4.6 - X sets

On Sat, Apr 02, 2016 at 09:23:33AM +0200, Matthieu Herrb wrote: > Hi, > > I think the section 4.6 of the FAQ about X sets is a bit > wrong/misleading. > > First the straight fact: there is no font servver in xfontXX.tgz > (patch below) > > Then I think the explanation on why X sets are

Re: faq 4.6 - X sets

On Sat, Apr 02, 2016 at 10:11:07AM +0200, Theo Buehler wrote: > On Sat, Apr 02, 2016 at 09:54:04AM +0200, Theo Buehler wrote: > > On Sat, Apr 02, 2016 at 09:23:33AM +0200, Matthieu Herrb wrote: > > > Hi, > > > > > > I think the section 4.6 of the FAQ about X sets is a bit > > > wrong/misleading.

Re: faq 4.6 - X sets

On Sat, Apr 02, 2016 at 10:25:40AM +0200, Theo Buehler wrote: > > And now with the updated diff... Sorry for the noise. I would make the sentence about splitting xbase more terse: Index: faq4.html === RCS file:

arm: 8-byte alignment (AAPCS)

Hi, the Procedure Call Standard used in EABI requires the stack pointer to be 8-byte aligned by * exception handlers, before calling AAPCS-conforming code. * the OS, before giving control to an application. This diff makes sure our kernel interfaces adhere to that requirement. Can someone

[patch] ftpd: pledge(2)

Hi, this adds pledge(2) to ftpd(8). Unfortunately, the main process and its children "[priv pre-auth]" need a lot of rights. The unprivileged process is better to pledge, as it does not need that much rights. But, I try to find other strategic points where pledge(2) could take place. Maybe it's

DMA overruns and iommu's

It is pretty clear that the DMA engine on the Davicom dc(4) hardware is broken and will read beyond the end of the buffer that we pass it. This is bad news for hardware that uses an IOMMU, as it will detect the DMA overrun and (at least on sparc64) signal an unrecoverable error. It is somewhat

increase clone bitmap size (again)

Below is the fixed v_specbitmap enlargements diff, including some tweaks by mikeb@. I have tested this with fuse _and_ drm on amd64 and macppc. I also tested on macppc with cloning bpf (not in the tree). Can anyone come up with another interesting test case? Comments? Ok? natano Index:

[patch] ftpd: no pid_t to long cast

Is it really necessary to cast pid_t values to long, only for printing? --f. Index: ftpd.c === RCS file: /cvs/src/libexec/ftpd/ftpd.c,v retrieving revision 1.213 diff -u -r1.213 ftpd.c --- ftpd.c 16 Mar 2016 15:41:10 -

Re: DMA overruns and iommu's

I like this approach better than the alternative. although i might put BROKEN in the flag name or something. On Saturday, 2 April 2016, Mark Kettenis wrote: > It is pretty clear that the DMA engine on the Davicom dc(4) hardware > is broken and will read beyond the end

[patch] ftpd: UINT_MAX -> UID_MAX

Maybe it's better to use UID_MAX instead of UINT_MAX to indicate the max value is the max possible user id and not the max possible unsigned int value, even if they are the same at the end of the day. --f. Index: ftpd.c === RCS

Re: [patch] ftpd: no pid_t to long cast

On Sat, Apr 02, 2016 at 05:32:02PM +0200, frit...@alokat.org wrote: > Is it really necessary to cast pid_t values to long, only > for printing? yes, pid_t may be long, as defined by posix, -Otto > > --f. > > > Index: ftpd.c >

Re: increase clone bitmap size (again)

On 2 April 2016 at 18:36, Martin Natano wrote: > Below is the fixed v_specbitmap enlargements diff, including some tweaks > by mikeb@. I have tested this with fuse _and_ drm on amd64 and macppc. I > also tested on macppc with cloning bpf (not in the tree). Can anyone > come up

bug in grep

Hello. Doing this echo "stuffb01b02stuff" |grep -o b[0-9][0-9] will print: b01 b02 as it should. echo "stuffb01b02stuff" |grep -o b.. will only print last match. so it will print: b02 using b.. works both on linux and with freebsd-grep Thanks!

Re: DMA overruns and iommu's

Should we clear the scratch page to prevent that the dc(4) hardware may see sensitive information? bluhm On Sat, Apr 02, 2016 at 05:53:03PM +0200, Mark Kettenis wrote: > It is pretty clear that the DMA engine on the Davicom dc(4) hardware > is broken and will read beyond the end of the buffer

Re: arm: 8-byte alignment (AAPCS)

On Sat, Apr 2, 2016 at 5:19 AM, Patrick Wildt wrote: > the Procedure Call Standard used in EABI requires the stack pointer to > be 8-byte aligned by > > * exception handlers, before calling AAPCS-conforming code. > * the OS, before giving control to an application. > > This

Re: arm: store curcpu pointer in thread id register

ok? On Sat, Feb 20, 2016 at 10:49:36PM +0100, Patrick Wildt wrote: > Hi, > > since ARMv6 the coprocessor provides special registers to store software > defined values. Those registers are: > > * TPIDRURW -> kernel RW, user RW > * TPIDRURO -> kernel RW, user RO > * TPIDRPRW -> kernel RW >

Minor style rewrite for crypt.c

Greetings, The function crypt (/usr/src/lib/libc/crypt/crypt.c) might be rewritten as: char * crypt(const char *key, const char *setting) { if (setting[0] == '$' && setting[1] == '2') return bcrypt(key, setting); errno = EINVAL; return (NULL); } --- HLG

Re: arm: 8-byte alignment (AAPCS)

On Sat, Apr 2, 2016 at 12:44 PM, Philip Guenther wrote: > On Sat, Apr 2, 2016 at 5:19 AM, Patrick Wildt wrote: >> the Procedure Call Standard used in EABI requires the stack pointer to >> be 8-byte aligned by >> >> * exception handlers, before calling

Re: DMA overruns and iommu's

> Date: Sat, 2 Apr 2016 21:30:55 +0200 > From: Alexander Bluhm > > Should we clear the scratch page to prevent that the dc(4) hardware > may see sensitive information? Good point; new diff below. Index: dev/ic/dc.c

Re: libpthread: simplify syscall wrapping/invocation

> Authentication-Results: xs4all.nl; spf=pass smtp.mailfrom=openbsd.org; > dkim=pass header.d=gmail.com; dmarc=pass header.from=gmail.com > DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; > d=gmail.com; s=20120113; >

Re: bug in grep

Hi, Apparently the error seems to be in /usr/src/usr.bin/grep/util.c at line 400: if ((!(lflag || cflag)) && ((!(bol || eol)) && ((lastHalfDot) && ((firstHalfDot < 0) || ((fg->patternLen - (lastHalfDot + 1)) < firstHalfDot) { fg->reversedSearch

Re: libpthread: tighten various internal references

> Date: Fri, 1 Apr 2016 23:18:19 -0700 > From: Philip Guenther > > This diff tightens up internal references to exported functions, plus one > pointless syscall. > > This is done via a namespace.h and wrapper headers like the hidden/* added > in the libc source. The files

Re: libpthread: tighten various internal references

On Sat, Apr 2, 2016 at 2:26 PM, Mark Kettenis wrote: >> Date: Fri, 1 Apr 2016 23:18:19 -0700 >> From: Philip Guenther ... >> This version also implements the pattern I intend to apply to libc at some >> point, where symbols in the shared library are