Re: bsd.port.mk.5: restructure `clean' section

2015-10-11 Thread Ingo Schwarze
Hi Vadim, Vadim Zhukov wrote on Mon, Oct 05, 2015 at 09:07:41PM +0300: > 2015-09-26 21:49 GMT+03:00 Michael Reed : >> The `clean' target takes optional arguments, so denote that in >> the item header. Additionally, the subtargets are fixed strings, >> not variables, so change the use of Va to Cm

Re: tame() error handling diff

2015-10-11 Thread Ingo Schwarze
Hi, Nicholas Marriott wrote on Tue, Oct 06, 2015 at 11:53:48AM +0100: > On Tue, Oct 06, 2015 at 12:25:57PM +0200, Benny Lofgren wrote: >> In any case, I hope you at least agree with me that the documentation >> should reflect actual behaviour? :-) I've updated my diff to tame.2 to >> describe the

Re: ftp: ctype interfaces need unsigned chars

2015-10-11 Thread Alexander Bluhm
On Sat, Oct 10, 2015 at 08:03:28PM -0700, Philip Guenther wrote: > On Sat, 10 Oct 2015, Michael McConville wrote: > > FWIW, this is a perfect use case for Coccinelle. Below is what I dredged > > up in src/usr.sbin (diff not yet carefully audited, but apparently > > sane). > > These look good to

Re: [PATCH] fix failover delay in relayd

2015-10-11 Thread Brian S. Vangsgaard
bump Den 02-10-2015 kl. 12:09 skrev Brian S. Vangsgaard: Hi Patch for relayd that will enable quick removal of all host-related entries in the related relayd anchor if the host fails the SLA check. Without this patch, the anchor cleanup wil not be called before the next SLA round (adding a min

sendbug(1): remove -V flag

2015-10-11 Thread Michael Reed
The version is stored in a constant string which is prone to become outdated, as has happened here. uname(3) could be used to make sure it's always up to date, but I don't see the point given uname(1)'s `r' flag already does this. Index: sendbug.1

Re: sleep: don't return errno from main()

2015-10-11 Thread Philip Guenther
On Sun, Oct 11, 2015 at 8:19 AM, Ted Unangst wrote: > agreed, but why not return 1? i don't want to have to slap 2>/dev/null around > all my sleep calls now. So don't. Why would you need to?

Re: FreeType-2.6.1 !!header files layout changed again!!

2015-10-11 Thread Matthieu Herrb
On Wed, Oct 07, 2015 at 06:12:24AM -0600, David Coppa wrote: > > Hi! > > New freetype version, new header file layout :( :( > > Now, all header files except 'ft2build.h' are (again) into > /usr/X11R6/include/freetype2/freetype/. > > Luckily, no ABI changes this time. > As far as I'm concerned (

Re: iwm: fix handling of large firmware commands

2015-10-11 Thread Mark Kettenis
> Date: Sun, 11 Oct 2015 17:45:47 +0200 > From: Stefan Sperling > > On Sun, Oct 11, 2015 at 11:31:35AM -0400, Ted Unangst wrote: > > huh? Why an mbuf? Is dma_alloc not a better choice? > > The mbuf pointer already exists to keep track of packets on the > otheor Tx queues. I guess that's why iwn

Re: iwm: fix handling of large firmware commands

2015-10-11 Thread Stefan Sperling
On Sun, Oct 11, 2015 at 12:11:22PM -0400, Ted Unangst wrote: > oh, ok. it look like the short command path wasn't using an mbuf, but i got > that impression only from looking at the diff. maybe wrong. No, it's as bad as you think it is. Short commands stick payload data into the Tx descriptor, whi

Re: iwm: fix handling of large firmware commands

2015-10-11 Thread Ted Unangst
Stefan Sperling wrote: > On Sun, Oct 11, 2015 at 11:31:35AM -0400, Ted Unangst wrote: > > huh? Why an mbuf? Is dma_alloc not a better choice? > > The mbuf pointer already exists to keep track of packets on the > otheor Tx queues. I guess that's why iwn (where this came from) > does it this way. >

Re: iwm: fix handling of large firmware commands

2015-10-11 Thread Stefan Sperling
On Sun, Oct 11, 2015 at 11:31:35AM -0400, Ted Unangst wrote: > huh? Why an mbuf? Is dma_alloc not a better choice? The mbuf pointer already exists to keep track of packets on the otheor Tx queues. I guess that's why iwn (where this came from) does it this way. I don't mind changing to dma_alloc.

Re: iwm: fix handling of large firmware commands

2015-10-11 Thread Ted Unangst
Stefan Sperling wrote: > The iwm(4) driver pre-allocates fw command payload buffers of 320 bytes. > > For some firmware commands, particularly those used when configuring > the PHY (iwm_send_phy_db_cmd) and running scans (iwm_mvm_scan_request), > the payload exceeds 320 bytes. I've seen somewhere

Re: sleep: don't return errno from main()

2015-10-11 Thread Ted Unangst
Philip Guenther wrote: > > As a general rule, programs should not use errno values as an exit status. > > Compare "sleep 10001" w/ and w/o this diff. > > ok? agreed, but why not return 1? i don't want to have to slap 2>/dev/null around all my sleep calls now. > > Index: sleep.c >

iwm: fix handling of large firmware commands

2015-10-11 Thread Stefan Sperling
The iwm(4) driver pre-allocates fw command payload buffers of 320 bytes. For some firmware commands, particularly those used when configuring the PHY (iwm_send_phy_db_cmd) and running scans (iwm_mvm_scan_request), the payload exceeds 320 bytes. I've seen somewhere between 2k and 3.5k being used. P

iwm: always initialize index into tx queue array

2015-10-11 Thread Stefan Sperling
The index into sc->txq used by iwm_tx() is only initialized for management frames. For data frames, iwm picks a garbage index off the stack which is not initialized unless a mgmt frame was processed first in the same loop. This could end rather badly. Fix it the easy way for now, because overall q

[patch] tcpdump segfault on invalid DECnet packet

2015-10-11 Thread Kevin Reay
Fix a tcpdump segfault when attempting to print an invalid DECnet packet. DECnet packet printing code could cause a segfault on an impossibly large packet from a specifically crafted packet. The segfault would occur in tcpdump.c:default_print() called by print-decnet.c:decnet_print(). Patch buil

patch: native ed support

2015-10-11 Thread Tobias Stoeckmann
Currently, patch calls /bin/ed to support ed-formatted diffs, which means that patch needs to pledge proc and exec. As discussed, it would be a huge benefit if we can remove that. Our patch implementation and GNU patch are already very restrictive in which patch lines are sent to ed, so don't expe

Re: document that execve(2) reset an ignored SIGCHLD to default

2015-10-11 Thread jmc
Also reads fine. jmc   Original Message   From: Philip Guenther Sent: Sunday, 11 October 2015 10:04 To: Tech-OpenBSD Subject: Re: document that execve(2) reset an ignored SIGCHLD to default On Sun, 11 Oct 2015, Philip Guenther wrote: > Oooh, I like that combo. How's this this look then, overall?

Re: document that execve(2) reset an ignored SIGCHLD to default

2015-10-11 Thread jmc
I think that reads fine. jmc   Original Message   From: Philip Guenther Sent: Sunday, 11 October 2015 09:49 To: Tech-OpenBSD Subject: Re: document that execve(2) reset an ignored SIGCHLD to default On Sun, 11 Oct 2015, Jason McIntyre wrote: > if you can easily combine it, it probably makes sense

Re: ftp: ctype interfaces need unsigned chars

2015-10-11 Thread Joerg Jung
> Am 11.10.2015 um 04:38 schrieb Philip Guenther : > >> --- smtpd/rfc2822.c >> +++ /tmp/cocci-output-29655-69b554-rfc2822.c >> @@ -93,13 +93,13 @@ parser_feed_header(struct rfc2822_parser >>char*pos; >> >>/* new header */ >> -if (! isspace(*line) && *line != '\0') { >> +

Re: document that execve(2) reset an ignored SIGCHLD to default

2015-10-11 Thread Philip Guenther
On Sun, 11 Oct 2015, Philip Guenther wrote: > Oooh, I like that combo. How's this this look then, overall? ...and a followup diff for sigaction(2) and signal(3)... Index: gen/signal.3 === RCS file: /cvs/src/lib/libc/gen/signal.3,v r

Re: document that execve(2) reset an ignored SIGCHLD to default

2015-10-11 Thread Philip Guenther
On Sun, 11 Oct 2015, Jason McIntyre wrote: > if you can easily combine it, it probably makes sense to do so. i find > the last example you've given to be easiest to read. wording it that way > puts the emphasis on SIGCHLD though - not sure if that's your aim. if > not you could use example two, but

Re: npppd: simplify and lock down priv_open()

2015-10-11 Thread YASUOKA Masahiko
ok yasuoka, the diff is tested. On Sat, 10 Oct 2015 21:58:02 -0700 Philip Guenther wrote: > On Sat, 10 Oct 2015, Theo de Raadt wrote: >> I don't know the code either, but it is probably better if privsep's had >> more narrow task-specific operations. Like open-specific-file-for-read, >> and op

Re: document that execve(2) reset an ignored SIGCHLD to default

2015-10-11 Thread Jason McIntyre
On Sat, Oct 10, 2015 at 11:34:02PM -0700, Philip Guenther wrote: > POSIX permits the Right Thing (resetting SIGCHLD, as we do), but doesn't > require it. Document both that we do it and that it's not portable to > require it. > > > I'm moderately concerned that the first bit should be merged i