All of lore.kernel.org
 help / color / mirror / Atom feed
From: Deepa Dinamani <deepa.kernel@gmail.com>
To: "Yan, Zheng" <zyan@redhat.com>, Sage Weil <sage@redhat.com>,
	Ilya Dryomov <idryomov@gmail.com>,
	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	[thread overview]
Message-ID: <1455505313-1298-1-git-send-email-deepa.kernel@gmail.com> (raw)

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 <arnd@arndb.de>
Signed-off-by: Deepa Dinamani <deepa.kernel@gmail.com>
---
 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)
-- 
1.9.1


             reply	other threads:[~2016-02-15  3:02 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-02-15  3:01 Deepa Dinamani [this message]
2016-02-15  9:04 ` [PATCH] include: ceph: Fix encode and decode type conversions Yan, Zheng
2016-02-15 11:17 ` [Y2038] " Arnd Bergmann
2016-02-16  5:02   ` Deepa Dinamani
2016-02-16  8:56     ` Arnd Bergmann
2016-02-18  6:02       ` Deepa Dinamani
2016-02-18  9:17         ` Arnd Bergmann
2016-02-18  9:35           ` Deepa Dinamani
2016-02-18 11:29             ` Arnd Bergmann
2016-02-18 16:02             ` Ilya Dryomov
2016-02-18 16:20               ` Arnd Bergmann
2016-02-18 17:22                 ` Ilya Dryomov
2016-02-19 10:00                   ` Arnd Bergmann
2016-02-19 11:42                     ` Ilya Dryomov
2016-02-19 16:30                       ` [Y2038] " Arnd Bergmann
2016-03-01 16:18                         ` Sage Weil
2016-02-15 12:37 ` Ilya Dryomov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1455505313-1298-1-git-send-email-deepa.kernel@gmail.com \
    --to=deepa.kernel@gmail.com \
    --cc=arnd@arndb.de \
    --cc=ceph-devel@vger.kernel.org \
    --cc=idryomov@gmail.com \
    --cc=sage@redhat.com \
    --cc=y2038@lists.linaro.org \
    --cc=zyan@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.