Re: WAL & SHM principles

Поиск
Список
Период
Сортировка
От Matthew Kirkwood
Тема Re: WAL & SHM principles
Дата
Msg-id Pine.LNX.4.10.10103132057330.27388-100000@sphinx.mythic-beasts.com
обсуждение исходный текст
Ответ на Re: WAL & SHM principles  ("Ken Hirsch" <kenhirsch@myself.com>)
Ответы Re: WAL & SHM principles  (Alfred Perlstein <bright@wintelcom.net>)
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Shutdown term
Следующее
От: Alfred Perlstein
Дата:
Сообщение: Re: WAL & SHM principles