mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Martin J. Bligh" <mbligh@aracnet.com>
To: Linus Torvalds <torvalds@transmeta.com>
Cc: Andrew Morton <akpm@digeo.com>,
	Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: Fw: 2.5.61 oops running SDET
Date: Sun, 16 Feb 2003 10:26:26 -0800	[thread overview]
Message-ID: <24190000.1045419985@[10.10.2.4]> (raw)
In-Reply-To: <Pine.LNX.4.44.0302160952280.2619-100000@home.transmeta.com>

> So the choice seems to be either:
> 
>  - make the exit path hold the task lock over the whole exit path, not 
>    just over mm exit.
> 
>  - take the "tasklist_lock" over more of "task_sig()" (not just the 
>    collect_sigign_sigcatch() thing, but the "&p->signal->shared_pending"  
>    rendering too.
> 
> The latter is a two-liner. The former is the "right thing" for multiple 
> reasons.
> 
> The reason I'd _like_ to see the task lock held over _all_ of the fields
> in the exit() path is:
> 
>  - right now we actually take it and drop it multiple times in exit. See 
>    __exit_files(), __exit_fs(), __exit_mm(). Which all take it just to 
>    serialize setting ot "mm/files/fs" to NULL.
> 
>  - task_lock is a nice local lock, no global scalability impact.

Don't we have to take tasklist_lock anyway for when task_state reads
p->real_parent->pid and p->parent->pid? Or should we have to grab
the task_lock for those too? If so, it sounds like it could get into 
rather horrible ordering dependencies to me. 

If we move exit under task_lock ... then tasklist_lock doesn't help us
any more there either (presumably we're trying to stop them exiting 
whilst we look at them) ... I've coded up the stupid approach for now, 
and will check that works first. Should have results very soon.

M.


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

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [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 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                             ` more signal locking bugs? Manfred Spraul
2003-02-17 19:06                               ` Linus Torvalds
2003-02-16 18:07         ` Fw: 2.5.61 oops running SDET Linus Torvalds
2003-02-16 18:26           ` Martin J. Bligh [this message]
2003-02-16 18:36             ` Martin J. Bligh
2003-02-16  2:48     ` Zwane Mwaikambo
2003-02-16 17:41 Manfred Spraul
2003-02-16 18:15 ` Linus Torvalds
2003-02-16 18:45   ` Manfred Spraul
2003-02-16 18:56     ` Linus Torvalds

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='24190000.1045419985@[10.10.2.4]' \
    --to=mbligh@aracnet.com \
    --cc=akpm@digeo.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=torvalds@transmeta.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®