Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1556489 > unrolled thread

[PATCH] afs: correctly use 64-bit time for UUID

Started byArnd Bergmann <arnd@arndb.de>
First post2017-01-11 14:50 +0100
Last post2017-01-12 10:30 +0100
Articles 6 — 3 participants

Back to article view | Back to linux.kernel


Contents

  [PATCH] afs: correctly use 64-bit time for UUID Arnd Bergmann <arnd@arndb.de> - 2017-01-11 14:50 +0100
    Re: [PATCH] afs: correctly use 64-bit time for UUID David Howells <dhowells@redhat.com> - 2017-01-11 15:00 +0100
      Re: [PATCH] afs: correctly use 64-bit time for UUID Arnd Bergmann <arnd@arndb.de> - 2017-01-11 15:10 +0100
        Re: [PATCH] afs: correctly use 64-bit time for UUID David Howells <dhowells@redhat.com> - 2017-01-11 15:50 +0100
          Re: [PATCH] afs: correctly use 64-bit time for UUID Arnd Bergmann <arnd@arndb.de> - 2017-01-11 17:00 +0100
            Re: [PATCH] afs: use random UUID kbuild test robot <lkp@intel.com> - 2017-01-12 10:30 +0100

#1556489 — [PATCH] afs: correctly use 64-bit time for UUID

FromArnd Bergmann <arnd@arndb.de>
Date2017-01-11 14:50 +0100
Subject[PATCH] afs: correctly use 64-bit time for UUID
Message-ID<sYrrQ-7xT-7@gated-at.bofh.it>
From: Tina Ruchandani <ruchandani.tina@gmail.com>

UUID calculation uses 'struct timespec' whose seconds will overflow
in year 2038 and beyond for 32-bit systems. This patch removes the
dependency on 'struct timespec' by using ktime_get_real().
While the patch does not fix a 'bug' as such, it is part of a larger
effort to remove instances of 'struct timespec' and other data-structures
suffering from y2038 problem from the kernel.

Suggested-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Tina Ruchandani <ruchandani.tina@gmail.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
 fs/afs/main.c | 6 ++----
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/fs/afs/main.c b/fs/afs/main.c
index f8188feb03ad..59e7ef38e541 100644
--- a/fs/afs/main.c
+++ b/fs/afs/main.c
@@ -13,6 +13,7 @@
 #include <linux/moduleparam.h>
 #include <linux/init.h>
 #include <linux/completion.h>
+#include <linux/ktime.h>
 #include <linux/sched.h>
 #include <linux/random.h>
 #define CREATE_TRACE_POINTS
@@ -39,7 +40,6 @@ struct workqueue_struct *afs_wq;
  */
 static int __init afs_get_client_UUID(void)
 {
-	struct timespec ts;
 	u64 uuidtime;
 	u16 clockseq;
 	int ret;
@@ -50,9 +50,7 @@ static int __init afs_get_client_UUID(void)
 	if (ret < 0)
 		return ret;
 
-	getnstimeofday(&ts);
-	uuidtime = (u64) ts.tv_sec * 1000 * 1000 * 10;
-	uuidtime += ts.tv_nsec / 100;
+	uuidtime = ktime_divns(ktime_get_real(), 100);
 	uuidtime += AFS_UUID_TO_UNIX_TIME;
 	afs_uuid.time_low = uuidtime;
 	afs_uuid.time_mid = uuidtime >> 32;
-- 
2.9.0

[toc] | [next] | [standalone]


#1556500

FromDavid Howells <dhowells@redhat.com>
Date2017-01-11 15:00 +0100
Message-ID<sYrBv-7Bc-19@gated-at.bofh.it>
In reply to#1556489
Arnd Bergmann <arnd@arndb.de> wrote:

> From: Tina Ruchandani <ruchandani.tina@gmail.com>
> 
> UUID calculation uses 'struct timespec' whose seconds will overflow
> in year 2038 and beyond for 32-bit systems. This patch removes the
> dependency on 'struct timespec' by using ktime_get_real().
> While the patch does not fix a 'bug' as such, it is part of a larger
> effort to remove instances of 'struct timespec' and other data-structures
> suffering from y2038 problem from the kernel.

Is it worth abstracting out in-kernel UUID generation?

David

[toc] | [prev] | [next] | [standalone]


#1556510

FromArnd Bergmann <arnd@arndb.de>
Date2017-01-11 15:10 +0100
Message-ID<sYrLc-7Tv-11@gated-at.bofh.it>
In reply to#1556500
On Wednesday, January 11, 2017 1:51:32 PM CET David Howells wrote:
> Arnd Bergmann <arnd@arndb.de> wrote:
> 
> > From: Tina Ruchandani <ruchandani.tina@gmail.com>
> > 
> > UUID calculation uses 'struct timespec' whose seconds will overflow
> > in year 2038 and beyond for 32-bit systems. This patch removes the
> > dependency on 'struct timespec' by using ktime_get_real().
> > While the patch does not fix a 'bug' as such, it is part of a larger
> > effort to remove instances of 'struct timespec' and other data-structures
> > suffering from y2038 problem from the kernel.
> 
> Is it worth abstracting out in-kernel UUID generation?

Do you mean moving it out of AFS into lib/*.c? I think the 'afs_uuid'
structure is quite different from other UUID definitions, so that wouldn't
work.

	Arnd

[toc] | [prev] | [next] | [standalone]


#1556542

FromDavid Howells <dhowells@redhat.com>
Date2017-01-11 15:50 +0100
Message-ID<sYsnT-86a-13@gated-at.bofh.it>
In reply to#1556510
Arnd Bergmann <arnd@arndb.de> wrote:

> > Is it worth abstracting out in-kernel UUID generation?
> 
> Do you mean moving it out of AFS into lib/*.c? I think the 'afs_uuid'
> structure is quite different from other UUID definitions, so that wouldn't
> work.

afs_uuid is as it is to make it easier to package into the on-wire format, but
I suspect there's no problem with using a completely random UUID instead and
divvying it up the same way.

David

[toc] | [prev] | [next] | [standalone]


#1556666

FromArnd Bergmann <arnd@arndb.de>
Date2017-01-11 17:00 +0100
Message-ID<sYttF-id-45@gated-at.bofh.it>
In reply to#1556542
On Wednesday, January 11, 2017 2:47:20 PM CET David Howells wrote:
> Arnd Bergmann <arnd@arndb.de> wrote:
> 
> > > Is it worth abstracting out in-kernel UUID generation?
> > 
> > Do you mean moving it out of AFS into lib/*.c? I think the 'afs_uuid'
> > structure is quite different from other UUID definitions, so that wouldn't
> > work.
> 
> afs_uuid is as it is to make it easier to package into the on-wire format, but
> I suspect there's no problem with using a completely random UUID instead and
> divvying it up the same way.

Maybe like this:

8<----7
From 9e164f852366750fdd732ae317af9f4a9a04a16e Mon Sep 17 00:00:00 2001
From: Arnd Bergmann <arnd@arndb.de>
Date: Wed, 11 Jan 2017 16:53:13 +0100
Subject: [PATCH] afs: use random UUID

AFS uses a time based UUID to identify the host itself. This requires
getting a timestamp which is currently done through the getnstimeofday()
interface that we want to eventually get rid of.

Instead of replacing it with a ktime based interface, this simply
removes the entire function and uses generate_random_uuid() instead,
which has a v4 ("completely random") uuid instead of the time based one.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>

diff --git a/fs/afs/main.c b/fs/afs/main.c
index f8188feb03ad..9944770849da 100644
--- a/fs/afs/main.c
+++ b/fs/afs/main.c
@@ -35,49 +35,6 @@ struct afs_uuid afs_uuid;
 struct workqueue_struct *afs_wq;
 
 /*
- * get a client UUID
- */
-static int __init afs_get_client_UUID(void)
-{
-	struct timespec ts;
-	u64 uuidtime;
-	u16 clockseq;
-	int ret;
-
-	/* read the MAC address of one of the external interfaces and construct
-	 * a UUID from it */
-	ret = afs_get_MAC_address(afs_uuid.node, sizeof(afs_uuid.node));
-	if (ret < 0)
-		return ret;
-
-	getnstimeofday(&ts);
-	uuidtime = (u64) ts.tv_sec * 1000 * 1000 * 10;
-	uuidtime += ts.tv_nsec / 100;
-	uuidtime += AFS_UUID_TO_UNIX_TIME;
-	afs_uuid.time_low = uuidtime;
-	afs_uuid.time_mid = uuidtime >> 32;
-	afs_uuid.time_hi_and_version = (uuidtime >> 48) & AFS_UUID_TIMEHI_MASK;
-	afs_uuid.time_hi_and_version |= AFS_UUID_VERSION_TIME;
-
-	get_random_bytes(&clockseq, 2);
-	afs_uuid.clock_seq_low = clockseq;
-	afs_uuid.clock_seq_hi_and_reserved =
-		(clockseq >> 8) & AFS_UUID_CLOCKHI_MASK;
-	afs_uuid.clock_seq_hi_and_reserved |= AFS_UUID_VARIANT_STD;
-
-	_debug("AFS UUID: %08x-%04x-%04x-%02x%02x-%02x%02x%02x%02x%02x%02x",
-	       afs_uuid.time_low,
-	       afs_uuid.time_mid,
-	       afs_uuid.time_hi_and_version,
-	       afs_uuid.clock_seq_hi_and_reserved,
-	       afs_uuid.clock_seq_low,
-	       afs_uuid.node[0], afs_uuid.node[1], afs_uuid.node[2],
-	       afs_uuid.node[3], afs_uuid.node[4], afs_uuid.node[5]);
-
-	return 0;
-}
-
-/*
  * initialise the AFS client FS module
  */
 static int __init afs_init(void)
@@ -86,9 +43,7 @@ static int __init afs_init(void)
 
 	printk(KERN_INFO "kAFS: Red Hat AFS client v0.1 registering.\n");
 
-	ret = afs_get_client_UUID();
-	if (ret < 0)
-		return ret;
+	generate_random_uuid((unsigned char *)&afs_uuid);
 
 	/* create workqueue */
 	ret = -ENOMEM;

[toc] | [prev] | [next] | [standalone]


#1557236 — Re: [PATCH] afs: use random UUID

Fromkbuild test robot <lkp@intel.com>
Date2017-01-12 10:30 +0100
SubjectRe: [PATCH] afs: use random UUID
Message-ID<sYJRM-2er-7@gated-at.bofh.it>
In reply to#1556666

[Multipart message — attachments visible in raw view] — view raw

Hi Arnd,

[auto build test ERROR on linus/master]
[also build test ERROR on v4.10-rc3 next-20170111]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]

url:    https://github.com/0day-ci/linux/commits/Arnd-Bergmann/afs-use-random-UUID/20170112-153644
config: x86_64-randconfig-in0-01121653 (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
        # save the attached .config to linux build tree
        make ARCH=x86_64 

All errors (new ones prefixed by >>):

   fs/afs/main.c: In function 'afs_init':
>> fs/afs/main.c:45:2: error: implicit declaration of function 'generate_random_uuid' [-Werror=implicit-function-declaration]
     generate_random_uuid((unsigned char *)&afs_uuid);
     ^~~~~~~~~~~~~~~~~~~~
   cc1: some warnings being treated as errors

vim +/generate_random_uuid +45 fs/afs/main.c

    39	static int __init afs_init(void)
    40	{
    41		int ret;
    42	
    43		printk(KERN_INFO "kAFS: Red Hat AFS client v0.1 registering.\n");
    44	
  > 45		generate_random_uuid((unsigned char *)&afs_uuid);
    46	
    47		/* create workqueue */
    48		ret = -ENOMEM;

---
0-DAY kernel test infrastructure                Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all                   Intel Corporation

[toc] | [prev] | [standalone]


Back to top | Article view | linux.kernel


csiph-web