All of lore.kernel.org
 help / color / mirror / Atom feed
From: Manfred Spraul <manfred@colorfullife.com>
To: Linus Torvalds <torvalds@transmeta.com>
Cc: "Martin J. Bligh" <mbligh@aracnet.com>,
	linux-kernel@vger.kernel.org, Anton Blanchard <anton@samba.org>,
	Zwane Mwaikambo <zwane@holomorphy.com>
Subject: Re: Fw: 2.5.61 oops running SDET
Date: Sun, 16 Feb 2003 19:45:53 +0100	[thread overview]
Message-ID: <3E4FDC61.8060301@colorfullife.com> (raw)
In-Reply-To: <Pine.LNX.4.44.0302161013560.2619-100000@home.transmeta.com>

Linus Torvalds wrote:

>On Sun, 16 Feb 2003, Manfred Spraul wrote:
>  
>
>>AFAICS both exec and exit rely on write_lock_irq(tasklist_lock) for 
>>synchronization of changes to tsk->sig{,hand}.
>>    
>>
>
>Yeah, as I sent out in my last email this does seem to be true right now, 
>but it's really not correct. It's disgusting that we use such a 
>fundamental global lock to protect something so trivially local to the one 
>process, where the local per-process lock really should be more than 
>enough.
>
The difference between the tasklist_lock and task_lock is that task_lock 
is not an interrupt lock.
Think about signal delivery during exec.

Do you want to replace tasklist_lock with task_lock in exit_sighand() 
and during exec, or do you want to add task_lock to tasklist_lock?

Hmm.
Someone removed the read_lock(tasklist_lock) around 
send_specific_sig_info() - which lock synchronizes exec and signal delivery?

--
    Manfred


  reply	other threads:[~2003-02-16 18:36 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-02-16 17:41 Fw: 2.5.61 oops running SDET Manfred Spraul
2003-02-16 18:15 ` Linus Torvalds
2003-02-16 18:45   ` Manfred Spraul [this message]
2003-02-16 18:56     ` Linus Torvalds
     [not found] <20030215172407.1fdd41fd.akpm@digeo.com>
2003-02-16  1:35 ` 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 18:07         ` 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=3E4FDC61.8060301@colorfullife.com \
    --to=manfred@colorfullife.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.