Hi everyone,
This is a set of changes for network drivers and core code to
get rid of the use of time_t and derived data structures.
I have a longer set of patches that enables me to build kernels
with the time_t definition removed completely as a help to find
y2038 overflow issues. This is the subset for networking that
contains all code that has a reasonable way of fixing at the
moment and that is either commonly used (in one of the defconfigs)
or that blocks building a whole subsystem.
Most of the patches in this series should be noncontroversial,
but the last two that I marked [RFC] are a bit tricky and
need input from people that are more familiar with the code than
I am. All 12 patches are independent of one another and can
be applied in any order, so feel free to pick all that look
good.
Patches that are not included here are:
- disabling less common device drivers that I don't have a fix
for yet, this includes
drivers/net/ethernet/brocade/bna/bfa_ioc.c
drivers/net/ethernet/qlogic/netxen/netxen_nic_hw.c
drivers/net/ethernet/tile/tilegx.c
drivers/net/hamradio/baycom_ser_fdx.c
drivers/net/wireless/ath/ath10k/core.h
drivers/net/wireless/ath/ath9k/
drivers/net/wireless/ath/ath9k/
drivers/net/wireless/atmel.c
drivers/net/wireless/prism54/isl_38xx.c
drivers/net/wireless/rt2x00/rt2x00debug.c
drivers/net/wireless/rtlwifi/
drivers/net/wireless/ti/wlcore/
drivers/staging/ozwpan/
net/atm/mpoa_caches.c
net/atm/mpoa_proc.c
net/dccp/probe.c
net/ipv4/tcp_probe.c
net/netfilter/nfnetlink_queue_core.c
net/netfilter/nfnetlink_queue_core.c
net/netfilter/xt_time.c
net/openvswitch/flow.c
net/sctp/probe.c
net/sunrpc/auth_gss/
net/sunrpc/svcauth_unix.c
net/vmw_vsock/af_vsock.c
We'll get there eventually, or we an add a dependency to ensure
they are not built on 32-bit kernels that need to survive
beyond 2038. Most of these should be really easy to fix.
- recvmmsg/sendmmsg system calls: patches have been sent out
as part of the syscall series, need a little more work and
review
- SIOCGSTAMP/SIOCGSTAMPNS/ ioctl calls: tricky, need to discuss
with some folks at kernel summit
- SO_RCVTIMEO/SO_SNDTIMEO/SO_TIMESTAMP/SO_TIMESTAMPNS socket
opt: similar and related to the ioctl
- mmapped packet socket: need to create v4 of the API, nontrivial
- pktgen: sends 32-bit timestamps over network, need to find out
if using unsigned stamps is good enough
- af_rxpc: similar to pktgen, uses 32-bit times for deadlines
- ppp ioctl: patch is being worked on, nontrivial but doable
Arnd
Arnd Bergmann (12):
net: fec: avoid timespec use
net: stmmac: avoid using timespec
net: igb: avoid using timespec
mwifiex: use ktime_get_real for timestamping
mwifiex: avoid gettimeofday in ba_threshold setting
mac80211: use ktime_get_seconds
atm: hide 'struct zatm_t_hist'
nfnetlink: use y2038 safe timestamp
ipv6: use ktime_t for internal timestamps
net: sctp: avoid incorrect time_t use
[RFC] ipv4: avoid timespec in timestamp computation
[RFC] can: avoid using timeval for uapi
drivers/net/ethernet/freescale/fec_ptp.c | 6 ++--
drivers/net/ethernet/intel/igb/igb.h | 4 +--
drivers/net/ethernet/intel/igb/igb_main.c | 15 +++++-----
drivers/net/ethernet/intel/igb/igb_ptp.c | 8 +++---
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 8 ++++--
drivers/net/wireless/mwifiex/11n_aggr.c | 4 +--
drivers/net/wireless/mwifiex/wmm.c | 15 +++-------
include/linux/timekeeping.h | 2 ++
include/uapi/linux/atm_zatm.h | 3 +-
include/uapi/linux/can/bcm.h | 7 ++++-
kernel/time/timekeeping.c | 34 +++++++++++++++++++++++
net/can/bcm.c | 15 ++++++----
net/ipv4/icmp.c | 8 ++----
net/ipv4/ip_options.c | 9 ++----
net/ipv6/mip6.c | 16 +++++------
net/mac80211/sta_info.c | 8 ++----
net/netfilter/nfnetlink_log.c | 6 ++--
net/sctp/sm_make_chunk.c | 2 +-
net/sctp/sm_statefuns.c | 2 +-
19 files changed, 99 insertions(+), 73 deletions(-)
Cc: coreteam@netfilter.org
Cc: intel-wired-lan@lists.osuosl.org
Cc: linux-api@vger.kernel.org
Cc: linux-atm-general@lists.sourceforge.net
Cc: linux-can@vger.kernel.org
Cc: linux-sctp@vger.kernel.org
Cc: linux-wireless@vger.kernel.org
Cc: netfilter-devel@vger.kernel.org
--
2.1.0.rc2
_______________________________________________
Y2038 mailing list
Y2038@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/y2038
The fec_ptp_enable_pps uses an open-coded implementation of ns_to_timespec,
which will be removed eventually as it is not y2038-safe on 32-bit
architectures. Two more instances of the same code in this file were
already converted to use the safe ns_to_timespec64 in commit 6630514fcee
("ptp: fec: use helpers for converting ns to timespec"), this changes
the last one as well.
The seconds portion here is actually unused and we could just remove the
timespec variable, but using ns_to_timespec64 can still be better as the
implementation can be hand-optimized in the future.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Richard Cochran <richardcochran@gmail.com>
Cc: Fugang Duan <redacted>
Cc: Luwei Zhou <redacted>
Cc: Frank Li <redacted>
---
drivers/net/ethernet/freescale/fec_ptp.c | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)
@@ -163,8 +162,7 @@ static int fec_ptp_enable_pps(struct fec_enet_private *fep, uint enable)tempval=readl(fep->hwp+FEC_ATIME);/* Convert the ptp local counter to 1588 timestamp */ns=timecounter_cyc2time(&fep->tc,tempval);-ts.tv_sec=div_u64_rem(ns,1000000000ULL,&remainder);-ts.tv_nsec=remainder;+ts=ns_to_timespec64(ns);/* The tempval is less than 3 seconds, and so val is less than*4seconds.Nooverflowfor32bitcalculation.
The __build_packet_message function fills a nfulnl_msg_packet_timestamp
structure that uses 64-bit seconds and is therefore y2038 safe, but
it uses an intermediate 'struct timespec' which is not.
This trivially changes the code to use 'struct timespec64' instead,
to correct the result on 32-bit architectures.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Pablo Neira Ayuso <pablo@netfilter.org>
Cc: Patrick McHardy <redacted>
Cc: Jozsef Kadlecsik <redacted>
Cc: netfilter-devel@vger.kernel.org
Cc: coreteam@netfilter.org
---
net/netfilter/nfnetlink_log.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
The ipv6 mip6 implementation is one of only a few users of the
skb_get_timestamp() function in the kernel, which is both unsafe
on 32-bit architectures because of the 2038 overflow, and slightly
less efficient than the skb_get_ktime() based approach.
This converts the function call and the mip6_report_rate_limiter
structure that stores the time stamp, eliminating all uses of
timeval in the ipv6 code.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Alexey Kuznetsov <redacted>
Cc: James Morris <jmorris@namei.org>
Cc: Hideaki YOSHIFUJI <redacted>
Cc: Patrick McHardy <redacted>
---
net/ipv6/mip6.c | 16 +++++++---------
1 file changed, 7 insertions(+), 9 deletions(-)
This is an attempt to avoid the use of timespec in ipv4, where
getnstimeofday() used to be used for computing the number of
milliseconds since midnight, in three places.
That computation would overflow in 2038 on 32-bit machines,
and the normal workaround for this is to use timespec64, which
in turn requires an expensive div_s64_mod() function call
for calculating the seconds modulo 86400.
Instead, this approach introduces a new generic helper function
that does this more efficiently, by using only a 32-bit modulo
(which the compiler can turn into two multiplications), relying
on 39 bits to be sufficient for the current time of day. This
is roughly 100 times faster than a full divmod operation on ARM.
As a further optimization, this does not use the exact nanosecond
value but instead relies tk_xtime() to report the time of the
last jiffy, which is slightly less accurate, depending on the
value of HZ.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Alexey Kuznetsov <redacted>
Cc: James Morris <jmorris@namei.org>
Cc: Hideaki YOSHIFUJI <redacted>
Cc: Patrick McHardy <redacted>
Cc: John Stultz <redacted>
Cc: Thomas Gleixner <redacted>
---
include/linux/timekeeping.h | 2 ++
kernel/time/timekeeping.c | 34 ++++++++++++++++++++++++++++++++++
net/ipv4/icmp.c | 8 +++-----
net/ipv4/ip_options.c | 9 ++-------
4 files changed, 41 insertions(+), 12 deletions(-)
@@ -846,6 +846,40 @@ time64_t ktime_get_real_seconds(void)}EXPORT_SYMBOL_GPL(ktime_get_real_seconds);+#if IS_ENABLED(CONFIG_INET)+u32ktime_get_ms_of_day(void)+{+structtimekeeper*tk=&tk_core.timekeeper;+structtimespec64now;+unsignedlongseq;+u32ms;++/* we assume that the coarse time is good enough here */+do{+seq=read_seqcount_begin(&tk_core.seq);++now=tk_xtime(tk);+}while(read_seqcount_retry(&tk_core.seq,seq));++/*+*efficientlycalculatethemillisecondssincemidnight:+*86400secondsperday==2^7*675,whichhelpsus+*replaceanexpensivediv_s64_rem()withahand-written+*39-bitmoduloon32-bitarchitectures.+*/+if(!IS_ENABLED(CONFIG_64BIT))+ms=(now.tv_sec&0x7f)*MSEC_PER_SEC++((u32)(now.tv_sec>>7)%675)*0x80*MSEC_PER_SEC;+else+ms=(now.tv_sec%86400)*MSEC_PER_SEC;++ms+=now.tv_nsec/NSEC_PER_MSEC;++returnms;+}+EXPORT_SYMBOL_GPL(ktime_get_ms_since_midnight);+#endif+#ifdef CONFIG_NTP_PPS/**
@@ -415,10 +413,7 @@ int ip_options_compile(struct net *net,break;}if(timeptr){-structtimespectv;-u32midtime;-getnstimeofday(&tv);-midtime=(tv.tv_sec%86400)*MSEC_PER_SEC+tv.tv_nsec/NSEC_PER_MSEC;+u32midtime=ktime_get_ms_since_midnight();put_unaligned_be32(midtime,timeptr);opt->is_changed=1;}
The can subsystem communicates with user space using a bcm_msg_head
header, which contains two timestamps. This is problematic for
multiple reasons:
a) The structure layout is currently incompatible between 64-bit
user space and 32-bit user space, and cannot work in compat
mode (other than x32).
b) The timeval structure layout will change in 32-bit user
space when we fix the y2038 overflow problem by redefining
time_t to 64-bit, making new 32-bit user space incompatible
with the current kernel interface.
Cars last a long time and often use old kernels, so the actual
users of this code are the most likely ones to migrate to y2038
safe user space.
This tries to work around part of the problem by changing the
publicly visible user interface in the header, but not the binary
interface. Fortunately, the values passed around in the structure
are relative times and do not actually suffer from the y2038
overflow, so 32-bit is enough here.
We replace the use of 'struct timeval' with a newly defined
'struct bcm_timeval' that uses the exact same binary layout
as before and that still suffers from problem a) but not problem
b).
The downside of this approach is that any user space program
that currently assigns a timeval structure to these members
rather than writing the tv_sec/tv_usec portions individually
will suffer a compile-time error when built with an updated
kernel header. Fixing this error makes it work fine with old
and new headers though.
We could address problem a) by using '__u32' or 'int' members
rather than 'long', but that would have a more significant
downside in also breaking support for all existing 64-bit user
binaries that might be using this interface, which is likely
not acceptable.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Oliver Hartkopp <socketcan@hartkopp.net>
Cc: Marc Kleine-Budde <mkl@pengutronix.de>
Cc: linux-can@vger.kernel.org
Cc: linux-api@vger.kernel.org
---
include/uapi/linux/can/bcm.h | 7 ++++++-
net/can/bcm.c | 15 ++++++++++-----
2 files changed, 16 insertions(+), 6 deletions(-)
@@ -953,8 +958,8 @@ static int bcm_tx_setup(struct bcm_msg_head *msg_head, struct msghdr *msg,op->count=msg_head->count;op->ival1=msg_head->ival1;op->ival2=msg_head->ival2;-op->kt_ival1=timeval_to_ktime(msg_head->ival1);-op->kt_ival2=timeval_to_ktime(msg_head->ival2);+op->kt_ival1=bcm_timeval_to_ktime(msg_head->ival1);+op->kt_ival2=bcm_timeval_to_ktime(msg_head->ival2);/* disable an active timer due to zero values? */if(!op->kt_ival1.tv64&&!op->kt_ival2.tv64)
@@ -1134,8 +1139,8 @@ static int bcm_rx_setup(struct bcm_msg_head *msg_head, struct msghdr *msg,/* set timer value */op->ival1=msg_head->ival1;op->ival2=msg_head->ival2;-op->kt_ival1=timeval_to_ktime(msg_head->ival1);-op->kt_ival2=timeval_to_ktime(msg_head->ival2);+op->kt_ival1=bcm_timeval_to_ktime(msg_head->ival1);+op->kt_ival2=bcm_timeval_to_ktime(msg_head->ival2);/* disable an active timer due to zero value? */if(!op->kt_ival1.tv64)
--
2.1.0.rc2
_______________________________________________
Y2038 mailing list
Y2038@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/y2038
We want to avoid using time_t in the kernel because of the y2038
overflow problem. The use in sctp is not for storing seconds at
all, but instead uses microseconds and is passed as 32-bit
on all machines.
This patch changes the type to u32, which better fits the use.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Vlad Yasevich <redacted>
Cc: Neil Horman <nhorman@tuxdriver.com>
Cc: linux-sctp@vger.kernel.org
---
net/sctp/sm_make_chunk.c | 2 +-
net/sctp/sm_statefuns.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
The zatm_t_hist structure is not used anywhere in the kernel, but is
exported to user space. As we are trying to eliminate uses of time_t
in the kernel for y2038 compatibility, the current definition triggers
checking tools because it contains 'struct timeval'.
We can work around this by adding '#ifdef __KERNEL__'. I could not find
out what the structure is actually used for, so this is the safe choice
in case there is some user space tool that relies on the definition.
If we are sure that nothing in user space relies on the structure, we
can instead remove the definition completely.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Chas Williams <3chas3@gmail.com>
Cc: linux-atm-general@lists.sourceforge.net
---
include/uapi/linux/atm_zatm.h | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
@@ -35,11 +35,12 @@ struct zatm_pool_req {structzatm_pool_infoinfo;/* actual information */};+#ifndef __KERNEL__structzatm_t_hist{structtimevalreal;/* real (wall-clock) time */structtimevalexpected;/* expected real time */};-+#endif#define ZATM_OAM_POOL 0 /* free buffer pool for OAM cells */#define ZATM_AAL0_POOL 1 /* free buffer pool for AAL0 cells */
--
2.1.0.rc2
_______________________________________________
Y2038 mailing list
Y2038@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/y2038
The mwifiex_11n_aggregate_pkt() function creates a ktime_t from
a timeval returned by do_gettimeofday, which is slow and causes
an overflow in 2038 on 32-bit architectures.
This solves both problems by using the appropriate ktime_get_real()
function.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Amitkumar Karwar <redacted>
Cc: Nishant Sarmukadam <redacted>
Cc: Kalle Valo <redacted>
Cc: linux-wireless@vger.kernel.org
---
drivers/net/wireless/mwifiex/11n_aggr.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
@@ -203,8 +202,7 @@ mwifiex_11n_aggregate_pkt(struct mwifiex_private *priv,tx_info_aggr->flags|=MWIFIEX_BUF_FLAG_AGGR_PKT;skb_aggr->priority=skb_src->priority;-do_gettimeofday(&tv);-skb_aggr->tstamp=timeval_to_ktime(tv);+skb_aggr->tstamp=ktime_get_real();do{/* Check if AMSDU can accommodate this MSDU */
--
2.1.0.rc2
_______________________________________________
Y2038 mailing list
Y2038@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/y2038
mwifiex_get_random_ba_threshold() uses a complex homegrown implementation
to generate a pseudo-random number from the current time as returned
from do_gettimeofday().
This currently requires two 32-bit divisions plus a couple of other
computations that are eventually discarded as only eight bits of
the microsecond portion are used at all.
We could replace this with a call to get_random_bytes(), but that
might drain the entropy pool too fast if this is called for each
packet.
Instead, this patch converts it to use ktime_get_ns(), which is a
bit faster than do_gettimeofday(), and then uses a similar algorithm
as before, but in a way that takes both the nanosecond and second
portion into account for slightly-more-but-still-not-very-random
pseudorandom number.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Amitkumar Karwar <redacted>
Cc: Nishant Sarmukadam <redacted>
Cc: Kalle Valo <redacted>
Cc: linux-wireless@vger.kernel.org
---
drivers/net/wireless/mwifiex/wmm.c | 15 ++++-----------
1 file changed, 4 insertions(+), 11 deletions(-)
We want to deprecate the use of 'struct timespec' on 32-bit
architectures, as it is will overflow in 2038. The stmmac
driver uses it to read the current time, and can simply
be changed to use ktime_get_real_ts64() instead.
Because of hardware limitations, there is still an overflow
in year 2106, which we cannot really avoid, but this documents
the overflow.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Giuseppe Cavallaro <redacted>
Cc: Richard Cochran <richardcochran@gmail.com>
---
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 8 +++++---
1 file changed, 5 insertions(+), 3 deletions(-)
@@ -621,8 +621,10 @@ static int stmmac_hwtstamp_ioctl(struct net_device *dev, struct ifreq *ifr)priv->default_addend);/* initialize system time */-getnstimeofday(&now);-priv->hw->ptp->init_systime(priv->ioaddr,now.tv_sec,+ktime_get_real_ts64(&now);++/* lower 32 bits of tv_sec are safe until y2106 */+priv->hw->ptp->init_systime(priv->ioaddr,(u32)now.tv_sec,now.tv_nsec);}
--
2.1.0.rc2
_______________________________________________
Y2038 mailing list
Y2038@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/y2038
We want to deprecate the use of 'struct timespec' on 32-bit
architectures, as it is will overflow in 2038. The igb
driver uses it to read the current time, and can simply
be changed to use ktime_get_real_ts64() instead.
Because of hardware limitations, there is still an overflow
in year 2106, which we cannot really avoid, but this documents
the overflow.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Jeff Kirsher <redacted>
Cc: intel-wired-lan@lists.osuosl.org
---
drivers/net/ethernet/intel/igb/igb.h | 4 ++--
drivers/net/ethernet/intel/igb/igb_main.c | 15 ++++++++-------
drivers/net/ethernet/intel/igb/igb_ptp.c | 8 ++++----
3 files changed, 14 insertions(+), 13 deletions(-)
The mac80211 code uses ktime_get_ts to measure the connected time.
As this uses monotonic time, it is y2038 safe on 32-bit systems,
but we still want to deprecate the use of 'timespec' because most
other users are broken.
This changes the code to use ktime_get_seconds() instead, which
avoids the timespec structure and is slightly more efficient.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Johannes Berg <johannes@sipsolutions.net>
Cc: linux-wireless@vger.kernel.org
---
net/mac80211/sta_info.c | 8 ++------
1 file changed, 2 insertions(+), 6 deletions(-)
@@ -339,8 +338,7 @@ struct sta_info *sta_info_alloc(struct ieee80211_sub_if_data *sdata,/* Mark TID as unreserved */sta->reserved_tid=IEEE80211_TID_UNRESERVED;-ktime_get_ts(&uptime);-sta->last_connected=uptime.tv_sec;+sta->last_connected=ktime_get_seconds();ewma_signal_init(&sta->avg_signal);for(i=0;i<ARRAY_SIZE(sta->chain_signal_avg);i++)ewma_signal_init(&sta->chain_signal_avg[i]);
From: kbuild test robot <hidden> Date: 2015-09-30 11:56:40
Hi Arnd,
[auto build test results on v4.3-rc3 -- if it's inappropriate base, please ignore]
config: mn10300-asb2364_defconfig (attached as .config)
reproduce:
wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout e1358094d427405462a47d6d2650458b689e55d9
# save the attached .config to linux build tree
make.cross ARCH=mn10300
All error/warnings (new ones prefixed by >>):
am33_2.0-linux-ld: Dwarf Error: mangled line number section.
am33_2.0-linux-ld: Dwarf Error: mangled line number section.
kernel/built-in.o: In function `current_thread_info':
(___ksymtab_gpl+ktime_get_ms_since_midnight+0x0): undefined reference to `ktime_get_ms_since_midnight'
am33_2.0-linux-ld: Dwarf Error: mangled line number section.
am33_2.0-linux-ld: Dwarf Error: mangled line number section.
am33_2.0-linux-ld: Dwarf Error: mangled line number section.
am33_2.0-linux-ld: Dwarf Error: mangled line number section.
am33_2.0-linux-ld: Dwarf Error: mangled line number section.
am33_2.0-linux-ld: Dwarf Error: mangled line number section.
am33_2.0-linux-ld: Dwarf Error: mangled line number section.
am33_2.0-linux-ld: Dwarf Error: mangled line number section.
am33_2.0-linux-ld: Dwarf Error: mangled line number section.
net/built-in.o: In function `register_netevent_notifier':
quoted
net/core/netevent.c:29: undefined reference to `ktime_get_ms_since_midnight'
net/core/netevent.c:29: undefined reference to `ktime_get_ms_since_midnight'
net/core/netevent.c:17: undefined reference to `ktime_get_ms_since_midnight'
vim +29 net/core/netevent.c
792d1932 Tom Tucker 2006-07-30 23 /**
792d1932 Tom Tucker 2006-07-30 24 * register_netevent_notifier - register a netevent notifier block
792d1932 Tom Tucker 2006-07-30 25 * @nb: notifier
792d1932 Tom Tucker 2006-07-30 26 *
792d1932 Tom Tucker 2006-07-30 27 * Register a notifier to be called when a netevent occurs.
792d1932 Tom Tucker 2006-07-30 28 * The notifier passed is linked into the kernel structures and must
792d1932 Tom Tucker 2006-07-30 @29 * not be reused until it has been unregistered. A negative errno code
792d1932 Tom Tucker 2006-07-30 30 * is returned on a failure.
792d1932 Tom Tucker 2006-07-30 31 */
792d1932 Tom Tucker 2006-07-30 32 int register_netevent_notifier(struct notifier_block *nb)
:::::: The code at line 29 was first introduced by commit
:::::: 792d1932e319ff8ba01361e7d151b1794c55c31f [NET]: Network Event Notifier Mechanism.
:::::: TO: Tom Tucker [off-list ref]
:::::: CC: David S. Miller [off-list ref]
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
From: kbuild test robot <hidden> Date: 2015-09-30 12:17:56
Hi Arnd,
[auto build test results on v4.3-rc3 -- if it's inappropriate base, please ignore]
reproduce:
# apt-get install sparse
make ARCH=x86_64 allmodconfig
make C=1 CF=-D__CHECK_ENDIAN__
sparse warnings: (new ones prefixed by >>)
quoted
kernel/time/timekeeping.c:850:5: sparse: symbol 'ktime_get_ms_of_day' was not declared. Should it be static?
On Wednesday 30 September 2015 19:55:43 kbuild test robot wrote:
Hi Arnd,
[auto build test results on v4.3-rc3 -- if it's inappropriate base, please ignore]
config: mn10300-asb2364_defconfig (attached as .config)
reproduce:
wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout e1358094d427405462a47d6d2650458b689e55d9
# save the attached .config to linux build tree
make.cross ARCH=mn10300
All error/warnings (new ones prefixed by >>):
am33_2.0-linux-ld: Dwarf Error: mangled line number section.
am33_2.0-linux-ld: Dwarf Error: mangled line number section.
kernel/built-in.o: In function `current_thread_info':
(___ksymtab_gpl+ktime_get_ms_since_midnight+0x0): undefined reference to `ktime_get_ms_since_midnight'
am33_2.0-linux-ld: Dwarf Error: mangled line number section.
am33_2.0-linux-ld: Dwarf Error: mangled line number section.
am33_2.0-linux-ld: Dwarf Error: mangled line number section.
am33_2.0-linux-ld: Dwarf Error: mangled line number section.
am33_2.0-linux-ld: Dwarf Error: mangled line number section.
am33_2.0-linux-ld: Dwarf Error: mangled line number section.
am33_2.0-linux-ld: Dwarf Error: mangled line number section.
am33_2.0-linux-ld: Dwarf Error: mangled line number section.
am33_2.0-linux-ld: Dwarf Error: mangled line number section.
net/built-in.o: In function `register_netevent_notifier':
quoted
quoted
net/core/netevent.c:29: undefined reference to `ktime_get_ms_since_midnight'
net/core/netevent.c:29: undefined reference to `ktime_get_ms_since_midnight'
net/core/netevent.c:17: undefined reference to `ktime_get_ms_since_midnight'
Thanks for the helpful report, I love the new feature of grabbing the patches
from the list.
Moreover, sorry for screwing up here, I changed the function name before
sending it out and only compiled the files individually but did not notice
that I only changed it in three out of four places because I did not
try to relink the kernel.
I'll send an updated version.
Arnd
This is an attempt to avoid the use of timespec in ipv4, where
getnstimeofday() used to be used for computing the number of
milliseconds since midnight, in three places.
That computation would overflow in 2038 on 32-bit machines,
and the normal workaround for this is to use timespec64, which
in turn requires an expensive div_s64_mod() function call
for calculating the seconds modulo 86400.
Instead, this approach introduces a new generic helper function
that does this more efficiently, by using only a 32-bit modulo
(which the compiler can turn into two multiplications), relying
on 39 bits to be sufficient for the current time of day. This
is roughly 100 times faster than a full divmod operation on ARM.
As a further optimization, this does not use the exact nanosecond
value but instead relies tk_xtime() to report the time of the
last jiffy, which is slightly less accurate, depending on the
value of HZ.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Alexey Kuznetsov <redacted>
Cc: James Morris <jmorris@namei.org>
Cc: Hideaki YOSHIFUJI <redacted>
Cc: Patrick McHardy <redacted>
Cc: John Stultz <redacted>
Cc: Thomas Gleixner <redacted>
---
v2: fixed build error reported by lkp@intel.com
@@ -846,6 +846,40 @@ time64_t ktime_get_real_seconds(void)}EXPORT_SYMBOL_GPL(ktime_get_real_seconds);+#if IS_ENABLED(CONFIG_INET)+u32ktime_get_ms_since_midnight(void)+{+structtimekeeper*tk=&tk_core.timekeeper;+structtimespec64now;+unsignedlongseq;+u32ms;++/* we assume that the coarse time is good enough here */+do{+seq=read_seqcount_begin(&tk_core.seq);++now=tk_xtime(tk);+}while(read_seqcount_retry(&tk_core.seq,seq));++/*+*efficientlycalculatethemillisecondssincemidnight:+*86400secondsperday==2^7*675,whichhelpsus+*replaceanexpensivediv_s64_rem()withahand-written+*39-bitmoduloon32-bitarchitectures.+*/+if(!IS_ENABLED(CONFIG_64BIT))+ms=(now.tv_sec&0x7f)*MSEC_PER_SEC++((u32)(now.tv_sec>>7)%675)*0x80*MSEC_PER_SEC;+else+ms=(now.tv_sec%86400)*MSEC_PER_SEC;++ms+=now.tv_nsec/NSEC_PER_MSEC;++returnms;+}+EXPORT_SYMBOL_GPL(ktime_get_ms_since_midnight);+#endif+#ifdef CONFIG_NTP_PPS/**
@@ -415,10 +413,7 @@ int ip_options_compile(struct net *net,break;}if(timeptr){-structtimespectv;-u32midtime;-getnstimeofday(&tv);-midtime=(tv.tv_sec%86400)*MSEC_PER_SEC+tv.tv_nsec/NSEC_PER_MSEC;+u32midtime=ktime_get_ms_since_midnight();put_unaligned_be32(midtime,timeptr);opt->is_changed=1;}
From: Neil Horman <nhorman@tuxdriver.com> Date: 2015-09-30 13:57:54
On Wed, Sep 30, 2015 at 01:26:40PM +0200, Arnd Bergmann wrote:
quoted hunk
We want to avoid using time_t in the kernel because of the y2038
overflow problem. The use in sctp is not for storing seconds at
all, but instead uses microseconds and is passed as 32-bit
on all machines.
This patch changes the type to u32, which better fits the use.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Vlad Yasevich <redacted>
Cc: Neil Horman <nhorman@tuxdriver.com>
Cc: linux-sctp@vger.kernel.org
---
net/sctp/sm_make_chunk.c | 2 +-
net/sctp/sm_statefuns.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
On Wed, Sep 30, 2015 at 09:57:31AM -0400, Neil Horman wrote:
On Wed, Sep 30, 2015 at 01:26:40PM +0200, Arnd Bergmann wrote:
quoted
We want to avoid using time_t in the kernel because of the y2038
overflow problem. The use in sctp is not for storing seconds at
all, but instead uses microseconds and is passed as 32-bit
on all machines.
This patch changes the type to u32, which better fits the use.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Vlad Yasevich <redacted>
Cc: Neil Horman <nhorman@tuxdriver.com>
Cc: linux-sctp@vger.kernel.org
---
net/sctp/sm_make_chunk.c | 2 +-
net/sctp/sm_statefuns.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
From: Neil Horman <nhorman@tuxdriver.com> Date: 2015-09-30 14:19:48
On Wed, Sep 30, 2015 at 11:15:20AM -0300, Marcelo Ricardo Leitner wrote:
On Wed, Sep 30, 2015 at 09:57:31AM -0400, Neil Horman wrote:
quoted
On Wed, Sep 30, 2015 at 01:26:40PM +0200, Arnd Bergmann wrote:
quoted
We want to avoid using time_t in the kernel because of the y2038
overflow problem. The use in sctp is not for storing seconds at
all, but instead uses microseconds and is passed as 32-bit
on all machines.
This patch changes the type to u32, which better fits the use.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Vlad Yasevich <redacted>
Cc: Neil Horman <nhorman@tuxdriver.com>
Cc: linux-sctp@vger.kernel.org
---
net/sctp/sm_make_chunk.c | 2 +-
net/sctp/sm_statefuns.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
@@ -2306,7 +2306,7 @@ static sctp_disposition_t sctp_sf_do_5_2_6_stale(struct net *net,sctp_cmd_seq_t*commands){structsctp_chunk*chunk=arg;-time_tstale;+u32stale;sctp_cookie_preserve_param_tbht;sctp_errhdr_t*err;structsctp_chunk*reply;
--
2.1.0.rc2
Assignments to this variable use ntohl, won't this change risk overflow?
Neil
But isn't ntohl always 4 bytes long?
Oh, you might be right. I was thinking it was 8, but I'm wrong
Acked-by: Neil Horman <nhorman@tuxdriver.com>
Marcelo
--
To unsubscribe from this list: send the line "unsubscribe linux-sctp" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, Sep 30, 2015 at 01:26:40PM +0200, Arnd Bergmann wrote:
We want to avoid using time_t in the kernel because of the y2038
overflow problem. The use in sctp is not for storing seconds at
all, but instead uses microseconds and is passed as 32-bit
on all machines.
This patch changes the type to u32, which better fits the use.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Vlad Yasevich <redacted>
Cc: Neil Horman <nhorman@tuxdriver.com>
Cc: linux-sctp@vger.kernel.org
@@ -2306,7 +2306,7 @@ static sctp_disposition_t sctp_sf_do_5_2_6_stale(struct net *net,sctp_cmd_seq_t*commands){structsctp_chunk*chunk=arg;-time_tstale;+u32stale;sctp_cookie_preserve_param_tbht;sctp_errhdr_t*err;structsctp_chunk*reply;
--
2.1.0.rc2
--
To unsubscribe from this list: send the line "unsubscribe linux-sctp" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, 2015-09-30 at 13:26 +0200, Arnd Bergmann wrote:
The zatm_t_hist structure is not used anywhere in the kernel, but is
exported to user space. As we are trying to eliminate uses of time_t
in the kernel for y2038 compatibility, the current definition triggers
checking tools because it contains 'struct timeval'.
We can work around this by adding '#ifdef __KERNEL__'. I could not find
out what the structure is actually used for, so this is the safe choice
in case there is some user space tool that relies on the definition.
If we are sure that nothing in user space relies on the structure, we
can instead remove the definition completely.
It was used by the ZATM_GETHIST ioctl which is long since gone in the
kernel driver. You can just remove this.
On Wednesday 30 September 2015 11:24:35 Charles Williams wrote:
On Wed, 2015-09-30 at 13:26 +0200, Arnd Bergmann wrote:
quoted
The zatm_t_hist structure is not used anywhere in the kernel, but is
exported to user space. As we are trying to eliminate uses of time_t
in the kernel for y2038 compatibility, the current definition triggers
checking tools because it contains 'struct timeval'.
We can work around this by adding '#ifdef __KERNEL__'. I could not find
out what the structure is actually used for, so this is the safe choice
in case there is some user space tool that relies on the definition.
If we are sure that nothing in user space relies on the structure, we
can instead remove the definition completely.
It was used by the ZATM_GETHIST ioctl which is long since gone in the
kernel driver. You can just remove this.
Perfect, I've updated the patch accordingly, see follow-up mail
Thanks,
Arnd
_______________________________________________
Y2038 mailing list
Y2038@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/y2038
The zatm_t_hist structure is not used anywhere in the kernel, but is
exported to user space. As we are trying to eliminate uses of time_t
in the kernel for y2038 compatibility, the current definition triggers
checking tools because it contains 'struct timeval'.
As pointed out by Chas Williams, the only user of this structure was
the ZATM_GETHIST ioctl command that has been removed a long time ago,
and we can remove the structure as well without breaking any user
space.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Chas Williams <3chas3@gmail.com>
Cc: linux-atm-general@lists.sourceforge.net
@@ -35,12 +35,6 @@ struct zatm_pool_req {structzatm_pool_infoinfo;/* actual information */};-structzatm_t_hist{-structtimevalreal;/* real (wall-clock) time */-structtimevalexpected;/* expected real time */-};--#define ZATM_OAM_POOL 0 /* free buffer pool for OAM cells */#define ZATM_AAL0_POOL 1 /* free buffer pool for AAL0 cells */#define ZATM_AAL5_POOL_BASE 2 /* first AAL5 free buffer pool */
From: Richard Cochran <richardcochran@gmail.com> Date: 2015-10-01 19:08:16
On Wed, Sep 30, 2015 at 01:26:31PM +0200, Arnd Bergmann wrote:
The fec_ptp_enable_pps uses an open-coded implementation of ns_to_timespec,
which will be removed eventually as it is not y2038-safe on 32-bit
architectures. Two more instances of the same code in this file were
already converted to use the safe ns_to_timespec64 in commit 6630514fcee
("ptp: fec: use helpers for converting ns to timespec"), this changes
the last one as well.
The seconds portion here is actually unused and we could just remove the
timespec variable, but using ns_to_timespec64 can still be better as the
implementation can be hand-optimized in the future.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Richard Cochran <richardcochran@gmail.com>
From: Richard Cochran <richardcochran@gmail.com> Date: 2015-10-01 19:08:38
On Wed, Sep 30, 2015 at 01:26:32PM +0200, Arnd Bergmann wrote:
We want to deprecate the use of 'struct timespec' on 32-bit
architectures, as it is will overflow in 2038. The stmmac
driver uses it to read the current time, and can simply
be changed to use ktime_get_real_ts64() instead.
Because of hardware limitations, there is still an overflow
in year 2106, which we cannot really avoid, but this documents
the overflow.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Richard Cochran <richardcochran@gmail.com>
From: Richard Cochran <richardcochran@gmail.com> Date: 2015-10-01 19:17:53
Arnd
As author of these snippets, I went ahead and reviewed. I have one
comment, below.
Reviewed-by: Richard Cochran <richardcochran@gmail.com>
On Wed, Sep 30, 2015 at 01:26:33PM +0200, Arnd Bergmann wrote:
This cast is unnecessary, because wr32 is writel, and that parameter
is a u32.
I tried to use this pattern whenever I convert the 64-bit 'long long'
tv_sec member of 'struct timespec64' into a 32-bit number, to annotate
the loss of range.
I have thought about defining separate helpers like this
/* result will overflow in 2038 for real time */
static inline s32 time64_to_s32_y2038(time64_t time)
{
return time;
}
/* result will overflow in 2106 for real time */
static inline u32 time64_to_u32_y2106(time64_t time)
{
return time;
}
/* monotonic times can safely be represented as 32 bit */
static inline s32 time64_to_s32_monotonic(time64_t time)
{
return time;
}
This would make it even more explicit, but my fear was that I was
adding too much complexity like that.
Arnd
_______________________________________________
Y2038 mailing list
Y2038@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/y2038
From: Richard Cochran <richardcochran@gmail.com> Date: 2015-10-02 07:47:27
On Thu, Oct 01, 2015 at 10:01:57PM +0200, Arnd Bergmann wrote:
I tried to use this pattern whenever I convert the 64-bit 'long long'
tv_sec member of 'struct timespec64' into a 32-bit number, to annotate
the loss of range.
Sounds reasonable to me.
I have thought about defining separate helpers like this
...
This would make it even more explicit, but my fear was that I was
adding too much complexity like that.
I think a cast plus a comment when needed is clear enough.
Thanks,
Richard
_______________________________________________
Y2038 mailing list
Y2038@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/y2038
From: Pablo Neira Ayuso <pablo@netfilter.org> Date: 2015-10-02 12:47:07
On Wed, Sep 30, 2015 at 01:26:38PM +0200, Arnd Bergmann wrote:
The __build_packet_message function fills a nfulnl_msg_packet_timestamp
structure that uses 64-bit seconds and is therefore y2038 safe, but
it uses an intermediate 'struct timespec' which is not.
This trivially changes the code to use 'struct timespec64' instead,
to correct the result on 32-bit architectures.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Pablo Neira Ayuso <pablo@netfilter.org>
Cc: Patrick McHardy <redacted>
Cc: Jozsef Kadlecsik <redacted>
Cc: netfilter-devel@vger.kernel.org
Cc: coreteam@netfilter.org
Acked-by: Pablo Neira Ayuso <pablo@netfilter.org>
BTW, I don't see the patch for nfnetlink_queue and I think I have seen
it in the diffstat from your cover letter.
On Friday 02 October 2015 14:53:55 Pablo Neira Ayuso wrote:
On Wed, Sep 30, 2015 at 01:26:38PM +0200, Arnd Bergmann wrote:
quoted
The __build_packet_message function fills a nfulnl_msg_packet_timestamp
structure that uses 64-bit seconds and is therefore y2038 safe, but
it uses an intermediate 'struct timespec' which is not.
This trivially changes the code to use 'struct timespec64' instead,
to correct the result on 32-bit architectures.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Pablo Neira Ayuso <pablo@netfilter.org>
Cc: Patrick McHardy <redacted>
Cc: Jozsef Kadlecsik <redacted>
Cc: netfilter-devel@vger.kernel.org
Cc: coreteam@netfilter.org
Acked-by: Pablo Neira Ayuso <pablo@netfilter.org>
Thanks
BTW, I don't see the patch for nfnetlink_queue and I think I have seen
it in the diffstat from your cover letter.
My text must have been unclear. What I meant is that I have identified
that file as needing a patch (among 120 other files) but have not
written one.
This one is trivial, it just needs replacing this code
if (entskb->tstamp.tv64) {
struct nfqnl_msg_packet_timestamp ts;
struct timeval tv = ktime_to_timeval(entskb->tstamp);
ts.sec = cpu_to_be64(tv.tv_sec);
ts.usec = cpu_to_be64(tv.tv_usec);
if (nla_put(skb, NFQA_TIMESTAMP, sizeof(ts), &ts))
goto nla_put_failure;
}
with a version using ktime_to_timespec64. If you or someone else does
this, that makes one less file for me to track.
Arnd
_______________________________________________
Y2038 mailing list
Y2038@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/y2038
This is a set of changes for network drivers and core code to
get rid of the use of time_t and derived data structures.
Applied patches #1-#10 to net-next, using the updated v2 version of
the zatm change.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
From: Oliver Hartkopp <socketcan@hartkopp.net> Date: 2015-10-05 18:51:25
Hello Arnd,
thanks for picking up this y2038 api issue.
On 09/30/2015 01:26 PM, Arnd Bergmann wrote:
The can subsystem communicates with user space using a bcm_msg_head
header, which contains two timestamps. This is problematic for
multiple reasons:
a) The structure layout is currently incompatible between 64-bit
user space and 32-bit user space, and cannot work in compat
mode (other than x32).
b) The timeval structure layout will change in 32-bit user
space when we fix the y2038 overflow problem by redefining
time_t to 64-bit, making new 32-bit user space incompatible
with the current kernel interface.
Cars last a long time and often use old kernels, so the actual
users of this code are the most likely ones to migrate to y2038
safe user space.
This tries to work around part of the problem by changing the
publicly visible user interface in the header, but not the binary
interface. Fortunately, the values passed around in the structure
are relative times and do not actually suffer from the y2038
overflow, so 32-bit is enough here.
We replace the use of 'struct timeval' with a newly defined
'struct bcm_timeval' that uses the exact same binary layout
as before and that still suffers from problem a) but not problem
b).
The downside of this approach is that any user space program
that currently assigns a timeval structure to these members
rather than writing the tv_sec/tv_usec portions individually
will suffer a compile-time error when built with an updated
kernel header. Fixing this error makes it work fine with old
and new headers though.
I double checked some (more) BCM applications I have access to.
E.g. https://github.com/linux-can/can-tests
When you do a 'git grep ival1' there you get something like
tst-bcm-cycle.c: msg.msg_head.ival1.tv_sec = 1;
tst-bcm-cycle.c: msg.msg_head.ival1.tv_usec = 0;
tst-bcm-cycle.c: msg.msg_head.ival1.tv_sec = 0;
tst-bcm-cycle.c: msg.msg_head.ival1.tv_usec = 0;
tst-bcm-dump.c: msg.msg_head.ival1.tv_sec = timeout / 1000000;
tst-bcm-dump.c: msg.msg_head.ival1.tv_usec = timeout % 1000000;
(..)
So the usual way to assign values to ival1 and ival2 is NOT to assign an
existing struct timeval but to directly assign its tv_[u]sec elements.
I applied your bcm.h changes to my local can-tests tree and it compiles
without any problems - as expected. I don't see any serious drawback with your
idea. I wonder whether developers would ever notice this change ...
We could address problem a) by using '__u32' or 'int' members
rather than 'long', but that would have a more significant
downside in also breaking support for all existing 64-bit user
binaries that might be using this interface, which is likely
not acceptable.
Indeed.
Signed-off-by: Arnd Bergmann <redacted>
Cc: Oliver Hartkopp <redacted>
Thanks for your good suggestion to make the BCM API y2038 proof!
Acked-by: Oliver Hartkopp <redacted>
@@ -953,8 +958,8 @@ static int bcm_tx_setup(struct bcm_msg_head *msg_head, struct msghdr *msg,op->count=msg_head->count;op->ival1=msg_head->ival1;op->ival2=msg_head->ival2;-op->kt_ival1=timeval_to_ktime(msg_head->ival1);-op->kt_ival2=timeval_to_ktime(msg_head->ival2);+op->kt_ival1=bcm_timeval_to_ktime(msg_head->ival1);+op->kt_ival2=bcm_timeval_to_ktime(msg_head->ival2);/* disable an active timer due to zero values? */if(!op->kt_ival1.tv64&&!op->kt_ival2.tv64)
@@ -1134,8 +1139,8 @@ static int bcm_rx_setup(struct bcm_msg_head *msg_head, struct msghdr *msg,/* set timer value */op->ival1=msg_head->ival1;op->ival2=msg_head->ival2;-op->kt_ival1=timeval_to_ktime(msg_head->ival1);-op->kt_ival2=timeval_to_ktime(msg_head->ival2);+op->kt_ival1=bcm_timeval_to_ktime(msg_head->ival1);+op->kt_ival2=bcm_timeval_to_ktime(msg_head->ival2);/* disable an active timer due to zero value? */if(!op->kt_ival1.tv64)
On Monday 05 October 2015 20:51:08 Oliver Hartkopp wrote:
I double checked some (more) BCM applications I have access to.
E.g. https://github.com/linux-can/can-tests
When you do a 'git grep ival1' there you get something like
tst-bcm-cycle.c: msg.msg_head.ival1.tv_sec = 1;
tst-bcm-cycle.c: msg.msg_head.ival1.tv_usec = 0;
tst-bcm-cycle.c: msg.msg_head.ival1.tv_sec = 0;
tst-bcm-cycle.c: msg.msg_head.ival1.tv_usec = 0;
tst-bcm-dump.c: msg.msg_head.ival1.tv_sec = timeout / 1000000;
tst-bcm-dump.c: msg.msg_head.ival1.tv_usec = timeout % 1000000;
(..)
So the usual way to assign values to ival1 and ival2 is NOT to assign an
existing struct timeval but to directly assign its tv_[u]sec elements.
Ok, very good.
I applied your bcm.h changes to my local can-tests tree and it compiles
without any problems - as expected. I don't see any serious drawback with your
idea. I wonder whether developers would ever notice this change ...
quoted
We could address problem a) by using '__u32' or 'int' members
rather than 'long', but that would have a more significant
downside in also breaking support for all existing 64-bit user
binaries that might be using this interface, which is likely
not acceptable.
Indeed.
quoted
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Oliver Hartkopp <socketcan@hartkopp.net>
Thanks for your good suggestion to make the BCM API y2038 proof!
Acked-by: Oliver Hartkopp <socketcan@hartkopp.net>
Thanks.
What is the normal path for CAN patches? Should I resend with your
Ack and without the RFC for Marc to pick it up?
Arnd
_______________________________________________
Y2038 mailing list
Y2038@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/y2038
From: Marc Kleine-Budde <mkl@pengutronix.de> Date: 2015-10-06 09:05:55
On 10/06/2015 10:32 AM, Arnd Bergmann wrote:
On Monday 05 October 2015 20:51:08 Oliver Hartkopp wrote:
quoted
I double checked some (more) BCM applications I have access to.
E.g. https://github.com/linux-can/can-tests
When you do a 'git grep ival1' there you get something like
tst-bcm-cycle.c: msg.msg_head.ival1.tv_sec = 1;
tst-bcm-cycle.c: msg.msg_head.ival1.tv_usec = 0;
tst-bcm-cycle.c: msg.msg_head.ival1.tv_sec = 0;
tst-bcm-cycle.c: msg.msg_head.ival1.tv_usec = 0;
tst-bcm-dump.c: msg.msg_head.ival1.tv_sec = timeout / 1000000;
tst-bcm-dump.c: msg.msg_head.ival1.tv_usec = timeout % 1000000;
(..)
So the usual way to assign values to ival1 and ival2 is NOT to assign an
existing struct timeval but to directly assign its tv_[u]sec elements.
Ok, very good.
quoted
I applied your bcm.h changes to my local can-tests tree and it compiles
without any problems - as expected. I don't see any serious drawback with your
idea. I wonder whether developers would ever notice this change ...
quoted
We could address problem a) by using '__u32' or 'int' members
rather than 'long', but that would have a more significant
downside in also breaking support for all existing 64-bit user
binaries that might be using this interface, which is likely
not acceptable.
Indeed.
quoted
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Oliver Hartkopp <socketcan@hartkopp.net>
Thanks for your good suggestion to make the BCM API y2038 proof!
Acked-by: Oliver Hartkopp <socketcan@hartkopp.net>
Thanks.
What is the normal path for CAN patches? Should I resend with your
Ack and without the RFC for Marc to pick it up?
You can add my:
Acked-by: Marc Kleine-Budde <mkl@pengutronix.de>
add upstream the 2038 fixes as a block.
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions | Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
On Tuesday 06 October 2015 11:05:32 Marc Kleine-Budde wrote:
On 10/06/2015 10:32 AM, Arnd Bergmann wrote:
quoted
On Monday 05 October 2015 20:51:08 Oliver Hartkopp wrote:
quoted
I double checked some (more) BCM applications I have access to.
E.g. https://github.com/linux-can/can-tests
When you do a 'git grep ival1' there you get something like
tst-bcm-cycle.c: msg.msg_head.ival1.tv_sec = 1;
tst-bcm-cycle.c: msg.msg_head.ival1.tv_usec = 0;
tst-bcm-cycle.c: msg.msg_head.ival1.tv_sec = 0;
tst-bcm-cycle.c: msg.msg_head.ival1.tv_usec = 0;
tst-bcm-dump.c: msg.msg_head.ival1.tv_sec = timeout / 1000000;
tst-bcm-dump.c: msg.msg_head.ival1.tv_usec = timeout % 1000000;
(..)
So the usual way to assign values to ival1 and ival2 is NOT to assign an
existing struct timeval but to directly assign its tv_[u]sec elements.
Ok, very good.
quoted
I applied your bcm.h changes to my local can-tests tree and it compiles
without any problems - as expected. I don't see any serious drawback with your
idea. I wonder whether developers would ever notice this change ...
quoted
We could address problem a) by using '__u32' or 'int' members
rather than 'long', but that would have a more significant
downside in also breaking support for all existing 64-bit user
binaries that might be using this interface, which is likely
not acceptable.
Indeed.
quoted
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Oliver Hartkopp <socketcan@hartkopp.net>
Thanks for your good suggestion to make the BCM API y2038 proof!
Acked-by: Oliver Hartkopp <socketcan@hartkopp.net>
Thanks.
What is the normal path for CAN patches? Should I resend with your
Ack and without the RFC for Marc to pick it up?
You can add my:
Acked-by: Marc Kleine-Budde <mkl@pengutronix.de>
add upstream the 2038 fixes as a block.
Davem already picked up the first 10 of the series. If you don't
mind, I'd prefer if you could take this one into your tree so I
have it off my list.
I have 200 other patches in various states and more getting added.
Arnd
From: Marc Kleine-Budde <mkl@pengutronix.de> Date: 2015-10-06 09:37:21
On 10/06/2015 11:18 AM, Arnd Bergmann wrote:
quoted
Acked-by: Marc Kleine-Budde <redacted>
add upstream the 2038 fixes as a block.
Davem already picked up the first 10 of the series. If you don't
mind, I'd prefer if you could take this one into your tree so I
have it off my list.
I have 200 other patches in various states and more getting added.
Ok. Consider it done.
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions | Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
From: Arnd Bergmann [mailto:arnd@arndb.de]
Sent: Wednesday, September 30, 2015 4:57 PM
To: netdev@vger.kernel.org
Cc: y2038@lists.linaro.org; linux-kernel@vger.kernel.org; David S.
Miller; Arnd Bergmann; Amitkumar Karwar; Nishant Sarmukadam; Kalle Valo;
linux-wireless@vger.kernel.org
Subject: [PATCH 05/12] mwifiex: avoid gettimeofday in ba_threshold
setting
mwifiex_get_random_ba_threshold() uses a complex homegrown
implementation to generate a pseudo-random number from the current time
as returned from do_gettimeofday().
This currently requires two 32-bit divisions plus a couple of other
computations that are eventually discarded as only eight bits of the
microsecond portion are used at all.
We could replace this with a call to get_random_bytes(), but that might
drain the entropy pool too fast if this is called for each packet.
Instead, this patch converts it to use ktime_get_ns(), which is a bit
faster than do_gettimeofday(), and then uses a similar algorithm as
before, but in a way that takes both the nanosecond and second portion
into account for slightly-more-but-still-not-very-random
pseudorandom number.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Amitkumar Karwar <redacted>
Cc: Nishant Sarmukadam <redacted>
Cc: Kalle Valo <redacted>
Cc: linux-wireless@vger.kernel.org
---
drivers/net/wireless/mwifiex/wmm.c | 15 ++++-----------
1 file changed, 4 insertions(+), 11 deletions(-)
diff --git a/drivers/net/wireless/mwifiex/wmm.c
b/drivers/net/wireless/mwifiex/wmm.c
index 173d3663c2e0..878d358063dc 100644
From: Arnd Bergmann [mailto:arnd@arndb.de]
Sent: Wednesday, September 30, 2015 4:57 PM
To: netdev@vger.kernel.org
Cc: y2038@lists.linaro.org; linux-kernel@vger.kernel.org; David S.
Miller; Arnd Bergmann; Amitkumar Karwar; Nishant Sarmukadam; Kalle Valo;
linux-wireless@vger.kernel.org
Subject: [PATCH 04/12] mwifiex: use ktime_get_real for timestamping
The mwifiex_11n_aggregate_pkt() function creates a ktime_t from a
timeval returned by do_gettimeofday, which is slow and causes an
overflow in 2038 on 32-bit architectures.
This solves both problems by using the appropriate ktime_get_real()
function.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Amitkumar Karwar <redacted>
Cc: Nishant Sarmukadam <redacted>
Cc: Kalle Valo <redacted>
Cc: linux-wireless@vger.kernel.org
---
drivers/net/wireless/mwifiex/11n_aggr.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)