From: Kurt Garloff <garloff@suse.de>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: linux-arch@vger.kernel.org, linux-mm@kvack.org, NPiggin@suse.de
Subject: Re: [garloff@suse.de: [PATCH 1/1] default mlock limit 32k->64k]
Date: Fri, 17 Oct 2008 18:46:30 +0200 [thread overview]
Message-ID: <20081017164630.GL5286@tpkurt2.garloff.de> (raw)
In-Reply-To: <20081016154816.c53a6f8e.akpm@linux-foundation.org>
[-- Attachment #1: Type: text/plain, Size: 2242 bytes --]
Andrew,
On Thu, Oct 16, 2008 at 03:48:16PM -0700, Andrew Morton wrote:
> On Thu, 16 Oct 2008 09:43:19 +0200 Kurt Garloff <garloff@suse.de> wrote:
> > Index: linux-2.6.27/include/linux/resource.h
> > ===================================================================
> > --- linux-2.6.27.orig/include/linux/resource.h
> > +++ linux-2.6.27/include/linux/resource.h
> > @@ -59,10 +59,10 @@ struct rlimit {
> > #define _STK_LIM (8*1024*1024)
> >
> > /*
> > - * GPG wants 32kB of mlocked memory, to make sure pass phrases
> > + * GPG2 wants 64kB of mlocked memory, to make sure pass phrases
> > * and other sensitive information are never written to disk.
> > */
> > -#define MLOCK_LIMIT (8 * PAGE_SIZE)
> > +#define MLOCK_LIMIT ((PAGE_SIZE > 64*1024) ? PAGE_SIZE : 64*1024)
>
> I dunno. Is there really much point in chasing userspace changes like
> this?
If there were many apps that would need it and that would have
contradicting or fast changing requirements, I would certainly
not wanna chase that.
We're lucky here that gpg/gpg2 is the only unprivileged user
of locked memory and that the requirement does not really change
often. We've had gpg1 with 32k need since 1999 and now gpg2 with
a 64k need.
Accommodating that seems like a pragmatic thing to do. Will ensure
good defaults for a broad set of users.
> Worst case, we end up releasing distributions which work properly on
> newer kernels and which fail to work properly on older kernels.
I know a number of users that run new kernels below old distributions
but few that do the opposite.
The failure mode in this specific case is not obscure at all, so I'm
not worried:
can't lock memory: Cannot allocate memory
Warning: using insecure memory!
> I suspect that it would be better to set the default to zero and
> *force* userspace to correctly tune whatever-kernel-they're-running-on
> to match their requirements.
That's feasible, though I think distributions are not today
preconfigured to do that. Turning your argument around:
It would it a bit harder to run new kernels on old distros.
(Which I believe is worse -- we need testers!)
Best,
--
Kurt Garloff, VP Business Development -- OPS, Novell Inc.
[-- Attachment #2: Type: application/pgp-signature, Size: 194 bytes --]
prev parent reply other threads:[~2008-10-17 16:46 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-10-16 7:43 Kurt Garloff
2008-10-16 22:48 ` Andrew Morton
2008-10-17 4:11 ` Nick Piggin
2008-10-17 16:46 ` Kurt Garloff [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20081017164630.GL5286@tpkurt2.garloff.de \
--to=garloff@suse.de \
--cc=NPiggin@suse.de \
--cc=akpm@linux-foundation.org \
--cc=linux-arch@vger.kernel.org \
--cc=linux-mm@kvack.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox