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

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

Re: head(1) -c

> 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

Re: opendev(3) tweak

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

Re: head(1) -c

"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

Probable logic error in st(4)

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

> 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

Re: opendev(3) tweak

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

Re: head(1) -c

> 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

Re: head(1) -c

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

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

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

Re: Xorg stipple

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

OpenSSH Security Advisory: xauth command injection

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

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

Re: Xorg stipple

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

Re: Xorg stipple

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

Re: Xorg stipple

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

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

> 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

Re: opendev(3) tweak

> 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

> 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

Re: head(1) -c

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

Re: Xorg stipple

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

opendev(3) tweak

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

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

Re: head(1) -c

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