netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH 0/8] y2038: bug fixes from y2038 work
@ 2019-11-08 20:34 Arnd Bergmann
  2019-11-08 20:34 ` [PATCH 1/8] y2038: timex: remove incorrect time_t truncation Arnd Bergmann
  2019-11-08 20:34 ` [PATCH 5/8] netfilter: xt_time: use time64_t Arnd Bergmann
  0 siblings, 2 replies; 5+ messages in thread
From: Arnd Bergmann @ 2019-11-08 20:34 UTC (permalink / raw)
  To: y2038
  Cc: linux-kernel, Arnd Bergmann, Benjamin Herrenschmidt,
	Paul Mackerras, Michael Ellerman, Corey Minyard,
	Greg Kroah-Hartman, Sudip Mukherjee, Dmitry Torokhov,
	John Stultz, Thomas Gleixner, Stephen Boyd, Pablo Neira Ayuso,
	Jozsef Kadlecsik, Florian Westphal, David S. Miller,
	linuxppc-dev, openipmi-developer, linux-input, netfilter-devel,
	coreteam, netdev, sparclinux

I've gone through the remaining uses of time_t etc and come up with a
set of 90 patches of varying complexity and importance, to the point
of being able to remove the old time_t/timeval/timespec from the kernel
headers completely.

This set includes the eight patches that I think should be merged
right away and backported into stable kernels if possible.

Please apply individual patches to the respective maintainer trees
for either v5.4 or v5.5 as appropriate.

For reference, the full series of 90 patches can be found at
https://git.kernel.org/pub/scm/linux/kernel/git/arnd/playground.git/log/?h=y2038-endgame

      Arnd

Arnd Bergmann (8):
  y2038: timex: remove incorrect time_t truncation
  timekeeping: optimize ns_to_timespec64
  powerpc: fix vdso32 for ppc64le
  ipmi: kill off 'timespec' usage again
  netfilter: xt_time: use time64_t
  lp: fix sparc64 LPSETTIMEOUT ioctl
  ppdev: fix PPGETTIME/PPSETTIME ioctls
  Input: input_event: fix struct padding on sparc64

 arch/powerpc/kernel/vdso32/gettimeofday.S |  2 +-
 drivers/char/ipmi/ipmi_si_intf.c          | 40 ++++++++---------------
 drivers/char/lp.c                         |  4 +++
 drivers/char/ppdev.c                      | 16 ++++++---
 drivers/input/evdev.c                     |  3 ++
 drivers/input/misc/uinput.c               |  3 ++
 include/uapi/linux/input.h                |  1 +
 kernel/time/ntp.c                         |  2 +-
 kernel/time/time.c                        | 21 +++++++-----
 net/netfilter/xt_time.c                   | 19 ++++++-----
 10 files changed, 61 insertions(+), 50 deletions(-)

Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Corey Minyard <minyard@acm.org>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Sudip Mukherjee <sudipm.mukherjee@gmail.com>
Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Cc: John Stultz <john.stultz@linaro.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Stephen Boyd <sboyd@kernel.org>
Cc: Pablo Neira Ayuso <pablo@netfilter.org>
Cc: Jozsef Kadlecsik <kadlec@netfilter.org>
Cc: Florian Westphal <fw@strlen.de>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: linuxppc-dev@lists.ozlabs.org
Cc: linux-kernel@vger.kernel.org
Cc: openipmi-developer@lists.sourceforge.net
Cc: linux-input@vger.kernel.org
Cc: netfilter-devel@vger.kernel.org
Cc: coreteam@netfilter.org
Cc: netdev@vger.kernel.org
Cc: sparclinux@vger.kernel.org

-- 
2.20.0


^ permalink raw reply	[flat|nested] 5+ messages in thread

* [PATCH 1/8] y2038: timex: remove incorrect time_t truncation
  2019-11-08 20:34 [PATCH 0/8] y2038: bug fixes from y2038 work Arnd Bergmann
@ 2019-11-08 20:34 ` Arnd Bergmann
  2019-11-10 20:44   ` Deepa Dinamani
  2019-11-08 20:34 ` [PATCH 5/8] netfilter: xt_time: use time64_t Arnd Bergmann
  1 sibling, 1 reply; 5+ messages in thread
From: Arnd Bergmann @ 2019-11-08 20:34 UTC (permalink / raw)
  To: y2038, John Stultz, Thomas Gleixner
  Cc: linux-kernel, Arnd Bergmann, stable, Deepa Dinamani, linux-alpha,
	netdev, Stephen Boyd

A cast to 'time_t' was accidentally left in place during the
conversion of __do_adjtimex() to 64-bit timestamps, so the
resulting value is incorrectly truncated.

Remove the cast so the 64-bit time gets propagated correctly.

Cc: stable@vger.kernel.org
Fixes: ead25417f82e ("timex: use __kernel_timex internally")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
 kernel/time/ntp.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/kernel/time/ntp.c b/kernel/time/ntp.c
index 65eb796610dc..069ca78fb0bf 100644
--- a/kernel/time/ntp.c
+++ b/kernel/time/ntp.c
@@ -771,7 +771,7 @@ int __do_adjtimex(struct __kernel_timex *txc, const struct timespec64 *ts,
 	/* fill PPS status fields */
 	pps_fill_timex(txc);
 
-	txc->time.tv_sec = (time_t)ts->tv_sec;
+	txc->time.tv_sec = ts->tv_sec;
 	txc->time.tv_usec = ts->tv_nsec;
 	if (!(time_status & STA_NANO))
 		txc->time.tv_usec = ts->tv_nsec / NSEC_PER_USEC;
-- 
2.20.0


^ permalink raw reply related	[flat|nested] 5+ messages in thread

* [PATCH 5/8] netfilter: xt_time: use time64_t
  2019-11-08 20:34 [PATCH 0/8] y2038: bug fixes from y2038 work Arnd Bergmann
  2019-11-08 20:34 ` [PATCH 1/8] y2038: timex: remove incorrect time_t truncation Arnd Bergmann
@ 2019-11-08 20:34 ` Arnd Bergmann
  2019-11-15 22:43   ` Pablo Neira Ayuso
  1 sibling, 1 reply; 5+ messages in thread
From: Arnd Bergmann @ 2019-11-08 20:34 UTC (permalink / raw)
  To: y2038, Pablo Neira Ayuso, Jozsef Kadlecsik, Florian Westphal,
	David S. Miller
  Cc: linux-kernel, Arnd Bergmann, Eric Dumazet, netfilter-devel,
	coreteam, netdev

The current xt_time driver suffers from the y2038 overflow on 32-bit
architectures, when the time of day calculations break.

Also, on both 32-bit and 64-bit architectures, there is a problem with
info->date_start/stop, which is part of the user ABI and overflows in
in 2106.

Fix the first issue by using time64_t and explicit calls to div_u64()
and div_u64_rem(), and document the seconds issue.

The explicit 64-bit division is unfortunately slower on 32-bit
architectures, but doing it as unsigned lets us use the optimized
division-through-multiplication path in most configurations.  This should
be fine, as the code already does not allow any negative time of day
values.

Using u32 seconds values consistently would probably also work and
be a little more efficient, but that doesn't feel right as it would
propagate the y2106 overflow to more place rather than fewer.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
 net/netfilter/xt_time.c | 19 +++++++++++--------
 1 file changed, 11 insertions(+), 8 deletions(-)

diff --git a/net/netfilter/xt_time.c b/net/netfilter/xt_time.c
index 8dbb4d48f2ed..67cb98489415 100644
--- a/net/netfilter/xt_time.c
+++ b/net/netfilter/xt_time.c
@@ -77,12 +77,12 @@ static inline bool is_leap(unsigned int y)
  * This is done in three separate functions so that the most expensive
  * calculations are done last, in case a "simple match" can be found earlier.
  */
-static inline unsigned int localtime_1(struct xtm *r, time_t time)
+static inline unsigned int localtime_1(struct xtm *r, time64_t time)
 {
 	unsigned int v, w;
 
 	/* Each day has 86400s, so finding the hour/minute is actually easy. */
-	v         = time % SECONDS_PER_DAY;
+	div_u64_rem(time, SECONDS_PER_DAY, &v);
 	r->second = v % 60;
 	w         = v / 60;
 	r->minute = w % 60;
@@ -90,13 +90,13 @@ static inline unsigned int localtime_1(struct xtm *r, time_t time)
 	return v;
 }
 
-static inline void localtime_2(struct xtm *r, time_t time)
+static inline void localtime_2(struct xtm *r, time64_t time)
 {
 	/*
 	 * Here comes the rest (weekday, monthday). First, divide the SSTE
 	 * by seconds-per-day to get the number of _days_ since the epoch.
 	 */
-	r->dse = time / 86400;
+	r->dse = div_u64(time, SECONDS_PER_DAY);
 
 	/*
 	 * 1970-01-01 (w=0) was a Thursday (4).
@@ -105,7 +105,7 @@ static inline void localtime_2(struct xtm *r, time_t time)
 	r->weekday = (4 + r->dse - 1) % 7 + 1;
 }
 
-static void localtime_3(struct xtm *r, time_t time)
+static void localtime_3(struct xtm *r, time64_t time)
 {
 	unsigned int year, i, w = r->dse;
 
@@ -160,7 +160,7 @@ time_mt(const struct sk_buff *skb, struct xt_action_param *par)
 	const struct xt_time_info *info = par->matchinfo;
 	unsigned int packet_time;
 	struct xtm current_time;
-	s64 stamp;
+	time64_t stamp;
 
 	/*
 	 * We need real time here, but we can neither use skb->tstamp
@@ -173,14 +173,14 @@ time_mt(const struct sk_buff *skb, struct xt_action_param *par)
 	 *	1. match before 13:00
 	 *	2. match after 13:00
 	 *
-	 * If you match against processing time (get_seconds) it
+	 * If you match against processing time (ktime_get_real_seconds) it
 	 * may happen that the same packet matches both rules if
 	 * it arrived at the right moment before 13:00, so it would be
 	 * better to check skb->tstamp and set it via __net_timestamp()
 	 * if needed.  This however breaks outgoing packets tx timestamp,
 	 * and causes them to get delayed forever by fq packet scheduler.
 	 */
-	stamp = get_seconds();
+	stamp = ktime_get_real_seconds();
 
 	if (info->flags & XT_TIME_LOCAL_TZ)
 		/* Adjust for local timezone */
@@ -193,6 +193,9 @@ time_mt(const struct sk_buff *skb, struct xt_action_param *par)
 	 *   - 'now' is in the weekday mask
 	 *   - 'now' is in the daytime range time_start..time_end
 	 * (and by default, libxt_time will set these so as to match)
+	 *
+	 * note: info->date_start/stop are unsigned 32-bit values that
+	 *	 can hold values beyond y2038, but not after y2106.
 	 */
 
 	if (stamp < info->date_start || stamp > info->date_stop)
-- 
2.20.0


^ permalink raw reply related	[flat|nested] 5+ messages in thread

* Re: [PATCH 1/8] y2038: timex: remove incorrect time_t truncation
  2019-11-08 20:34 ` [PATCH 1/8] y2038: timex: remove incorrect time_t truncation Arnd Bergmann
@ 2019-11-10 20:44   ` Deepa Dinamani
  0 siblings, 0 replies; 5+ messages in thread
From: Deepa Dinamani @ 2019-11-10 20:44 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: y2038 Mailman List, John Stultz, Thomas Gleixner,
	Linux Kernel Mailing List, # 3.4.x, alpha,
	Linux Network Devel Mailing List, Stephen Boyd

Thanks for fixing the bug.

Acked-by: Deepa Dinamani <deepa.kernel@gmail.com>

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [PATCH 5/8] netfilter: xt_time: use time64_t
  2019-11-08 20:34 ` [PATCH 5/8] netfilter: xt_time: use time64_t Arnd Bergmann
@ 2019-11-15 22:43   ` Pablo Neira Ayuso
  0 siblings, 0 replies; 5+ messages in thread
From: Pablo Neira Ayuso @ 2019-11-15 22:43 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: y2038, Jozsef Kadlecsik, Florian Westphal, David S. Miller,
	linux-kernel, Eric Dumazet, netfilter-devel, coreteam, netdev

On Fri, Nov 08, 2019 at 09:34:28PM +0100, Arnd Bergmann wrote:
> The current xt_time driver suffers from the y2038 overflow on 32-bit
> architectures, when the time of day calculations break.
> 
> Also, on both 32-bit and 64-bit architectures, there is a problem with
> info->date_start/stop, which is part of the user ABI and overflows in
> in 2106.
> 
> Fix the first issue by using time64_t and explicit calls to div_u64()
> and div_u64_rem(), and document the seconds issue.
> 
> The explicit 64-bit division is unfortunately slower on 32-bit
> architectures, but doing it as unsigned lets us use the optimized
> division-through-multiplication path in most configurations.  This should
> be fine, as the code already does not allow any negative time of day
> values.
> 
> Using u32 seconds values consistently would probably also work and
> be a little more efficient, but that doesn't feel right as it would
> propagate the y2106 overflow to more place rather than fewer.

Applied, thanks.

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2019-11-15 22:44 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-11-08 20:34 [PATCH 0/8] y2038: bug fixes from y2038 work Arnd Bergmann
2019-11-08 20:34 ` [PATCH 1/8] y2038: timex: remove incorrect time_t truncation Arnd Bergmann
2019-11-10 20:44   ` Deepa Dinamani
2019-11-08 20:34 ` [PATCH 5/8] netfilter: xt_time: use time64_t Arnd Bergmann
2019-11-15 22:43   ` Pablo Neira Ayuso

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).