On Sun, 2013-02-10 at 00:35 +0100, Pawel Jakub Dawidek wrote:
> On Sat, Feb 09, 2013 at 06:00:53PM +0200, Andriy Gapon wrote:
> > on 09/02/2013 17:04 Andrey Zonov said the following:
> > > On 2/9/13 5:07 PM, Fabian Keil wrote:
> > >>
> > >> This would at least prevent the segfault.
> > >>
> > >
>
Pawel Jakub Dawidek wrote:
> On Sun, Feb 10, 2013 at 09:50:58AM +0200, Andriy Gapon wrote:
> > I think that PAGE_SIZE (or at most a small multiple of it) should be
> > sufficient. I don't think that we currently have (or expect to see in
> > the near future) algorithms where keys with more than
on 10/02/2013 17:44 Pawel Jakub Dawidek said the following:
> On Sun, Feb 10, 2013 at 09:50:58AM +0200, Andriy Gapon wrote:
>> on 10/02/2013 01:35 Pawel Jakub Dawidek said the following:
>>> geli(8) almost exclusively deals with sensitive data. Even mlocking
>>> MAXPHYS would fail with current limi
On Sun, Feb 10, 2013 at 09:50:58AM +0200, Andriy Gapon wrote:
> on 10/02/2013 01:35 Pawel Jakub Dawidek said the following:
> > geli(8) almost exclusively deals with sensitive data. Even mlocking
> > MAXPHYS would fail with current limits, but this is bad idea.
> >
> > With mlockall() I am sure I
on 10/02/2013 01:35 Pawel Jakub Dawidek said the following:
> geli(8) almost exclusively deals with sensitive data. Even mlocking
> MAXPHYS would fail with current limits, but this is bad idea.
>
> With mlockall() I am sure I didn't miss anything - be it forgetting
> about mlocking some buffer or
On Sat, Feb 09, 2013 at 06:00:53PM +0200, Andriy Gapon wrote:
> on 09/02/2013 17:04 Andrey Zonov said the following:
> > On 2/9/13 5:07 PM, Fabian Keil wrote:
> >>
> >> This would at least prevent the segfault.
> >>
> >
> > I see two possibilities to get segfault:
> > - no checking for result fr
on 09/02/2013 17:04 Andrey Zonov said the following:
> On 2/9/13 5:07 PM, Fabian Keil wrote:
>>
>> This would at least prevent the segfault.
>>
>
> I see two possibilities to get segfault:
> - no checking for result from memory allocation functions
> - too big stack
>
> I have no found any br
on 09/02/2013 15:07 Fabian Keil said the following:
> It also wouldn't hurt to document why a 64K per-process limit with an
> unlimited number of processes per user is considered a good default in
> the first place.
I don't think that maxproc=unlimited is a good default regardless of
memorylocked.
On 2/9/13 5:07 PM, Fabian Keil wrote:
>
> This would at least prevent the segfault.
>
I see two possibilities to get segfault:
- no checking for result from memory allocation functions
- too big stack
I have no found any broken memory allocation checking, but I found two
big objects on the
Eitan Adler wrote:
> On 8 February 2013 07:46, Andriy Gapon wrote:
> > on 08/02/2013 13:48 Ulrich Spörlein said the following:
> >> It looks like 128k as a limit is still too low for geli(8) to work, and
> >> I've set it to 256k now, so that I can use "sudo geli". Can you maybe
> >> revise the
On 8 February 2013 07:46, Andriy Gapon wrote:
> on 08/02/2013 13:48 Ulrich Spörlein said the following:
>> The problem here is that I login via my user account, then either use
>> sudo or sudo -i for a root shell, this however does not raise the
>> memorylocked limit. So when I said this works dur
on 08/02/2013 13:48 Ulrich Spörlein said the following:
> The problem here is that I login via my user account, then either use
> sudo or sudo -i for a root shell, this however does not raise the
> memorylocked limit. So when I said this works during boot and shortly
> after, it's because I haven't
On Fri, 2013-02-08 at 09:57:09 +0100, Fabian Keil wrote:
> Ulrich Spörlein wrote:
>
> > On Thu, 2013-02-07 at 15:33:22 +0100, Fabian Keil wrote:
> > > Ulrich Spörlein wrote:
> > >
> > > > Yes, it's pretty much as weird as it sounds. All new machine, forklifted
> > > > the image from on old i386
Ulrich Spörlein wrote:
> On Thu, 2013-02-07 at 15:33:22 +0100, Fabian Keil wrote:
> > Ulrich Spörlein wrote:
> >
> > > Yes, it's pretty much as weird as it sounds. All new machine, forklifted
> > > the image from on old i386 machine running 8.x to current on amd64.
> > >
> > > Everything seemi
On Thu, 2013-02-07 at 15:33:22 +0100, Fabian Keil wrote:
> Ulrich Spörlein wrote:
>
> > Yes, it's pretty much as weird as it sounds. All new machine, forklifted
> > the image from on old i386 machine running 8.x to current on amd64.
> >
> > Everything seemingly works fine, attaching geli volumes
Ulrich Spörlein wrote:
> Yes, it's pretty much as weird as it sounds. All new machine, forklifted
> the image from on old i386 machine running 8.x to current on amd64.
>
> Everything seemingly works fine, attaching geli volumes shortly after
> boot is fine, attached devices continue to work fine
Yes, it's pretty much as weird as it sounds. All new machine, forklifted
the image from on old i386 machine running 8.x to current on amd64.
Everything seemingly works fine, attaching geli volumes shortly after
boot is fine, attached devices continue to work fine. There are no
strange crashes with
17 matches
Mail list logo
