explicitly check broadcast addresses on some ifa_ifwithaddr() uses

When fed a broadcast address, ifa_ifwitaddr() returns the unicast ifa whose broadcast address match the input. This is used mainly to select ifa, and there can be trouble when you have 2 ifas on the same range (e.g. 10.0.0.1/24@em0 & 10.0.0.20/24@em1) : netinet/ip_mroute.c:814 net/route.c:785

pf statekey inp chaining

Hi, To avoid that the stack manipules the pf statekeys directly, introduce some pf_inp_...() functions as an interface. Locks can be added to them later. I have removed the first chaining at the beginning of tcp_input() and udp_input() directly after in_pcbhashlookup() as it is not necessary.

ARM as: add .inst support

Add support for .inst 0xdeadbeef. Required to move forward with gcc 4.9 No GPLv3 license was violated during writing this trivial diff ok? Index: gnu/usr.bin/binutils-2.17/gas/config/tc-arm.c === RCS file:

Re: rm bge supported devices

On 2015-12-02 14:12, Reyk Floeter wrote: n Wed, Dec 02, 2015 at 06:37:19AM -0500, Ted Unangst wrote: >There are many other product lists, but starting with the two big broadcom >flavors here. I've had a dozen machines with bge, but none of them were listed >in the man page. I don't think

Re: WAPBL: Adding the FFS capability to alloc files contiguously

Bob Beck wrote: > On Fri, Nov 27, 2015 at 02:50:57PM -0200, Walter Neto wrote: > > You have a number of places here where you introduce a line of 8 spaces > after your #endif - please clean up the trailing spaces, they shouldn't be > there. > > You also have uses of B_METAONLY that are not

rm bonus inet6 option

We have a socket option guarded by ifdef _KERNEL that therefore cannot be used by userland (nor used in kernel). No pcb code tests for the flag either. Index: netinet/in_pcb.h === RCS file: /cvs/src/sys/netinet/in_pcb.h,v retrieving

Re: WAPBL: Adding the FFS capability to alloc files contiguously

Walter Neto wrote: > > You also have uses of B_METAONLY that are not inside a #ifdef WAPBL in > > ffs_balloc.c > > > > Yeah, but I don't know what is the best way to correct it. > Should I use: > #ifdef WAPBL > foo(..., flags | B_METAONLY, ...); > #else > foo(..., flags, ...); >

Re: rm bge supported devices

> On 2015/12/02 12:09, jus...@postgresql.org wrote: > > On 2015-12-02 11:37, Ted Unangst wrote: > > >2. If you have picked a driver and are trying to find a device, these > > >are very incomplete guides. Most of the devices aren't for sale anymore. > > >Many of the rest are now revision B or

Re: rm bge supported devices

On 2015-12-02 16:07, Alexander Salmin wrote: I don't mind if this information is removed from the manual of the device driver but I do mind if this information is lost without being implemented somewhere else. Maybe it can be a list on the web FAQ somewhere if you don't want it there. I'd also

Re: WAPBL: Adding the FFS capability to alloc files contiguously

On Sat, Nov 28, 2015 at 03:49:21PM -0700, Bob Beck wrote: > On Fri, Nov 27, 2015 at 02:50:57PM -0200, Walter Neto wrote: > > You have a number of places here where you introduce a line of 8 spaces > after your #endif - please clean up the trailing spaces, they shouldn't be > there. > Ok,

netinet6 - bcopy -> memcpy

Hello - Here are a few bcopy -> memcpy conversions for buffers that do not overlap. Index: sys/netinet6/ip6_forward.c === RCS file: /cvs/src/sys/netinet6/ip6_forward.c,v retrieving revision 1.86 diff -u -p -r1.86 ip6_forward.c ---

Re: rm bge supported devices

On Wed, Dec 02, 2015 at 09:30:30AM -0700, Theo de Raadt wrote: > I agree with Stuart. > > When these lists include chip numbers, that is valuable. Lists > containing names like Belkin RandomProduct may be less helpful, but > the case hasn't been proven the lists should be removed. I completely

Re: rm bge supported devices

On 2015/12/02 16:40, jus...@postgresql.org wrote: > On 2015-12-02 16:07, Alexander Salmin wrote: > > >I don't mind if this information is removed from the manual of the > >device driver but I do mind if this information is lost without being > >implemented somewhere else. Maybe it can be a list

Re: rm bge supported devices

On 2015-12-02 17:39, Theo de Raadt wrote: Sorry to have to tell you - what you propose is competely impossible. At the low-end, we have experienced numerous cases where model numbers don't change, but chipsets do. What you propose is not time well spent. Oh well. Another case of theory !=

Re: rm bge supported devices

> > > >> I don't mind if this information is removed from the manual of the > >> device driver but I do mind if this information is lost without > >> being > >> implemented somewhere else. Maybe it can be a list on the web FAQ > >> somewhere if you don't want it there. I'd also be happy to help

Re: rm bge supported devices

On 2015-12-02 17:24, Stuart Henderson wrote: On 2015/12/02 16:40, jus...@postgresql.org wrote: On 2015-12-02 16:07, Alexander Salmin wrote: >I don't mind if this information is removed from the manual of the >device driver but I do mind if this information is lost without being >implemented

kill another carp madness

The check in if_ether.c for carp here does not make any sense. There are two possible cases. - parent interface without IP address - parent interface with IP address In the first case the carp mac-address will always be used. So no need to do the check. In the 2nd case the parent interface

Re: explicitly check broadcast addresses on some ifa_ifwithaddr() uses

On 02/12/15(Wed) 16:18, Vincent Gross wrote: > When fed a broadcast address, ifa_ifwitaddr() returns the unicast ifa > whose broadcast address match the input. This is used mainly to select > ifa, and there can be trouble when you have 2 ifas on the same range > (e.g. 10.0.0.1/24@em0 &

Re: doas password prompt

Vadim Zhukov wrote: > 2015-12-02 12:40 GMT+03:00 Ted Unangst : > > henning points out that if you are seven levels deep when doas asks for a > > password, it can be hard to tell who is asking for what password. > > > > modify the prompt to include the program name and

Re: doas password prompt

2015-12-02 12:40 GMT+03:00 Ted Unangst : > henning points out that if you are seven levels deep when doas asks for a > password, it can be hard to tell who is asking for what password. > > modify the prompt to include the program name and user@host. The patch itself looks

remove language catalogs from vi

Hello tech@, I've had a discussion with bentley@ about some patches for vi. Some of which I've send to Zhihao from the nvi2 project to keep the projects somewhat in sync. I'm still awaiting his response on those before sending them here. nvi2 switched with catalog support to using the

Ansify phantasia(6)

phantasia(6) needs some KNF love, but for now here is a patch to ansify it: Index: fight.c === RCS file: /cvs/src/games/phantasia/fight.c,v retrieving revision 1.11 diff -u -p -u -r1.11 fight.c --- fight.c 12 Jul 2014 03:41:04

Re: WAPBL: Adding the FFS capability to alloc files contiguously

Fixed diff Ok beck@ and tedu@ -- Walter Neto diff --git a/sys/sys/buf.h b/sys/sys/buf.h index c47f3f9..fd38c28 100644 --- a/sys/sys/buf.h +++ b/sys/sys/buf.h @@ -254,6 +254,8 @@ struct cluster_save { /* Flags to low-level allocation routines. */ #define B_CLRBUF 0x01/* Request

libc: locale/rune.c input validation

Hi, this patch adds a lot of input validation to libc/locale/rune.c. The kind of validations are borrowed from my nls changes some weeks ago. I've contacted stsp@ about this. I think it's ready to get more review from tech@. Let me know what you think! Tobias Index: rune.c

more arp cleanup

More rt_ifp killing. This time in in_arpinput(). This function is a bit special because of the way we propagte multicast and broadcast packets it is possible that multiple interfaces recieve the same request. In most cases this is because of -- you can guess -- carp(4). So simplify these checks

Re: pf statekey inp chaining

On Wed, Dec 02, 2015 at 04:48:51PM +0100, Alexander Bluhm wrote: > To avoid that the stack manipules the pf statekeys directly, introduce > some pf_inp_...() functions as an interface. Locks can be added > to them later. Here is a new version of the diff. This is new: - rename "chain" to

Re: unifdef(1) - in-place editing without backups

On 2015/12/02 00:04, Michael McConville wrote: > unifdef's -M option is like sed's -i option, editing in-place and saving > a backup with the supplied extension. There is an upstream for unifdef: http://dotat.at/prog/unifdef/ Please talk to Tony Finch and see if he'll take the diff; it's helpful

bridge(4) never outputs packets

Make sure if_output() and if_start() will never be called for the bridge(4). Concerns? Index: net/if_bridge.c === RCS file: /cvs/src/sys/net/if_bridge.c,v retrieving revision 1.273 diff -u -p -r1.273 if_bridge.c --- net/if_bridge.c

Re: pledge dhcpd(8), 1st attempt

Hi Stuart, You are right, they have, my problem in this case was that I'm trying to pledge earlier and with the codepaths I was using I was being blocked right there. I should have checked kern_pledge.c first and/or removed those earlier pledges to confirm if the problem really was from

Dumb arplookup()

If the kernel tries to create (cloned) an ARP entry and found an existing conflicting route, do not try to be clever and just bail. I'm fine with rtalloc(9) taking the KERNEL_LOCK when cloning an entry but I'd prefer the ARP layer to not try to delete anything in the hot path. If you entered a

Re: Completely disable 2D acceleration on Broadwell

On 2015 Dec 02 (Wed) at 17:13:32 +1100 (+1100), Jonathan Gray wrote: :On Tue, Dec 01, 2015 at 04:44:39PM +0100, Mark Kettenis wrote: :> As tedu@ reported (and some pople on misc@ confirmed) partly disabling :> 2D acceleration on Broadwell made X unstable. It really looks like :> the alternative

Re: Dumb arplookup()

On Wed, Dec 02, 2015 at 09:44:15AM +0100, Martin Pieuchot wrote: > If the kernel tries to create (cloned) an ARP entry and found an > existing conflicting route, do not try to be clever and just bail. > > I'm fine with rtalloc(9) taking the KERNEL_LOCK when cloning an entry > but I'd prefer the

pf unlink remove

Hi, So here is the result of the pf unlink bikeshedding. Rename pf_unlink_state() to pf_remove_state() so the name does not collide with the statekey to inp unlinking. ok? bluhm Index: net/if_pfsync.c === RCS file:

Re: more arp cleanup

Last but of rt_ifp cleanup. Since we want to print the interface names in those log messages we need to do the if_get/if_put dance there. Since this is only in 2 places which should not be super common that should be fine and with this arp should be MP save :) -- :wq Claudio Index: if_ether.c

Pledge `dns' in httpd(8)

Hi people, httpd needs to pledge `dns' for name resolution to work while loading the configuration: # cat /tmp/test.conf server "default" { listen on imnotlocal port 80 } # httpd -dnvf /tmp/test.conf Abort trap # dmesg | tail -n1

IPsec: remove DES support

Quoth ipsec.conf(5): Use of DES as an encryption algorithm is considered to be insecure since brute force attacks are practical due its short key length. The attached patch removes support for DES-CBC encryption in ESP and in IKE main and quick mode from the kernel, iked(8), ipsecctl(8),

Re: more arp cleanup

On Wed, Dec 02, 2015 at 10:19:23PM +0100, Claudio Jeker wrote: > Last but of rt_ifp cleanup. Since we want to print the interface names in > those log messages we need to do the if_get/if_put dance there. Since this > is only in 2 places which should not be super common that should be fine > and

Re: more arp cleanup

On 02/12/15(Wed) 22:19, Claudio Jeker wrote: > Last but of rt_ifp cleanup. Since we want to print the interface names in > those log messages we need to do the if_get/if_put dance there. Since this > is only in 2 places which should not be super common that should be fine > and with this arp

preparing multitouch support - request for tests

The diffs below contain a complete and extensive rewrite of the input-processing parts of wsmouse and the interface it provides to the hardware drivers. It prepares the support for various kinds of multitouch input, as well as an extended support for touchpads by wsmouse. Tests for regression

Re: pf unlink remove

Hello, OK sasha

Re: unifdef(1) - in-place editing without backups

Stuart Henderson wrote: > On 2015/12/02 00:04, Michael McConville wrote: > > unifdef's -M option is like sed's -i option, editing in-place and > > saving a backup with the supplied extension. > > There is an upstream for unifdef: http://dotat.at/prog/unifdef/ > Please talk to Tony Finch and see

Re: bridge(4) never outputs packets

On Wed, Dec 02, 2015 at 09:57:59AM +0100, Martin Pieuchot wrote: > Make sure if_output() and if_start() will never be called for the > bridge(4). > > Concerns? > You should clarify in the comment above the actual bridge_output() function that this function is intended to be used by bridgeport /

Re: Dumb arplookup()

On 2015/12/02 09:44, Martin Pieuchot wrote: > If the kernel tries to create (cloned) an ARP entry and found an > existing conflicting route, do not try to be clever and just bail. > > I'm fine with rtalloc(9) taking the KERNEL_LOCK when cloning an entry > but I'd prefer the ARP layer to not try

Re: Dumb arplookup()

On 02/12/15(Wed) 09:26, Stuart Henderson wrote: > On 2015/12/02 09:44, Martin Pieuchot wrote: > > If the kernel tries to create (cloned) an ARP entry and found an > > existing conflicting route, do not try to be clever and just bail. > > > > I'm fine with rtalloc(9) taking the KERNEL_LOCK when

doas password prompt

henning points out that if you are seven levels deep when doas asks for a password, it can be hard to tell who is asking for what password. modify the prompt to include the program name and user@host. Index: doas.c === RCS file:

Re: Completely disable 2D acceleration on Broadwell

On Wed, Dec 02, 2015 at 10:16:21AM +0100, Peter Hessler wrote: > On 2015 Dec 02 (Wed) at 17:13:32 +1100 (+1100), Jonathan Gray wrote: > :On Tue, Dec 01, 2015 at 04:44:39PM +0100, Mark Kettenis wrote: > :> As tedu@ reported (and some pople on misc@ confirmed) partly disabling > :> 2D acceleration

Re: Dumb arplookup()

On Wed, Dec 02, 2015 at 09:26:35AM +, Stuart Henderson wrote: > On 2015/12/02 09:44, Martin Pieuchot wrote: > > If the kernel tries to create (cloned) an ARP entry and found an > > existing conflicting route, do not try to be clever and just bail. > > > > I'm fine with rtalloc(9) taking the

Re: bridge(4) never outputs packets

On 02/12/15(Wed) 10:25, Claudio Jeker wrote: > On Wed, Dec 02, 2015 at 09:57:59AM +0100, Martin Pieuchot wrote: > > Make sure if_output() and if_start() will never be called for the > > bridge(4). > > > > Concerns? > > Why not use if_detached_start()? There is no if_detached_output() but we >

Re: serialise if_start calls

> On 30 Nov 2015, at 9:55 PM, David Gwynne wrote: > > this tweaks the guts of if_start so it guarantees that there's only > ever one call to ifp->if_start running in the system at a time. > previously this was implicit because it could only be called with > the KERNEL_LOCK

Re: bridge(4) never outputs packets

On Wed, Dec 02, 2015 at 09:57:59AM +0100, Martin Pieuchot wrote: > Make sure if_output() and if_start() will never be called for the > bridge(4). > > Concerns? Why not use if_detached_start()? There is no if_detached_output() but we could add that as well. I would prefer that over NULL pointers

Re: Completely disable 2D acceleration on Broadwell

Peter Hessler wrote: > On 2015 Dec 02 (Wed) at 17:13:32 +1100 (+1100), Jonathan Gray wrote: > :On Tue, Dec 01, 2015 at 04:44:39PM +0100, Mark Kettenis wrote: > :> As tedu@ reported (and some pople on misc@ confirmed) partly disabling > :> 2D acceleration on Broadwell made X unstable. It really

Re: serialise if_start calls

On 02/12/15(Wed) 20:38, David Gwynne wrote: > > > On 30 Nov 2015, at 9:55 PM, David Gwynne wrote: > > > > this tweaks the guts of if_start so it guarantees that there's only > > ever one call to ifp->if_start running in the system at a time. > > previously this was implicit

Re: bridge(4) never outputs packets

On Wed, Dec 02, 2015 at 11:07:40AM +0100, Martin Pieuchot wrote: > On 02/12/15(Wed) 10:25, Claudio Jeker wrote: > > On Wed, Dec 02, 2015 at 09:57:59AM +0100, Martin Pieuchot wrote: > > > Make sure if_output() and if_start() will never be called for the > > > bridge(4). > > > > > > Concerns? > >

Re: rm bge supported devices

On Wed, Dec 02, 2015 at 06:37:19AM -0500, Ted Unangst wrote: > There are many other product lists, but starting with the two big broadcom > flavors here. I've had a dozen machines with bge, but none of them were listed > in the man page. I don't think these product lists are helpful. > > 1. If

Kill RTM_MISS & RT_REPORT

As suggested by claudio@, RTM_MISS is no longer useful and it makes rt_match() complicated with the upcoming KERNEL_LOCK dance. This simplifies rtalloc(9) as RT_REPORT can also die. I'll update the manuals if this is ok. Index: net/if_mpe.c

kill RT_REPORT since it is useless

The time where route miss messages on rtalloc() where useful are long gone. In modern times this just produces a lot of noise with no benefit. Nothing in userland is using this information anyway. Because of this reti^Wtedu RT_REPORT. OK? -- :wq Claudio Index: net/if_mpe.c

rm bge supported devices

There are many other product lists, but starting with the two big broadcom flavors here. I've had a dozen machines with bge, but none of them were listed in the man page. I don't think these product lists are helpful. 1. If you have a device and want to know if it's supported, there's no reverse

Re: bridge(4) never outputs packets

> On 2 Dec 2015, at 8:49 PM, Claudio Jeker wrote: > > On Wed, Dec 02, 2015 at 11:07:40AM +0100, Martin Pieuchot wrote: >> On 02/12/15(Wed) 10:25, Claudio Jeker wrote: >>> On Wed, Dec 02, 2015 at 09:57:59AM +0100, Martin Pieuchot wrote: Make sure if_output() and

Re: rm bge supported devices

> Date: Wed, 2 Dec 2015 12:32:52 + > From: Stuart Henderson > > On 2015/12/02 12:09, jus...@postgresql.org wrote: > > On 2015-12-02 11:37, Ted Unangst wrote: > > >2. If you have picked a driver and are trying to find a device, these > > >are very incomplete guides. Most of

Few nitpicks on games

Hi tech@ Few nitpicks on games: Change home var to const char* both on canfield(6)/cfscores(6), and on the latter also remove unused var name. Additionaly on snake(6) one of the getenv("HOME") missed a safe checking for NULL. Index: games/canfield/canfield/canfield.c

malloc canaries and validation

This is a variant of the diffs sent by Daniel Micay, and then assembled by Theo Buehler. I've looked it over and made a few tweaks. One: validate the junk in malloc hasn't been touched. I've tweaked this to always be on if junk is on, but to only check the first 32 bytes. (Without the atexit()

Re: rm bge supported devices

On Wed, Dec 02, 2015 at 06:37:19AM -0500, Ted Unangst wrote: > There are many other product lists, but starting with the two big broadcom > flavors here. I've had a dozen machines with bge, but none of them were listed > in the man page. I don't think these product lists are helpful. > > 1. If