From patchwork Mon Feb 15 03:01:53 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Deepa Dinamani X-Patchwork-Id: 8308691 Return-Path: X-Original-To: patchwork-ceph-devel@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork2.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.136]) by patchwork2.web.kernel.org (Postfix) with ESMTP id 81878C02AA for ; Mon, 15 Feb 2016 03:02:38 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 5061B204DE for ; Mon, 15 Feb 2016 03:02:37 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 6845E204C9 for ; Mon, 15 Feb 2016 03:02:36 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751634AbcBODC3 (ORCPT ); Sun, 14 Feb 2016 22:02:29 -0500 Received: from mail-pf0-f174.google.com ([209.85.192.174]:33186 "EHLO mail-pf0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751558AbcBODC2 (ORCPT ); Sun, 14 Feb 2016 22:02:28 -0500 Received: by mail-pf0-f174.google.com with SMTP id q63so79425533pfb.0 for ; Sun, 14 Feb 2016 19:02:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:subject:date:message-id; bh=Lhz2i+IgsOG/zCvFfESnmzzqIAXbRPdIttGh8Ma7NbA=; b=HS0ggKbTAOt2Q6VjqgjutDODRbqJMFR6tiAdb6hXSFpUcB5U0gE5xoFs8ULey3mtt0 pwALpm3Voz/2e/zTU59XWfrGiFYWDVZNAygGxSIbFg6KFgaUcMn1YqnOIP5edZEGzmMB AZ69t+49tR7gVzKAwM2wxT/UofGr7d2ZJVWUkFHyo+gg/ANQPbvkzbXR60cGaOg6Rwlb z1aQKhVipM3L3M7/Dy9luatowUg/ElrLpWi5IXE5LEY9dP765vVo58BrXKlNb7NnHQ3i x660IYJKeg4NvPgg+i8AchyRYzk8AxdBrbHvVXTCLpZKsuJ+QQFoWQYm3/gW9ft4izQo ks+w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:date:message-id; bh=Lhz2i+IgsOG/zCvFfESnmzzqIAXbRPdIttGh8Ma7NbA=; b=XkYgAqsEiVmFtFeAgqbJn3YF5WFWLFCEbdNY9Ur1zVyPQxY8baZMm4K9cQajP1Xk5i J9g1Bd9MS185KZ+rOdSlFbeFOisy0yQhoqcn/dB3gVCYd9OZC2RkILQciNXC4J7p1GP0 7zDQFlHdysHaz6zM1EX3MUGkFjxg7hDsfl4HJoRgyWoohRbdCqy/F1el7eN1Sbmq93gf O7YIMoby+0wAaF3QqwpbgTH8Fg9vXLFZQB/9/kZtq3aXZwSeedDxFppRCy2jgjRRXjMe atFzmIsrJ/DF6n53hIN+I2Rc2BeXOHZH20lapTMJZ5VtvGZzgTvNr+RaXXqFXIIfBRxH JX2g== X-Gm-Message-State: AG10YORu92n/Lzz97449WLR/8pAsr/VxXR6VOVp2ctkzhbxtGybVqUQY2SrnHW0MLKoImQ== X-Received: by 10.98.8.219 with SMTP id 88mr20376745pfi.51.1455505348269; Sun, 14 Feb 2016 19:02:28 -0800 (PST) Received: from localhost.localdomain ([106.51.25.184]) by smtp.gmail.com with ESMTPSA id 195sm34285245pfa.5.2016.02.14.19.02.25 (version=TLS1_2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sun, 14 Feb 2016 19:02:27 -0800 (PST) From: Deepa Dinamani To: "Yan, Zheng" , Sage Weil , Ilya Dryomov , ceph-devel@vger.kernel.org Cc: arnd@arndb.de, y2038@lists.linaro.org Subject: [PATCH] include: ceph: Fix encode and decode type conversions Date: Sun, 14 Feb 2016 19:01:53 -0800 Message-Id: <1455505313-1298-1-git-send-email-deepa.kernel@gmail.com> X-Mailer: git-send-email 1.9.1 Sender: ceph-devel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: ceph-devel@vger.kernel.org X-Spam-Status: No, score=-6.8 required=5.0 tests=BAYES_00, DKIM_ADSP_CUSTOM_MED, DKIM_SIGNED, FREEMAIL_FROM, RCVD_IN_DNSWL_HI, RP_MATCHES_RCVD, T_DKIM_INVALID, UNPARSEABLE_RELAY autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP long/ kernel_time_t is 32 bit on a 32 bit system and 64 bit on a 64 bit system. ceph_encode_timespec() encodes only the lower 32 bits on a 64 bit system and encodes all of 32 bits on a 32bit system. ceph_decode_timespec() decodes 32 bit tv_sec and tv_nsec into kernel_time_t/ long. The encode and decode functions do not match when the values are negative: Consider the following scenario on a 32 bit system: When a negative number is cast to u32 as encode does, the value is positive and is greater than INT_MAX. Decode reads back this value. And, this value cannot be represented by long on 32 bit systems. So by section 6.3.1.3 of the C99 standard, the result is implementation defined. Consider the following scenario on a 64 bit system: When a negative number is cast to u32 as encode does, the value is positive. This value is later assigned by decode function by a cast to long. Since this value can be represented in long data type, this becomes a positive value greater than INT_MAX. But, the value encoded was negative, so the encode and decode functions do not match. Change the decode function as follows to overcome the above bug: The decode should first cast the value to a s64 this will be positive value greater than INT_MAX(in case of a negative encoded value)and then cast this value again as s32, which drops the higher order 32 bits. On 32 bit systems, this is the right value in kernel_time_t/ long. On 64 bit systems, assignment to kernel_time_t/ long will sign extend this value to reflect the signed bit encoded. Assume ceph timestamp ranges permitted are 1902..2038. Suggested-by: Arnd Bergmann Signed-off-by: Deepa Dinamani --- include/linux/ceph/decode.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/include/linux/ceph/decode.h b/include/linux/ceph/decode.h index a6ef9cc..e777e99 100644 --- a/include/linux/ceph/decode.h +++ b/include/linux/ceph/decode.h @@ -137,8 +137,8 @@ bad: static inline void ceph_decode_timespec(struct timespec *ts, const struct ceph_timespec *tv) { - ts->tv_sec = (__kernel_time_t)le32_to_cpu(tv->tv_sec); - ts->tv_nsec = (long)le32_to_cpu(tv->tv_nsec); + ts->tv_sec = (s32)(s64)le32_to_cpu(tv->tv_sec); + ts->tv_nsec = (s32)(s64)le32_to_cpu(tv->tv_nsec); } static inline void ceph_encode_timespec(struct ceph_timespec *tv, const struct timespec *ts)