All of lore.kernel.org
 help / color / mirror / Atom feed
From: John Stultz <johnstul@us.ibm.com>
To: Thomas Gleixner <tglx@linutronix.de>
Cc: Linux Kernel <linux-kernel@vger.kernel.org>,
	Prarit Bhargava <prarit@redhat.com>,
	stable@vger.kernel.org
Subject: Re: [PATCH 1/2] [RFC] Fix clock_was_set so it is safe to call from atomic
Date: Mon, 02 Jul 2012 15:11:20 -0700	[thread overview]
Message-ID: <4FF21C88.3060801@us.ibm.com> (raw)
In-Reply-To: <alpine.LFD.2.02.1207021050500.2793@ionos>

On 07/02/2012 01:53 AM, Thomas Gleixner wrote:
> On Sun, 1 Jul 2012, John Stultz wrote:
>
>> NOTE:This is a prerequisite patch that's required to
>> address the widely observed leap-second related futex/hrtimer
>> issues.
>>
>> Currently clock_was_set() is unsafe to be called from atomic
>> context, as it calls on_each_cpu(). This causes problems when
>> we need to adjust the time from update_wall_time().
>>
>> To fix this, introduce a work_struct so if we're in_atomic,
>> we can schedule work to do the necessary update after we're
>> out of the atomic section.
> Shouldn't we queue a timer_list timer with expiry time jiffies + 0
> instead. We can call on_each_cpu() from softirq context. And that
> ensures that the update happens right away, while a scheduled work
> might be delayed arbitrary long.
Thanks for the feedback.
I've implemented this, but before I send it out, I'm trying to see if 
there's not a way to change hrtimers so it doesn't keep its own per-cpu 
sense of time.  If I don't sort that out shortly, I'll go ahead and send 
your suggestion out for inclusion so the fix is committed and I can try 
to further improve it afterwards.

thanks
-john


  reply	other threads:[~2012-07-02 22:12 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-07-01 18:29 [PATCH 0/2][RFC] Potential fix for leapsecond caused futex issue (v2) John Stultz
2012-07-01 18:30 ` [PATCH 1/2] [RFC] Fix clock_was_set so it is safe to call from atomic John Stultz
2012-07-02  8:53   ` Thomas Gleixner
2012-07-02 22:11     ` John Stultz [this message]
2012-07-01 18:30 ` [PATCH 2/2] [RFC] Fix leapsecond triggered hrtimer/futex load spike issue John Stultz
2012-07-01 18:34 ` [PATCH 0/2][RFC] Potential fix for leapsecond caused futex issue (v2) John Stultz
2012-07-01 18:47 ` Jan Engelhardt
2012-07-01 22:05 ` John Stultz
2012-07-02  4:12 ` John Stultz
2012-07-02 13:53   ` Prarit Bhargava
2012-07-02 18:51   ` Dave Jones
2012-07-02 19:08     ` John Stultz

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4FF21C88.3060801@us.ibm.com \
    --to=johnstul@us.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=prarit@redhat.com \
    --cc=stable@vger.kernel.org \
    --cc=tglx@linutronix.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.