Hello Dmitry,
A quick question after considering your comments and doing a bit more
homework on extension lifetime:The patch introduces syscall in the hot function (this may be
optimized).Agreed. That isn't ideal. But the geteuid() call shouldn't be done
during opcache initialization when the SHM object is initialized,
because EUID might change afterwards. I didn't want to get EUID too
early so I erred on the side of caution, getting it at the last possible
moment. This is slower but safer because it prevents trivial cross-user
cache access from PHP userland. I'm open to suggestion if there's a more
"local" initialization function outside of key generation, which is
guaranteed to run after EUID changes in both FPM user pool, and
mod_ruid2/mod_php.Looks like OPCache currently does not implement a request_startup_func for
per-request initialization. I'm assuming this was avoided for
performance reasons and due to no perceived need until now for
per-request initialization. This seems like it would be the proper point
in extension lifetime to call geteuid() and save results in the
zend_accel_globals struct to use during key construction. Correct? Any
objection to my implementing this?
See zend_accel_activate() in ZendAccelerator.c
I'm also thinking the
stat()for device+inode should be done in opcache
code at file compilation time; correct?
It's not a problem to make extra stat() at script compile (I think we already do it to record mtime), however we will have to do it also on each access.
Would this be a step in the right direction? Apologies if these are
basic questions; I'm new to PHP extensions but strongly motivated to fix
OPCache keys quickly. I may have time for a second pass at this over the
weekend.
I see your point, but I don't like a quick fix, I like a "good" fix.
And I hope, our discussion could lead us to some better solution :)
Thanks. Dmitry.
-php-dev at coydogsoftware dot net