Bug 330121 - uuid generator truncates clock_seq_hi_and_reserved field
uuid generator truncates clock_seq_hi_and_reserved field
Status: CLOSED CURRENTRELEASE
Product: 389
Classification: Community
Component: Directory Server (Show other bugs)
1.1.0beta
All All
high Severity high
: ---
: ---
Assigned To: Rich Megginson
Viktor Ashirov
:
Depends On:
Blocks: 240316 FDS1.1.0
  Show dependency treegraph
 
Reported: 2007-10-12 17:37 EDT by Rich Megginson
Modified: 2015-12-07 11:36 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2015-12-07 11:36:00 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
diffs (1.33 KB, patch)
2007-10-12 17:37 EDT, Rich Megginson
no flags Details | Diff
cvs commit log (162 bytes, text/plain)
2007-10-12 21:48 EDT, Rich Megginson
no flags Details

  None (edit)
Description Rich Megginson 2007-10-12 17:37:24 EDT
The uuid code has this code (where clock_seq is unsigned16 - 2 bytes and
uuid->clock_seq_hi_and_reserved is unsigned8 - 1 byte):
    uuid->clock_seq_hi_and_reserved = (unsigned8)(clock_seq & 0x3F00) >> 8;
In this code, the cast to unsigned8 takes precedence over over the shift.  So
what happens is that (clock_seq & 0x3F00) is first cast to an 8 bit quantity,
then shifted by 8 bits.  The result is that the value is _always 0_.  The code
also does this:
    uuid->clock_seq_hi_and_reserved |= 0x80;

You can see this because every nsUniqueID looks like this:
XXXXXXXX-XXXXXXXX-80XXXXXXXX-XXXXXXXX
The first byte of the 3rd octet is always 80.
Comment 1 Rich Megginson 2007-10-12 17:37:24 EDT
Created attachment 226161 [details]
diffs
Comment 2 Nathan Kinder 2007-10-12 19:24:35 EDT
Good catch!
Comment 3 Rich Megginson 2007-10-12 21:48:01 EDT
Created attachment 226261 [details]
cvs commit log

Reviewed by: nkinder (Thanks!)
Files: see diff
Branch: HEAD
Fix Description: https://bugzilla.redhat.com/show_bug.cgi?id=330121#c0
This may also be related to https://bugzilla.redhat.com/show_bug.cgi?id=197886
and may explain why the sequence numbers were exhausted so quickly.  Without
this fix, we only have 256 sequence numbers available.	This fix adds another 6
bits.
The fix is to mask and shift as an unsigned16 quantity, then cast to unsigned8.

Platforms tested: RHEL5 x86_64
Flag Day: no - I think this will only impact new unique IDs that are generated.
 It will not affect existing unique IDs.
Doc impact: no

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