Front page | perl.perl5.porters |
Postings from October 2003
Re: 5.8.2-RC1 and mp2
From: Stas Bekman
October 28, 2003 16:10
Re: 5.8.2-RC1 and mp2
Message ID: 3F9F057A.firstname.lastname@example.org
Nicholas Clark wrote:
> On Tue, Oct 28, 2003 at 03:44:56PM -0800, Stas Bekman wrote:
>>To remind what the story is: as mp2 uses PERL_HASH to cache the key hashes,
>>the hash seed has to stay indentical across different perl interpreters.
>>The workaround for 5.8.1 was to take over the setting PL_hash_seed and
>>telling Perl not to reset it by setting PL_hash_seed_set to TRUE>
>>I remember Nick saying, that 8.2 sets that hash seed to 0 and keeps it that
>>way, taking special measures only if under attack. I haven't debugged the
>>issue yet, but it seems that in 5.8.2 PERL_HASH is not a deterministic
>>function and will return different values at different times. This is not
>>how it was in 5.8.0. Before I fire up gdb, can you please summarize how
>>different 5.8.2 is from 5.8.0 in the hash seed aspect? Thanks.
> Yes, sorry, I think there is still at least one of your p5p e-mails that
> I have yet to reply to.
> If "under attack" (from any sort of user data) 5.8.2 switches internally
> to randomised hashing. It's using PL_new_hash_seed and
> PL_new_hash_seed_set internally in a similar fashion to 5.8.1's use of
> PL_hash_seed and PL_hash_seed_set (in external code)
So 5.8.2 is using PL_new_hash_seed only if under attack, right? Otherwise
using PL_hash_seed, which is supposed to be 0, if 5.8.2 == 5.8.0.
That's exactly the problem. If I revert the changes I did to workaround the
change in 5.8.1, and build with 5.8.2 it breaks right away. I doubt that 100
normal GVs will trigger the "under attack" condition.
> I hope that the fix is a simple as replicating whatever mod_perl did
> with PL_hash_seed and PL_hash_seed_set onto
> PL_new_hash_seed and PL_new_hash_seed_set.
I've lost you. Earlier you said that under attack passed PERL_HASH values are
going to be ignored for all affected GVs, and hash values recalculated for
*each* repeated fetch_gv call. If I understood you correctly no workaround
will be needed. I guess we aren't on the same line. Which is why a test will
help to verify the assumptions. Though before that we have a problem long
before the attack, that I'd like to figure out first.
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:email@example.com http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com