Bug 838928

Summary:	bad cast, not 64-bit clean, dict_allocate_and_serialize()
Product:	[Community] GlusterFS	Reporter:	Kaleb KEITHLEY <kkeithle>
Component:	core	Assignee:	Amar Tumballi <amarts>
Status:	CLOSED CURRENTRELEASE	QA Contact:
Severity:	medium	Docs Contact:
Priority:	medium
Version:	mainline	CC:	gluster-bugs, vraman
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:	glusterfs-3.4.0	Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2013-07-24 17:19:32 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Kaleb KEITHLEY 2012-07-10 13:05:38 UTC

Description of problem:

All calls to dict_allocate_and_serialize() pass the address of a 32-bit type, but cast it to a 64-bit pointer type (size_t *). This happens to work on LE machines, but even if it's benign, it's still a bug. On BE machines it is not benign.

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

How reproducible: build/run on a BE machine, e.g. SPARC or PPC


Steps to Reproduce:
1.
2.
3.
  
Actual results:


Expected results:


Additional info:

Found by xinfeng.liu, email on gluster-devel mailing list

Comment 1 Kaleb KEITHLEY 2012-07-10 13:32:22 UTC

In every call to dict_allocate_and_serialize(), the underlying 'len' param is always a u_int, so:
 a) why is the param a size_t* ?
 b) and then why have extra code in GF_PROTOCOL_DICT_SERIALIZE to work around it?

By changing the param in dict_allocate_and_serialize() to a u_int* we only need to fix a few files and then we have 64-bit clean code everywhere we call dict_allocate_and_serialize().

Comment 2 Vijay Bellur 2012-07-12 07:31:56 UTC

CHANGE: http://review.gluster.com/3642 (calls to dict_allocate_and_serialize() are not 64-bit clean) merged in master by Anand Avati (avati)