[Gluster-devel] syncops and thread specific memory regions

2014-07-02 Thread Raghavendra Gowdappa
Hi all,

The bug fixed by [1] is a one instance of the class of problems where:
1. we access a variable which is stored in thread-specific area and hence can 
be stored in different memory regions across different threads.
2. A single (code) control flow is executed in more than one thread.
3. Optimization prevents recalculating address of variable mentioned in 1 every 
time its accessed, instead using an address calculated earlier.

The bug fixed by [1] involved errno as the variable. However there are other 
pointers which are stored in TLS like,
1. The xlator object in whose context the current code is executing in (aka 
THIS, set/read by using __glusterfs_this_location() ).
2. A buffer used to parse binary uuids into strings (used by uuid_utoa () ).

I think we can hit the corruption uncovered by [1] in the above two scenarios 
too. Comments?

[1] http://review.gluster.org/6475

regards,
Raghavendra.
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://supercolony.gluster.org/mailman/listinfo/gluster-devel


Re: [Gluster-devel] syncops and thread specific memory regions

2014-07-02 Thread Xavier Hernandez
On Wednesday 02 July 2014 07:57:52 Raghavendra Gowdappa wrote:
 Hi all,
 
 The bug fixed by [1] is a one instance of the class of problems where:
 1. we access a variable which is stored in thread-specific area and hence
 can be stored in different memory regions across different threads. 2. A
 single (code) control flow is executed in more than one thread. 3.
 Optimization prevents recalculating address of variable mentioned in 1
 every time its accessed, instead using an address calculated earlier.
 
 The bug fixed by [1] involved errno as the variable. However there are
 other pointers which are stored in TLS like, 1. The xlator object in whose
 context the current code is executing in (aka THIS, set/read by using
 __glusterfs_this_location() ). 2. A buffer used to parse binary uuids into
 strings (used by uuid_utoa () ).
 
 I think we can hit the corruption uncovered by [1] in the above two
 scenarios too. Comments?

I did discuss these same two problems with Pranith some time ago [1].

Basically the errno issue was caused because __errno_location() is declared 
with 'const':

extern int *__errno_location (void) __THROW __attribute__ ((__const__));
#   define errno (*__errno_location ())

__gluster_this_location() is not declared as 'const', so the compiler doesn't 
optimize it so much as __errno_location() and this bug is not present.

The uuid_utoa() issue is not a problem as long as it is only used for logging 
purposes or very local access. The returned pointer cannot be stored anywhere 
for future access. At the time of that discussion, all these conditions were 
satisfied.

Refer to the emails [1] for more detailed information.

Xavi

[1] http://gluster.org/pipermail/gluster-devel/2013-December/026279.html

___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://supercolony.gluster.org/mailman/listinfo/gluster-devel