if it's like that in grsec/pax, it's also in linux-vserver + grsec patches, since i use those as a base for patching the combo's... grtzzz... Rik Bobbaers -- http://harry.enzoverder.be linux/unix/system/network/security/hardware/DR admin > 2009/9/30 Natanael Copa <natanael.copa@gmail.com>: >> On Tue, 2009-09-29 at 19:36 +0200, Romain Riviere wrote: >>> Hello there, >>> >>> More feedback on this nasty issue : it's *SOLVED* ! The bad news is, I >>> can blame it on the VServer+GrSec patch. The good news is, it's just >>> the grsec part. >>> >>> After perusing the patch source a little, I had a hunch that PaX was >>> interfering here, especially SEGMEXEC. And what do you know, one >>> kernel with CONFIG_PAX_SEGMEXEC unset later, PHP is happily using >>> exactly the amount of memory it should. >>> >>> Further debugging is not exactly in my league :-) >> >> Does this affect the grsecurity alone or does it only affect the vserver >> +grsecurity combo? >> >> Did you report it back to the grsecurity maintainers? > > I asked spender and he he added a comment on > http://bugs.php.net/bug.php?id=49501 > seems its more of a SEGMEXEC feature than a bug : > "Due to VMA mirroring, the SEGMEXEC option causes accounted vm usage > to double. So you weren't experiencing a memory leak -- you were just > being accounted for twice as much memory as you thought you were using. > The solution would be to double the resource limit or, if your system is > NX-capable and PAE is enabled, use PAGEEXEC. > -Brad" >