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? ...and a followup diff for sigaction(2) and signal(3)... Index: gen/signal.3 === RCS file: /cvs/src/lib/libc/gen/signal.3,v

[patch] tcpdump segfault on invalid DECnet packet

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

Re: npppd: simplify and lock down priv_open()

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

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

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

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

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 into the sentence at the start of the context. Which is clearer, what I

patch: native ed support

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

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

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

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

Re: ftp: ctype interfaces need unsigned chars

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

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

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?

tcpdump: simplify signal handling

I suspect I haven't gone far enough. Simplify and correct signal handling in tcpdump: * RETSIGTYPE == void, so kill the define for it * simplify and strengthen setsignal(): * we have sigaction(), so use it * in general, CLI tools shouldn't catch a signal that was ignored on entry.

iwm: fix handling of large firmware commands

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.

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

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 >

Re: iwm: fix handling of large firmware commands

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: iwm: fix handling of large firmware commands

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.

iwm: always initialize index into tx queue array

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

Re: iwm: fix handling of large firmware commands

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

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,

Re: iwm: fix handling of large firmware commands

> 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

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

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: sleep: don't return errno from main()

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?

sendbug(1): remove -V flag

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: [PATCH] fix failover delay in relayd

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

Re: ftp: ctype interfaces need unsigned chars

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: tame() error handling diff

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

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

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