Re: pfctl: Fix function name in errx(3) message

2017-03-27 Thread Ingo Schwarze
Hi, Gleydson Soares wrote on Mon, Mar 27, 2017 at 04:43:28PM -0300: > instead of hard code, maybe those calls should be changed to: > errx(1, "%s: anystring", __func__) the usual OpenBSD idiom is if ((p = malloc(size)) == NULL) err(1, NULL); see EXAMPLES in malloc(3),

Re: Fix broken example link in packages.7

2017-03-27 Thread Frederic Cambus
On Wed, Mar 01, 2017 at 11:16:57PM +, Stuart Henderson wrote: > > -# export PKG_PATH=ftp://ftp.openbsd.org/pub/OpenBSD/5.2/packages/i386/ > > +# export PKG_PATH=http://ftp.openbsd.org/pub/OpenBSD/%c/packages/%a/ > > Hmm - if you're going to trust autodetection of snapshots vs release >

Re: pfctl: Fix function name in errx(3) message

2017-03-27 Thread Gleydson Soares
> What about the other calls to calloc(3); shouldn't we keep their > respective error messages consistent? seems that several err()/errx() calls in pfctl code are hard-coding the function name... instead of hard code, maybe those calls should be changed to: errx(1, "%s: anystring", __func__)

Re: pfctl: Fix function name in errx(3) message

2017-03-27 Thread Klemens Nanni
On Mon, Mar 27, 2017 at 07:39:09PM +0200, Sebastian Benoit wrote: i commited a err(1, "calloc") instead. What about the other calls to calloc(3); shouldn't we keep their respective error messages consistent?

Re: pfctl: Fix function name in errx(3) message

2017-03-27 Thread Sebastian Benoit
Klemens Nanni(k...@posteo.org) on 2017.03.25 12:39:48 +0100: > Index: pfctl.c > === > RCS file: /cvs/src/sbin/pfctl/pfctl.c,v > retrieving revision 1.338 > diff -u -p -r1.338 pfctl.c > --- pfctl.c 26 Jan 2017 08:24:34 -

Re: sendsyslog file race

2017-03-27 Thread Mateusz Guzik
On Mon, Mar 27, 2017 at 6:09 PM, Alexander Bluhm wrote: > On Mon, Mar 27, 2017 at 05:39:27PM +0200, Mateusz Guzik wrote: > > The previous patch replaced multiple reads of the global var with just > > one read and had the result stored in a local variable, which then is >

arm64 kernel W^X, for real this time?

2017-03-27 Thread Mark Kettenis
So my previous diff only did W^X for the bootstrap page tables. Since these page tables get replaced quickly afterwards, W^X wasn't really enforced. The diff below hopefully does a better job. It removes some commented out code that was clearly trying to do the same thing as pmap_map_stolen().

Re: sendsyslog file race

2017-03-27 Thread Theo de Raadt
> On Mon, Mar 27, 2017 at 05:39:27PM +0200, Mateusz Guzik wrote: > > The previous patch replaced multiple reads of the global var with just > > one read and had the result stored in a local variable, which then is > > read multiple times. Even though the compiler ended up emitting one read > > of

Re: sendsyslog file race

2017-03-27 Thread Alexander Bluhm
On Mon, Mar 27, 2017 at 05:39:27PM +0200, Mateusz Guzik wrote: > The previous patch replaced multiple reads of the global var with just > one read and had the result stored in a local variable, which then is > read multiple times. Even though the compiler ended up emitting one read > of the

Re: sendsyslog file race

2017-03-27 Thread Mateusz Guzik
On Sun, Mar 26, 2017 at 10:04 PM, Alexander Bluhm wrote: > On Sun, Mar 26, 2017 at 05:00:12PM +0200, Mateusz Guzik wrote: > > The patch is somewhat incorrect, although from what I checked it happens > > to generate the expected outcome in terms of assembly (the global

Re: pf: percpu anchor stacks

2017-03-27 Thread Mike Belopuhov
On Fri, Mar 24, 2017 at 12:19 +0100, Alexandr Nedvedicky wrote: > Hello, > > I'm attaching patch, which removes stack-as-a-global variable. > it's updated patch [1] to current tree. > > sorry for being pushy advocating my old, rusty patch. > I think your diff is the way to go indeed. If we can

Re: RTC clocks

2017-03-27 Thread Mark Kettenis
> From: "Todd C. Miller" > Date: Sun, 26 Mar 2017 19:42:01 -0600 > > On Sun, 26 Mar 2017 23:25:48 +0200, Mark Kettenis wrote: > > > The downside of this is that it becomes impossible to set the time > > back that far. But the upside is that if you haven't left a

Re: [PATCH] pcidump - read and write registers

2017-03-27 Thread Simon Mages
Ah ok, good to know. Thanks anyway. 2017-03-27 14:57 GMT+02:00, Mark Kettenis : >> From: Simon Mages >> Date: Mon, 27 Mar 2017 13:57:54 +0200 >> >> Hi, >> >> right now i use the following diff to poke around in the PCIe config >> space. This

Re: [PATCH] pcidump - read and write registers

2017-03-27 Thread Mark Kettenis
> From: Simon Mages > Date: Mon, 27 Mar 2017 13:57:54 +0200 > > Hi, > > right now i use the following diff to poke around in the PCIe config > space. This diff enables > pcidump to read and write to a register. So far i used this mainly to > play with the Advanced >

Re: regarding OpenSSL License change

2017-03-27 Thread Marc Espie
On Thu, Mar 23, 2017 at 10:18:26AM -0600, Theo de Raadt wrote: > Lots of people have been receiving emails like the one below. [...] > Date: Wed, 22 Mar 2017 16:48:10 -0400 > From: lice...@openssl.org > To: dera...@cvs.openbsd.org > Subject: OpenSSL License change > Message-ID:

[PATCH] pcidump - read and write registers

2017-03-27 Thread Simon Mages
Hi, right now i use the following diff to poke around in the PCIe config space. This diff enables pcidump to read and write to a register. So far i used this mainly to play with the Advanced Error Reporting Capability some devices have. $ pcidump 4:0:0:104 4:0:0: Broadcom BCM5754

Re: regarding OpenSSL License change

2017-03-27 Thread Marc Espie
On Sun, Mar 26, 2017 at 08:49:39PM -0500, Jimmy Hess wrote: > > > From: "Constantine A. Murenin" > > > If we do not hear from you, we will assume that you have no objection. > > Is this for real?! > > Who do they think they are? ... > >People should not bother to respond to such nonsense, and

[PATCH] Fix audio on MacBook Pro 5,5

2017-03-27 Thread Manav Rathi
The following changes to the azalia(4) driver were required to hear audio on a MacbookPro 5,5 laptop: --- azalia_codec.c.orig Wed Dec 2 08:41:32 2015 +++ azalia_codec.c Thu Mar 16 17:58:38 2017 @@ -66,7 +66,8 @@ case 0x10134206: this->name = "Cirrus Logic CS4206";