From: Oleg Nesterov <oleg@tv-sign.ru>
To: Mark McLoughlin <markmc@redhat.com>
Cc: linux-kernel@vger.kernel.org, kvm@vger.kernel.org,
Roland McGrath <roland@redhat.com>,
Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [PATCH] posix-timers: Do not modify an already queued timer signal
Date: Thu, 17 Jul 2008 17:55:56 +0400 [thread overview]
Message-ID: <20080717135556.GA770@tv-sign.ru> (raw)
In-Reply-To: <1216292911.28332.12.camel@muff>
On 07/17, Mark McLoughlin wrote:
>
> On Wed, 2008-07-16 at 20:21 +0400, Oleg Nesterov wrote:
> > On 07/16, Mark McLoughlin wrote:
> > >
> > > When a timer fires, posix_timer_event() zeroes out its
> > > pre-allocated siginfo structure, initialises it and then
> > > queues up the signal with send_sigqueue().
> > >
> > > However, we may have previously queued up this signal, in
> > > which case we only want to increment si_overrun and
> > > re-initialising the siginfo structure is incorrect.
> >
> > Quoting Roland McGrath:
> > >
> > > I'm not clear on how the already-queued case could ever happen. Do we
> > > really need that check at all? It shouldn't be possible for the timer to
> > > be firing when it's already queued, because it won't have been reloaded.
> > > It only reloads via do_schedule_next_timer after it's dequeued, or because
> > > a 1 return value said it never was queued.
>
> The app can reload the timer itself before the signal has been dequeued
> via signalfd ...
Indeed! Thanks Mark.
Thomas, Roland, could you take a look?
> > If we need this fix, perhaps it is better to modify posix_timer_event()
> > to check !list_empty()?
>
> Yeah, I had considered that, but it's a tad more invasive. See below.
>
> I mainly don't like this patch
Agreed, this one looks worse.
I forgot (if ever knew ;) this code completely, but can't we make a simpler
fix? posix_timer_event() can check list_empty() lockless,
posix_timer_event()
{
if (!list_emtpy(sigq->list))
return 0;
... fill and send ->sigq...
}
When the signal will be dequeued, schedule_next_timer() should afaics
set ->it_overrun_last which is copied to ->si_overrun then. Or we can
increment timr->it_overrun before return if I misread hrtimer_forward().
What do you think?
Another possible fix... we can change sys_timer_settime() to do
sigqueue_free() and re-alloc ->sigq when it is pending. Not that
I like this very much though.
Oleg.
next prev parent reply other threads:[~2008-07-17 13:52 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-07-16 14:50 [PATCH] posix-timers: Do not modify an already queued timer signal Mark McLoughlin
2008-07-16 15:33 ` Mark McLoughlin
2008-07-16 16:21 ` Oleg Nesterov
2008-07-17 11:08 ` Mark McLoughlin
2008-07-17 13:55 ` Oleg Nesterov [this message]
2008-07-18 10:39 ` Mark McLoughlin
2008-07-19 16:37 ` Oleg Nesterov
2008-07-20 6:52 ` Roland McGrath
2008-07-20 11:08 ` Oleg Nesterov
2008-07-20 12:26 ` Oleg Nesterov
2008-07-21 0:47 ` Roland McGrath
2008-07-21 15:23 ` Oleg Nesterov
2008-07-21 15:40 ` do_schedule_next_timer && si_overrun (Was: [PATCH] posix-timers: Do not modify an already queued timer signal) Oleg Nesterov
2008-07-21 15:55 ` [PATCH] posix-timers: Do not modify an already queued timer signal Oliver Pinter
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=20080717135556.GA770@tv-sign.ru \
--to=oleg@tv-sign.ru \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=markmc@redhat.com \
--cc=roland@redhat.com \
--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.