Message ID | 1566461871-21992-1-git-send-email-ayal@mellanox.com |
---|---|
State | Changes Requested |
Delegated to: | David Miller |
Headers | show |
Series | [net] devlink: Add method for time-stamp on reporter's dump | expand |
On Thu, Aug 22, 2019 at 11:17:51AM +0300, Aya Levin wrote: > When setting the dump's time-stamp, use ktime_get_real in addition to > jiffies. This simplifies the user space implementation and bypasses > some inconsistent behavior with translating jiffies to current time. Hi Aya Is this year 2038 safe? I don't know enough about this to answer the question myself. Thanks Andrew
On Thu, Aug 22, 2019 at 04:06:35PM +0200, Andrew Lunn wrote: > On Thu, Aug 22, 2019 at 11:17:51AM +0300, Aya Levin wrote: > > When setting the dump's time-stamp, use ktime_get_real in addition to > > jiffies. This simplifies the user space implementation and bypasses > > some inconsistent behavior with translating jiffies to current time. > > Hi Aya > > Is this year 2038 safe? I don't know enough about this to answer the > question myself. Hi Andrew, Good point. 'struct timespec' is not considered year 2038 safe and unfortunately I recently made the mistake of using it to communicate timestamps to user space over netlink. :/ The code is still in net-next, so I will fix it while I can. Arnd, would it be acceptable to use 'struct __kernel_timespec' instead? Thanks
On Thu, Aug 22, 2019 at 7:40 PM Ido Schimmel <idosch@idosch.org> wrote: > On Thu, Aug 22, 2019 at 04:06:35PM +0200, Andrew Lunn wrote: > > On Thu, Aug 22, 2019 at 11:17:51AM +0300, Aya Levin wrote: > > > When setting the dump's time-stamp, use ktime_get_real in addition to > > > jiffies. This simplifies the user space implementation and bypasses > > > some inconsistent behavior with translating jiffies to current time. > > > > Is this year 2038 safe? I don't know enough about this to answer the > > question myself. > > Good point. 'struct timespec' is not considered year 2038 safe and > unfortunately I recently made the mistake of using it to communicate > timestamps to user space over netlink. :/ The code is still in net-next, > so I will fix it while I can. > > Arnd, would it be acceptable to use 'struct __kernel_timespec' instead? The in-kernel representation should just use 'timespec64' if you need separate seconds and nanoseconds, you can convert that to __kernel_timespec while copying to user space. However, please consider two other points: - for simplicity, the general recommendation is to use 64-bit nanoseconds without separate seconds for timestamps - instead of CLOCK_REALTIME, you could use CLOCK_MONOTONIC timestamps that are not affected by clock_settime() or leap second jumps. Arnd
diff --git a/include/uapi/linux/devlink.h b/include/uapi/linux/devlink.h index ffc993256527..4dd4e4e7b19b 100644 --- a/include/uapi/linux/devlink.h +++ b/include/uapi/linux/devlink.h @@ -348,6 +348,8 @@ enum devlink_attr { DEVLINK_ATTR_PORT_PCI_PF_NUMBER, /* u16 */ DEVLINK_ATTR_PORT_PCI_VF_NUMBER, /* u16 */ + DEVLINK_ATTR_HEALTH_REPORTER_DUMP_TSPEC, + /* add new attributes above here, update the policy in devlink.c */ __DEVLINK_ATTR_MAX, diff --git a/net/core/devlink.c b/net/core/devlink.c index d3dbb904bf3b..b26875c4329b 100644 --- a/net/core/devlink.c +++ b/net/core/devlink.c @@ -4577,6 +4577,7 @@ struct devlink_health_reporter { bool auto_recover; u8 health_state; u64 dump_ts; + struct timespec dump_real_ts; u64 error_count; u64 recovery_count; u64 last_recovery_ts; @@ -4749,6 +4750,7 @@ static int devlink_health_do_dump(struct devlink_health_reporter *reporter, goto dump_err; reporter->dump_ts = jiffies; + reporter->dump_real_ts = ktime_to_timespec(ktime_get_real()); return 0; @@ -4911,6 +4913,10 @@ devlink_nl_health_reporter_fill(struct sk_buff *msg, jiffies_to_msecs(reporter->dump_ts), DEVLINK_ATTR_PAD)) goto reporter_nest_cancel; + if (reporter->dump_fmsg && + nla_put(msg, DEVLINK_ATTR_HEALTH_REPORTER_DUMP_TSPEC, + sizeof(reporter->dump_real_ts), &reporter->dump_real_ts)) + goto reporter_nest_cancel; nla_nest_end(msg, reporter_attr); genlmsg_end(msg, hdr);