Re: (ITS#3932) regex/librewrite concurrency issue

[ando@sys-net.it]

>> There may be concurrent accesses to regex_t datum by librewrite; if
>> regexec is
>> not thread safe (which I suppose is not) this may result in concurrency
>> issues.
>> I randomly experienced this with test039 on a 4 CPU machine; never
>> experienced
>> it on single CPU machine.
>
> I'm not sure the one committed is the right fix: if the non-reentrancy
> issue is in regexec(3), then also ACLs should suffer from it.  In this
> case either we assume regex is not reentrant, or require it is, or provide
> compile switches or function wrappers to handle the case it's not.  I note
> there are a few past ITSes that point in this direction and that have
> never been fixed (e.g. ITS#3634).
>
> On the machine I'm able to experience this issue the OS is CentOS release
> 4.1 (Final) and regex is part of glibc 2.3.4

OK, it could well be a glibc issue; see
<http://sources.redhat.com/cgi-bin/cvsweb.cgi/libc/posix/regexec.c.diff?r1=1.78&r2=1.79&cvsroot=glibc&f=h>
which appears to be a reentrancy issue fix in glibc 2.3.5.  Assuming we
cannot pretend people compile glibc, I think we should definitely provide
a conditionally compiled set of wrappers.  If you give me a go I have it
almost ready (for HEAD) which is very little intrusive: since regex always
goes

regcomp/regexec/regfree, I can wrap a mutex 'round regex_r and have
pthread_mutex_init() called along with regcomp(), lock()/unlock() around
regexec(), and pthread_mutex_destroy() with regfree().

p.

-- 
Pierangelo Masarati
mailto:pierangelo.masarati@sys-net.it


    SysNet - via Dossi,8 27100 Pavia Tel: +390382573859 Fax: +390382476497