[Bugs] [Bug 1208482] New: pthread cond and mutex variables of fs struct has to be destroyed conditionally.

bugzilla at redhat.com bugzilla at redhat.com
Thu Apr 2 11:31:44 UTC 2015


https://bugzilla.redhat.com/show_bug.cgi?id=1208482

            Bug ID: 1208482
           Summary: pthread cond and mutex variables of fs struct has to
                    be destroyed conditionally.
           Product: GlusterFS
           Version: mainline
         Component: libgfapi
          Assignee: bugs at gluster.org
          Reporter: hchiramm at redhat.com
        QA Contact: sdharane at redhat.com
                CC: bugs at gluster.org, gluster-bugs at redhat.com



Description of problem:

At present stage the initialization and destroy of conditional and mutex
variables of fs struct happen in different scenarios and there is no uniformal
way of destroying these variables incase there is a failure when initializing
the same. The fs mutex and conditional variables( cond and child_down_count)
are getting destroyed from glfs_free_from_ctx(). However this destroy is not
done by a conditional check inside destroy function. This has to be corrected.

Version-Release number of selected component (if applicable):

GlusterFS 3.6.2

How reproducible:

N/A

Steps to Reproduce:

N/A

Actual results:

The destroy of variables done in an unconditional way in glfs_fini().

Expected results:

It has to follow a single path to destroy in clean up function glfs_fini().

Additional info:

By introducing bit flags in glfs fs object we can make use of the same ( if
there is a failure in initialization ) in glfs_fini() which is evolving as a
one and only function to free fs and ctx resources. The init functions can set
the flags according to the initialization flow of the mutex and conditional
variables of struct fs members. Without this patch we are compelled to use the
goto lables and other hacks in init functions to make sure
the resources are freed if there is an error path.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.


More information about the Bugs mailing list