develooper Front page | perl.perl5.porters | Postings from October 2003

Re: 5.8.2-RC1 and mp2

Thread Previous | Thread Next
From:
Stas Bekman
Date:
October 28, 2003 16:10
Subject:
Re: 5.8.2-RC1 and mp2
Message ID:
3F9F057A.8090304@stason.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:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com


Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About