Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 1513928 - call stack group list leaks
Summary: call stack group list leaks
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: GlusterFS
Classification: Community
Component: core
Version: mainline
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Csaba Henk
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks: 1600349
TreeView+ depends on / blocked
 
Reported: 2017-11-16 10:00 UTC by Csaba Henk
Modified: 2018-07-12 04:28 UTC (History)
1 user (show)

Fixed In Version: glusterfs-4.0.0
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
: 1600349 (view as bug list)
Environment:
Last Closed: 2018-03-15 11:20:54 UTC
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:


Attachments (Terms of Use)

Description Csaba Henk 2017-11-16 10:00:25 UTC
Description of problem:

The call_stack_set_groups() function that was made available in https://review.gluster.org/17706 (the fix of Bug 1464327) is a defectuous interface: it sets the group list buffer of the call stack in a way that ignores its memory management conventions and thus the call stack's group list will not be freed upon the retirement of the call stack.

Comment 1 Worker Ant 2017-11-16 11:09:01 UTC
REVIEW: https://review.gluster.org/18789 (libglusterfs: fix the call_stack_set_group() function) posted (#1) for review on master by Csaba Henk

Comment 2 Worker Ant 2017-11-24 16:55:19 UTC
COMMIT: https://review.gluster.org/18789 committed in master by \"Csaba Henk\" <csaba@redhat.com> with a commit message- libglusterfs: fix the call_stack_set_group() function

- call_stack_set_group() will take the ownership of passed
  buffer from caller;
- to indicate the change, its signature is changed from
  including the buffer directly to take a pointer to it;
- either the content of the buffer is copied to the
  groups_small embedded buffer of the call stack, or
  the buffer is set as groups_large member of the call
  stack;
- the groups member of the call stack is set to,
  respectively, groups_small or groups_large, according
  to the memory management conventions of the call stack;
- the buffer address is overwritten with junk to effectively
  prevent the caller from using it further on.

Also move call_stack_set_group to stack.c from stack.h
to prevent "defined but not used [-Wunused-function]"
warnings (not using it anymore in call_stack_alloc_group()
implementation, which saved us from this so far).

protocol/server: refactor gid_resolve()

In gid_resolve there are two cases:
either the gid_cache_lookup() call returns
a value or not. The result is caputured in
the agl variable, and throughout the function,
each particular stage of the implementation
comes with an agl and a no-agl variant.

In most cases this is explicitly indicated
via an

   if (agl) {
      ...
   } else {
      ...
   }

but some of this branching are expressed via
goto constructs (obfuscating the fact we stated
above, that is, each particular stage having
an agl/no-agl variant).

In the current refactor, we bring the agl
conditional to the top, and present the
agl/non-agl implementations sequentially.

Also we take the opportunity to clean up and
fix the agl case:
- remove the spurious
    gl.gl_list = agl->gl_list;
  setting, as gl is not used in the agl caae
- populate the group list of call stack from
  agl, fixing thus referred BUG.

Also fixes BUG: 1513920

Change-Id: I61f4574ba21969f7661b9ff0c9dce202b874025d
BUG: 1513928
Signed-off-by: Csaba Henk <csaba@redhat.com>

Comment 3 Shyamsundar 2018-03-15 11:20:54 UTC
This bug is getting closed because a release has been made available that should address the reported issue. In case the problem is still not fixed with glusterfs-4.0.0, please open a new bug report.

glusterfs-4.0.0 has been announced on the Gluster mailinglists [1], packages for several distributions should become available in the near future. Keep an eye on the Gluster Users mailinglist [2] and the update infrastructure for your distribution.

[1] http://lists.gluster.org/pipermail/announce/2018-March/000092.html
[2] https://www.gluster.org/pipermail/gluster-users/


Note You need to log in before you can comment on or make changes to this bug.