Re: WAL & SHM principles - Mailing list pgsql-hackers

From Matthew Kirkwood
Subject Re: WAL & SHM principles
Date
Msg-id Pine.LNX.4.10.10103132057330.27388-100000@sphinx.mythic-beasts.com
Whole thread Raw
In response to Re: WAL & SHM principles  ("Ken Hirsch" <kenhirsch@myself.com>)
Responses Re: WAL & SHM principles  (Alfred Perlstein <bright@wintelcom.net>)
List 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.



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Shutdown term
Next
From: Alfred Perlstein
Date:
Subject: Re: WAL & SHM principles