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 if
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 wit
Hello,
OK
sasha
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),
a
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: /data/mirror/op
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 should
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 wi
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
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
==
Ricardo Mestre wrote:
> phantasia(6) needs some KNF love, but for now here is a patch to
> ansify it:
Did you verify that there's no binary change?
> Index: fight.c
> ===
> RCS file: /cvs/src/games/phantasia/fight.c,v
> retrieving re
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
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 alloca
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 cat{op
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 -00
On 02/12/15(Wed) 19:48, Claudio Jeker wrote:
> 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 -- y
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 like fine for me, but why
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 & 10.0.0.20/24
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 user@host.
>
> The patch itse
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 "link"
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 and
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 r
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 insid
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 s
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 mac-ad
> >
> >> 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
>
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 !=
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, ...);
> #endi
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
--- sy
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 a
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 on
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 on the web
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, cleaned
> 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 revisi
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 b
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 these
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. I
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
neti
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:
/home/vcs/cvs/openbsd/src
On 2015-12-02 12:32, Stuart Henderson wrote:
On 2015/12/02 12:09, jus...@postgresql.org wrote:
... This is because I'm a newbie with OpenBSD, and only recently
went looking
for Wifi adapters that will work.
For the ral man page, it lists a whole bunch:
http://www.openbsd.org/cgi-bin/man.cgi
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() han
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
===
> 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 the devices aren't
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 you
> Date: Wed, 2 Dec 2015 13:11:51 +0100
> From: Jonathan Matthew
>
> I'm not sure anyone uses cas(4) but I have one.
I have a couple, but I don't use them a lot.
> I actually started working on this to fix the tx path (it got stuck
> in OACTIVE, didn't use m_defrag) but once I did that, making i
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 revision C and m
I'm not sure anyone uses cas(4) but I have one.
I actually started working on this to fix the tx path (it got stuck in OACTIVE,
didn't use m_defrag) but once I did that, making it mpsafe was pretty easy so I
did that too.
Tested with:
cas0 at pci13 dev 2 function 0 "NS Saturn" rev 0x30: ivec 0x7c
On 02/12/15(Wed) 21:46, David Gwynne wrote:
>
> > 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:
> >>
On Wed, Dec 02, 2015 at 07:07:03AM -0500, Ted Unangst wrote:
> Jason McIntyre wrote:
> > i disagree. it takes .2 of a second to grep the man pages. if nothing
> > shows up, so what. you're no worse off. but if you get a match, great.
> >
> > why undo what's already there? we all know it's impossib
Jason McIntyre wrote:
> i disagree. it takes .2 of a second to grep the man pages. if nothing
> shows up, so what. you're no worse off. but if you get a match, great.
>
> why undo what's already there? we all know it's impossible to list
> everything. it doesn;t mean we can;t list whatever it is w
Hi tech@
This is a revised version of pledging dhcpd(8) with earler pledging.
Hoist up sync_init() due to a multicast setsockopt(2) (IP_MULTICAST_TTL) that
pledge doesn't allow, also hoist up the daemon(3) section, getpwnam(3) and the
check if arguments -A, -C or -L were used (pf table handling)
On 2015-12-02 11:37, 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 you have a device and want to k
On 02/12/15(Wed) 12:36, Claudio Jeker wrote:
> 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?
o
On 1 December 2015 at 23:50, Christian Weisgerber wrote:
> pfkeyv2.h has defines for a number of obsolete algorithms we don't and
> won't implement. These have been mechanically added to ipsecctl and
> iked. I'd like to remove all traces of these zombies.
> (SADB_X_AALG_DES designates DES-MAC au
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 you
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
==
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
m
> 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 if_start() will never be call
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
==
This is mostly a backout of if_bnx.c r1.77, which introduced lists of tx
descriptors, allocated on demand, in order to avoid allocating space per ring
slot. These days I think we can afford a few kb of memory overhead if it
makes the packets go faster.
Aside from that, there are the usual mpsafe
When running rebound without network, the behavior isn't quite the same
because it will receive the query, but then "loses" it trying to forward. This
leads to long timeout delays when a machine might otherwise fail fast.
Proposed solution: send back an empty reply. This counts as a failure and
pu
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?
> >
>
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 because it could only
> 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 held.
>
> as we move
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
> cou
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 KE
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 clo
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 AR
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 loo
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: /cvs
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 on
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 to
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 /
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 t
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 BL
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 AR
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 sendto(2)
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
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 co
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
t
Theo Buehler wrote:
> On Wed, Nov 25, 2015 at 03:22:27PM -0500, Ted Unangst wrote:
> > Theo Buehler wrote:
> > >
> > > If you're not going to maintain a list of high scores of the user, you
> > > could still simplify snscore() further: The score file will just
> > > contain the user's score as a
80 matches
Mail list logo