From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1750846AbdALOUH (ORCPT ); Thu, 12 Jan 2017 09:20:07 -0500 Received: from mx1.redhat.com ([209.132.183.28]:56644 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750720AbdALOUE (ORCPT ); Thu, 12 Jan 2017 09:20:04 -0500 Organization: Red Hat UK Ltd. Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SI4 1TE, United Kingdom. Registered in England and Wales under Company Registration No. 3798903 From: David Howells In-Reply-To: <107420020.65PPp1ZfLz@wuerfel> References: <107420020.65PPp1ZfLz@wuerfel> <148422219487.9419.2588525606361566422.stgit@warthog.procyon.org.uk> To: Arnd Bergmann Cc: dhowells@redhat.com, linux-kernel@vger.kernel.org, ruchandani.tina@gmail.com, linux-afs@lists.infradead.org Subject: Re: [PATCH 1/2] afs: Move UUID struct to linux/uuid.h MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <13020.1484230376.1@warthog.procyon.org.uk> Date: Thu, 12 Jan 2017 14:12:56 +0000 Message-ID: <13021.1484230376@warthog.procyon.org.uk> X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.28]); Thu, 12 Jan 2017 14:12:59 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Arnd Bergmann 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