From: Manfred Spraul <manfred@colorfullife.com>
To: Linus Torvalds <torvalds@transmeta.com>
Cc: "Martin J. Bligh" <mbligh@aracnet.com>,
Anton Blanchard <anton@samba.org>, Andrew Morton <akpm@digeo.com>,
Kernel Mailing List <linux-kernel@vger.kernel.org>,
Zwane Mwaikambo <zwane@holomorphy.com>
Subject: Re: more signal locking bugs?
Date: Mon, 17 Feb 2003 07:36:56 +0100 [thread overview]
Message-ID: <3E508308.4020400@colorfullife.com> (raw)
In-Reply-To: <Pine.LNX.4.44.0302161620020.1609-100000@home.transmeta.com>
Linus Torvalds wrote:
>On Sun, 16 Feb 2003, Manfred Spraul wrote:
>
>
>>What about this minimal patch? The performance critical operation is
>>signal delivery - we should fix the synchronization between signal
>>delivery and exec first.
>>
>>
>
>Ok, I committed this alternative change, which isn't quite as minimal, but
>looks a lot cleaner to me.
>
>Also, looking at execve() and other paths, we do seem to have sufficient
>protection from the tasklist_lock that signal delivery should be fine. So
>despite a long and confused thread, I think in the end the only real bug
>was the one Martin found which should be thus fixed..
>
>
I'm not convinced that exec is correct.
app with two threads, cloned sighand and sig structures.
thread one does exec().
thread two does exit().
Now we can arrive at no_thread_group in de_thread() and
tsk->sig{,hand}->count == 1.
>no_thread_group:
>
> write_lock_irq(&tasklist_lock);
> spin_lock(&oldsighand->siglock);
> spin_lock(&newsighand->siglock);
>
> if (current == oldsig->curr_target)
> oldsig->curr_target = next_thread(current);
>
signal sender: in send_sig_info().
reads tsk->signal. blocks on tsk->sighand->siglock.
> if (newsig)
> current->signal = newsig;
> current->sighand = newsighand;
> init_sigpending(¤t->pending);
> recalc_sigpending();
>
> spin_unlock(&newsighand->siglock);
> spin_unlock(&oldsighand->siglock);
> write_unlock_irq(&tasklist_lock);
>
> if (newsig && atomic_dec_and_test(&oldsig->count))
> kmem_cache_free(signal_cachep, oldsig);
>
> if (atomic_dec_and_test(&oldsighand->count))
> kmem_cache_free(sighand_cachep, oldsighand);
>
>
And now the signal sender continues. BOOM.
sighand structure, sig structure already kfreed, etc.
--
Manfred
next prev parent reply other threads:[~2003-02-17 6:27 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20030215172407.1fdd41fd.akpm@digeo.com>
2003-02-16 1:35 ` Fw: 2.5.61 oops running SDET Linus Torvalds
2003-02-16 2:09 ` Martin J. Bligh
2003-02-16 2:27 ` Linus Torvalds
2003-02-16 4:00 ` Martin J. Bligh
2003-02-16 13:05 ` Anton Blanchard
2003-02-16 16:39 ` Martin J. Bligh
2003-02-16 18:21 ` Linus Torvalds
2003-02-16 19:06 ` Martin J. Bligh
2003-02-16 19:17 ` Linus Torvalds
2003-02-16 21:15 ` Martin J. Bligh
2003-02-16 21:21 ` Manfred Spraul
2003-02-16 22:34 ` Linus Torvalds
2003-02-16 23:08 ` Martin J. Bligh
2003-02-16 23:32 ` Linus Torvalds
2003-02-16 19:18 ` Manfred Spraul
2003-02-16 19:19 ` more signal locking bugs? Martin J. Bligh
2003-02-16 19:24 ` Linus Torvalds
2003-02-16 19:37 ` Manfred Spraul
2003-02-16 19:42 ` Linus Torvalds
2003-02-16 20:01 ` Linus Torvalds
2003-02-16 20:07 ` Manfred Spraul
2003-02-16 20:10 ` Linus Torvalds
2003-02-16 20:23 ` Manfred Spraul
2003-02-17 0:23 ` Linus Torvalds
2003-02-17 2:05 ` Martin J. Bligh
2003-02-17 2:39 ` Martin J. Bligh
2003-02-17 3:53 ` Linus Torvalds
2003-02-17 5:07 ` Martin J. Bligh
2003-02-17 6:17 ` Martin J. Bligh
2003-02-17 17:09 ` Magnus Naeslund(f)
2003-02-17 3:54 ` [PATCH] fix secondary oops in sighand locking Martin J. Bligh
2003-02-17 6:36 ` Manfred Spraul [this message]
2003-02-17 19:06 ` more signal locking bugs? Linus Torvalds
2003-02-16 18:07 ` Fw: 2.5.61 oops running SDET Linus Torvalds
2003-02-16 18:26 ` Martin J. Bligh
2003-02-16 18:36 ` Martin J. Bligh
2003-02-16 2:48 ` Zwane Mwaikambo
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=3E508308.4020400@colorfullife.com \
--to=manfred@colorfullife.com \
--cc=akpm@digeo.com \
--cc=anton@samba.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mbligh@aracnet.com \
--cc=torvalds@transmeta.com \
--cc=zwane@holomorphy.com \
/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.