From: Peter Xu <peterx@redhat.com>
To: linux-kernel@vger.kernel.org
Cc: Thomas Gleixner <tglx@linutronix.de>,
John Stultz <john.stultz@linaro.org>,
Stephen Boyd <sboyd@kernel.org>,
Luiz Capitulino <lcapitulino@redhat.com>,
Marcelo Tosatti <mtosatti@redhat.com>
Subject: Re: [PATCH] timers: Fix up get_target_base() to use old base properly
Date: Tue, 4 Jun 2019 13:42:16 +0800 [thread overview]
Message-ID: <20190604054216.GB15459@xz-x1> (raw)
In-Reply-To: <20190603132944.9726-1-peterx@redhat.com>
On Mon, Jun 03, 2019 at 09:29:44PM +0800, Peter Xu wrote:
> get_target_base() in the timer code is not using the "base" parameter
> at all. My gut feeling is that instead of removing that extra
> parameter, what we really want to do is "return the old base if it
> does not suite for a new one".
I'm trying to think of a detailed scenario of this patch:
1. setup a timer T1 with TIMER_PINNED on cpu 3 and arm it
2. on another cpu (e.g., cpu 4), call mod_timer() upon T1 before the
timer fires itself
2.1. in __mod_timer(), lock_timer_base() will return cpu 3's
timer base because it was pinned with cpu 3
2.2. in the same __mod_timer(), get_target_base() will return cpu
4's timer base if without this patch, and will return cpu
3's timer base if with this patch
I don't know whether step 2 is easy to happen but I don't see why it
was forbidden so I'm assuming it could still happen... Then IMHO if
without this patch, the timer T1 will be queued on cpu 4's timer base
rather than cpu 3's, which seems to break TIMER_PINNED.
And just in case if this patch makes sense - get_timer_this_cpu_base()
can be dropped together since not used any more.
--
Peter Xu
next prev parent reply other threads:[~2019-06-04 5:42 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-06-03 13:29 [PATCH] timers: Fix up get_target_base() to use old base properly Peter Xu
2019-06-04 5:42 ` Peter Xu [this message]
2019-06-06 15:28 ` Marcelo Tosatti
2019-06-10 1:05 ` Peter Xu
2019-06-17 4:09 ` Peter Xu
2019-06-17 6:09 ` Thomas Gleixner
2019-06-17 9:11 ` Peter Xu
2019-06-17 12:07 ` Thomas Gleixner
2019-06-18 0:41 ` Peter Xu
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=20190604054216.GB15459@xz-x1 \
--to=peterx@redhat.com \
--cc=john.stultz@linaro.org \
--cc=lcapitulino@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mtosatti@redhat.com \
--cc=sboyd@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox