Received: by 2002:ac0:a581:0:0:0:0:0 with SMTP id m1-v6csp966374imm; Wed, 20 Jun 2018 09:22:10 -0700 (PDT) X-Google-Smtp-Source: ADUXVKIAoXFqxndo5a02F60oU2fsslhfiYOg7ZJfCbWDfEqos6jdNpYPROQ94pRKwRjAC6RxoYAp X-Received: by 2002:a62:9c0d:: with SMTP id f13-v6mr6155751pfe.215.1529511730676; Wed, 20 Jun 2018 09:22:10 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1529511730; cv=none; d=google.com; s=arc-20160816; b=XN6pyCcIGdTrLauqisXyLIIcDbknVkWI/BtSXlb7f629RjycBpVXzp8vHUOHSfwQHP L3Qp7QydUBKOS09yTrbb4w4+uUU+Sp3IQKn/MqUCQQXZrDFAhmlkysmWSxl6q7oLA5fm zkZ834b2EHQIXK5DBG/E7CQcCwlWDnAPcZkSq2Lh8m0O3SK0IzaBRRcdu3J7o0S2tpMR hxSEVBC+0QTSVQ7fDHE2FMUvtTZv8lrd82O8qML9z1bklFf+mYp8n1RZeqjiDBFoLJEn sgnx/ur6sZV83ibvL1oloQRlChqEJ1I+y6YXsUUg/9UtAOGd4aQU48vFYLwVVLG2TFUV CTaA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :references:in-reply-to:mime-version:dkim-signature :arc-authentication-results; bh=ju8PtELIqgoIk5huwRdbUX6rV3vDV4Dz/UoQntvf9c8=; b=mwjam9qrO1rnXPiwaDQXRy8ctGTXLUObocTgORAW5/xrQk3lgPcWr0tu/8xySFPOxi JSq3SZFqcaXk5ICxOxzEbZxxVdHuzbMR66nwxumVt1LXmsMFKI7FvS9wGk2G2Huac7Qm CB3Ca2leTx2Pjrj0I9A6T78LwvxaL2L0dguyADvEusIYhsmWCHJvCmB5gglMILFZxdBz Fv5PMCT6EeEXLPhHyuTL8lbxQj0cI73cg4z6Upm2EriCTBZ9qD79jZhyRYJ4oOjFqmz4 73D0STDae05wgpwM8xiPdX+LxJyEWl0rRogi/vtu+mBrM59vUlrS7Uf2ovD7lS6/FYZC Gw9g== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@gmail.com header.s=20161025 header.b=q5dsWk5d; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id w23-v6si2759816ply.320.2018.06.20.09.21.56; Wed, 20 Jun 2018 09:22:10 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=fail header.i=@gmail.com header.s=20161025 header.b=q5dsWk5d; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754562AbeFTQUs (ORCPT + 99 others); Wed, 20 Jun 2018 12:20:48 -0400 Received: from mail-lf0-f67.google.com ([209.85.215.67]:44487 "EHLO mail-lf0-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754548AbeFTQUq (ORCPT ); Wed, 20 Jun 2018 12:20:46 -0400 Received: by mail-lf0-f67.google.com with SMTP id p23-v6so167290lfh.11; Wed, 20 Jun 2018 09:20:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=ju8PtELIqgoIk5huwRdbUX6rV3vDV4Dz/UoQntvf9c8=; b=q5dsWk5dgtfguqFttd2byr8U11GQ/6HcWlm/TvRuuzKtWWZGJs2SnJx0H2rN1CRjXY 7nIRI1zdOj2z95SLvXZ2hapT/PGAWcPVB9OhaZyW/oRWQpbhKuzj6tzJ4PRnM8dPP3Gj qk+zAy9SDKeflUYnqLmkmwYMdLth3BqhrrCxKLVrstqvlnjsAAWfY6YyO1RCfiCSOVvr kTzuhGodYtQTdBxw+A95etUufsmf06q0igQ4QzcDk1ROJUHCbs5dEyI5eVRaAhQzXo6N +pegl4xVKv8mIgbEgxCpb2/dMveVJUC2vctIuORDZmX1WQMXETga//Mv3V7ZW+qIA1pj OhjQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=ju8PtELIqgoIk5huwRdbUX6rV3vDV4Dz/UoQntvf9c8=; b=GqJ6/Qfv8NLYCpvrc3svrm76t5qVKmiJDVUzOujOWFmug8KrK/bei9fYoTalWC3Fq+ /AiQCbNgcIjYZeAQwD/dw1rrywMxoe9b/XV0TtQ9AyZdepe0PTNTHt1Aul7m67rIDGou sVVuWhidzD/ZekaxjACX8DjAsQkAjvbL2B6+irn4p9zP9zr7S/+on1kPvT0h5DjSYUKD UzNCXJJFt6/mIkvpA/CWSx7efSqOCUcJd9ALsJlFAzMj2BcyvFUGzbDSvMva890TgW1O fVR28Yfxwa1bijpqOBJMzlzpzFILJ/oQXA9uOlCY520uqb9UCaqPMuKBq5TnlYt2j4NV rSzg== X-Gm-Message-State: APt69E2oO+JUy8vMS2QNAKAoSbcTh0mNL6WZQhjWzkpysit9jkCEW32/ AarIXm1IFV1T/dN9uIdhHwLq6VzHb3uPNnQezIk= X-Received: by 2002:a2e:40d9:: with SMTP id r86-v6mr14558154lje.19.1529511645328; Wed, 20 Jun 2018 09:20:45 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a2e:56c8:0:0:0:0:0 with HTTP; Wed, 20 Jun 2018 09:20:44 -0700 (PDT) In-Reply-To: <5ffd5433-6bb3-71a8-2b33-ceef50ddf6d7@suse.de> References: <20180620095228.3686471-1-arnd@arndb.de> <5ffd5433-6bb3-71a8-2b33-ceef50ddf6d7@suse.de> From: Arnd Bergmann Date: Wed, 20 Jun 2018 18:20:44 +0200 X-Google-Sender-Auth: u1FaefQbaqocJKOQY1QjnJ93wKI Message-ID: Subject: Re: [PATCH] bcache: stop using the deprecated get_seconds() To: Coly Li Cc: Kent Overstreet , y2038 Mailman List , Jens Axboe , Michael Lyle , Tang Junhui , Hannes Reinecke , Bart Van Assche , Andy Shevchenko , linux-bcache@vger.kernel.org, Linux Kernel Mailing List Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Jun 20, 2018 at 5:51 PM, Coly Li wrote: > On 2018/6/20 5:51 PM, Arnd Bergmann wrote: >> bcache uses get_seconds() to read the current system time and store it in >> the superblock as well as in uuid_entry structures that are user visible. >> >> This changes over from the deprecated function to >> ktime_get_real_seconds(), which returns a 64-bit timestamp as it >> should. Unfortunately, the two structures are still limited to 32 bits, >> so this won't fix any real problems. Let's at least document that >> properly, in case we get an updated format in the future it can be >> fixed. Until then, we still have some time, and checking the tools >> at https://github.com/koverstreet/bcache-tools reveals no access to >> any of them. >> >> Signed-off-by: Arnd Bergmann > > Hi Arnd, > > Firstly thanks to your patch, especially the detailed information in > patch log, it helps me to understand the problem more easier. > > From the information, it seems the problem is current 32bit time stamp > will be overflow in 2106. So it will be 88 years later, which I have to > say I don't care. > > Also for get_seconds() which works well for current code as many other > places call it, I would like to keep it. I'm currently in the process of removing all instances of get_seconds() with patches like this. In many cases, we actually want to use ktime_get_seconds() to return a monotonic time that is immune to concurrent setttimeofday() calls, in others the code needs to be changed to avoid the y2038 overflow. For bcache, we don't really need either of them, but I'd still want to move over everything to ktime_get_* based interfaces. Should I clarify that motivation in the changelog text further? I can also do a simple replacement of get_seconds() with ktime_get_real_seconds() throughout bcache instead of adding the intermediate helper function. Arnd