Description of problem: The "struct auth_cache_entry" gets put into a dictionary, with a hash-string of the client and the requested mount-point/directory as key. However, due to a programming error, the hash-string is often set to NULL. Version-Release number of selected component (if applicable): 3.7 and mainline Additional notes: Noticed during code-review.
REVIEW: http://review.gluster.org/11019 (nfs: allocate and return the hashkey for the auth_cache_entry) posted (#2) for review on master by Niels de Vos (ndevos)
REVIEW: http://review.gluster.org/11019 (nfs: allocate and return the hashkey for the auth_cache_entry) posted (#3) for review on master by Niels de Vos (ndevos)
COMMIT: http://review.gluster.org/11019 committed in master by Niels de Vos (ndevos) ------ commit b8b59fea7822f9ab1e10d7a3f730354fe82a6097 Author: Niels de Vos <ndevos> Date: Sun May 31 22:29:11 2015 +0200 nfs: allocate and return the hashkey for the auth_cache_entry The allocation of the hashkey was never returned to the calling function. Allocating it with alloca() puts it on the stack, returning from the function makes the pointer invalid. Functions that are annotated with "inline" and call alloca(), will not always be inlined. Returning a pointer allocated with alloca() is in those cases not correct. One such confirmation was provided by GCC developer Alexandre Oliva: - http://gcc.gnu.org/ml/gcc-help/2004-04/msg00158.html It is more correct to call GF_MALLOC() and GF_FREE() for the hashkey. If this would result in preformance hit, we can always think of using alloca() again and turn make_hashkey() into a macro (yuck). Change-Id: Ia86a1f79d33240af4713bfb92f702b0ee6e87eb7 BUG: 1226714 Signed-off-by: Niels de Vos <ndevos> Reviewed-on: http://review.gluster.org/11019 Reviewed-by: Kaleb KEITHLEY <kkeithle> Reviewed-by: jiffin tony Thottan <jthottan> Reviewed-by: soumya k <skoduri> Tested-by: Gluster Build System <jenkins.com>
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-3.8.0, please open a new bug report. glusterfs-3.8.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://blog.gluster.org/2016/06/glusterfs-3-8-released/ [2] http://thread.gmane.org/gmane.comp.file-systems.gluster.user