linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH] kdb: Change timespec to use timespec64
@ 2018-01-25  8:05 Baolin Wang
  2018-01-25  8:55 ` Arnd Bergmann
  0 siblings, 1 reply; 7+ messages in thread
From: Baolin Wang @ 2018-01-25  8:05 UTC (permalink / raw)
  To: jason.wessel, daniel.thompson
  Cc: baolin.wang, mingo, arnd, broonie, kgdb-bugreport, linux-kernel

Since struct timespec is not y2038 safe on 32 bit machines, thus replace
uses of struct timespec with struct timespec64 in the kernel.

Signed-off-by: Baolin Wang <baolin.wang@linaro.org>
---
 kernel/debug/kdb/kdb_main.c |   10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/kernel/debug/kdb/kdb_main.c b/kernel/debug/kdb/kdb_main.c
index c8146d5..c20c61e 100644
--- a/kernel/debug/kdb/kdb_main.c
+++ b/kernel/debug/kdb/kdb_main.c
@@ -2488,7 +2488,7 @@ struct kdb_tm {
 	int tm_year;	/* year */
 };
 
-static void kdb_gmtime(struct timespec *tv, struct kdb_tm *tm)
+static void kdb_gmtime(struct timespec64 *tv, struct kdb_tm *tm)
 {
 	/* This will work from 1970-2099, 2100 is not a leap year */
 	static int mon_day[] = { 31, 29, 31, 30, 31, 30, 31,
@@ -2521,8 +2521,8 @@ static void kdb_gmtime(struct timespec *tv, struct kdb_tm *tm)
  */
 static void kdb_sysinfo(struct sysinfo *val)
 {
-	struct timespec uptime;
-	ktime_get_ts(&uptime);
+	struct timespec64 uptime;
+	ktime_get_ts64(&uptime);
 	memset(val, 0, sizeof(*val));
 	val->uptime = uptime.tv_sec;
 	val->loads[0] = avenrun[0];
@@ -2539,7 +2539,7 @@ static void kdb_sysinfo(struct sysinfo *val)
  */
 static int kdb_summary(int argc, const char **argv)
 {
-	struct timespec now;
+	struct timespec64 now;
 	struct kdb_tm tm;
 	struct sysinfo val;
 
@@ -2554,7 +2554,7 @@ static int kdb_summary(int argc, const char **argv)
 	kdb_printf("domainname %s\n", init_uts_ns.name.domainname);
 	kdb_printf("ccversion  %s\n", __stringify(CCVERSION));
 
-	now = __current_kernel_time();
+	now = current_kernel_time64();
 	kdb_gmtime(&now, &tm);
 	kdb_printf("date       %04d-%02d-%02d %02d:%02d:%02d "
 		   "tz_minuteswest %d\n",
-- 
1.7.9.5

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

* Re: [PATCH] kdb: Change timespec to use timespec64
  2018-01-25  8:05 [PATCH] kdb: Change timespec to use timespec64 Baolin Wang
@ 2018-01-25  8:55 ` Arnd Bergmann
  2018-01-25  9:18   ` Baolin Wang
  0 siblings, 1 reply; 7+ messages in thread
From: Arnd Bergmann @ 2018-01-25  8:55 UTC (permalink / raw)
  To: Baolin Wang
  Cc: Jason Wessel, Daniel Thompson, Ingo Molnar, Mark Brown,
	kgdb-bugreport, Linux Kernel Mailing List

On Thu, Jan 25, 2018 at 9:05 AM, Baolin Wang <baolin.wang@linaro.org> wrote:
> @@ -2554,7 +2554,7 @@ static int kdb_summary(int argc, const char **argv)
>         kdb_printf("domainname %s\n", init_uts_ns.name.domainname);
>         kdb_printf("ccversion  %s\n", __stringify(CCVERSION));
>
> -       now = __current_kernel_time();
> +       now = current_kernel_time64();
>         kdb_gmtime(&now, &tm);
>         kdb_printf("date       %04d-%02d-%02d %02d:%02d:%02d "
>                    "tz_minuteswest %d\n",

Thanks for picking this one up again, we should find a permanent solution here.
Unfortunately you patch is incorrect, as we cannot safely call
current_kernel_time64()
from NMI context.

The __ prefix on __current_kernel_time() indicates that this is a special call
that intentionally doesn't read the hardware time to avoid taking locks that
might already be held in the context from which we entered the debugger.

See https://patchwork.kernel.org/patch/10002097/ for my earlier patch.

> @@ -2521,8 +2521,8 @@ static void kdb_gmtime(struct timespec *tv, struct kdb_tm *tm)
>   */
>  static void kdb_sysinfo(struct sysinfo *val)
>  {
> -       struct timespec uptime;
> -       ktime_get_ts(&uptime);
> +       struct timespec64 uptime;
> +       ktime_get_ts64(&uptime);
>         memset(val, 0, sizeof(*val));
>         val->uptime = uptime.tv_sec;
>         val->loads[0] = avenrun[0];

This function appears to have the same problem, except that it is a preexisting
issue in this case. I had not noticed this earlier, but we must fix it
in a similar
manner to the other one.

        Arnd

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

* Re: [PATCH] kdb: Change timespec to use timespec64
  2018-01-25  8:55 ` Arnd Bergmann
@ 2018-01-25  9:18   ` Baolin Wang
  2018-01-25 11:38     ` Daniel Thompson
  0 siblings, 1 reply; 7+ messages in thread
From: Baolin Wang @ 2018-01-25  9:18 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: Jason Wessel, Daniel Thompson, Ingo Molnar, Mark Brown,
	kgdb-bugreport, Linux Kernel Mailing List

On 25 January 2018 at 16:55, Arnd Bergmann <arnd@arndb.de> wrote:
> On Thu, Jan 25, 2018 at 9:05 AM, Baolin Wang <baolin.wang@linaro.org> wrote:
>> @@ -2554,7 +2554,7 @@ static int kdb_summary(int argc, const char **argv)
>>         kdb_printf("domainname %s\n", init_uts_ns.name.domainname);
>>         kdb_printf("ccversion  %s\n", __stringify(CCVERSION));
>>
>> -       now = __current_kernel_time();
>> +       now = current_kernel_time64();
>>         kdb_gmtime(&now, &tm);
>>         kdb_printf("date       %04d-%02d-%02d %02d:%02d:%02d "
>>                    "tz_minuteswest %d\n",
>
> Thanks for picking this one up again, we should find a permanent solution here.
> Unfortunately you patch is incorrect, as we cannot safely call
> current_kernel_time64()
> from NMI context.

Ah, thanks for pointing out the issue, since I do not know what
context the function will be called in kdb.

>
> The __ prefix on __current_kernel_time() indicates that this is a special call
> that intentionally doesn't read the hardware time to avoid taking locks that
> might already be held in the context from which we entered the debugger.
>
> See https://patchwork.kernel.org/patch/10002097/ for my earlier patch.

This patch had not been merged into mainline?

>
>> @@ -2521,8 +2521,8 @@ static void kdb_gmtime(struct timespec *tv, struct kdb_tm *tm)
>>   */
>>  static void kdb_sysinfo(struct sysinfo *val)
>>  {
>> -       struct timespec uptime;
>> -       ktime_get_ts(&uptime);
>> +       struct timespec64 uptime;
>> +       ktime_get_ts64(&uptime);
>>         memset(val, 0, sizeof(*val));
>>         val->uptime = uptime.tv_sec;
>>         val->loads[0] = avenrun[0];
>
> This function appears to have the same problem, except that it is a preexisting
> issue in this case. I had not noticed this earlier, but we must fix it
> in a similar
> manner to the other one.

OK.

-- 
Baolin.wang
Best Regards

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

* Re: [PATCH] kdb: Change timespec to use timespec64
  2018-01-25  9:18   ` Baolin Wang
@ 2018-01-25 11:38     ` Daniel Thompson
  2018-01-25 14:49       ` Jason Wessel
  0 siblings, 1 reply; 7+ messages in thread
From: Daniel Thompson @ 2018-01-25 11:38 UTC (permalink / raw)
  To: Baolin Wang
  Cc: Arnd Bergmann, Jason Wessel, Ingo Molnar, Mark Brown,
	kgdb-bugreport, Linux Kernel Mailing List

On Thu, Jan 25, 2018 at 05:18:54PM +0800, Baolin Wang wrote:
> On 25 January 2018 at 16:55, Arnd Bergmann <arnd@arndb.de> wrote:
> > On Thu, Jan 25, 2018 at 9:05 AM, Baolin Wang <baolin.wang@linaro.org> wrote:
> >> @@ -2554,7 +2554,7 @@ static int kdb_summary(int argc, const char **argv)
> >>         kdb_printf("domainname %s\n", init_uts_ns.name.domainname);
> >>         kdb_printf("ccversion  %s\n", __stringify(CCVERSION));
> >>
> >> -       now = __current_kernel_time();
> >> +       now = current_kernel_time64();
> >>         kdb_gmtime(&now, &tm);
> >>         kdb_printf("date       %04d-%02d-%02d %02d:%02d:%02d "
> >>                    "tz_minuteswest %d\n",
> >
> > Thanks for picking this one up again, we should find a permanent solution here.
> > Unfortunately you patch is incorrect, as we cannot safely call
> > current_kernel_time64()
> > from NMI context.
> 
> Ah, thanks for pointing out the issue, since I do not know what
> context the function will be called in kdb.
> 
> >
> > The __ prefix on __current_kernel_time() indicates that this is a special call
> > that intentionally doesn't read the hardware time to avoid taking locks that
> > might already be held in the context from which we entered the debugger.
> >
> > See https://patchwork.kernel.org/patch/10002097/ for my earlier patch.
> 
> This patch had not been merged into mainline?

Not yet (and I'm afraid it's not in kgdb-next either) but the ack from Jason is from 
this kernel cycle so we'll see what can be done!


Daniel.

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

* Re: [PATCH] kdb: Change timespec to use timespec64
  2018-01-25 11:38     ` Daniel Thompson
@ 2018-01-25 14:49       ` Jason Wessel
  2018-01-25 15:12         ` Arnd Bergmann
  0 siblings, 1 reply; 7+ messages in thread
From: Jason Wessel @ 2018-01-25 14:49 UTC (permalink / raw)
  To: Daniel Thompson, Baolin Wang
  Cc: Arnd Bergmann, Ingo Molnar, Mark Brown, kgdb-bugreport,
	Linux Kernel Mailing List

On 01/25/2018 05:38 AM, Daniel Thompson wrote:
> On Thu, Jan 25, 2018 at 05:18:54PM +0800, Baolin Wang wrote:
>> On 25 January 2018 at 16:55, Arnd Bergmann <arnd@arndb.de> wrote:
>>> On Thu, Jan 25, 2018 at 9:05 AM, Baolin Wang <baolin.wang@linaro.org> wrote:
>>>> @@ -2554,7 +2554,7 @@ static int kdb_summary(int argc, const char **argv)
>>>>          kdb_printf("domainname %s\n", init_uts_ns.name.domainname);
>>>>          kdb_printf("ccversion  %s\n", __stringify(CCVERSION));
>>>>
>>>> -       now = __current_kernel_time();
>>>> +       now = current_kernel_time64();
>>>>          kdb_gmtime(&now, &tm);
>>>>          kdb_printf("date       %04d-%02d-%02d %02d:%02d:%02d "
>>>>                     "tz_minuteswest %d\n",
>>>
>>> Thanks for picking this one up again, we should find a permanent solution here.
>>> Unfortunately you patch is incorrect, as we cannot safely call
>>> current_kernel_time64()
>>> from NMI context.
>>
>> Ah, thanks for pointing out the issue, since I do not know what
>> context the function will be called in kdb.
>>
>>>
>>> The __ prefix on __current_kernel_time() indicates that this is a special call
>>> that intentionally doesn't read the hardware time to avoid taking locks that
>>> might already be held in the context from which we entered the debugger.
>>>
>>> See https://patchwork.kernel.org/patch/10002097/ for my earlier patch.
>>
>> This patch had not been merged into mainline?
> 
> Not yet (and I'm afraid it's not in kgdb-next either) but the ack from Jason is from
> this kernel cycle so we'll see what can be done!
> 
> 

I thought for what ever reason this was going through the time keeper subtree.   I added it immediately to kgdb-next so it will be evaluated in the linux-next tree in the next day or so, and we can get this merged in the merge window.

Thanks,
Jason.

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

* Re: [PATCH] kdb: Change timespec to use timespec64
  2018-01-25 14:49       ` Jason Wessel
@ 2018-01-25 15:12         ` Arnd Bergmann
  2018-01-26  1:40           ` Baolin Wang
  0 siblings, 1 reply; 7+ messages in thread
From: Arnd Bergmann @ 2018-01-25 15:12 UTC (permalink / raw)
  To: Jason Wessel
  Cc: Daniel Thompson, Baolin Wang, Ingo Molnar, Mark Brown,
	kgdb-bugreport, Linux Kernel Mailing List

On Thu, Jan 25, 2018 at 3:49 PM, Jason Wessel
<jason.wessel@windriver.com> wrote:
> On 01/25/2018 05:38 AM, Daniel Thompson wrote:
>>
>> On Thu, Jan 25, 2018 at 05:18:54PM +0800, Baolin Wang wrote:
>>>
>>> On 25 January 2018 at 16:55, Arnd Bergmann <arnd@arndb.de> wrote:
>>>>
>>>> On Thu, Jan 25, 2018 at 9:05 AM, Baolin Wang <baolin.wang@linaro.org>
>>>> wrote:
>>>>>
>>>>> @@ -2554,7 +2554,7 @@ static int kdb_summary(int argc, const char
>>>>> **argv)
>>>>>          kdb_printf("domainname %s\n", init_uts_ns.name.domainname);
>>>>>          kdb_printf("ccversion  %s\n", __stringify(CCVERSION));
>>>>>
>>>>> -       now = __current_kernel_time();
>>>>> +       now = current_kernel_time64();
>>>>>          kdb_gmtime(&now, &tm);
>>>>>          kdb_printf("date       %04d-%02d-%02d %02d:%02d:%02d "
>>>>>                     "tz_minuteswest %d\n",
>>>>
>>>>
>>>> Thanks for picking this one up again, we should find a permanent
>>>> solution here.
>>>> Unfortunately you patch is incorrect, as we cannot safely call
>>>> current_kernel_time64()
>>>> from NMI context.
>>>
>>>
>>> Ah, thanks for pointing out the issue, since I do not know what
>>> context the function will be called in kdb.
>>>
>>>>
>>>> The __ prefix on __current_kernel_time() indicates that this is a
>>>> special call
>>>> that intentionally doesn't read the hardware time to avoid taking locks
>>>> that
>>>> might already be held in the context from which we entered the debugger.
>>>>
>>>> See https://patchwork.kernel.org/patch/10002097/ for my earlier patch.
>>>
>>>
>>> This patch had not been merged into mainline?
>>
>>
>> Not yet (and I'm afraid it's not in kgdb-next either) but the ack from
>> Jason is from
>> this kernel cycle so we'll see what can be done!
>>
>>
>
> I thought for what ever reason this was going through the time keeper
> subtree.   I added it immediately to kgdb-next so it will be evaluated in
> the linux-next tree in the next day or so, and we can get this merged in the
> merge window.

Ok, thanks a lot!

We should still come up with a patch for kdb_sysinfo(), which doesn't
have a problem with time overflow (monotonic time doesn't overflow)
but has an issue with locking and uses 'struct timespec'.

Baolin, could you respin your patch on top of Jason's tree and
replace ktime_get_ts64() with something based on ktime_get_fast_ns?

        Arnd

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

* Re: [PATCH] kdb: Change timespec to use timespec64
  2018-01-25 15:12         ` Arnd Bergmann
@ 2018-01-26  1:40           ` Baolin Wang
  0 siblings, 0 replies; 7+ messages in thread
From: Baolin Wang @ 2018-01-26  1:40 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: Jason Wessel, Daniel Thompson, Ingo Molnar, Mark Brown,
	kgdb-bugreport, Linux Kernel Mailing List

On 25 January 2018 at 23:12, Arnd Bergmann <arnd@arndb.de> wrote:
> On Thu, Jan 25, 2018 at 3:49 PM, Jason Wessel
> <jason.wessel@windriver.com> wrote:
>> On 01/25/2018 05:38 AM, Daniel Thompson wrote:
>>>
>>> On Thu, Jan 25, 2018 at 05:18:54PM +0800, Baolin Wang wrote:
>>>>
>>>> On 25 January 2018 at 16:55, Arnd Bergmann <arnd@arndb.de> wrote:
>>>>>
>>>>> On Thu, Jan 25, 2018 at 9:05 AM, Baolin Wang <baolin.wang@linaro.org>
>>>>> wrote:
>>>>>>
>>>>>> @@ -2554,7 +2554,7 @@ static int kdb_summary(int argc, const char
>>>>>> **argv)
>>>>>>          kdb_printf("domainname %s\n", init_uts_ns.name.domainname);
>>>>>>          kdb_printf("ccversion  %s\n", __stringify(CCVERSION));
>>>>>>
>>>>>> -       now = __current_kernel_time();
>>>>>> +       now = current_kernel_time64();
>>>>>>          kdb_gmtime(&now, &tm);
>>>>>>          kdb_printf("date       %04d-%02d-%02d %02d:%02d:%02d "
>>>>>>                     "tz_minuteswest %d\n",
>>>>>
>>>>>
>>>>> Thanks for picking this one up again, we should find a permanent
>>>>> solution here.
>>>>> Unfortunately you patch is incorrect, as we cannot safely call
>>>>> current_kernel_time64()
>>>>> from NMI context.
>>>>
>>>>
>>>> Ah, thanks for pointing out the issue, since I do not know what
>>>> context the function will be called in kdb.
>>>>
>>>>>
>>>>> The __ prefix on __current_kernel_time() indicates that this is a
>>>>> special call
>>>>> that intentionally doesn't read the hardware time to avoid taking locks
>>>>> that
>>>>> might already be held in the context from which we entered the debugger.
>>>>>
>>>>> See https://patchwork.kernel.org/patch/10002097/ for my earlier patch.
>>>>
>>>>
>>>> This patch had not been merged into mainline?
>>>
>>>
>>> Not yet (and I'm afraid it's not in kgdb-next either) but the ack from
>>> Jason is from
>>> this kernel cycle so we'll see what can be done!
>>>
>>>
>>
>> I thought for what ever reason this was going through the time keeper
>> subtree.   I added it immediately to kgdb-next so it will be evaluated in
>> the linux-next tree in the next day or so, and we can get this merged in the
>> merge window.
>
> Ok, thanks a lot!
>
> We should still come up with a patch for kdb_sysinfo(), which doesn't
> have a problem with time overflow (monotonic time doesn't overflow)
> but has an issue with locking and uses 'struct timespec'.
>
> Baolin, could you respin your patch on top of Jason's tree and
> replace ktime_get_ts64() with something based on ktime_get_fast_ns?

Sure, I will do that today.

-- 
Baolin.wang
Best Regards

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

end of thread, other threads:[~2018-01-26  1:40 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-01-25  8:05 [PATCH] kdb: Change timespec to use timespec64 Baolin Wang
2018-01-25  8:55 ` Arnd Bergmann
2018-01-25  9:18   ` Baolin Wang
2018-01-25 11:38     ` Daniel Thompson
2018-01-25 14:49       ` Jason Wessel
2018-01-25 15:12         ` Arnd Bergmann
2018-01-26  1:40           ` Baolin Wang

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