Re: malloc: 1st small step in long way to multiple pools

2016-03-10 Thread Michael McConville
Otto Moerbeek wrote: > a future goal for malloc is to use multiple pools in threaded > environments, to reduce lock contention. > > This is a small first step towards that goal: move two globals to the > pool-specific struct dir_info. Currently there's only a single pool, > but that will change o

Re: head(1) -c

2016-03-10 Thread lists
> To repeat myself, the addition of this rather silly option is supposed > to reduce differences from other implementations so that we can stop > wasting time about it. It should be cool to be able to run scripts that are expected to run so fine on the other POSIX targeting systems. So, push th

Re: opendev(3) tweak

2016-03-10 Thread Theo de Raadt
I am compelled to add two throughts about opendev() and pledge: Beforehands, please read src/lib/libutil/opendev.c I am not saying opendev is wrong, the design of opening a master device, doing an ioctl, and then finding the correct device to actually open was very expedient, DUID development was

Re: head(1) -c

2016-03-10 Thread Jeremie Courreges-Anglas
"Dmitrij D. Czarkoff" writes: > Jeremie Courreges-Anglas said: >> To repeat myself, the addition of this rather silly option is supposed >> to reduce differences from other implementations so that we can stop >> wasting time about it. > > There is a big difference between providing a switch for c

Probable logic error in st(4)

2016-03-10 Thread Michael McConville
sys/scsi/st.c:1024 uses: > cmd->len != 0 as a condition. However, cmd is of type struct scsi_rw_tape, and its len field is of type u_int8_t len[3]. Therefore, the condition is always true because len is treated as a pointer. Clang warns about this. Thanks for your time, Mike

Re: opendev(3) tweak

2016-03-10 Thread Theo de Raadt
> On Thu, Mar 10, 2016 at 08:48:21AM -0700, Theo de Raadt wrote: > > The reason for these checks is because they protect the kernel, > > and they identify a program that does the wrong thing. Here, a > > program did the wrong thing. I am 100% in agreement that opendev > > may not be the right pla

Re: opendev(3) tweak

2016-03-10 Thread Marc Espie
On Thu, Mar 10, 2016 at 08:48:21AM -0700, Theo de Raadt wrote: > The reason for these checks is because they protect the kernel, > and they identify a program that does the wrong thing. Here, a > program did the wrong thing. I am 100% in agreement that opendev > may not be the right place to do t

Re: head(1) -c

2016-03-10 Thread Theo de Raadt
> Jeremie Courreges-Anglas said: > > To repeat myself, the addition of this rather silly option is supposed > > to reduce differences from other implementations so that we can stop > > wasting time about it. > > There is a big difference between providing a switch for compatibility > and following

Re: head(1) -c

2016-03-10 Thread Dmitrij D. Czarkoff
Jeremie Courreges-Anglas said: > To repeat myself, the addition of this rather silly option is supposed > to reduce differences from other implementations so that we can stop > wasting time about it. There is a big difference between providing a switch for compatibility and following specific beha

Re: head(1) -c

2016-03-10 Thread Daniel Dickman
On Thu, Mar 10, 2016 at 8:14 AM, Jeremie Courreges-Anglas wrote: > Ingo Schwarze writes: > >> Hi, > > Hi Ingo, > >> two general remarks: >> >> 1) The head(1) utility is supposed to handle text files. The posix description for tail seems clear. I suggest following the same treatment for head. >

Re: hang with processes in fltamap: how can I identify running out of RAM?

2016-03-10 Thread Stefan Kempf
Stefan Kempf wrote: > Stuart Henderson wrote: > > On 2016/03/09 20:49, Stefan Kempf wrote: > > > Here's a diff that allocates the most commonly used amap slot sizes > > > (between 1 and 16) using pool_get(9) instead of malloc(9). That should > > > reduce the pressure on kernel virtual address space

Re: Xorg stipple

2016-03-10 Thread Aaron Bieber
joshua stein writes: > Is anyone seriously finding video/Xorg bugs through the default X > stipple pattern anymore? Xorg changed the default to draw a black > background a while ago (with stipple enabled using the -retro flag), > but we have this local change that reverted it while adding a sill

OpenSSH Security Advisory: xauth command injection

2016-03-10 Thread Damien Miller
OpenSSH Security Advisory: x11fwd.adv This document may be found at: http://www.openssh.com/txt/x11fwd.adv 1. Affected configurations All versions of OpenSSH prior to 7.2p2 with X11Forwarding enabled. 2. Vulnerability Missing sanitisation of untrusted input allows an

Re: Xorg stipple

2016-03-10 Thread lists
Wed, 9 Mar 2016 19:40:35 -0600 joshua stein > On Thu, 10 Mar 2016 at 03:32:53 +0200, li...@wrant.com wrote: > > Apparently all you guys use laptops with LVDS, but TFT/LCD panels on > > VGA are still widely common in use. You remember the automatic adjust > > functional button on these monitors, r

Re: Xorg stipple

2016-03-10 Thread lists
Wed, 9 Mar 2016 17:10:07 -0800 Michael McConville > Theo de Raadt wrote: > > > > Is anyone seriously finding video/Xorg bugs through the default X > > > > stipple pattern anymore? Xorg changed the default to draw a black > > > > background a while ago (with stipple enabled using the -retro flag),

Re: Xorg stipple

2016-03-10 Thread lists
Thu, 10 Mar 2016 13:37:50 +0100 Matthieu Herrb > On Wed, Mar 09, 2016 at 05:09:13PM -0600, joshua stein wrote: > > Is anyone seriously finding video/Xorg bugs through the default X > > stipple pattern anymore? Xorg changed the default to draw a black > > background a while ago (with stipple enabl

Re: Xorg stipple

2016-03-10 Thread Artturi Alm
On Wed, Mar 09, 2016 at 07:40:35PM -0600, joshua stein wrote: > On Thu, 10 Mar 2016 at 03:32:53 +0200, li...@wrant.com wrote: > > Apparently all you guys use laptops with LVDS, but TFT/LCD panels on > > VGA are still widely common in use. You remember the automatic adjust > > functional button on

Re: Xorg stipple

2016-03-10 Thread Alexander Bluhm
On Thu, Mar 10, 2016 at 08:00:43AM +0100, Martin Pieuchot wrote: > The current status is just a bad software experience from the 80s. Usually you complain about the 90s :-) Personally I like the traditional X11 appearance. bluhm

Re: opendev(3) tweak

2016-03-10 Thread Theo de Raadt
> So I think we need to narrow down the pledge(2) semantics a bit more > with respect to ioctls. I'm inclined to say that if a certain ioctl > is allowed by pledge(2) it should not abort the program anymore but > return an error like it would do if unpledged. But perhaps we need to > make that de

Re: opendev(3) tweak

2016-03-10 Thread Theo de Raadt
> Checks like the one you introduce here suffer from TOCTOU. I don't see that. It is not a stat, it is an fstat. The descriptor opened early, remains the same type through the whole operation.

Re: opendev(3) tweak

2016-03-10 Thread Mark Kettenis
> Date: Thu, 10 Mar 2016 12:52:35 +0100 > From: Marc Espie > > Already shown to a few people, but since pledge(2) aborts on non-dev, let's > check upfront that we're of the right type. > > I don't think this requires a bump. It doesn't really change the interface, > just makes it stricter. EFTY

Re: head(1) -c

2016-03-10 Thread Jeremie Courreges-Anglas
Ingo Schwarze writes: > Hi, Hi Ingo, > two general remarks: > > 1) The head(1) utility is supposed to handle text files. Our > manual page doesn't mention that technicality - in general, our > manuals avoid excessive technicality in favour of readability - > but POSIX is explicit:

Re: Xorg stipple

2016-03-10 Thread Matthieu Herrb
On Wed, Mar 09, 2016 at 05:09:13PM -0600, joshua stein wrote: > Is anyone seriously finding video/Xorg bugs through the default X > stipple pattern anymore? Xorg changed the default to draw a black > background a while ago (with stipple enabled using the -retro flag), > but we have this local chan

opendev(3) tweak

2016-03-10 Thread Marc Espie
Already shown to a few people, but since pledge(2) aborts on non-dev, let's check upfront that we're of the right type. I don't think this requires a bump. It doesn't really change the interface, just makes it stricter. Index: opendev.3

Re: head(1) -c

2016-03-10 Thread Ingo Schwarze
Hi, two general remarks: 1) The head(1) utility is supposed to handle text files. Our manual page doesn't mention that technicality - in general, our manuals avoid excessive technicality in favour of readability - but POSIX is explicit: "Input files shall be text files, but th

Re: head(1) -c

2016-03-10 Thread Dmitrij D. Czarkoff
Jeremie Courreges-Anglas said: > The situation is a bit muddy. :) > 1. GNU head obeys the last command line option > 2. FreeBSD errors out if both -c and -n are specified > 3. NetBSD always follows -c if it has been specified, probably mixing -c >and -n was overlooked > 4. busybox is a bit more