On Thu, 1 May 2014, Ted Unangst wrote:
> What's better than a freelist? Four freelists!
Apart from moar = better, what's the motivation? Do you have a particular
attack in mind? The only thing I can think of where this change might help
is an attack that speculatively spams small offsets from the
What's better than a freelist? Four freelists!
For each chunk size, pick one of four freelists at random. This
scatters allocations about some more and eliminates the guarantee that
consecutive allocations will always be on the same page.
Technically, there is no bound to how much memory will be
Clean up a few things.
1. Drop support for no minor. This variant doesn't exist anymore.
2. Pull up the actual minor processing code into the switch that
parses it.
3. atoi is actually simpler than strtonum in this case, but check the
input beforehand so we don't get unexpected results.
4. Slig
On 2014/04/29 23:12, Stuart Henderson wrote:
> On 2014/04/29 22:25, Paul de Weerd wrote:
> > Disabling IPv6 should not be necessary: it shouldn't be enabled by
> > default, even link-local addresses.
>
> If doing this, then we need a way to enable link-local, like the opposite
> of "ifconfig $if -
Il giorno 30/apr/2014 23.11, "SASANO Takayoshi" ha
scritto:
>
> Hello,
>
> I found some debug messages need to be fixed in sys/dev/usb/umodem.c.
> Can I commit the diff?
Ok dcoppa@
>
> SASANO Takayoshi
>
> Index: umodem.c
> ==
On Wed, Apr 30, 2014 at 05:12:44PM -0400, Okan Demirmen wrote:
> Thank you; I'm aware of these (along with others). If anyone is
> waiting for me, please be patient while I find a working
> laptop/desktop setup.
Ah, ok, sorry to pile on. Thanks for acknowledging my diffs!
Thank you; I'm aware of these (along with others). If anyone is
waiting for me, please be patient while I find a working
laptop/desktop setup.
On Wed, Apr 30, 2014 at 5:07 PM, Kent R. Spillner wrote:
> Ping.
>
> On Wed, Apr 23, 2014 at 12:44:38PM -0500, Kent R. Spillner wrote:
>> I think I sent
Hello,
I found some debug messages need to be fixed in sys/dev/usb/umodem.c.
Can I commit the diff?
SASANO Takayoshi
Index: umodem.c
===
RCS file: /cvs/src/sys/dev/usb/umodem.c,v
retrieving revision 1.55
diff -u -p -r1.55 umod
Ping.
On Wed, Apr 23, 2014 at 10:48:38PM -0500, Kent R. Spillner wrote:
> The diff below removes the check for siz == 0 in xmalloc() because it is
> unnecessary.
>
> I was curious about the check for siz == 0 in xmalloc() when I first saw
> it, so I dug in further and came to the conclusion it's
Ping.
On Wed, Apr 23, 2014 at 12:44:38PM -0500, Kent R. Spillner wrote:
> I think I sent this out a long time ago but never followed up on it. :(
>
> According to cwmrc(5) you can configure an autogroup like so:
>
> autogroup group windowname,windowclass
>
> However, parse.y doesn't actual
Ping.
On Wed, Apr 23, 2014 at 10:15:10PM -0500, Kent R. Spillner wrote:
> The diff below removes an unncessary memset() on line 253 of conf.c.
>
> cwm used to support reloading the config file, but okan@ removed that
> functionality about a year ago in favor of simply restarting the whole
> thing
>> I have been following the recent LibreSSL developments quite active and
>> would like to contribute.
>>
>> I have some questions:
>>
>> - The accelerated assembly code for the crypto, is that gonna stay?
>
>Of course. Why do you think anyone would try to break code which works?
Because it is a
> I'm not comfortable with introducing more APIs. So
> perhaps we should just punt on the optimization and remove/insert all
> list items. Removing the trap comments that pedro set up...
Since the removal macros poison pointers which should no longer be
dereferenced after the operation, I'm str
Speaking for myself here, but as far as LibreSSL is concerned, I'd say
my opinion has a certain weight.
> - The accelerated assembly code for the crypto, is that gonna stay?
Yes. Including existing code for platforms OpenBSD itself does not run
on (e.g. s390).
> - Why not use uint32_t and uint64
> I have been following the recent LibreSSL developments quite active and
> would like to contribute.
>
> I have some questions:
>
> - The accelerated assembly code for the crypto, is that gonna stay?
Of course. Why do you think anyone would try to break code which works?
> - Why not use uint3
If I had to guess at this point - SRP may have a future.
I'm betting kssl does not, and this should probably go away.
On Tue, Apr 29, 2014 at 4:06 PM, Stefan Fritsch wrote:
> Am Montag, 28. April 2014, 21:40:30 schrieb Ted Unangst:
>> Also note that I'm not really interested in rumors or whispe
> On Wed, Apr 30, 2014 at 03:38:39PM +0200, Mark Kettenis wrote:
> > > Date: Wed, 30 Apr 2014 13:39:20 +0100
> > > From: Stuart Henderson
> > >
> > > Seen when running e2fsprogs regression tests with /tmp on tmpfs
> >
> > I'm not surprised; tmpfs contains some serious bugs. I recommend not
> >
On 30 April 2014 16:55, Mark Kettenis wrote:
>> From: Mike Belopuhov
>> Date: Wed, 30 Apr 2014 16:00:45 +0200
>>
>> On 30 April 2014 15:55, Mark Kettenis wrote:
>> >> Date: Wed, 30 Apr 2014 15:38:39 +0200 (CEST)
>> >> From: Mark Kettenis
>> >>
>> >> > Date: Wed, 30 Apr 2014 13:39:20 +0100
>> >>
This is probably the simplest way to solve the problem for now.
if we want to mess with sys/queue we can do that separately.
On Wed, Apr 30, 2014 at 8:55 AM, Mark Kettenis wrote:
>> From: Mike Belopuhov
>> Date: Wed, 30 Apr 2014 16:00:45 +0200
>>
>> On 30 April 2014 15:55, Mark Kettenis wrot
On 30 April 2014 10:55, Mark Kettenis wrote:
>> From: Mike Belopuhov
>> Date: Wed, 30 Apr 2014 16:00:45 +0200
>>
>> On 30 April 2014 15:55, Mark Kettenis wrote:
>> >> Date: Wed, 30 Apr 2014 15:38:39 +0200 (CEST)
>> >> From: Mark Kettenis
>> >>
>> >> > Date: Wed, 30 Apr 2014 13:39:20 +0100
>> >>
> From: Mike Belopuhov
> Date: Wed, 30 Apr 2014 16:00:45 +0200
>
> On 30 April 2014 15:55, Mark Kettenis wrote:
> >> Date: Wed, 30 Apr 2014 15:38:39 +0200 (CEST)
> >> From: Mark Kettenis
> >>
> >> > Date: Wed, 30 Apr 2014 13:39:20 +0100
> >> > From: Stuart Henderson
> >> >
> >> > Seen when run
On 30 April 2014 15:55, Mark Kettenis wrote:
>> Date: Wed, 30 Apr 2014 15:38:39 +0200 (CEST)
>> From: Mark Kettenis
>>
>> > Date: Wed, 30 Apr 2014 13:39:20 +0100
>> > From: Stuart Henderson
>> >
>> > Seen when running e2fsprogs regression tests with /tmp on tmpfs
>>
>> I'm not surprised; tmpfs c
> Date: Wed, 30 Apr 2014 15:38:39 +0200 (CEST)
> From: Mark Kettenis
>
> > Date: Wed, 30 Apr 2014 13:39:20 +0100
> > From: Stuart Henderson
> >
> > Seen when running e2fsprogs regression tests with /tmp on tmpfs
>
> I'm not surprised; tmpfs contains some serious bugs. I recommend not
> using
On Wed, Apr 30, 2014 at 03:38:39PM +0200, Mark Kettenis wrote:
> > Date: Wed, 30 Apr 2014 13:39:20 +0100
> > From: Stuart Henderson
> >
> > Seen when running e2fsprogs regression tests with /tmp on tmpfs
>
> I'm not surprised; tmpfs contains some serious bugs. I recommend not
> using it until t
> Date: Wed, 30 Apr 2014 13:39:20 +0100
> From: Stuart Henderson
>
> Seen when running e2fsprogs regression tests with /tmp on tmpfs
I'm not surprised; tmpfs contains some serious bugs. I recommend not
using it until those are fixed.
> Data modified on freelist: word -35183628471970 of object
Seen when running e2fsprogs regression tests with /tmp on tmpfs
...
Data modified on freelist: word -35183628471970 of object 0x80d36c00
size 0x400 previous type free (invalid addr 0xf40858de1f81cbe9)
panic: Data modified on freelist: word 4 of object 0x80d36c00 size
0x400 previ
Le 2014-04-29 22:04, Theo de Raadt a écrit :
> measurements all over the world show that IPv4 is better
> in every respect.
Not disagreeing, but I would like to have access to more data backing
this up. I'm not satisfied with what I found (see other post).
> Change that, then we can talk.
Workin
Hello everyone,
I have been following the recent LibreSSL developments quite active and
would like to contribute.
I have some questions:
- The accelerated assembly code for the crypto, is that gonna stay?
- Why not use uint32_t and uint64_t all over (incl the APIs) instead of
custom XX_ULONG stu
On Tue, Apr 29, 2014 at 07:57:32PM -0600, Theo de Raadt wrote:
> Don't bother with diffs to b_sock.c. Instead, if you have code
> which uses it, talk to krw.
>
> There is a monster diff coming which rewrites it all.
>
> And by the way, all that code disapears and is replaced by 2 lines.
That's
29 matches
Mail list logo
