I did a similar change recently (http://marc.info/?l=openbsd-cvs&m=135055003602935&w=2). Therefore I think that Ilya's patch is valid and should be applied.
If anyone is willing to ok, I can commit it. Gerhard On 11/08/2012 01:34 PM, Ilya Bakulin wrote: > Hi list, > after upgrade on OpenBSD 5.2 we observe the following message from ntpd: > > Oct 22 17:20:13 gg74 ntpd[2918]: ntpd 4.2.6p2@1.2194-o Tue Oct 16 20:26:47 > UTC > 2012 (1) > Oct 22 17:20:13 gg74 ntpd[10103]: mlockall(): Cannot allocate memory > Oct 22 17:20:13 gg74 ntpd[10103]: signal_no_reset: signal 13 had flags 12 > Oct 22 17:20:13 gg74 ntpd[10103]: proto: precision = 6.390 usec > ... > This doesn't prevent ntpd from starting, however. > We tried to debug this problem. This occurs when an application tries to set > resource limits (more precisely, RLIMIT_MEMLOCK) to some relatively low value > and then does mlockall(). > > The problem seems to be in uvm_map_pageable_all() function > (sys/uvm/uvm_map.c). This function is a "special case of uvm_map_pageable", > which tries to mlockall() all mapped memory regions. > Prior to calling uvm_map_pageable_wire(), which actually does locking, it > tries to count how many memory bytes will be locked, and compares this number > with uvmexp.wiredmax, which is set by RLIMIT_MEMLOCK. > The problem is that counting algorithm doesn't take into account that some > pages have VM_PROT_NONE flag set and hence won't be locked anyway. > Later in uvm_map_pageable_wire() these pages are skipped when doing actual > job. > > Attached patch fixes the problem on OpenBSD 5.2. > > I'm also attaching a simple test application, that can be used to reproduce > the bug. Just compile and run as root (otherwise mlockall() doesn't work > anyway). On OpenBSD 5.2 the RLIMIT_MEMLOCK limit will be significantly higher > than on OpenBSD 5.1. After applying my patch they will be almost the same. > > Thank you for your attention. > > // Ilya
