[Bugs] [Bug 1745916] New: glusterfs client process memory leak after enable tls on community version 6.5

[bugzilla at redhat.com]

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

            Bug ID: 1745916
           Summary: glusterfs client process memory leak after enable tls
                    on community version 6.5
           Product: GlusterFS
           Version: 6
          Hardware: x86_64
                OS: Linux
            Status: NEW
         Component: rpc
          Severity: medium
          Assignee: bugs at gluster.org
          Reporter: zz.sh.cynthia at gmail.com
                CC: bugs at gluster.org
  Target Milestone: ---
    Classification: Community



Description of problem:
after enable ssl, glusterfs process memory leak detected

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

glusterfs 6.5
How reproducible:


Steps to Reproduce:
1.enable tls
2.do io on volume with tls enabled
3.found glusterfs client process memory increase steadily

Actual results:


Expected results:


Additional info:
I find that the following patch create new SSL_CTX for each transport, but when
I check the code, I am not clear that 
In function socket_server_event_handler, “ret = socket_init(new_trans);” create
new SSL_CTX for new_trans, but why after that, new_priv->ssl_ctx =
priv->ssl_ctx; this will overwrite the newly allocated ssl_ctx in new_priv, and
may cause potential memory leak, i think.
      Could you please brief on my confusion, many thanks!


SHA-1: 06fa261207f0f0625c52fa977b96e5875e9a91e0

* socket/ssl: fix crl handling

Problem:
Just setting the path to the CRL directory in socket_init() wasn't working.

Solution:
Need to use special API to retrieve and set X509_VERIFY_PARAM and set
the CRL checking flags explicitly.
Also, setting the CRL checking flags is a big pain, since the connection
is declared as failed if any CRL isn't found in the designated file or
directory. A comment has been added to the code appropriately.

Change-Id: I8a8ed2ddaf4b5eb974387d2f7b1a85c1ca39fe79
fixes: bz#1687326
Signed-off-by: Milind Changire <mchangir at redhat.com>

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