Re: WAL & SHM principles

From: Matthew Kirkwood <matthew(at)hairy(dot)beasts(dot)org>
To: Ken Hirsch <kenhirsch(at)myself(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: WAL & SHM principles
Date: 2001-03-13 21:10:09
Message-ID: Pine.LNX.4.10.10103132057330.27388-100000@sphinx.mythic-beasts.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, 13 Mar 2001, Ken Hirsch wrote:

> > mlock() guarantees that the locked address space is in memory. This
> > doesn't imply that updates are not written to the backing file.
>
> I've wondered about this myself. It _is_ true on Linux that mlock
> prevents writes to the backing store,

I don't believe that this is true. The manpage offers no
such promises, and the semantics are not useful.

> and this is used as a security feature for cryptography software.

mlock() is used to prevent pages being swapped out. Its
use for crypto software is essentially restricted to anon
memory (allocated via brk() or mmap() of /dev/zero).

If my understanding is accurate, before 2.4 Linux would
never swap out pages which had a backing store. It would
simply write them back or drop them (if clean). (This is
why you need around twice as much swap with 2.4.)

> The code for gnupg assumes that if you have mlock() on any operating
> system, it does mean this--which doesn't mean it's true, but perhaps
> whoever wrote it does have good reason to think so.

strace on gpg startup says:

mmap(0, 16384, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40015000
getuid() = 500
mlock(0x40015000) = -1 EPERM (Operation not permitted)

so whatever the authors think, it does not require this semantic.

Matthew.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alfred Perlstein 2001-03-13 21:21:54 Re: WAL & SHM principles
Previous Message Daniel Lopez 2001-03-13 20:44:35 Escaping strings