Chuck Silvers wrote:

>On Mon, Dec 12, 2005 at 08:18:49PM +0100, Manuel Bouyer wrote:
>  
>
>>On Mon, Dec 12, 2005 at 09:09:24AM -0800, Chuck Silvers wrote:
>>    
>>
>>>>If PTHREAD_CONCURRENCY > 1 can cause kernel panics, just removing it from
>>>>libpthread isn't enouth. The kernel has to be patched as well, otherwise a
>>>>local user could start an application linked with a bad libpthread and
>>>>cause a local DOS.
>>>>        
>>>>
>>>I was more worried about us advertising a feature that crashes the system
>>>than a malicious user.  but disabling the sa_setconcurrency() syscall
>>>as well is easy enough, I'll add that to the patch.
>>>      
>>>
>>Maybe not disable it (possible backward compat issues ?) but return error
>>if the value is not 1.
>>    
>>
>
>this setup is in pthread_init(), which returns void.
>this is called before main() as the constructor for the pthread library.
>"return an error" in this case would mean "cause the process to exit".
>  
>
I think its easy enough to just ignore the environment variable that
sets it.

Solaris pthreads have a function call to set the concurrency; if we had
that then it would make sense to return an error.  But in our case just
silently ignoring the env. var (possibly logging a message?) would be
best, I think.

>what compatibility issue are you concerned about?
>  
>
Can't imagine what it would be -- this isn't part of an official API
that I'm aware of.

    -- Garrett

>-Chuck
>  
>


-- 
Garrett D'Amore                          http://www.tadpolecomputer.com/
Sr. Staff Engineer          Extending the Power of 64-bit UNIX Computing
Tadpole Computer, Inc.                             Phone: (951) 325-2134