https://dvdhrm.wordpress.com/2014/06/10/memfd_create2/
Teoretycznie można osiągnąć
memfd_create()
zachowanie [ ] bez wprowadzania nowych wywołań systemowych, takich jak:
int fd = open("/tmp", O_RDWR | O_TMPFILE | O_EXCL, S_IRWXU);
(Uwaga: aby bardziej przenośnie zagwarantować tmpfs tutaj, możemy użyć „ /dev/shm
” zamiast „ /tmp
”).
Dlatego najważniejsze pytanie brzmi: dlaczego do diabła potrzebujemy trzeciej drogi?
[...]
- Pamięć kopii zapasowej jest uwzględniana w procesie, który jest właścicielem pliku i nie podlega limitom montowania.
^ Czy mam rację, sądząc, że nie można polegać na pierwszej części tego zdania?
Kod memfd_create () jest dosłownie zaimplementowany jako „ niepowiązany plik żyjący w [a] tmpfs, który musi być wewnętrznym jądrem ”. Śledząc kod, rozumiem, że różni się tym, że nie wdraża kontroli LSM, a także memfds są tworzone w celu obsługi „pieczęci”, jak wyjaśnia blog. Jednak jestem bardzo sceptyczny że memfds są ujmowane odmiennie do tmpfile w zasadzie.
W szczególności, kiedy zabijający OOM puka, nie sądzę, że będzie to wyjaśniać pamięć przechowywaną przez memfds. Może to wynieść do 50% pamięci RAM - wartość opcji size = dla tmpfs . Jądro nie ustawia innej wartości dla wewnętrznych tmpfs, więc użyłby domyślnego rozmiaru 50%.
Myślę więc, że ogólnie możemy oczekiwać procesów, które przechowują dużą pamięć memfd, ale żadne inne znaczące przydziały pamięci nie zostaną zabite przez OOM. Czy to jest poprawne?