lkml.org 
[lkml]   [2017]   [Jan]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [PATCH 1/2] afs: Move UUID struct to linux/uuid.h
Date
Arnd Bergmann <arnd@arndb.de> wrote:

> Looks good to me, but I wonder if this part:
>
> r = call->request;
> - r->time_low = ntohl(b[0]);
> - r->time_mid = ntohl(b[1]);
> - r->time_hi_and_version = ntohl(b[2]);
> + r->time_low = b[0];
> + r->time_mid = htons(ntohl(b[1]));
> + r->time_hi_and_version = htons(ntohl(b[2]));
> r->clock_seq_hi_and_reserved = ntohl(b[3]);
> r->clock_seq_low = ntohl(b[4]);
>
> should be considered a bugfix and split out into a
> separate patch.

I changed the definitions in the struct from u16/u32 to __be16/__be32 so it's
not a bugfix.

For some reason, rather than specifying UUIDs as just a 16-octet field, the
AFS protocol breaks the UUID down into pieces and converts them into 32-bit
fields (apparently signed in some places:-/).

> From what I understand about the mess in UUID formats, the time fields can
> either be big-endian (as defined) or little-endian (for all things
> Microsoft),

RFC 4122 specified that the multi-octet fields are stored MSB-first.

> and you are changing the representation from CPU-specific to big-endian,
> which makes it different for x86 and most ARM at least.

In-kernel, not in the protocol.

The problem is that you can't do what you put in your suggested patch and just
copy the UUID produced by the generate_random_uuid() over the afs_uuid struct
since that puts the version in the wrong place.

David

\
 
 \ /
  Last update: 2017-01-12 15:20    [W:0.074 / U:0.276 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site