Re: Return ESRCH instead of zero result for KERN_FILE sysctl

Alexander Bluhm wrote: > > Can we have the same logic for KERN_FILE_BYPID and KERN_FILE_BYUID? I think this should be BYPID only. I'm not sure why. Maybe because a user exists even when the user isn't running any processes. But a process doesn't exist when it doesn't exist.

Re: pledge: telnet should not verify if hostname is a fully qualified domain

Adam Wolk [adam.w...@tintagel.pl] wrote: > > I would like to just drop that part of code. Any OK's, comments? > Please do. It's utterly useless. ok chris@ > Index: commands.c > === > RCS file: /cvs/src/usr.bin/telnet/commands.c,v >

pledge: telnet should not verify if hostname is a fully qualified domain

Hi tech@, I have been noticing coredumps from telnet on my laptop for some time now and finally found an evening to investigate it. The typical use case: $ telnet localhost 22 Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. SSH-2.0-OpenSSH_7.2 ^] telnet> quit Connection

Re: Return ESRCH instead of zero result for KERN_FILE sysctl

2016-05-03 1:19 GMT+03:00 Mark Kettenis : >> Date: Tue, 3 May 2016 00:04:13 +0200 >> From: Alexander Bluhm >> >> On Sun, May 01, 2016 at 01:24:19AM +0300, Vadim Zhukov wrote: >> > When matching by PID, we'd better return ESRCH expicitly rather >>

Re: Return ESRCH instead of zero result for KERN_FILE sysctl

2016-05-03 1:04 GMT+03:00 Alexander Bluhm : > On Sun, May 01, 2016 at 01:24:19AM +0300, Vadim Zhukov wrote: >> When matching by PID, we'd better return ESRCH expicitly rather >> than zero entries. This makes, for example, fstat(1) behaviour >> more consistent and makes it

xclock patch

I saw this in /var/log/messages May 2 17:19:07 thinkpad /bsd: xclock(81091): syscall 5 "rpath" Does it mean xclock needs rpath? If so here you go. Index: xclock.c === RCS file: /cvs/xenocara/app/xclock/xclock.c,v retrieving

Re: Moving away from softnet interrupts

On Mon, May 02, 2016 at 11:27:36AM +0200, Martin Pieuchot wrote: > On 18/04/16(Mon) 10:50, Martin Pieuchot wrote: > > The current goal of the Network SMP effort is to have a single CPU > > process the IP forwarding path in a process context without holding > > the KERNEL_LOCK(). To achieve this

tcpdump yacc reference

Hi. Not sure if yacc is needed here. Index: src/usr.sbin/tcpdump/tcpdump.c === RCS file: /cvs/src/usr.sbin/tcpdump/tcpdump.c,v retrieving revision 1.78 diff -u -p -u -r1.78 tcpdump.c --- src/usr.sbin/tcpdump/tcpdump.c 22 Dec

Re: Return ESRCH instead of zero result for KERN_FILE sysctl

> Date: Tue, 3 May 2016 00:04:13 +0200 > From: Alexander Bluhm > > On Sun, May 01, 2016 at 01:24:19AM +0300, Vadim Zhukov wrote: > > When matching by PID, we'd better return ESRCH expicitly rather > > than zero entries. This makes, for example, fstat(1) behaviour > >

Re: Single route lookup when forwarding an IPv4 packet

On Mon, Apr 25, 2016 at 02:40:41PM +0200, Martin Pieuchot wrote: > Diff below makes ip_forward() use the route entry fetched in in_ouraddr(). > > As you can imagine a proper caching could be done for forwarding using > PF statekey. > > This diff has been tested by Hrvoje Popovski who confirmed

Re: Return ESRCH instead of zero result for KERN_FILE sysctl

On Sun, May 01, 2016 at 01:24:19AM +0300, Vadim Zhukov wrote: > When matching by PID, we'd better return ESRCH expicitly rather > than zero entries. This makes, for example, fstat(1) behaviour > more consistent and makes it easier to replace "if lsof -p ..." > checks in third-party code with "if

Re: Speedup sdhc(4)

On 5/1/16 3:09 PM, Mark Kettenis wrote: Date: Sat, 30 Apr 2016 13:31:21 +0200 (CEST) From: Mark Kettenis From: John Troy Date: Fri, 29 Apr 2016 11:56:24 -0400 On 4/28/16 2:30 PM, Mark Kettenis wrote: So here are just the bits that add DMA support.

Re: mklocale(1): TODIGIT > 255 clobbers type and width data

Hi, Andrew Fresh wrote on Mon, May 02, 2016 at 11:55:52AM -0700: > On Mon, May 02, 2016 at 08:34:43PM +0200, Ingo Schwarze wrote: >> The following patch fixes the bug by limiting digit values to >> the range 0x00 to 0xff that our LC_CTYPE file format can actually >> store. > Does this fix mean

Re: mklocale(1): TODIGIT > 255 clobbers type and width data

On Mon, 02 May 2016 20:34:43 +0200, Ingo Schwarze wrote: > The following patch fixes the bug by limiting digit values to > the range 0x00 to 0xff that our LC_CTYPE file format can actually > store. Wouldn't it be better to just ignore values > 0xff instead of clamping to 0xff? - todd

Re: mklocale(1): TODIGIT > 255 clobbers type and width data

On Mon, May 02, 2016 at 08:34:43PM +0200, Ingo Schwarze wrote: > The following patch fixes the bug by limiting digit values to > the range 0x00 to 0xff that our LC_CTYPE file format can actually > store. Does this fix mean that these numbers (like the super cool Aegean numerals) and the more

Re: sqlite c api manpages?

Kristaps Dzonsons wrote: > If you're on OpenBSD, you started with "apropos -s3 sqlite3", were > shocked that there's nothing there, then moved on to Google with a > wounding confusion in your heart. Indeed. I see this didn't get much traction, but it sounds good to me. We are shipping sqlite as a

Re: DMA overruns and iommu's

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 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

mklocale(1): TODIGIT > 255 clobbers type and width data

Hi, when mklocale(1) input - the only relevant input file for us being /usr/src/share/locale/ctype/en_US.UTF-8.src - contains a line TODIGIT < character(s) digit > where digit is greater than 0xff, mklocale(1) clobbers character type and character width data for the specified character(s).

Re: armv7: only attach platform busses if explicitly asked for

On Mon, May 02, 2016 at 10:25:13AM +0200, Patrick Wildt wrote: > Hi, > > currently the armv7 platform busses always match if the board id is set > to something they know. This means that even with a device tree the > platforms will always try to match, even though they should not. > > By

Re: Document inet4/prefix in hostname.if(5)

On Mon, May 02, 2016 at 01:25:22PM +0100, Jason McIntyre wrote: > On Mon, May 02, 2016 at 01:27:50PM +0200, Henning Brauer wrote: > > [...] > > technically, hostname.if doesn't support ip/len notation. It is a > > notation that the hostname parser doesn't grok and just passes on to > >

64-bit time_t for user(1)

Whilst reading through Ricardo Mestre's user.c diff I noticed that user(1) still treats time_t as long for password aging. - todd Index: user.c === RCS file: /cvs/src/usr.sbin/user/user.c,v retrieving revision 1.109 diff -u -p -u

Re: Document inet4/prefix in hostname.if(5)

On Mon, May 02, 2016 at 01:27:50PM +0200, Henning Brauer wrote: > * Gregor Best [2016-05-01 19:22]: > > /etc/hostname.if supports IPv4 addresses with a CIDR prefix length: > > > > inet 10.0.0.1/16 > > > > which is not documented in hostname.if(5). The attached patch

Re: Document inet4/prefix in hostname.if(5)

* Gregor Best [2016-05-01 19:22]: > /etc/hostname.if supports IPv4 addresses with a CIDR prefix length: > > inet 10.0.0.1/16 > > which is not documented in hostname.if(5). The attached patch fixes > that. I'm not sure whether describing '/prefixlen' before 'netmask' is

ndp(8) CPPFLAGS

ndp.c doesn't have any #ifdef INET6 preprocessor directive, I can't see how keeping that in CPPFLAGS changes anything. While here, -I${.CURDIR} isn't needed either. Verified with sha256(1). ok? Index: Makefile === RCS file:

Re: document NOLOCK in syscalls.master

On 10:30:02, 7.04.16, Martin Natano wrote: > > * mention INDIR and NOLOCK in 'Fields'. > > How about something like "one of the types listed below, or one of the > compatibility options defined in syscalls.conf" instead? That's a better idea, included below but s/listed/described/. > > * sort

Re: remove MPSAFE from makesyscalls.sh

On 10:22:58, 7.04.16, Martin Natano wrote: > On Wed, Apr 06, 2016 at 03:42:20PM +0200, Michal Mazurek wrote: > > MPSAFE is never used, and doesn't look like it's even supported (no > > matching SY_MPSAFE anywhere). > > SY_MPSAFE seems to be unused since it's introduction in 2007 and it > doesn't

Re: Moving away from softnet interrupts

> Date: Mon, 2 May 2016 11:27:36 +0200 > From: Martin Pieuchot > > On 18/04/16(Mon) 10:50, Martin Pieuchot wrote: > > The current goal of the Network SMP effort is to have a single CPU > > process the IP forwarding path in a process context without holding > > the

Re: Moving away from softnet interrupts

On 18/04/16(Mon) 10:50, Martin Pieuchot wrote: > The current goal of the Network SMP effort is to have a single CPU > process the IP forwarding path in a process context without holding > the KERNEL_LOCK(). To achieve this goal we're progressively moving > code from the softnet interrupt context

Re: Single route lookup when forwarding an IPv4 packet

On 25/04/16(Mon) 14:40, Martin Pieuchot wrote: > Diff below makes ip_forward() use the route entry fetched in in_ouraddr(). > > As you can imagine a proper caching could be done for forwarding using > PF statekey. > > This diff has been tested by Hrvoje Popovski who confirmed that the >

libpcap: use /dev/bpf

And again: /dev/bpf instead of /dev/bpf*. Ok? natano Index: pcap-bpf.c === RCS file: /cvs/src/lib/libpcap/pcap-bpf.c,v retrieving revision 1.32 diff -u -p -r1.32 pcap-bpf.c --- pcap-bpf.c 22 Dec 2015 19:51:04 - 1.32 +++

armv7: only attach platform busses if explicitly asked for

Hi, currently the armv7 platform busses always match if the board id is set to something they know. This means that even with a device tree the platforms will always try to match, even though they should not. By properly checking for the ma_name member, we can find out if we're being asked to

Re: arm: new FDT-enabled mainbus

On Sun, May 01, 2016 at 04:55:02PM +0200, Mark Kettenis wrote: > > Date: Sun, 1 May 2016 13:27:29 +0200 > > From: Patrick Wildt > > > > Hi, > > > > I updated the diff with the feedback received. This basically adds > > a tree-like topology by making mainbus FDT aware and

dhclient: use /dev/bpf

Diff below simplifies the device open path and removes an explanation about bpf device nodes from the manpage. Ok? natano Index: bpf.c === RCS file: /cvs/src/sbin/dhclient/bpf.c,v retrieving revision 1.38 diff -u -p -r1.38 bpf.c