* [PATCH 4/4] time: rtc-lib: Add CONFIG_RTC_SHOW_TIME_RTC
From: Mark Salyzyn @ 2017-07-19 19:50 UTC (permalink / raw)
To: linux-kernel
Cc: rjw, len.brown, pavel, linux-pm, a.zummo, alexandre.belloni,
linux-rtc, prarit, andy.shevchenko, Mark Salyzyn,
Paul E. McKenney
Add an option to report REALTIME in RTC time format for
rtc_show_time() function.
Feature activated by CONFIG_RTC_SHOW_TIME_RTC.
Signed-off-by: Mark Salyzyn <salyzyn@android.com>
---
kernel/time/Kconfig | 17 +++++++++++++++++
kernel/time/rtc_show_time.c | 12 ++++++++++++
2 files changed, 29 insertions(+)
diff --git a/kernel/time/Kconfig b/kernel/time/Kconfig
index 2dc891056635..3c2920b8825c 100644
--- a/kernel/time/Kconfig
+++ b/kernel/time/Kconfig
@@ -221,4 +221,21 @@ choice
continues, and the timestamps help re-orient post-analysis.
Print boottime <s>.<ns> timestamp in rtc_show_time
+ config RTC_SHOW_TIME_RTC
+ bool "realtime in wall clock format"
+ select RTC_SHOW_TIME
+ select RTC_LIB
+ help
+ Activate optional rtc_show_time(const char *msg) wall clock
+ time instrumentation.
+
+ The primary use of the instrumentation is to aid field
+ analysis of Battery and Power usage. The instrumentation
+ may also help triage and synchronize kernel logs and user
+ space activity logs at key displacements. For instance
+ CLOCK_MONOTONIC stops while suspended, while CLOCK_REALTIME
+ continues, and the timestamps help re-orient post-analysis.
+
+ Print realtime YYYY-MM-DD hh:mm:ss.<ns> timestamp in
+ rtc_show_time.
endchoice
diff --git a/kernel/time/rtc_show_time.c b/kernel/time/rtc_show_time.c
index 6c7b8ae6be0c..d861a30aef77 100644
--- a/kernel/time/rtc_show_time.c
+++ b/kernel/time/rtc_show_time.c
@@ -24,9 +24,21 @@ void rtc_show_time(const char *prefix_msg)
struct timespec64 ts;
getnstimeofday64(&ts);
+#if defined(CONFIG_RTC_SHOW_TIME_RTC)
+ {
+ struct rtc_time tm;
+
+ rtc_time64_to_tm(ts.tv_sec, &tm);
+ pr_info("%s %d-%02d-%02d %02d:%02d:%02d.%09lu UTC\n",
+ prefix_msg ? prefix_msg : "Time:",
+ tm.tm_year + 1900, tm.tm_mon + 1, tm.tm_mday,
+ tm.tm_hour, tm.tm_min, tm.tm_sec, ts.tv_nsec);
+ }
+#else
pr_info("%s %lu.%09lu UTC\n",
prefix_msg ? prefix_msg : "Time:", ts.tv_sec, ts.tv_nsec);
#endif
+#endif
}
EXPORT_SYMBOL(rtc_show_time);
--
2.14.0.rc0.284.gd933b75aa4-goog
^ permalink raw reply related
* [PATCH v2 3/4] PM: Print wall time at suspend & hibernate entry and exit
From: Mark Salyzyn @ 2017-07-19 19:48 UTC (permalink / raw)
To: linux-kernel
Cc: rjw, len.brown, pavel, linux-pm, a.zummo, alexandre.belloni,
linux-rtc, prarit, andy.shevchenko, Mark Salyzyn
Permits power state and battery life diagnosis.
Since one is not guaranteed to have a persistent hardware clock to
report Suspended for in milliseconds, we report at a higher level
at just the entry and exit points for suspend and hibernate.
Feature activated by CONFIG_RTC_SHOW_TIME_*
Signed-off-by: Mark Salyzyn <salyzyn@android.com>
v2:
- merge suspend and hibernate into a single patch
---
kernel/power/hibernate.c | 4 +++-
kernel/power/suspend.c | 3 +++
2 files changed, 6 insertions(+), 1 deletion(-)
diff --git a/kernel/power/hibernate.c b/kernel/power/hibernate.c
index e1914c7b85b1..0b5460f9189b 100644
--- a/kernel/power/hibernate.c
+++ b/kernel/power/hibernate.c
@@ -32,11 +32,11 @@
#include <linux/ctype.h>
#include <linux/genhd.h>
#include <linux/ktime.h>
+#include <linux/rtc.h>
#include <trace/events/power.h>
#include "power.h"
-
static int nocompress;
static int noresume;
static int nohibernate;
@@ -342,6 +342,7 @@ int hibernation_snapshot(int platform_mode)
pm_message_t msg;
int error;
+ rtc_show_time("PM: hibernation entry");
pm_suspend_clear_flags();
error = platform_begin(platform_mode);
if (error)
@@ -409,6 +410,7 @@ int hibernation_snapshot(int platform_mode)
thaw_kernel_threads();
Cleanup:
swsusp_free();
+ rtc_show_time("PM: hibernation exit");
goto Close;
}
diff --git a/kernel/power/suspend.c b/kernel/power/suspend.c
index 3ecf275d7e44..f44d2152ab3f 100644
--- a/kernel/power/suspend.c
+++ b/kernel/power/suspend.c
@@ -26,6 +26,7 @@
#include <linux/suspend.h>
#include <linux/syscore_ops.h>
#include <linux/ftrace.h>
+#include <linux/rtc.h>
#include <trace/events/power.h>
#include <linux/compiler.h>
#include <linux/moduleparam.h>
@@ -579,6 +580,7 @@ int pm_suspend(suspend_state_t state)
if (state <= PM_SUSPEND_ON || state >= PM_SUSPEND_MAX)
return -EINVAL;
+ rtc_show_time("PM: suspend entry");
error = enter_state(state);
if (error) {
suspend_stats.fail++;
@@ -586,6 +588,7 @@ int pm_suspend(suspend_state_t state)
} else {
suspend_stats.success++;
}
+ rtc_show_time("PM: suspend exit");
return error;
}
EXPORT_SYMBOL(pm_suspend);
--
2.14.0.rc0.284.gd933b75aa4-goog
^ permalink raw reply related
* [PATCH v2 3/4] PM: Print wall time at suspend & hibernate entry and exit
From: Mark Salyzyn @ 2017-07-19 19:45 UTC (permalink / raw)
To: linux-kernel
Cc: rjw, len.brown, pavel, linux-pm, a.zummo, alexandre.belloni,
linux-rtc, Mark Salyzyn
Permits power state and battery life diagnosis.
Since one is not guaranteed to have a persistent hardware clock to
report Suspended for in milliseconds, we report at a higher level
at just the entry and exit points for suspend and hibernate.
Feature activated by CONFIG_RTC_SHOW_TIME_*
Signed-off-by: Mark Salyzyn <salyzyn@android.com>
v2:
- merge suspend and hibernate into a single patch
---
kernel/power/hibernate.c | 4 +++-
kernel/power/suspend.c | 3 +++
2 files changed, 6 insertions(+), 1 deletion(-)
diff --git a/kernel/power/hibernate.c b/kernel/power/hibernate.c
index e1914c7b85b1..0b5460f9189b 100644
--- a/kernel/power/hibernate.c
+++ b/kernel/power/hibernate.c
@@ -32,11 +32,11 @@
#include <linux/ctype.h>
#include <linux/genhd.h>
#include <linux/ktime.h>
+#include <linux/rtc.h>
#include <trace/events/power.h>
#include "power.h"
-
static int nocompress;
static int noresume;
static int nohibernate;
@@ -342,6 +342,7 @@ int hibernation_snapshot(int platform_mode)
pm_message_t msg;
int error;
+ rtc_show_time("PM: hibernation entry");
pm_suspend_clear_flags();
error = platform_begin(platform_mode);
if (error)
@@ -409,6 +410,7 @@ int hibernation_snapshot(int platform_mode)
thaw_kernel_threads();
Cleanup:
swsusp_free();
+ rtc_show_time("PM: hibernation exit");
goto Close;
}
diff --git a/kernel/power/suspend.c b/kernel/power/suspend.c
index 3ecf275d7e44..f44d2152ab3f 100644
--- a/kernel/power/suspend.c
+++ b/kernel/power/suspend.c
@@ -26,6 +26,7 @@
#include <linux/suspend.h>
#include <linux/syscore_ops.h>
#include <linux/ftrace.h>
+#include <linux/rtc.h>
#include <trace/events/power.h>
#include <linux/compiler.h>
#include <linux/moduleparam.h>
@@ -579,6 +580,7 @@ int pm_suspend(suspend_state_t state)
if (state <= PM_SUSPEND_ON || state >= PM_SUSPEND_MAX)
return -EINVAL;
+ rtc_show_time("PM: suspend entry");
error = enter_state(state);
if (error) {
suspend_stats.fail++;
@@ -586,6 +588,7 @@ int pm_suspend(suspend_state_t state)
} else {
suspend_stats.success++;
}
+ rtc_show_time("PM: suspend exit");
return error;
}
EXPORT_SYMBOL(pm_suspend);
--
2.14.0.rc0.284.gd933b75aa4-goog
^ permalink raw reply related
* [PATCH v2 2/4] time: Print wall time at die and reboot
From: Mark Salyzyn @ 2017-07-19 19:45 UTC (permalink / raw)
To: linux-kernel
Cc: rjw, len.brown, pavel, linux-pm, a.zummo, alexandre.belloni,
linux-rtc, Mark Salyzyn
Permits power state and battery life diagnosis.
Feature activated by CONFIG_RTC_SHOW_TIME.
Signed-off-by: Mark Salyzyn <salyzyn@android.com>
v2:
- react to implementation move to kernel timekeeping from rtc_lib
- use late_initcall to ensure rtc_lib driver(s) are loaded
---
kernel/time/rtc_show_time.c | 59 +++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 59 insertions(+)
diff --git a/kernel/time/rtc_show_time.c b/kernel/time/rtc_show_time.c
index 19a8a0cc94f0..6c7b8ae6be0c 100644
--- a/kernel/time/rtc_show_time.c
+++ b/kernel/time/rtc_show_time.c
@@ -6,6 +6,8 @@
* published by the Free Software Foundation.
*/
+#include <linux/kdebug.h>
+#include <linux/reboot.h>
#include <linux/rtc.h>
void rtc_show_time(const char *prefix_msg)
@@ -27,3 +29,60 @@ void rtc_show_time(const char *prefix_msg)
#endif
}
EXPORT_SYMBOL(rtc_show_time);
+
+static int rtc_show_time_die_notify(struct notifier_block *self,
+ unsigned long event, void *data)
+{
+ if (event != DIE_OOPS)
+ return NOTIFY_DONE;
+ rtc_show_time("Oops");
+ return NOTIFY_DONE;
+}
+
+static struct notifier_block rtc_show_time_die_nb = {
+ .notifier_call = rtc_show_time_die_notify,
+ .priority = 0,
+};
+
+static int rtc_show_time_reboot_notify(struct notifier_block *self,
+ unsigned long event, void *data)
+{
+ const char *txt;
+
+ switch (event) {
+ case SYS_RESTART:
+ txt = "Restart";
+ break;
+ case SYS_HALT:
+ txt = "Halt";
+ break;
+ case SYS_POWER_OFF:
+ txt = "Power-Off";
+ break;
+ default:
+ return NOTIFY_DONE;
+ }
+ rtc_show_time(txt);
+ return NOTIFY_DONE;
+}
+
+static struct notifier_block rtc_show_time_reboot_nb = {
+ .notifier_call = rtc_show_time_reboot_notify,
+ .priority = 0,
+};
+
+static __init int init_rtc_show_time(void)
+{
+ int ret;
+
+ ret = register_die_notifier(&rtc_show_time_die_nb);
+ if (ret)
+ pr_warn("Failed to register rtc_show_time die notifier\n");
+ ret = register_reboot_notifier(&rtc_show_time_reboot_nb);
+ if (ret)
+ pr_warn("Failed to register rtc_show_time reboot notifier\n");
+
+ return ret;
+}
+/* rtc driver needs to be loaded before this is truly functional */
+late_initcall(init_rtc_show_time);
--
2.14.0.rc0.284.gd933b75aa4-goog
^ permalink raw reply related
* [PATCH v4 1/4] time: rtc-lib: Add rtc_show_time(const char *prefix_msg)
From: Mark Salyzyn @ 2017-07-19 19:44 UTC (permalink / raw)
To: linux-kernel
Cc: rjw, len.brown, pavel, linux-pm, a.zummo, alexandre.belloni,
linux-rtc, Mark Salyzyn, Kees Cook, Anton Vorontsov, Colin Cross,
Tony Luck, Paul E. McKenney, Thomas Gleixner, John Stultz,
Nicolas Pitre, Richard Cochran
Primary purpose of rtc_show_time is to provide a marker used for
post-mortem Battery and Power analysis. These markers occur at
major discontinuities of time, and thus optionally add a timestamp
to aid the analysis. This function is to be called at a higher
level, and were added because of a lack of current kernel logging
data.
The persistent clock that is used to report Suspended for message
is not present on all platforms, and is currently standardized for
millisecond precision.
An added value to the time report is the ability in post-mortem
triage analysis to synchronize kernel activities in MONOTONIC
time with user space activities in REALTIME.
Feature activated by CONFIG_RTC_SHOW_TIME_<TYPE>, where <TYPE> is
None (default, disabled), realtime, boottime or monotonic.
Since this is for post mortem field analysis, there is no debugfs
or trace facility that can generally be leveraged. analyze_suspend.py
for example requires a debug configured kernel, on the other hand
these prints can remain in a field product. The purpose for
rtc_show_time is not for development debugging.
Data collected may be recorded by klogd with a longer logspan
than the built-in dmesg buffer, or land in pstore console driver
to be collected after a reboot.
Signed-off-by: Mark Salyzyn <salyzyn@android.com>
v2:
- move implementation to kernel timekeeping from rtc_lib files
- use rtc_time64_to_tm() instead of rtc_time_to_tm()
- use inline in include/linux/rtc.h for !CONFIG_RTC_SHOW_TIME
v3:
- _correctly_ use rtc_time64_to_tm
v4:
- introduce CONFIG_RTC_SHOW_TIME_<TYPE> and split off rtc time
format printing to a separate patch.
---
include/linux/rtc.h | 5 +++
kernel/time/Kconfig | 77 +++++++++++++++++++++++++++++++++++++++++++++
kernel/time/Makefile | 1 +
kernel/time/rtc_show_time.c | 29 +++++++++++++++++
4 files changed, 112 insertions(+)
create mode 100644 kernel/time/rtc_show_time.c
diff --git a/include/linux/rtc.h b/include/linux/rtc.h
index 0a0f0d14a5fb..779401c937d5 100644
--- a/include/linux/rtc.h
+++ b/include/linux/rtc.h
@@ -22,6 +22,11 @@ extern int rtc_year_days(unsigned int day, unsigned int month, unsigned int year
extern int rtc_valid_tm(struct rtc_time *tm);
extern time64_t rtc_tm_to_time64(struct rtc_time *tm);
extern void rtc_time64_to_tm(time64_t time, struct rtc_time *tm);
+#ifdef CONFIG_RTC_SHOW_TIME
+extern void rtc_show_time(const char *prefix_msg);
+#else
+static inline void rtc_show_time(const char *prefix_msg) { }
+#endif
ktime_t rtc_tm_to_ktime(struct rtc_time tm);
struct rtc_time rtc_ktime_to_tm(ktime_t kt);
diff --git a/kernel/time/Kconfig b/kernel/time/Kconfig
index ac09bc29eb08..2dc891056635 100644
--- a/kernel/time/Kconfig
+++ b/kernel/time/Kconfig
@@ -145,3 +145,80 @@ config HIGH_RES_TIMERS
endmenu
endif
+
+config RTC_SHOW_TIME
+ bool
+ help
+ Activate optional rtc_show_time(const char *msg) wall clock
+ time instrumentation.
+
+ The primary use of the instrumentation is to aid field
+ analysis of Battery and Power usage. The instrumentation
+ may also help triage and synchronize kernel logs and user
+ space activity logs at key displacements. For instance
+ CLOCK_MONOTONIC stops while suspended, while CLOCK_REALTIME
+ continues, and the timestamps help re-orient post-analysis.
+
+ Select the appropriate RTC_SHOW_TIME_<type>
+
+choice
+ prompt "choose a clock for rtc_show_time"
+ config RTC_SHOW_TIME_NONE
+ bool "not activated"
+ help
+ Turn off all printing associated with rtc_show_time
+
+ The primary use of the instrumentation is to aid field
+ analysis of Battery and Power usage. The instrumentation
+ may also help triage and synchronize kernel logs and user
+ space activity logs at key displacements. For instance
+ CLOCK_MONOTONIC stops while suspended, while CLOCK_REALTIME
+ continues, and the timestamps help re-orient post-analysis.
+
+ This is the default behavior.
+ config RTC_SHOW_TIME_REALTIME
+ bool "realtime"
+ select RTC_SHOW_TIME
+ help
+ Activate optional rtc_show_time(const char *msg) wall clock
+ time instrumentation.
+
+ The primary use of the instrumentation is to aid field
+ analysis of Battery and Power usage. The instrumentation
+ may also help triage and synchronize kernel logs and user
+ space activity logs at key displacements. For instance
+ CLOCK_MONOTONIC stops while suspended, while CLOCK_REALTIME
+ continues, and the timestamps help re-orient post-analysis.
+
+ Print realtime <epoch>.<ns> timestamp in rtc_show_time
+ config RTC_SHOW_TIME_MONOTONIC
+ bool "monotonic"
+ select RTC_SHOW_TIME
+ help
+ Activate optional rtc_show_time(const char *msg) wall clock
+ time instrumentation.
+
+ The primary use of the instrumentation is to aid field
+ analysis of Battery and Power usage. The instrumentation
+ may also help triage and synchronize kernel logs and user
+ space activity logs at key displacements. For instance
+ CLOCK_MONOTONIC stops while suspended, while CLOCK_REALTIME
+ continues, and the timestamps help re-orient post-analysis.
+
+ Print only the supplied message in rtc_show_time
+ config RTC_SHOW_TIME_BOOTTIME
+ bool "boottime"
+ select RTC_SHOW_TIME
+ help
+ Activate optional rtc_show_time(const char *msg) wall clock
+ time instrumentation.
+
+ The primary use of the instrumentation is to aid field
+ analysis of Battery and Power usage. The instrumentation
+ may also help triage and synchronize kernel logs and user
+ space activity logs at key displacements. For instance
+ CLOCK_MONOTONIC stops while suspended, while CLOCK_REALTIME
+ continues, and the timestamps help re-orient post-analysis.
+
+ Print boottime <s>.<ns> timestamp in rtc_show_time
+endchoice
diff --git a/kernel/time/Makefile b/kernel/time/Makefile
index 938dbf33ef49..66f17e641052 100644
--- a/kernel/time/Makefile
+++ b/kernel/time/Makefile
@@ -17,3 +17,4 @@ obj-$(CONFIG_GENERIC_SCHED_CLOCK) += sched_clock.o
obj-$(CONFIG_TICK_ONESHOT) += tick-oneshot.o tick-sched.o
obj-$(CONFIG_DEBUG_FS) += timekeeping_debug.o
obj-$(CONFIG_TEST_UDELAY) += test_udelay.o
+obj-$(CONFIG_RTC_SHOW_TIME) += rtc_show_time.o
diff --git a/kernel/time/rtc_show_time.c b/kernel/time/rtc_show_time.c
new file mode 100644
index 000000000000..19a8a0cc94f0
--- /dev/null
+++ b/kernel/time/rtc_show_time.c
@@ -0,0 +1,29 @@
+/*
+ * rtc time printing utility functions
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include <linux/rtc.h>
+
+void rtc_show_time(const char *prefix_msg)
+{
+#if defined(CONFIG_RTC_SHOW_TIME_MONOTONIC) /* dmesg is in monotonic */
+ pr_info("%s\n", prefix_msg ? prefix_msg : "Time:");
+#elif defined(CONFIG_RTC_SHOW_TIME_BOOTTIME)
+ struct timespec64 ts;
+
+ getboottime64(&ts);
+ pr_info("%s %lu.%09lu B\n",
+ prefix_msg ? prefix_msg : "Time:", ts.tv_sec, ts.tv_nsec);
+#else /* realtime */
+ struct timespec64 ts;
+
+ getnstimeofday64(&ts);
+ pr_info("%s %lu.%09lu UTC\n",
+ prefix_msg ? prefix_msg : "Time:", ts.tv_sec, ts.tv_nsec);
+#endif
+}
+EXPORT_SYMBOL(rtc_show_time);
--
2.14.0.rc0.284.gd933b75aa4-goog
^ permalink raw reply related
* Re: [PATCH v2 1/4] time: rtc-lib: Add rtc_show_time(const char *prefix_msg)
From: Mark Salyzyn @ 2017-07-19 18:13 UTC (permalink / raw)
To: Prarit Bhargava, Thomas Gleixner
Cc: LKML, rjw, len.brown, pavel, linux-pm, a.zummo, alexandre.belloni,
linux-rtc, andy.shevchenko, Mark Salyzyn, Paul E. McKenney,
Thierry Strudel, John Stultz, Richard Cochran, Nicolas Pitre,
Kees Cook, Ingo Molnar, Peter Zijlstra
In-Reply-To: <f50dbf47-d1dc-5e51-fdcd-0318c2ab93cd@redhat.com>
On 07/19/2017 05:03 AM, Prarit Bhargava wrote:
>
> On 07/19/2017 03:23 AM, Thomas Gleixner wrote:
>> On Tue, 18 Jul 2017, Mark Salyzyn wrote:
>>> On 07/18/2017 03:35 PM, Thomas Gleixner wrote:
>>>> There was some discussion about making the clock source for dmesg time
>>>> stamps selectable, so you can use MONOTONIC, REALTIME, BOOTTIME. The
>>>> patches looked sensible, but there was some showstopper vs. the user space
>>>> dmesg utility. See:
>>> The timestamps are useful for the 'second' purpose of these patches when
>>> dmesg time is BOOTTIME or MONOTONIC, and can be turned off if REALTIME
>>> is selected. Having rtc_show_time a single point for switching this no doubt
>>> helps,
>>> not hinders, that dmesg issue.
>>>
>>> The inflection points would still serve a purpose, still need
>>> suspend/resume/hibernate/restore. The reboot messages are _only_ useful to
>>> us with their timestamps, as I checked and the only tools that use those are
>>> for log synchronization. We may be able to do away with them on REALTIME
>>> dmesg'ing; but the standardization of the message as a marker would have a
>>> legacy purpose (!)
>>>
>>> NB: We have a similar configuration for the user space logger, which can be
>>> configured to report in MONOTONIC time. We have yet to have a vendor
>>> use the feature, opting for REALTIME logging for user space activities.
>>> Our klogd (which runs at background priority and is batched) manages a
>>> histogram relationship between MONOTONIC and REALTIME helped by these
>>> prints and incorporates the REALTIME dmesg logs merged into our user
>>> space logging database.
>> There is another option to remedy this and the dmesg tooling issues:
>>
>> Instead of switching the time stamps in dmesg to a different clock we might
>> as well have an optional secondary timestamp. So instead of:
>>
>> [ 341.590930] wlan0: associated
>>
>> you would get:
>>
>> [ 341.590930] [ sec.usec] wlan0: associated
>>
>> where the second time stamp would be CLOCK_REALTIME/BOOTTIME.
>>
>> That should also solve Prarits problem, hmm?
> It would but I would prefer a single time stamp be printed than two. I think
> two timestamps is adding confusion to the output from a end-users point of view.
Agreed, and so many tools will be in pain (toybox, busybox, for
instance). Not that I disagree, but API changes should always get an
environmental assessment ...
> Mark, why don't we get together and fixup my original patchset to make sure it
> meets your needs? It will fix both of our issues albeit not necessarily in the
> text format you want it.
I am currently retesting with the rtc format patch rolled out
separately, could probably roll into your set.
-- Mark
^ permalink raw reply
* Re: [PATCH] rtc: sun6i: ensure clk_data is kfree'd on error
From: Colin Ian King @ 2017-07-19 17:48 UTC (permalink / raw)
To: Alexandre Belloni
Cc: Alessandro Zummo, Maxime Ripard, Chen-Yu Tsai, linux-rtc,
linux-arm-kernel, kernel-janitors, linux-kernel
In-Reply-To: <20170719173248.l4w5xc33enuor5if@piout.net>
On 19/07/17 18:32, Alexandre Belloni wrote:
> Hi,
>
> On 19/07/2017 at 17:57:02 +0100, Colin King wrote:
>> From: Colin Ian King <colin.king@canonical.com>
>>
>> There are two error return paths that do not kfree clk_data and
>> we end up with a memory leak. Fix these with a kfree error exit
>> path.
>>
>> Detected by CoverityScan, CID#1402959 ("Resource Leak")
>>
>
> I think that patch fixes the same issue (and more):
> http://patchwork.ozlabs.org/patch/787151/
Yep, that's true.
>
>> Signed-off-by: Colin Ian King <colin.king@canonical.com>
>> ---
>> drivers/rtc/rtc-sun6i.c | 8 ++++++--
>> 1 file changed, 6 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/rtc/rtc-sun6i.c b/drivers/rtc/rtc-sun6i.c
>> index 39cbc1238b92..61502221ab6e 100644
>> --- a/drivers/rtc/rtc-sun6i.c
>> +++ b/drivers/rtc/rtc-sun6i.c
>> @@ -204,7 +204,7 @@ static void __init sun6i_rtc_clk_init(struct device_node *node)
>> rtc->base = of_io_request_and_map(node, 0, of_node_full_name(node));
>> if (IS_ERR(rtc->base)) {
>> pr_crit("Can't map RTC registers");
>> - return;
>> + goto err;
>> }
>>
>> /* Switch to the external, more precise, oscillator */
>> @@ -216,7 +216,7 @@ static void __init sun6i_rtc_clk_init(struct device_node *node)
>>
>> /* Deal with old DTs */
>> if (!of_get_property(node, "clocks", NULL))
>> - return;
>> + goto err;
>>
>> rtc->int_osc = clk_hw_register_fixed_rate_with_accuracy(NULL,
>> "rtc-int-osc",
>> @@ -246,6 +246,10 @@ static void __init sun6i_rtc_clk_init(struct device_node *node)
>> clk_data->num = 1;
>> clk_data->hws[0] = &rtc->hw;
>> of_clk_add_hw_provider(node, of_clk_hw_onecell_get, clk_data);
>> + return;
>> +
>> +err:
>> + kfree(clk_data);
>> }
>> CLK_OF_DECLARE_DRIVER(sun6i_rtc_clk, "allwinner,sun6i-a31-rtc",
>> sun6i_rtc_clk_init);
>> --
>> 2.11.0
>>
>
^ permalink raw reply
* Re: [PATCH] rtc: sun6i: ensure clk_data is kfree'd on error
From: Alexandre Belloni @ 2017-07-19 17:32 UTC (permalink / raw)
To: Colin King
Cc: Alessandro Zummo, Maxime Ripard, Chen-Yu Tsai, linux-rtc,
linux-arm-kernel, kernel-janitors, linux-kernel
In-Reply-To: <20170719165702.22220-1-colin.king@canonical.com>
Hi,
On 19/07/2017 at 17:57:02 +0100, Colin King wrote:
> From: Colin Ian King <colin.king@canonical.com>
>
> There are two error return paths that do not kfree clk_data and
> we end up with a memory leak. Fix these with a kfree error exit
> path.
>
> Detected by CoverityScan, CID#1402959 ("Resource Leak")
>
I think that patch fixes the same issue (and more):
http://patchwork.ozlabs.org/patch/787151/
> Signed-off-by: Colin Ian King <colin.king@canonical.com>
> ---
> drivers/rtc/rtc-sun6i.c | 8 ++++++--
> 1 file changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/rtc/rtc-sun6i.c b/drivers/rtc/rtc-sun6i.c
> index 39cbc1238b92..61502221ab6e 100644
> --- a/drivers/rtc/rtc-sun6i.c
> +++ b/drivers/rtc/rtc-sun6i.c
> @@ -204,7 +204,7 @@ static void __init sun6i_rtc_clk_init(struct device_node *node)
> rtc->base = of_io_request_and_map(node, 0, of_node_full_name(node));
> if (IS_ERR(rtc->base)) {
> pr_crit("Can't map RTC registers");
> - return;
> + goto err;
> }
>
> /* Switch to the external, more precise, oscillator */
> @@ -216,7 +216,7 @@ static void __init sun6i_rtc_clk_init(struct device_node *node)
>
> /* Deal with old DTs */
> if (!of_get_property(node, "clocks", NULL))
> - return;
> + goto err;
>
> rtc->int_osc = clk_hw_register_fixed_rate_with_accuracy(NULL,
> "rtc-int-osc",
> @@ -246,6 +246,10 @@ static void __init sun6i_rtc_clk_init(struct device_node *node)
> clk_data->num = 1;
> clk_data->hws[0] = &rtc->hw;
> of_clk_add_hw_provider(node, of_clk_hw_onecell_get, clk_data);
> + return;
> +
> +err:
> + kfree(clk_data);
> }
> CLK_OF_DECLARE_DRIVER(sun6i_rtc_clk, "allwinner,sun6i-a31-rtc",
> sun6i_rtc_clk_init);
> --
> 2.11.0
>
--
Alexandre Belloni, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* [PATCH] rtc: sun6i: ensure clk_data is kfree'd on error
From: Colin King @ 2017-07-19 16:57 UTC (permalink / raw)
To: Alessandro Zummo, Alexandre Belloni, Maxime Ripard, Chen-Yu Tsai,
linux-rtc, linux-arm-kernel
Cc: kernel-janitors, linux-kernel
From: Colin Ian King <colin.king@canonical.com>
There are two error return paths that do not kfree clk_data and
we end up with a memory leak. Fix these with a kfree error exit
path.
Detected by CoverityScan, CID#1402959 ("Resource Leak")
Signed-off-by: Colin Ian King <colin.king@canonical.com>
---
drivers/rtc/rtc-sun6i.c | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/rtc/rtc-sun6i.c b/drivers/rtc/rtc-sun6i.c
index 39cbc1238b92..61502221ab6e 100644
--- a/drivers/rtc/rtc-sun6i.c
+++ b/drivers/rtc/rtc-sun6i.c
@@ -204,7 +204,7 @@ static void __init sun6i_rtc_clk_init(struct device_node *node)
rtc->base = of_io_request_and_map(node, 0, of_node_full_name(node));
if (IS_ERR(rtc->base)) {
pr_crit("Can't map RTC registers");
- return;
+ goto err;
}
/* Switch to the external, more precise, oscillator */
@@ -216,7 +216,7 @@ static void __init sun6i_rtc_clk_init(struct device_node *node)
/* Deal with old DTs */
if (!of_get_property(node, "clocks", NULL))
- return;
+ goto err;
rtc->int_osc = clk_hw_register_fixed_rate_with_accuracy(NULL,
"rtc-int-osc",
@@ -246,6 +246,10 @@ static void __init sun6i_rtc_clk_init(struct device_node *node)
clk_data->num = 1;
clk_data->hws[0] = &rtc->hw;
of_clk_add_hw_provider(node, of_clk_hw_onecell_get, clk_data);
+ return;
+
+err:
+ kfree(clk_data);
}
CLK_OF_DECLARE_DRIVER(sun6i_rtc_clk, "allwinner,sun6i-a31-rtc",
sun6i_rtc_clk_init);
--
2.11.0
^ permalink raw reply related
* Re: [PATCH v3 1/4] time: rtc-lib: Add rtc_show_time(const char *prefix_msg)
From: Mark Salyzyn @ 2017-07-19 14:52 UTC (permalink / raw)
To: John Stultz
Cc: lkml, Rafael J. Wysocki, Len Brown, Pavel Machek, Linux PM list,
Alessandro Zummo, Alexandre Belloni, linux-rtc, andy.shevchenko,
Paul E. McKenney, Mark Salyzyn, Thierry Strudel, Thomas Gleixner,
Josh Triplett, Nicolas Pitre, Kees Cook
In-Reply-To: <CALAqxLWK+_vnG_bpp4dPguNDTt1=JG6GANJm6b=V8gF1UGi1VQ@mail.gmail.com>
On 07/18/2017 05:00 PM, John Stultz wrote:
> On Tue, Jul 18, 2017 at 3:15 PM, Mark Salyzyn <salyzyn@android.com> wrote:
>> Go directly to the rtc for persistent wall clock time and print.
> So, first, the above doesn't seem accurate to me. You're using
> getnstimeofday64() which doesn't touch the RTC.
I admit I got that backwards. I copied and pasted a line, that was
supposed to read "We can not go" ... The point was that persistent or
RTC clock is _not_ always available,
so we have to print suspend times when the timeofday clock is available
at the points before suspend, and after suspend is complete.
The "Suspended for" message (in ms, we want us at least) albeit helpful,
is performed at the bottom, and can only be reported if there is a
persistent clock available. On most Android devices, it is not available.
I will post update, a better description in the primary patch, dropping
the intro, printing in <epoch>.<ns> format. I asked in another thread if
it would be OK to preserve the Legacy of RTC time format printing with
another CONFIG parameter since we have 5 years of tooling that depends
on that format.
-- Mark
^ permalink raw reply
* Re: [PATCH v2 1/4] time: rtc-lib: Add rtc_show_time(const char *prefix_msg)
From: Prarit Bhargava @ 2017-07-19 14:28 UTC (permalink / raw)
To: Thomas Gleixner
Cc: Mark Salyzyn, LKML, rjw, len.brown, pavel, linux-pm, a.zummo,
alexandre.belloni, linux-rtc, andy.shevchenko, Mark Salyzyn,
Paul E. McKenney, Thierry Strudel, John Stultz, Richard Cochran,
Nicolas Pitre, Kees Cook, Ingo Molnar, Peter Zijlstra
In-Reply-To: <alpine.DEB.2.20.1707191426060.2286@nanos>
On 07/19/2017 08:28 AM, Thomas Gleixner wrote:
> On Wed, 19 Jul 2017, Prarit Bhargava wrote:
>> On 07/19/2017 03:23 AM, Thomas Gleixner wrote:
>>> There is another option to remedy this and the dmesg tooling issues:
>>>
>>> Instead of switching the time stamps in dmesg to a different clock we might
>>> as well have an optional secondary timestamp. So instead of:
>>>
>>> [ 341.590930] wlan0: associated
>>>
>>> you would get:
>>>
>>> [ 341.590930] [ sec.usec] wlan0: associated
>>>
>>> where the second time stamp would be CLOCK_REALTIME/BOOTTIME.
>>>
>>> That should also solve Prarits problem, hmm?
>>
>> It would but I would prefer a single time stamp be printed than two. I think
>> two timestamps is adding confusion to the output from a end-users point of view.
>
> Fair enough. I came up with that idea when I looked at the old thread. The
> discussion about tools (e.g. dmesg) dried out at some point and looked
> unresolved.
tglx,
There were two outstanding issues with my patchset. The first, as you mention
above, is the issue with tooling. I will handle the chicken-and-egg issue with
the kernel modification and tooling. I will post patches for dmesg & systemd
once the kernel patchset lands in a "next" tree; other tools will have to be
patched as we find them.
The second issue is a sysfs stability and output issue that I have a question
on. Since I'm changing the value of print.time from a bool to an int, the
output of /sys/modules/printk/parameters/time would change from Y/N to 0-3. The
file is not listed in Documentation/ABI/stable so I think I can change it. Can
you confirm that this is the case? I wary of changing anything under sysfs and
I'm not sure who else would know if I can change the output of that file.
If it is the case that the output can be changed, then I'm going to suggest that
we allow, for example, human-readable format "printk.time=monotonic" along with
"printk.time=2" as kernel parameters. I would also like your thoughts on that idea.
If the file cannot be changed I will have to add an additional module parameter
to printk. Does "timestamp" sound okay to you? I will go with whatever you
suggest.
Thanks,
P.
^ permalink raw reply
* Re: [PATCH v2 1/4] time: rtc-lib: Add rtc_show_time(const char *prefix_msg)
From: Thomas Gleixner @ 2017-07-19 12:28 UTC (permalink / raw)
To: Prarit Bhargava
Cc: Mark Salyzyn, LKML, rjw, len.brown, pavel, linux-pm, a.zummo,
alexandre.belloni, linux-rtc, andy.shevchenko, Mark Salyzyn,
Paul E. McKenney, Thierry Strudel, John Stultz, Richard Cochran,
Nicolas Pitre, Kees Cook, Ingo Molnar, Peter Zijlstra
In-Reply-To: <f50dbf47-d1dc-5e51-fdcd-0318c2ab93cd@redhat.com>
On Wed, 19 Jul 2017, Prarit Bhargava wrote:
> On 07/19/2017 03:23 AM, Thomas Gleixner wrote:
> > There is another option to remedy this and the dmesg tooling issues:
> >
> > Instead of switching the time stamps in dmesg to a different clock we might
> > as well have an optional secondary timestamp. So instead of:
> >
> > [ 341.590930] wlan0: associated
> >
> > you would get:
> >
> > [ 341.590930] [ sec.usec] wlan0: associated
> >
> > where the second time stamp would be CLOCK_REALTIME/BOOTTIME.
> >
> > That should also solve Prarits problem, hmm?
>
> It would but I would prefer a single time stamp be printed than two. I think
> two timestamps is adding confusion to the output from a end-users point of view.
Fair enough. I came up with that idea when I looked at the old thread. The
discussion about tools (e.g. dmesg) dried out at some point and looked
unresolved.
Thanks,
tglx
^ permalink raw reply
* Re: [PATCH v2 1/4] time: rtc-lib: Add rtc_show_time(const char *prefix_msg)
From: Prarit Bhargava @ 2017-07-19 12:03 UTC (permalink / raw)
To: Thomas Gleixner, Mark Salyzyn
Cc: LKML, rjw, len.brown, pavel, linux-pm, a.zummo, alexandre.belloni,
linux-rtc, andy.shevchenko, Mark Salyzyn, Paul E. McKenney,
Thierry Strudel, John Stultz, Richard Cochran, Nicolas Pitre,
Kees Cook, Ingo Molnar, Peter Zijlstra
In-Reply-To: <alpine.DEB.2.20.1707190913500.2286@nanos>
On 07/19/2017 03:23 AM, Thomas Gleixner wrote:
> On Tue, 18 Jul 2017, Mark Salyzyn wrote:
>> On 07/18/2017 03:35 PM, Thomas Gleixner wrote:
>>> There was some discussion about making the clock source for dmesg time
>>> stamps selectable, so you can use MONOTONIC, REALTIME, BOOTTIME. The
>>> patches looked sensible, but there was some showstopper vs. the user space
>>> dmesg utility. See:
>>
>> The timestamps are useful for the 'second' purpose of these patches when
>> dmesg time is BOOTTIME or MONOTONIC, and can be turned off if REALTIME
>> is selected. Having rtc_show_time a single point for switching this no doubt
>> helps,
>> not hinders, that dmesg issue.
>>
>> The inflection points would still serve a purpose, still need
>> suspend/resume/hibernate/restore. The reboot messages are _only_ useful to
>> us with their timestamps, as I checked and the only tools that use those are
>> for log synchronization. We may be able to do away with them on REALTIME
>> dmesg'ing; but the standardization of the message as a marker would have a
>> legacy purpose (!)
>>
>> NB: We have a similar configuration for the user space logger, which can be
>> configured to report in MONOTONIC time. We have yet to have a vendor
>> use the feature, opting for REALTIME logging for user space activities.
>> Our klogd (which runs at background priority and is batched) manages a
>> histogram relationship between MONOTONIC and REALTIME helped by these
>> prints and incorporates the REALTIME dmesg logs merged into our user
>> space logging database.
>
> There is another option to remedy this and the dmesg tooling issues:
>
> Instead of switching the time stamps in dmesg to a different clock we might
> as well have an optional secondary timestamp. So instead of:
>
> [ 341.590930] wlan0: associated
>
> you would get:
>
> [ 341.590930] [ sec.usec] wlan0: associated
>
> where the second time stamp would be CLOCK_REALTIME/BOOTTIME.
>
> That should also solve Prarits problem, hmm?
It would but I would prefer a single time stamp be printed than two. I think
two timestamps is adding confusion to the output from a end-users point of view.
Mark, why don't we get together and fixup my original patchset to make sure it
meets your needs? It will fix both of our issues albeit not necessarily in the
text format you want it.
P.
>
> Thanks,
>
> tglx
>
>
^ permalink raw reply
* [PATCH] rtc: zynqmp: Disable the build as a module
From: Michal Simek @ 2017-07-19 11:39 UTC (permalink / raw)
To: linux-kernel, monstr
Cc: Sören Brinkmann, linux-rtc, Alessandro Zummo,
Alexandre Belloni, linux-arm-kernel
The patch:
"timers: Introduce in-kernel alarm-timer interface"
(sha1: ff3ead96d17f47ee70c294a5cc2cce9b61e82f0f)
introduced new requirement that RTC drivers with alarm functionality
can't be used as a module.
When module is unloaded there is still a reference that's why
rtc_device_release() is not called and ida is not freed.
That's why when module is loaded again it can't use the same RTC number
based on aliases.
Log:
sh-4.3# modprobe rtc-zynqmp
[ 42.468565] rtc_zynqmp ffa60000.rtc: rtc core: registered
ffa60000.rtc as rtc5
sh-4.3# rmmod rtc-zynqmp
sh-4.3# modprobe rtc-zynqmp
[ 48.648222] rtc_zynqmp ffa60000.rtc: /aliases ID 5 not available
[ 48.654280] rtc_zynqmp ffa60000.rtc: rtc core: registered
ffa60000.rtc as rtc0
This patch is removing module support which is just a workaround till
alarm-timer interface is fixed to support device releasing when alarm
timer is not used.
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
---
Based on discussion:
https://www.mail-archive.com/rtc-linux@googlegroups.com/msg00908.html
---
drivers/rtc/Kconfig | 2 +-
drivers/rtc/rtc-zynqmp.c | 15 +--------------
2 files changed, 2 insertions(+), 15 deletions(-)
diff --git a/drivers/rtc/Kconfig b/drivers/rtc/Kconfig
index 72419ac2c52a..a2bbe7c2cf92 100644
--- a/drivers/rtc/Kconfig
+++ b/drivers/rtc/Kconfig
@@ -1225,7 +1225,7 @@ config RTC_DRV_OPAL
will be called rtc-opal.
config RTC_DRV_ZYNQMP
- tristate "Xilinx Zynq Ultrascale+ MPSoC RTC"
+ bool "Xilinx Zynq Ultrascale+ MPSoC RTC"
depends on OF
help
If you say yes here you get support for the RTC controller found on
diff --git a/drivers/rtc/rtc-zynqmp.c b/drivers/rtc/rtc-zynqmp.c
index da18a8ae3c1d..5fc50145dbd2 100644
--- a/drivers/rtc/rtc-zynqmp.c
+++ b/drivers/rtc/rtc-zynqmp.c
@@ -268,14 +268,6 @@ static int xlnx_rtc_probe(struct platform_device *pdev)
return PTR_ERR_OR_ZERO(xrtcdev->rtc);
}
-static int xlnx_rtc_remove(struct platform_device *pdev)
-{
- xlnx_rtc_alarm_irq_enable(&pdev->dev, 0);
- device_init_wakeup(&pdev->dev, 0);
-
- return 0;
-}
-
static int __maybe_unused xlnx_rtc_suspend(struct device *dev)
{
struct platform_device *pdev = to_platform_device(dev);
@@ -312,7 +304,6 @@ static int __maybe_unused xlnx_rtc_resume(struct device *dev)
static struct platform_driver xlnx_rtc_driver = {
.probe = xlnx_rtc_probe,
- .remove = xlnx_rtc_remove,
.driver = {
.name = KBUILD_MODNAME,
.pm = &xlnx_rtc_pm_ops,
@@ -320,8 +311,4 @@ static int __maybe_unused xlnx_rtc_resume(struct device *dev)
},
};
-module_platform_driver(xlnx_rtc_driver);
-
-MODULE_DESCRIPTION("Xilinx Zynq MPSoC RTC driver");
-MODULE_AUTHOR("Xilinx Inc.");
-MODULE_LICENSE("GPL v2");
+builtin_platform_driver(xlnx_rtc_driver);
--
1.9.1
^ permalink raw reply related
* Re: [PATCH v2 1/4] time: rtc-lib: Add rtc_show_time(const char *prefix_msg)
From: Thomas Gleixner @ 2017-07-19 7:23 UTC (permalink / raw)
To: Mark Salyzyn
Cc: LKML, rjw, len.brown, pavel, linux-pm, a.zummo, alexandre.belloni,
linux-rtc, andy.shevchenko, Mark Salyzyn, Paul E. McKenney,
Thierry Strudel, John Stultz, Richard Cochran, Nicolas Pitre,
Kees Cook, Ingo Molnar, Peter Zijlstra, Prarit Bhargava
In-Reply-To: <5016ccc4-7faa-b61e-c0a1-b851620849c7@android.com>
On Tue, 18 Jul 2017, Mark Salyzyn wrote:
> On 07/18/2017 03:35 PM, Thomas Gleixner wrote:
> > There was some discussion about making the clock source for dmesg time
> > stamps selectable, so you can use MONOTONIC, REALTIME, BOOTTIME. The
> > patches looked sensible, but there was some showstopper vs. the user space
> > dmesg utility. See:
>
> The timestamps are useful for the 'second' purpose of these patches when
> dmesg time is BOOTTIME or MONOTONIC, and can be turned off if REALTIME
> is selected. Having rtc_show_time a single point for switching this no doubt
> helps,
> not hinders, that dmesg issue.
>
> The inflection points would still serve a purpose, still need
> suspend/resume/hibernate/restore. The reboot messages are _only_ useful to
> us with their timestamps, as I checked and the only tools that use those are
> for log synchronization. We may be able to do away with them on REALTIME
> dmesg'ing; but the standardization of the message as a marker would have a
> legacy purpose (!)
>
> NB: We have a similar configuration for the user space logger, which can be
> configured to report in MONOTONIC time. We have yet to have a vendor
> use the feature, opting for REALTIME logging for user space activities.
> Our klogd (which runs at background priority and is batched) manages a
> histogram relationship between MONOTONIC and REALTIME helped by these
> prints and incorporates the REALTIME dmesg logs merged into our user
> space logging database.
There is another option to remedy this and the dmesg tooling issues:
Instead of switching the time stamps in dmesg to a different clock we might
as well have an optional secondary timestamp. So instead of:
[ 341.590930] wlan0: associated
you would get:
[ 341.590930] [ sec.usec] wlan0: associated
where the second time stamp would be CLOCK_REALTIME/BOOTTIME.
That should also solve Prarits problem, hmm?
Thanks,
tglx
^ permalink raw reply
* Re: [PATCH v3 1/4] time: rtc-lib: Add rtc_show_time(const char *prefix_msg)
From: John Stultz @ 2017-07-19 0:00 UTC (permalink / raw)
To: Mark Salyzyn
Cc: lkml, Rafael J. Wysocki, Len Brown, Pavel Machek, Linux PM list,
Alessandro Zummo, Alexandre Belloni, linux-rtc, andy.shevchenko,
Paul E. McKenney, Mark Salyzyn, Thierry Strudel, Thomas Gleixner,
Josh Triplett, Nicolas Pitre, Kees Cook
In-Reply-To: <20170718221607.132539-1-salyzyn@android.com>
On Tue, Jul 18, 2017 at 3:15 PM, Mark Salyzyn <salyzyn@android.com> wrote:
> Go directly to the rtc for persistent wall clock time and print.
So, first, the above doesn't seem accurate to me. You're using
getnstimeofday64() which doesn't touch the RTC.
> Useful if REALTIME is required to be logged in a low level power
> management function or when clock activities are suspended. An
> aid to permit user space alignment of kernel activities.
This explanation doesn't make much sense either. I've tried looking
over the patch series to better understand but its not super clear
right off.
A good practice is to start by explaining what you want to do ("allow
for battery and suspend time analysis"), and why the current upstream
kernel doesn't provide what you need ("timekeeping can be suspended,
so we want to reference the persistent clock that is always running
and provide a way to align those timestamps with
CLOCK_MONOTONIC/CLOCK_REALTIME timestamps that userspace uses"), and
only then explain how your solution addresses this issue.
> Feature activated by CONFIG_RTC_SHOW_TIME.
>
> Signed-off-by: Mark Salyzyn <salyzyn@android.com>
>
> v2
> - move implementation to kernel timekeeping from rtc_lib files
> - use rtc_time64_to_tm() instead of rtc_time_to_tm()
> - use inline in include/linux/rtc.h for !CONFIG_RTC_SHOW_TIME
> v3
> - _correctly_ use rtc_time64_to_tm
> ---
> include/linux/rtc.h | 5 +++++
> kernel/time/Kconfig | 11 +++++++++++
> kernel/time/Makefile | 1 +
> kernel/time/rtc_show_time.c | 23 +++++++++++++++++++++++
> 4 files changed, 40 insertions(+)
> create mode 100644 kernel/time/rtc_show_time.c
>
> diff --git a/include/linux/rtc.h b/include/linux/rtc.h
> index 0a0f0d14a5fb..779401c937d5 100644
> --- a/include/linux/rtc.h
> +++ b/include/linux/rtc.h
> @@ -22,6 +22,11 @@ extern int rtc_year_days(unsigned int day, unsigned int month, unsigned int year
> extern int rtc_valid_tm(struct rtc_time *tm);
> extern time64_t rtc_tm_to_time64(struct rtc_time *tm);
> extern void rtc_time64_to_tm(time64_t time, struct rtc_time *tm);
> +#ifdef CONFIG_RTC_SHOW_TIME
> +extern void rtc_show_time(const char *prefix_msg);
> +#else
> +static inline void rtc_show_time(const char *prefix_msg) { }
> +#endif
> ktime_t rtc_tm_to_ktime(struct rtc_time tm);
> struct rtc_time rtc_ktime_to_tm(ktime_t kt);
>
> diff --git a/kernel/time/Kconfig b/kernel/time/Kconfig
> index ac09bc29eb08..4da093ae3e37 100644
> --- a/kernel/time/Kconfig
> +++ b/kernel/time/Kconfig
> @@ -145,3 +145,14 @@ config HIGH_RES_TIMERS
>
> endmenu
> endif
> +
> +config RTC_SHOW_TIME
> + bool "rtc_show_time instrumentation"
> + select RTC_LIB
> + help
> + Activate rtc_show_time(const char *msg) wall clock time
> + instrumentation.
> +
> + The instrumentation is used to help triage and synchronize
> + kernel logs using CLOCK_MONOTONIC and user space activity
> + logs utilizing CLOCK_REALTIME references.
RTC_SHOW_TIME seems like a poor name for this, as you're not really
doing much with the RTC here (other then printing the current
CLOCK_REALTIME value to be printed out in in a format that's commonly
used w/ RTC hardware). As for the reference to CLOCK_MONOTONIC, I
assume you are correlating that via printk timestamp (which may not
always be enabled)?
> diff --git a/kernel/time/Makefile b/kernel/time/Makefile
> index 938dbf33ef49..66f17e641052 100644
> --- a/kernel/time/Makefile
> +++ b/kernel/time/Makefile
> @@ -17,3 +17,4 @@ obj-$(CONFIG_GENERIC_SCHED_CLOCK) += sched_clock.o
> obj-$(CONFIG_TICK_ONESHOT) += tick-oneshot.o tick-sched.o
> obj-$(CONFIG_DEBUG_FS) += timekeeping_debug.o
> obj-$(CONFIG_TEST_UDELAY) += test_udelay.o
> +obj-$(CONFIG_RTC_SHOW_TIME) += rtc_show_time.o
> diff --git a/kernel/time/rtc_show_time.c b/kernel/time/rtc_show_time.c
> new file mode 100644
> index 000000000000..bbf4f92abf4f
> --- /dev/null
> +++ b/kernel/time/rtc_show_time.c
> @@ -0,0 +1,23 @@
> +/*
> + * rtc time printing utility functions
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +
> +#include <linux/rtc.h>
> +
> +void rtc_show_time(const char *prefix_msg)
> +{
> + struct timespec64 ts;
> + struct rtc_time tm;
> +
> + getnstimeofday64(&ts);
> + rtc_time64_to_tm(ts.tv_sec, &tm);
> + pr_info("%s %d-%02d-%02d %02d:%02d:%02d.%09lu UTC\n",
> + prefix_msg ? prefix_msg : "Time:",
> + tm.tm_year + 1900, tm.tm_mon + 1, tm.tm_mday,
> + tm.tm_hour, tm.tm_min, tm.tm_sec, ts.tv_nsec);
> +}
> +EXPORT_SYMBOL(rtc_show_time);
Overall, this does feel very single-use-case specific.
thanks
-john
^ permalink raw reply
* Re: [PATCH 3/4] PM: Print wall time at suspend entry and exit
From: Mark Salyzyn @ 2017-07-18 23:26 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: linux-kernel, len.brown, pavel, linux-pm, a.zummo,
alexandre.belloni, linux-rtc
In-Reply-To: <214360396.4sfZrYBT7N@aspire.rjw.lan>
On 07/18/2017 03:25 PM, Rafael J. Wysocki wrote:
> On Tuesday, July 18, 2017 10:25:58 AM Mark Salyzyn wrote:
>> Permits power state and battery life diagnosis.
>>
>> Feature activated by CONFIG_RTC_SHOW_TIME.
>>
>> Signed-off-by: Mark Salyzyn <salyzyn@android.com>
> Please fold the [4/4] into this one and I have a patch series that you'd
> want to rebase this on I guess. I'll send it shortly.
>
> Thanks,
> Rafael
>
Ok, after all the disputes are laid to rest, I will roll these in
together on the respin.
^ permalink raw reply
* Re: [PATCH v2 1/4] time: rtc-lib: Add rtc_show_time(const char *prefix_msg)
From: Mark Salyzyn @ 2017-07-18 23:25 UTC (permalink / raw)
To: Thomas Gleixner
Cc: LKML, rjw, len.brown, pavel, linux-pm, a.zummo, alexandre.belloni,
linux-rtc, andy.shevchenko, Mark Salyzyn, Paul E. McKenney,
Thierry Strudel, John Stultz, Richard Cochran, Nicolas Pitre,
Kees Cook, Ingo Molnar, Peter Zijlstra, Prarit Bhargava
In-Reply-To: <alpine.DEB.2.20.1707190023010.2425@nanos>
[TL;DR]
On 07/18/2017 03:35 PM, Thomas Gleixner wrote:
> Can we please fix the tools and not introduce that horror in the kernel?
IMHO, we can switch this patch to epoch.ns time; but the momentum on the
tools will end up with us internally patching it back to RTC format at
least until
we can get our act together ... I have accepted that risk, we always like to
see all changes upstream though. Would an additional config parameter
appease the situation?
> Just for the record: You cannot use that stuff deep in the suspend/resume
> code because timekeeping is suspended there as well and that call to
> getnstimeofday() is going to trigger a WARNON() when called after
> timekeeping was suspended. So please be more precise about the limitations
> of this.
Yes, I should have been clearer about that, in fact my comments in 0/4
were _backwards_
when I reread them ;-/. One of the issues is the somewhat helpful suspend
millisecond duration requires a persistent clock, which is _not_
available on all
hardware. Printing the time on entry and exit from suspend and resume is
always
possible because we are staying away from that lower level issue.
I should probably roll the details of 0/4 comments into 1/4, the intro
has not served
its purpose.
It should also be made clearer that these single messages serve _two_
purposes,
the primary one is power analysis; the secondary one is log synchronization.
> There was some discussion about making the clock source for dmesg time
> stamps selectable, so you can use MONOTONIC, REALTIME, BOOTTIME. The
> patches looked sensible, but there was some showstopper vs. the user space
> dmesg utility. See:
The timestamps are useful for the 'second' purpose of these patches when
dmesg time is BOOTTIME or MONOTONIC, and can be turned off if REALTIME
is selected. Having rtc_show_time a single point for switching this no
doubt helps,
not hinders, that dmesg issue.
The inflection points would still serve a purpose, still need
suspend/resume/hibernate/restore. The reboot messages are _only_ useful to
us with their timestamps, as I checked and the only tools that use those are
for log synchronization. We may be able to do away with them on REALTIME
dmesg'ing; but the standardization of the message as a marker would have a
legacy purpose (!)
NB: We have a similar configuration for the user space logger, which can be
configured to report in MONOTONIC time. We have yet to have a vendor
use the feature, opting for REALTIME logging for user space activities.
Our klogd (which runs at background priority and is batched) manages a
histogram relationship between MONOTONIC and REALTIME helped by these
prints and incorporates the REALTIME dmesg logs merged into our user
space logging database.
-- Mark
^ permalink raw reply
* Re: [PATCH v3 1/4] time: rtc-lib: Add rtc_show_time(const char *prefix_msg)
From: Thomas Gleixner @ 2017-07-18 22:36 UTC (permalink / raw)
To: Mark Salyzyn
Cc: linux-kernel, rjw, len.brown, pavel, linux-pm, a.zummo,
alexandre.belloni, linux-rtc, andy.shevchenko, Paul E. McKenney,
Mark Salyzyn, Thierry Strudel, John Stultz, Josh Triplett,
Nicolas Pitre, Kees Cook
In-Reply-To: <20170718221607.132539-1-salyzyn@android.com>
On Tue, 18 Jul 2017, Mark Salyzyn wrote:
> Go directly to the rtc for persistent wall clock time and print.
> Useful if REALTIME is required to be logged in a low level power
> management function or when clock activities are suspended. An
> aid to permit user space alignment of kernel activities.
Can you please spare the churn and wait until the discussion about the
general issues is resolved before sending out yet another set of patches,
which do not address any of the real important questions?
Thanks,
tglx
^ permalink raw reply
* Re: [PATCH v2 1/4] time: rtc-lib: Add rtc_show_time(const char *prefix_msg)
From: Thomas Gleixner @ 2017-07-18 22:35 UTC (permalink / raw)
To: Mark Salyzyn
Cc: LKML, rjw, len.brown, pavel, linux-pm, a.zummo, alexandre.belloni,
linux-rtc, andy.shevchenko, Mark Salyzyn, Paul E. McKenney,
Thierry Strudel, John Stultz, Richard Cochran, Nicolas Pitre,
Kees Cook, Ingo Molnar, Peter Zijlstra, Prarit Bhargava
In-Reply-To: <8afb372a-3951-6fb9-c0be-82756623061f@android.com>
On Tue, 18 Jul 2017, Mark Salyzyn wrote:
> On 07/18/2017 02:52 PM, Thomas Gleixner wrote:
> > Why on earth do you need to print that information in RTC format? What's
> > wrong with just doing:
> >
> > pr_info("My so important log message %lld\n",
> > ktime_get_real_seconds());
>
> Legacy (these prints have been in Android tree since 2013) for all our battery
> and power analysis tools are keyed off RTC format. There is some momentum,
> default should be epoch seconds/nanoseconds as that is a good example; and
> another option can select RTC (the option can be an internal patch to alter
> the format ... ick)
Can we please fix the tools and not introduce that horror in the kernel?
> > and then decoding the seconds in post processing? That's completely
> > sufficient as you intend that for logging. Correlation with user space
> > CLOCK_REALTIME is even simpler as this is the same as reading it from user
> > space.
> This is part of triage and post-analysis, there is no user space call that can
> be made after the fact to correlate MONOTONIC time with REALTIME. The
> historgram for the relationship between the two time formats is built up in
> user space based on batched analysis of the kernel logs. Although the values
> slip because of ntp and other sources, suspend/resume/hibernate/restore and
> shutdown are definitive points of interest for analysis. The analysis is
> performed on klogd data which has a longer logging span than the internal
> buffer.
Printing ktime_get_real_seconds() gives you the wall time. I was merily
explaining that this is the same as reading CLOCK_REALTIME from userspace.
Just for the record: You cannot use that stuff deep in the suspend/resume
code because timekeeping is suspended there as well and that call to
getnstimeofday() is going to trigger a WARNON() when called after
timekeeping was suspended. So please be more precise about the limitations
of this.
> > If your main intention is logging/debugging, then you can just use
> > tracepoints. The tracer allows correlation to user space tracing already.
> tracepoints are disabled on field devices. As is debugfs. This is not
> logging/debugging, but field battery and power analysis. Some of the data
> shows up in the Battery Settings screen on the devices. We also _benefit_ from
> this information when correlating kernel logs with user space logs during
> triage.
There was some discussion about making the clock source for dmesg time
stamps selectable, so you can use MONOTONIC, REALTIME, BOOTTIME. The
patches looked sensible, but there was some showstopper vs. the user space
dmesg utility. See:
http://lkml.kernel.org/r/1456250040-22351-1-git-send-email-prarit@redhat.com
I rather see that resolved and these patches merged than having yet another
half baken special purpose debug band aid. Maybe Prarit can shed some light
on the state of this.
Thanks,
tglx
^ permalink raw reply
* Re: [PATCH 3/4] PM: Print wall time at suspend entry and exit
From: Rafael J. Wysocki @ 2017-07-18 22:25 UTC (permalink / raw)
To: Mark Salyzyn
Cc: linux-kernel, len.brown, pavel, linux-pm, a.zummo,
alexandre.belloni, linux-rtc
In-Reply-To: <20170718172600.114761-1-salyzyn@android.com>
On Tuesday, July 18, 2017 10:25:58 AM Mark Salyzyn wrote:
> Permits power state and battery life diagnosis.
>
> Feature activated by CONFIG_RTC_SHOW_TIME.
>
> Signed-off-by: Mark Salyzyn <salyzyn@android.com>
Please fold the [4/4] into this one and I have a patch series that you'd
want to rebase this on I guess. I'll send it shortly.
Thanks,
Rafael
^ permalink raw reply
* [PATCH v3 1/4] time: rtc-lib: Add rtc_show_time(const char *prefix_msg)
From: Mark Salyzyn @ 2017-07-18 22:15 UTC (permalink / raw)
To: linux-kernel
Cc: rjw, len.brown, pavel, linux-pm, a.zummo, alexandre.belloni,
linux-rtc, andy.shevchenko, Mark Salyzyn, Paul E. McKenney,
Mark Salyzyn, Thierry Strudel, Thomas Gleixner, John Stultz,
Josh Triplett, Nicolas Pitre, Kees Cook
Go directly to the rtc for persistent wall clock time and print.
Useful if REALTIME is required to be logged in a low level power
management function or when clock activities are suspended. An
aid to permit user space alignment of kernel activities.
Feature activated by CONFIG_RTC_SHOW_TIME.
Signed-off-by: Mark Salyzyn <salyzyn@android.com>
v2
- move implementation to kernel timekeeping from rtc_lib files
- use rtc_time64_to_tm() instead of rtc_time_to_tm()
- use inline in include/linux/rtc.h for !CONFIG_RTC_SHOW_TIME
v3
- _correctly_ use rtc_time64_to_tm
---
include/linux/rtc.h | 5 +++++
kernel/time/Kconfig | 11 +++++++++++
kernel/time/Makefile | 1 +
kernel/time/rtc_show_time.c | 23 +++++++++++++++++++++++
4 files changed, 40 insertions(+)
create mode 100644 kernel/time/rtc_show_time.c
diff --git a/include/linux/rtc.h b/include/linux/rtc.h
index 0a0f0d14a5fb..779401c937d5 100644
--- a/include/linux/rtc.h
+++ b/include/linux/rtc.h
@@ -22,6 +22,11 @@ extern int rtc_year_days(unsigned int day, unsigned int month, unsigned int year
extern int rtc_valid_tm(struct rtc_time *tm);
extern time64_t rtc_tm_to_time64(struct rtc_time *tm);
extern void rtc_time64_to_tm(time64_t time, struct rtc_time *tm);
+#ifdef CONFIG_RTC_SHOW_TIME
+extern void rtc_show_time(const char *prefix_msg);
+#else
+static inline void rtc_show_time(const char *prefix_msg) { }
+#endif
ktime_t rtc_tm_to_ktime(struct rtc_time tm);
struct rtc_time rtc_ktime_to_tm(ktime_t kt);
diff --git a/kernel/time/Kconfig b/kernel/time/Kconfig
index ac09bc29eb08..4da093ae3e37 100644
--- a/kernel/time/Kconfig
+++ b/kernel/time/Kconfig
@@ -145,3 +145,14 @@ config HIGH_RES_TIMERS
endmenu
endif
+
+config RTC_SHOW_TIME
+ bool "rtc_show_time instrumentation"
+ select RTC_LIB
+ help
+ Activate rtc_show_time(const char *msg) wall clock time
+ instrumentation.
+
+ The instrumentation is used to help triage and synchronize
+ kernel logs using CLOCK_MONOTONIC and user space activity
+ logs utilizing CLOCK_REALTIME references.
diff --git a/kernel/time/Makefile b/kernel/time/Makefile
index 938dbf33ef49..66f17e641052 100644
--- a/kernel/time/Makefile
+++ b/kernel/time/Makefile
@@ -17,3 +17,4 @@ obj-$(CONFIG_GENERIC_SCHED_CLOCK) += sched_clock.o
obj-$(CONFIG_TICK_ONESHOT) += tick-oneshot.o tick-sched.o
obj-$(CONFIG_DEBUG_FS) += timekeeping_debug.o
obj-$(CONFIG_TEST_UDELAY) += test_udelay.o
+obj-$(CONFIG_RTC_SHOW_TIME) += rtc_show_time.o
diff --git a/kernel/time/rtc_show_time.c b/kernel/time/rtc_show_time.c
new file mode 100644
index 000000000000..bbf4f92abf4f
--- /dev/null
+++ b/kernel/time/rtc_show_time.c
@@ -0,0 +1,23 @@
+/*
+ * rtc time printing utility functions
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include <linux/rtc.h>
+
+void rtc_show_time(const char *prefix_msg)
+{
+ struct timespec64 ts;
+ struct rtc_time tm;
+
+ getnstimeofday64(&ts);
+ rtc_time64_to_tm(ts.tv_sec, &tm);
+ pr_info("%s %d-%02d-%02d %02d:%02d:%02d.%09lu UTC\n",
+ prefix_msg ? prefix_msg : "Time:",
+ tm.tm_year + 1900, tm.tm_mon + 1, tm.tm_mday,
+ tm.tm_hour, tm.tm_min, tm.tm_sec, ts.tv_nsec);
+}
+EXPORT_SYMBOL(rtc_show_time);
--
2.13.2.932.g7449e964c-goog
^ permalink raw reply related
* Re: [PATCH v2 2/4] time: Print wall time at die and reboot
From: Thomas Gleixner @ 2017-07-18 22:06 UTC (permalink / raw)
To: Mark Salyzyn
Cc: linux-kernel, rjw, len.brown, pavel, linux-pm, a.zummo,
alexandre.belloni, linux-rtc, Mark Salyzyn, Thierry Strudel
In-Reply-To: <20170718212117.123296-1-salyzyn@android.com>
On Tue, 18 Jul 2017, Mark Salyzyn wrote:
> Permits power state and battery life diagnosis.
This changelog is useless as long as you do not explain in which whay that
permits power state and battery life diagnosis.
I really have a hard time to figure out why you need to print RTC time on
oops or any of the other actions. That whole thing looks pretty
overengineered for a dubious value.
What kind of information is the current stuff missing and how are you using
this new information for better diagnosis?
Thanks,
tglx
^ permalink raw reply
* Re: [PATCH v2 1/4] time: rtc-lib: Add rtc_show_time(const char *prefix_msg)
From: Mark Salyzyn @ 2017-07-18 22:06 UTC (permalink / raw)
To: Thomas Gleixner
Cc: linux-kernel, rjw, len.brown, pavel, linux-pm, a.zummo,
alexandre.belloni, linux-rtc, andy.shevchenko, Mark Salyzyn,
Paul E. McKenney, Thierry Strudel, John Stultz, Richard Cochran,
Nicolas Pitre, Kees Cook
In-Reply-To: <alpine.DEB.2.20.1707182338470.2425@nanos>
On 07/18/2017 02:52 PM, Thomas Gleixner wrote:
> On Tue, 18 Jul 2017, Mark Salyzyn wrote:
>
>> Go directly to the rtc for persistent wall clock time and print.
>> Useful if REALTIME is required to be logged in a low level power
>> management function or when clock activities are suspended. An
>> aid to permit user space alignment of kernel activities.
> That's a horrible idea, really. And there is no point at all.
>
>> +void rtc_show_time(const char *prefix_msg)
>> +{
>> + struct timespec ts;
>> + struct rtc_time tm;
>> +
>> + getnstimeofday(&ts);
> It calls getnstimeofday(), which is wrong to begin with as we switch
> everything in kernel to the 64bit variants.
oops, good catch.
>
>> + rtc_time64_to_tm(ts.tv_sec, &tm);
> This is even more wrong as rtc_time64_to_tm is for 64 bit wide second
> values....
Again, oops, changed rtc_time_to_tm to rtc_time64_to_tm as requested,
did not change other pieces.
>
>> + pr_info("%s %d-%02d-%02d %02d:%02d:%02d.%09lu UTC\n",
>> + prefix_msg ? prefix_msg : "Time:",
>> + tm.tm_year + 1900, tm.tm_mon + 1, tm.tm_mday,
>> + tm.tm_hour, tm.tm_min, tm.tm_sec, ts.tv_nsec);
> Why on earth do you need to print that information in RTC format? What's
> wrong with just doing:
>
> pr_info("My so important log message %lld\n", ktime_get_real_seconds());
Legacy (these prints have been in Android tree since 2013) for all our
battery and power analysis tools are keyed off RTC format. There is some
momentum, default should be epoch seconds/nanoseconds as that is a good
example; and another option can select RTC (the option can be an
internal patch to alter the format ... ick)
>
> and then decoding the seconds in post processing? That's completely
> sufficient as you intend that for logging. Correlation with user space
> CLOCK_REALTIME is even simpler as this is the same as reading it from user
> space.
This is part of triage and post-analysis, there is no user space call
that can be made after the fact to correlate MONOTONIC time with
REALTIME. The historgram for the relationship between the two time
formats is built up in user space based on batched analysis of the
kernel logs. Although the values slip because of ntp and other sources,
suspend/resume/hibernate/restore and shutdown are definitive points of
interest for analysis. The analysis is performed on klogd data which has
a longer logging span than the internal buffer.
>
> If your main intention is logging/debugging, then you can just use
> tracepoints. The tracer allows correlation to user space tracing already.
tracepoints are disabled on field devices. As is debugfs. This is not
logging/debugging, but field battery and power analysis. Some of the
data shows up in the Battery Settings screen on the devices. We also
_benefit_ from this information when correlating kernel logs with user
space logs during triage.
>
> So unless you can come up with a reasonable explanation why all this voodoo
> is required, this is going nowhere.
>
> Thanks,
>
> tglx
>
>
>
>
^ permalink raw reply
* Re: [PATCH v2 1/4] time: rtc-lib: Add rtc_show_time(const char *prefix_msg)
From: Thomas Gleixner @ 2017-07-18 21:52 UTC (permalink / raw)
To: Mark Salyzyn
Cc: linux-kernel, rjw, len.brown, pavel, linux-pm, a.zummo,
alexandre.belloni, linux-rtc, andy.shevchenko, Mark Salyzyn,
Paul E. McKenney, Thierry Strudel, John Stultz, Richard Cochran,
Nicolas Pitre, Kees Cook
In-Reply-To: <20170718211930.123077-1-salyzyn@android.com>
On Tue, 18 Jul 2017, Mark Salyzyn wrote:
> Go directly to the rtc for persistent wall clock time and print.
> Useful if REALTIME is required to be logged in a low level power
> management function or when clock activities are suspended. An
> aid to permit user space alignment of kernel activities.
That's a horrible idea, really. And there is no point at all.
> +void rtc_show_time(const char *prefix_msg)
> +{
> + struct timespec ts;
> + struct rtc_time tm;
> +
> + getnstimeofday(&ts);
It calls getnstimeofday(), which is wrong to begin with as we switch
everything in kernel to the 64bit variants.
> + rtc_time64_to_tm(ts.tv_sec, &tm);
This is even more wrong as rtc_time64_to_tm is for 64 bit wide second
values....
> + pr_info("%s %d-%02d-%02d %02d:%02d:%02d.%09lu UTC\n",
> + prefix_msg ? prefix_msg : "Time:",
> + tm.tm_year + 1900, tm.tm_mon + 1, tm.tm_mday,
> + tm.tm_hour, tm.tm_min, tm.tm_sec, ts.tv_nsec);
Why on earth do you need to print that information in RTC format? What's
wrong with just doing:
pr_info("My so important log message %lld\n", ktime_get_real_seconds());
and then decoding the seconds in post processing? That's completely
sufficient as you intend that for logging. Correlation with user space
CLOCK_REALTIME is even simpler as this is the same as reading it from user
space.
If your main intention is logging/debugging, then you can just use
tracepoints. The tracer allows correlation to user space tracing already.
So unless you can come up with a reasonable explanation why all this voodoo
is required, this is going nowhere.
Thanks,
tglx
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox