From: Maxim Levitsky <maximlevitsky@gmail.com>
To: Alan Stern <stern@rowland.harvard.edu>
Cc: linux-kernel@vger.kernel.org, netdev@vger.kernel.org,
linux-pm@lists.linux-foundation.org
Subject: Re: [linux-pm] QUESTION: How to fix race between .suspend routine and watchdog timer
Date: Sat, 27 Oct 2007 21:19:44 +0200 [thread overview]
Message-ID: <200710272119.44574.maximlevitsky@gmail.com> (raw)
In-Reply-To: <Pine.LNX.4.44L0.0710271516570.30287-100000@netrider.rowland.org>
On Saturday 27 October 2007 21:17:55 Alan Stern wrote:
> On Fri, 26 Oct 2007, Maxim Levitsky wrote:
>
> > > > Looking through the dmfe code, I noticed yet another possible race.
> > > > A race between the .suspend, and a timer that serves both as a watchdog, and link state detector.
> > > > Again I need to prevent it from running during the suspend/resume, but how?
> > > >
> > > > I can use del_timer in .suspend, and mod_timer in .resume, but that doesn't protect against
> > > > race with already running timer.
> > > > I can use del_timer_sync, but it states that it is useless if timer re-enables itself, and I agree with that.
> > > > In dmfe case the timer does re-enable itself.
> > >
> > > That comment isn't right. del_timer_sync works perfectly well even if
> > > the timer routine re-enables itself, provided it stops doing so after a
> > > small number of iterations.
> > Thanks for the info. but....
> > Due to the "don't access the hardware, while powered-off" rule, I must know that the timer isn't running.
> > and won't be.
> > So what function to use (if possible) to be sure that the timer won't run anymore?
> > (Taking in the account the fact that it re-enables itself)
>
> Use del_timer_sync(). It guarantees that when it returns, the timer
> will be stopped and the timer routine will no longer be running on any
> CPU.
>
Even if the timer re-enables itself, are you sure?
> Alan Stern
>
>
Best regards,
Maxim Levitsky
next prev parent reply other threads:[~2007-10-27 19:22 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-10-25 4:12 QUESTION: How to fix race between .suspend routine and watchdog timer Maxim Levitsky
2007-10-25 17:02 ` [linux-pm] " Alan Stern
2007-10-26 11:48 ` Maxim Levitsky
2007-10-26 11:48 ` [linux-pm] " Maxim Levitsky
2007-10-27 19:17 ` Alan Stern
2007-10-27 19:19 ` Maxim Levitsky
2007-10-27 19:19 ` Maxim Levitsky [this message]
2007-10-27 22:24 ` Alan Stern
2007-10-27 22:24 ` [linux-pm] " Alan Stern
2007-10-28 19:19 ` Maxim Levitsky
2007-10-28 19:19 ` Maxim Levitsky
2007-10-27 19:17 ` Alan Stern
2007-10-25 17:02 ` Alan Stern
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=200710272119.44574.maximlevitsky@gmail.com \
--to=maximlevitsky@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@lists.linux-foundation.org \
--cc=netdev@vger.kernel.org \
--cc=stern@rowland.harvard.edu \
/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.