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
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.
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:
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
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
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
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, ...);
>
> 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
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
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,
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
---
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
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 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 !=
> >
> >> 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: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
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
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 &
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
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
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
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
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
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 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
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
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
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
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
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
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
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
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:
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
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
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),
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
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
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
Hello,
OK
sasha
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
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 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
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
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:
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 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
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
>
> 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
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
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
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
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 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
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
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
> 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
> 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
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
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()
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
62 matches
Mail list logo