From: Oleg Nesterov <oleg@tv-sign.ru>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Austin Clements <amdragon+kernelbugzilla@mit.edu>,
Ingo Molnar <mingo@elte.hu>, john stultz <johnstul@us.ibm.com>,
Michael Kerrisk <mtk.manpages@googlemail.com>,
Roland McGrath <roland@redhat.com>,
Thomas Gleixner <tglx@linutronix.de>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 3/3] posix timers: use SIGQUEUE_CANCELLED when the timer is destroyed
Date: Sun, 18 May 2008 21:46:46 +0400 [thread overview]
Message-ID: <20080518174646.GA25915@tv-sign.ru> (raw)
In-Reply-To: <alpine.LFD.1.10.0805181024050.3020@woody.linux-foundation.org>
On 05/18, Linus Torvalds wrote:
>
> On Sun, 18 May 2008, Oleg Nesterov wrote:
> >
> > Initially, I did
> >
> > q->flags |= SIGQUEUE_CANCELLED;
> > spin_lock_irqsave(lock, flags);
> > q->flags &= ~SIGQUEUE_PREALLOC;
> >
> > to document the fact that SIGQUEUE_CANCELLED can be set lockless, but
> > then "optimized" the code, couldn't help myself... Besides, the code
> > above looks really confusing without the fat comment.
>
> Oh, and the above is *wrong*.
>
> Why?
>
> Becayse if SIGQUEUE_PREALLOC setting needs the lock, then setting any
> *other* bit in that word will also need the lock!
>
> That's because
>
> q->flags |= SIGQUEUE_CANCELLED;
>
> writes those other bits too - admittedly with the value they were read
> just before, but if it races with something setting SIGQUEUE_PREALLOC that
> doesn't matter - the newly written version will simply be wrong.
>
> So the rule is that if one bit of a word needs locking, then they *all*
> do.
Ah. I wasn't clear.
Clearing of SIGQUEUE_PREALLOC needs ->siglock, yes. But not because anybody
else can write to q->flags. Nobody can, we (the timer) "own" this sigqueue.
Once we clear SIGQUEUE_PREALLOC, "q" can be freed by the receiver (it doesn't
writes to q->flags, it only reads ->flags). After that we can't trust the
list_empty() check, we just can't dereference this "struct sigqueue *".
Taking ->siglock before "&= ~SIGQUEUE_PREALLOC" ensures that "q" can't be
be freed if it is queued, nothing more.
Oleg.
next prev parent reply other threads:[~2008-05-18 17:47 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-05-17 15:14 [PATCH 3/3] posix timers: use SIGQUEUE_CANCELLED when the timer is destroyed Oleg Nesterov
2008-05-17 15:31 ` Oleg Nesterov
2008-05-17 17:11 ` Linus Torvalds
2008-05-18 17:15 ` Oleg Nesterov
2008-05-18 17:24 ` Linus Torvalds
2008-05-18 17:40 ` Linus Torvalds
2008-05-18 17:46 ` Oleg Nesterov [this message]
2008-05-21 2:27 ` Roland McGrath
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=20080518174646.GA25915@tv-sign.ru \
--to=oleg@tv-sign.ru \
--cc=akpm@linux-foundation.org \
--cc=amdragon+kernelbugzilla@mit.edu \
--cc=johnstul@us.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=mtk.manpages@googlemail.com \
--cc=roland@redhat.com \
--cc=tglx@linutronix.de \
--cc=torvalds@linux-foundation.org \
/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.