|
Hi, Thanks for your quick responding! My test env is without patch 22334, so priv->ssl_ctx is shared one. In socket_reset there is no need to free it. but if with patch 22334, it is absolutely needed to free priv->ssl_ctx
as well. Following is the log captured from glusterfsd side while connection establishment, when accept returns, a new new_trans is allocated, and the socket_init input param is this
new_trans, because this new_trans has no option now, so in socket_init ssl_setup_connection_params is not called, so there should be no malloc done here, as showed from following log, ssl_setup_connection_params is called in socket_event_handler, and here
the ssl_ctx had been assigned to the shared one. This issue is very easy to reproduce in my env, just “while true; do gluster v heal <vol-name> info;done” and check the memory of the corresponding glusterfsd , it is very
obvious increase. One more thing to confirm is that there is no need to free the ssl_sbio right? Ssl_free will handle it and just call ssl_free is enough? [2019-04-21 05:02:17.820346] T [socket.c:2776:socket_server_event_handler] 0-tcp.ccs-server: XXX server:192.168.1.13:53952, client:192.168.1.13:63683 [2019-04-21 05:02:17.820370] T [socket.c:2820:socket_server_event_handler] 0-tcp.ccs-server: ### use non-blocking IO [2019-04-21 05:02:17.820410] T [socket.c:2603:socket_event_handler] 0-tcp.ccs-server: server (sock:126) in:1, out:0, err:0 [2019-04-21 05:02:17.820431] T [socket.c:2610:socket_event_handler] 0-tcp.ccs-server: server (sock:126) socket is not connected, completing connection [2019-04-21 05:02:17.820442] T [socket.c:3829:ssl_setup_connection_params] 0-tcp.ccs-server:
found old SSL context! // context is shared between listening socket and accepted socket [2019-04-21 05:02:17.820451] T [socket.c:310:ssl_setup_connection_prefix] 0-tcp.ccs-server: + ssl_setup_connection_params() done! [2019-04-21 05:02:17.822559] T [socket.c:2617:socket_event_handler] 0-tcp.ccs-server: (sock:126) socket_complete_connection() returned 1 [2019-04-21 05:02:17.822585] T [socket.c:2621:socket_event_handler] 0-tcp.ccs-server: (sock:126) returning to wait on socket [2019-04-21 05:02:17.828455] T [socket.c:2603:socket_event_handler] 0-tcp.ccs-server: server (sock:126) in:1, out:0, err:0 [2019-04-21 05:02:17.828483] T [socket.c:2610:socket_event_handler] 0-tcp.ccs-server: server (sock:126) socket is not connected, completing connection [2019-04-21 05:02:17.829130] D [socket.c:366:ssl_setup_connection_postfix] 0-tcp.ccs-server: peer CN = example ee certificate [2019-04-21 05:02:17.829157] D [socket.c:369:ssl_setup_connection_postfix] 0-tcp.ccs-server: SSL verification succeeded (client: 192.168.1.13:63683) (server: 192.168.1.13:53952) [2019-04-21 05:02:17.829171] T [socket.c:423:ssl_complete_connection] 0-tcp.ccs-server: ssl_accepted! [2019-04-21 05:02:17.829183] T [socket.c:2617:socket_event_handler] 0-tcp.ccs-server: (sock:126) socket_complete_connection() returned 1 [2019-04-21 05:02:17.829192] T [socket.c:2621:socket_event_handler] 0-tcp.ccs-server: (sock:126) returning to wait on socket [2019-04-21 05:02:17.829261] T [socket.c:2603:socket_event_handler] 0-tcp.ccs-server: server (sock:126) in:1, out:0, err:0 [2019-04-21 05:02:17.829282] T [socket.c:2628:socket_event_handler] 0-tcp.ccs-server: Server socket (126) is already connected [2019-04-21 05:02:17.829294] T [socket.c:493:__socket_ssl_readv] 0-tcp.ccs-server: ***** reading over SSL [2019-04-21 05:02:17.829311] T [socket.c:493:__socket_ssl_readv] 0-tcp.ccs-server: ***** reading over SSL [2019-04-21 05:02:17.829337] T [socket.c:493:__socket_ssl_readv] 0-tcp.ccs-server: ***** reading over SSL cynthia From: Milind Changire <mchangir@xxxxxxxxxx>
After patch
22334, the priv->ssl_ctx is now maintained per socket connection and is no longer shared. So you might want to SSL_free(priv->ssl_ctx) as well and set
priv->ssl_ctx to
NULL. There might be some strings that are duplicated (gf_strdup()) via the
socket_init() code path. Please take a look at those as well. Sorry about that. I missed it. On Mon, Apr 22, 2019 at 7:25 AM Zhou, Cynthia (NSB - CN/Hangzhou) <cynthia.zhou@xxxxxxxxxxxxxxx> wrote:
Milind |
_______________________________________________ Gluster-devel mailing list Gluster-devel@xxxxxxxxxxx https://lists.gluster.org/mailman/listinfo/gluster-devel
