[Gluster-devel] Be careful before closing fd in a default case

Mohit Agrawal moagrawa at redhat.com
Fri Apr 12 02:56:06 UTC 2019


  I want to highlight recent bug(
https://bugzilla.redhat.com/show_bug.cgi?id=1699025) due to raised after
fixed one Coverity
   bug https://review.gluster.org/#/c/glusterfs/+/20720/
  As we know all gluster processes initially keeping open standard fd's (0,1,2)
at the time of daemonizing so that kernel
  don't assign these fd's to any fd open by gluster process. In this
Coverity bug, we closed fd in changelog fini if fd value is not equal to -1.
  As we know GF_CALLOC initializes to all structure members to 0 so initial
fd value was 0 and changelog_init did not open htime_fd
  because changelog was not active so at the time of calling changelog fini it
closes fd(0). After closing fd(0) by changelog fini if any
  client(shd) is trying to establish a connection with the server(in the
brick_mux environment), the server gets fd(0) as a socket fd.
  I have observed socket event framework (socket_event_handler) was not
working perfectly for fd(0) while
  volumes are stopped in a loop in brick_mux environment and bricks are not
detached successfully.

  So always we should careful at the time of closing fd, before closing fd in
default case we should check fd should not be zero.
  I have fixed the same from (
https://review.gluster.org/#/c/glusterfs/+/22549/) and upload a .t also.

Mohit Agrawal
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gluster.org/pipermail/gluster-devel/attachments/20190412/bcb597b5/attachment.html>

More information about the Gluster-devel mailing list