----- Original Message ----- > From: "Xavier Hernandez" <xhernandez@xxxxxxxxxx> > To: "Raghavendra Gowdappa" <rgowdapp@xxxxxxxxxx> > Cc: gluster-devel@xxxxxxxxxxx > Sent: Wednesday, July 2, 2014 6:50:51 PM > Subject: Re: syncops and thread specific memory regions > > 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. Ah! ok. Sorry had missed the discussion :) > > 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@xxxxxxxxxxx http://supercolony.gluster.org/mailman/listinfo/gluster-devel
