From: Andrea Arcangeli <andrea@suse.de>
To: Ingo Molnar <mingo@elte.hu>
Cc: Andrew Morton <akpm@osdl.org>,
linas@austin.ibm.com, linux-kernel@vger.kernel.org
Subject: Re: PATCH: Race in 2.6.0-test2 timer code
Date: Wed, 30 Jul 2003 09:34:58 +0200 [thread overview]
Message-ID: <20030730073458.GA23835@dualathlon.random> (raw)
In-Reply-To: <Pine.LNX.4.44.0307300842550.29469-100000@localhost.localdomain>
On Wed, Jul 30, 2003 at 09:07:59AM +0200, Ingo Molnar wrote:
>
> On Tue, 29 Jul 2003, Andrew Morton wrote:
>
> > Well Andrea did mention a problem with the interval timers. But I am
> > not aware of the exact details of the race which he found, and I don't
> > understand why del_timer() and add_timer() would be needing the
> > per-timer locks.
>
> hmm ... indeed i cannot see the 2.6 itimer race anymore. Andrea, can you
> see any SMP races in the current 2.6 timer code?
>
> (in any case, i still think it would be safer to 'upgrade' the add_timer()
> interface to be SMP-safe and to allow double-adds - but not for any bug
> reason anymore.)
The thing triggered simply by running setitimer in one function, while
the it_real_fn was running in the other cpu. I don't see how 2.6 can
have fixed this, it_real_fun can still trivially call add_timer while
you run inside do_setitimer in 2.6 too. It's simply that 2.6 isn't
running in production yet, so a bug that didn't showup in years of 2.5,
showsup in a month of 2.4. But even if you serialized some how
it_real_fn against do_setitimer (and I don't see any external
serialization in 2.6 in current bkcvs) I wouldn't trust 2.6 drivers not
to execute del_timer_sync in parallel anyways etc.. that's why I didn't
search for too many 2.6 timer bugs too much, and I still suggested to
apply the locking despite I only known about a single bug. The real
scalability optimization is probably only the fast path check in
mod_timer, and the cacheline bouncing avoidance in the timer global data
structures like the cascading queues, the per-timer lock should do well,
and I'd feel much safer with the whole timer API being smp safe w/o
requiring driver developers to add complicated external brainer locking.
This will provide a much more friendly abstraction.
I would be definitely against putting external locking in
do_setitimer/it_timer_fn in 2.6 since like you missed that place, there
can be still tons of other buggy drivers out there that don't trigger
simply because the userspace is still too small.
Andrea
next prev parent reply other threads:[~2003-07-30 7:32 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-07-29 15:41 PATCH: Race in 2.6.0-test2 timer code linas
2003-07-29 20:56 ` Andrew Morton
2003-07-30 5:57 ` Ingo Molnar
2003-07-30 6:36 ` Andrew Morton
2003-07-30 7:07 ` Ingo Molnar
2003-07-30 7:34 ` Andrea Arcangeli [this message]
2003-07-30 7:34 ` Ingo Molnar
2003-07-30 8:28 ` Andrea Arcangeli
2003-07-30 10:31 ` Ingo Molnar
2003-07-30 11:16 ` Andrea Arcangeli
2003-07-30 11:49 ` Ingo Molnar
2003-07-30 12:34 ` Andrea Arcangeli
2003-07-30 21:18 ` linas
2003-07-30 22:06 ` Andrea Arcangeli
2003-07-30 22:17 ` Andrea Arcangeli
2003-07-31 7:04 ` Ingo Molnar
2003-07-30 21:19 ` Andrea Arcangeli
2003-07-30 23:43 ` linas
2003-07-30 23:56 ` Andrea Arcangeli
2003-07-30 23:54 ` Andrew Morton
2003-07-31 0:16 ` Andrea Arcangeli
2003-07-31 17:23 ` linas
2003-08-01 6:27 ` Ingo Molnar
2003-07-30 7:40 ` Ingo Molnar
2003-07-30 8:37 ` Andrea Arcangeli
2003-07-30 10:34 ` Ingo Molnar
2003-07-30 10:51 ` Andrew Morton
2003-07-30 11:28 ` Andrea Arcangeli
2003-07-30 11:22 ` Andrea Arcangeli
2003-07-30 20:05 ` linas
2003-07-31 6:50 ` Ingo Molnar
2003-07-31 22:56 ` linas
2003-08-01 6:23 ` Ingo Molnar
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=20030730073458.GA23835@dualathlon.random \
--to=andrea@suse.de \
--cc=akpm@osdl.org \
--cc=linas@austin.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
/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;
as well as URLs for NNTP newsgroup(s).