diff options
author | Arnd Bergmann <arnd@arndb.de> | 2019-10-24 16:34:25 +0200 |
---|---|---|
committer | Arnd Bergmann <arnd@arndb.de> | 2019-12-18 18:07:31 +0100 |
commit | 2d602bf28316e2f61a553f13d279f3d74c2e5189 (patch) | |
tree | 26caf2d720c009f5f68b7f4db5e0079602b9e65c /kernel/tsacct.c | |
parent | 853bc0ab341b0c99619f83f4060dedcccad77b2a (diff) | |
download | linux-2d602bf28316e2f61a553f13d279f3d74c2e5189.tar.bz2 |
acct: stop using get_seconds()
In 'struct acct', 'struct acct_v3', and 'struct taskstats' we have
a 32-bit 'ac_btime' field containing an absolute time value, which
will overflow in year 2106.
There are two possible ways to deal with it:
a) let it overflow and have user space code deal with reconstructing
the data based on the current time, or
b) truncate the times based on the range of the u32 type.
Neither of them solves the actual problem. Pick the second
one to best document what the issue is, and have someone
fix it in a future version.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Diffstat (limited to 'kernel/tsacct.c')
-rw-r--r-- | kernel/tsacct.c | 8 |
1 files changed, 5 insertions, 3 deletions
diff --git a/kernel/tsacct.c b/kernel/tsacct.c index 7be3e7530841..ab12616ee6fb 100644 --- a/kernel/tsacct.c +++ b/kernel/tsacct.c @@ -24,6 +24,7 @@ void bacct_add_tsk(struct user_namespace *user_ns, const struct cred *tcred; u64 utime, stime, utimescaled, stimescaled; u64 delta; + time64_t btime; BUILD_BUG_ON(TS_COMM_LEN < TASK_COMM_LEN); @@ -32,9 +33,10 @@ void bacct_add_tsk(struct user_namespace *user_ns, /* Convert to micro seconds */ do_div(delta, NSEC_PER_USEC); stats->ac_etime = delta; - /* Convert to seconds for btime */ - do_div(delta, USEC_PER_SEC); - stats->ac_btime = get_seconds() - delta; + /* Convert to seconds for btime (note y2106 limit) */ + btime = ktime_get_real_seconds() - div_u64(delta, USEC_PER_SEC); + stats->ac_btime = clamp_t(time64_t, btime, 0, U32_MAX); + if (thread_group_leader(tsk)) { stats->ac_exitcode = tsk->exit_code; if (tsk->flags & PF_FORKNOEXEC) |