On April 25, 2014 2:14:29 AM CEST, Peter Malone wrote:
>Hi,
>
>Here's another.
>
>Index: l2tp_ctrl.c
>===
>RCS file: /cvs/src/usr.sbin/npppd/l2tp/l2tp_ctrl.c,v
>retrieving revision 1.16
>diff -u -p -u -r1.16 l2tp_ctrl.c
>--- l2tp_ct
Now is not the time for this diff
Please wait a week or so till the ports mysteries are sorted
Patch updated.
ok?
Index: nfsd.c
===
RCS file: /cvs/src/sbin/nfsd/nfsd.c,v
retrieving revision 1.32
diff -u -p -u -r1.32 nfsd.c
--- nfsd.
On Fri, Apr 25, 2014 at 09:09:03AM +0900, Ryan McBride wrote:
> Part of the reason it's there is to make carp work properly for services
> listening on the carp interface, in particular so that hosts in the
> BACKUP state will reach the MASTER rather than trying and failing to
> connect to their ow
Thanks Ted.
I sent through another patch with timeout = -1. Passing INFTIM sounds
like the best option though.
Hopefully the rest checks out.
On 04/24/14 20:30, Ted Unangst wrote:
On Thu, Apr 24, 2014 at 19:27, Peter Malone wrote:
The more I think about this. if we want to continue the
Hi,
Another malloc & memset => calloc.
Index: parse.c
===
RCS file: /cvs/src/lib/libusbhid/parse.c,v
retrieving revision 1.7
diff -u -p -u -r1.7 parse.c
--- parse.c 16 Jul 2012 19:57:17 - 1.7
+++ parse.c 25 Apr 2014
On Thu, Apr 24, 2014 at 19:27, Peter Malone wrote:
> The more I think about this. if we want to continue the select()
> NULL functionality then timeout should be a negative value for poll(),
> as NULL is unrecognized and zero is a zero-length timeout.
The standard way to effect no timeout fo
On Thu, Apr 24, 2014 at 06:25:59PM +0200, Henning Brauer wrote:
> * Alexander Bluhm [2014-04-24 18:18]:
> > The carp_setroute() function starts with the encouraging comment
> > /* XXX this mess needs fixing */.
>
> I didn't change my mind at least :)
> 1.136(henning 04-May-07): /* X
Hi,
Here's another.
Index: l2tp_ctrl.c
===
RCS file: /cvs/src/usr.sbin/npppd/l2tp/l2tp_ctrl.c,v
retrieving revision 1.16
diff -u -p -u -r1.16 l2tp_ctrl.c
--- l2tp_ctrl.c 13 Sep 2013 03:25:27 - 1.16
+++ l2tp_ctrl.c 25 Apr 201
Hi,
Here's another.
Index: l2tpd.c
===
RCS file: /cvs/src/usr.sbin/npppd/l2tp/l2tpd.c,v
retrieving revision 1.14
diff -u -p -u -r1.14 l2tpd.c
--- l2tpd.c 22 Mar 2014 04:32:39 - 1.14
+++ l2tpd.c 25 Apr 2014 00:09:33
Hi,
Here's another malloc & memset => calloc replacement.
Index: rtsold.c
===
RCS file: /cvs/src/usr.sbin/rtsold/rtsold.c,v
retrieving revision 1.50
diff -u -p -u -r1.50 rtsold.c
--- rtsold.c21 Oct 2013 08:46:07 - 1.50
+
Patch updated.
ok?
Index: nfsd.c
===
RCS file: /cvs/src/sbin/nfsd/nfsd.c,v
retrieving revision 1.32
diff -u -p -u -r1.32 nfsd.c
--- nfsd.c 11 Mar 2013 17:40:10 - 1.32
+++ nfsd.c 24 Apr 2014 23:35:06 -
@@ -103,
The more I think about this. if we want to continue the select()
NULL functionality then timeout should be a negative value for poll(),
as NULL is unrecognized and zero is a zero-length timeout.
On 04/24/14 18:08, Peter Malone wrote:
As promised. I cleaned up some of the code as well.
On
As promised. I cleaned up some of the code as well.
One item of note - select() took a NULL value for timeout. I did not want to do
this with poll(), so I defaulted with 10 instead. We should probably discuss
this. I didn't even try to compile poll() with NULL - I don't think it's a good
idea a
Anybody have time to look at this?
On Tue, Apr 22, 2014 at 01:29:03AM +, Ben Cornett wrote:
> The following corrects the termination condition on the write
> loop in copyfile.
>
> Index: usr.sbin/vipw/vipw.c
> ===
> RCS file: /cvs
Hi tech,
this assignment is never read.
Fritjof
Index: collect.c
===
RCS file: /cvs/src/usr.bin/mail/collect.c,v
retrieving revision 1.34
diff -u -p -r1.34 collect.c
--- collect.c 17 Jan 2014 18:42:30 - 1.34
+++ collect.c
Great explanation - thanks.
On 04/24/14 08:28, Todd C. Miller wrote:
Sudo runs on more systems thsan just OpenBSD and so has a lot of
configure goo and defines as a result. There's really no point in
removing that. Any changes made to the sudo in OpenBSD just makes
updates harder.
The allo
On 04/24/14 22:28, Mike Belopuhov wrote:
On 24 April 2014 22:25, Alexander Hall wrote:
On 04/24/14 21:53, Stuart Henderson wrote:
On 2014/04/24 20:30, Mike Belopuhov wrote:
On 24 April 2014 20:25, Chris Cappuccio wrote:
Mike Belopuhov [m...@belopuhov.com] wrote:
more like it's not sup
On 2014/04/24 22:28, Mike Belopuhov wrote:
> On 24 April 2014 22:25, Alexander Hall wrote:
> > On 04/24/14 21:53, Stuart Henderson wrote:
> >>
> >> On 2014/04/24 20:30, Mike Belopuhov wrote:
> >>>
> >>> On 24 April 2014 20:25, Chris Cappuccio wrote:
>
> Mike Belopuhov [m...@belopuhov.co
On 24 April 2014 22:25, Alexander Hall wrote:
> On 04/24/14 21:53, Stuart Henderson wrote:
>>
>> On 2014/04/24 20:30, Mike Belopuhov wrote:
>>>
>>> On 24 April 2014 20:25, Chris Cappuccio wrote:
Mike Belopuhov [m...@belopuhov.com] wrote:
>
>
> more like it's not supported an
On 04/24/14 21:53, Stuart Henderson wrote:
On 2014/04/24 20:30, Mike Belopuhov wrote:
On 24 April 2014 20:25, Chris Cappuccio wrote:
Mike Belopuhov [m...@belopuhov.com] wrote:
more like it's not supported and is not supposed to work.
it's like running nginx and apache at the same time
hey,
Hello tech,
I got a bit bored, so I decided to help in the springcleaning of libssl.
I removed some seemingly harmless WIN32 defines.
According to grep there's still some WIN32 named functions and defines
left, but I didn't dare to touch those.
I couldn't test this diff because I got the follow
On 2014/04/24 20:30, Mike Belopuhov wrote:
> On 24 April 2014 20:25, Chris Cappuccio wrote:
> > Mike Belopuhov [m...@belopuhov.com] wrote:
> >>
> >> more like it's not supported and is not supposed to work.
> >> it's like running nginx and apache at the same time
> >
> > hey, nginx and httpd run c
On 24 April 2014 20:25, Chris Cappuccio wrote:
> Mike Belopuhov [m...@belopuhov.com] wrote:
>>
>> more like it's not supported and is not supposed to work.
>> it's like running nginx and apache at the same time
>
> hey, nginx and httpd run concurrently quite fine on
> different IP addresses, same
Mike Belopuhov [m...@belopuhov.com] wrote:
>
> more like it's not supported and is not supposed to work.
> it's like running nginx and apache at the same time
hey, nginx and httpd run concurrently quite fine on
different IP addresses, same box :)
On 24/04/14(Thu) 18:17, Alexander Bluhm wrote:
> On Thu, Apr 24, 2014 at 01:43:16PM +0200, Henning Brauer wrote:
> > * Martin Pieuchot [2014-04-24 13:24]:
> > > This ifp pointer is only needed by rt_getifa() to find an address, so
> > > make it a local variable.
> > >
> > > The rtrequest1(9) chan
* Alexander Bluhm [2014-04-24 18:18]:
> The carp_setroute() function starts with the encouraging comment
> /* XXX this mess needs fixing */.
I didn't change my mind at least :)
1.136(henning 04-May-07): /* XXX this mess needs fixing */
> When switching carp states fast,
> the routi
On Thu, Apr 24, 2014 at 01:43:16PM +0200, Henning Brauer wrote:
> * Martin Pieuchot [2014-04-24 13:24]:
> > This ifp pointer is only needed by rt_getifa() to find an address, so
> > make it a local variable.
> >
> > The rtrequest1(9) change might introduce a negligible slowdown since
> > I remove
On Thu, Apr 24, 2014 at 04:41:06PM +0200, Martin Pieuchot wrote:
> in_localaddr() is used only once in our tree and only if the sysctl
> net.inet.ip.mtudisc is set to 0.
>
> It is used to optimize the size of the MSS if the forward address
> correspond to a host on one of our subnets. Since it's
On 24 April 2014 16:41, Martin Pieuchot wrote:
> in_localaddr() is used only once in our tree and only if the sysctl
> net.inet.ip.mtudisc is set to 0.
>
> It is used to optimize the size of the MSS if the forward address
> correspond to a host on one of our subnets. Since it's an
> optimization
On Thu, Apr 24, 2014 at 02:52:27PM +0200, Martin Pieuchot wrote:
> On 24/04/14(Thu) 13:43, Henning Brauer wrote:
> > * Martin Pieuchot [2014-04-24 13:24]:
> > > This ifp pointer is only needed by rt_getifa() to find an address, so
> > > make it a local variable.
> > >
> > > The rtrequest1(9) chan
in_localaddr() is used only once in our tree and only if the sysctl
net.inet.ip.mtudisc is set to 0.
It is used to optimize the size of the MSS if the forward address
correspond to a host on one of our subnets. Since it's an
optimization for a special case that's not enabled by default, I'd
like
I've heard nothing but positive feedback on this diff. It seems to
help fix sluggish ssh connections experienced while machines were
under high load. Looking for some folks to OK this. Thanks.
On Wed, Apr 16, 2014 at 2:35 PM, Benjamin Baier wrote:
> Compiles, boots and runs fine on my BBB.
> I ha
On 24.04.14 02:45, Bob Beck wrote:
> Hi Dirk, I'm not fond of this because you've included all the various
> BLAHWOOF_free functions in the bag.
I agree that this creepy macro hell must die. It makes auditing the
software nearly impossible. What they basically have done is to put
OO-lipstick on a
On 24/04/14(Thu) 13:43, Henning Brauer wrote:
> * Martin Pieuchot [2014-04-24 13:24]:
> > This ifp pointer is only needed by rt_getifa() to find an address, so
> > make it a local variable.
> >
> > The rtrequest1(9) change might introduce a negligible slowdown since
> > I remove the already known
Sudo runs on more systems thsan just OpenBSD and so has a lot of
configure goo and defines as a result. There's really no point in
removing that. Any changes made to the sudo in OpenBSD just makes
updates harder.
The alloc functions implement integer overflow checks that are not
present on most
* Martin Pieuchot [2014-04-24 13:24]:
> This ifp pointer is only needed by rt_getifa() to find an address, so
> make it a local variable.
>
> The rtrequest1(9) change might introduce a negligible slowdown since
> I remove the already known ifp pointer. But this only happens in the
> case describ
This ifp pointer is only needed by rt_getifa() to find an address, so
make it a local variable.
The rtrequest1(9) change might introduce a negligible slowdown since
I remove the already known ifp pointer. But this only happens in the
case described in the comment just before and I would bet becau
On 04/24/14 04:09, Stuart Henderson wrote:
On 2014/04/24 04:26, Miod Vallat wrote:
Same as the others, this time with src/usr.bin/mg/undo.c
You are now losing a memset() in the `rec doesn't come from malloc' code
path.
From the number and types of diff being sent, I am guessing these are
tool
On 24 April 2014 12:12, Philipp
wrote:
> Am 22.04.2014 17:28 schrieb Mike Belopuhov:
>
>> more like it's not supported and is not supposed to work.
>
> not supposed as in 'not wanted'?
>
not supposed.
>
>> it's like running nginx and apache at the same time but
>
> Quite frankly: I'm doing that
Am 22.04.2014 17:28 schrieb Mike Belopuhov:
more like it's not supported and is not supposed to work.
not supposed as in 'not wanted'?
it's like running nginx and apache at the same time but
Quite frankly: I'm doing that in some locations ;-)
worse since there are kernel tentacles involved
On 2014/04/24 09:40, Vadim Lebedev wrote:
> Peter Malone petermalone.org> writes:
>
> >
> > Hi,
> >
> > Same as the others. Replace malloc & memset with calloc in
> usr.sbin/snmpd/mib.c
> >
> > Index: mib.c
> > ===
> > RCS file:
Peter Malone petermalone.org> writes:
>
> Hi,
>
> Same as the others. Replace malloc & memset with calloc in
usr.sbin/snmpd/mib.c
>
> Index: mib.c
> ===
> RCS file: /cvs/src/usr.sbin/snmpd/mib.c,v
> retrieving revision 1.67
> dif
On 22 April 2014 17:40, Claer wrote:
> On Tue, Apr 22 2014 at 28:17, Mike Belopuhov wrote:
>
>> On 22 April 2014 17:13, Philipp
>> wrote:
>> > It happened! A remote peer *requires* IKEv2 - and I've to do that on a
>> > machine running isakmpd with somewhat 25+ IKEv1 peers.
>> >
>> > First hurdle:
Hi tech@,
The patch below adds the nVidia GeForce GT 740M found on a Dell Lattitude 3440.
This laptop has a onboard inteldrm(4) and this nVidia as dedicated graphics.
Please, note two things. First, pcidump shows it a "NVIDIA unknown" but on
Windows nVidia control panel recognizes it as a GeFor
On 2014/04/24 04:26, Miod Vallat wrote:
> > Same as the others, this time with src/usr.bin/mg/undo.c
>
> You are now losing a memset() in the `rec doesn't come from malloc' code
> path.
>From the number and types of diff being sent, I am guessing these are
tool-generated (coccinelle?); while this
> This doesn't fix the problems, only removes markers alerting us
> to audit it.
>
> Memory management in these files is still missing integer overflow
> checks, NULL return checks, and is full of crazy abominations [...]
Yes, I saw that but I thought I'd take care of one thing first
then send pa
46 matches
Mail list logo
