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
|
Список | 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 по дате отправления: