public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Brian Gerst <bgerst@didntduck.org>
To: Andreas Schwab <schwab@suse.de>
Cc: Keith Owens <kaos@ocs.com.au>,
	Todd Inglett <tinglett@vnet.ibm.com>,
	Alexander Viro <viro@math.psu.edu>,
	linux-kernel@vger.kernel.org
Subject: Re: SMP races in proc with thread_struct
Date: Fri, 04 May 2001 09:38:52 -0400	[thread overview]
Message-ID: <3AF2B0EC.F576090F@didntduck.org> (raw)
In-Reply-To: <8541.988980403@ocs3.ocs-net> <jer8y52r92.fsf@hawking.suse.de>

Andreas Schwab wrote:
> 
> Keith Owens <kaos@ocs.com.au> writes:
> 
> |> On Fri, 04 May 2001 07:34:20 -0500,
> |> Todd Inglett <tinglett@vnet.ibm.com> wrote:
> |> >But this is where hell breaks loose.  Every process has a valid parent
> |> >-- unless it is dead and nobody cares.  Process N has already exited and
> |> >released from the tasklist while its parent was still alive.  There was
> |> >no reason to reparent it.  It just got released.  So N's task_struct has
> |> >a dangling ptr to its parent.  Nobody is holding the parent task_struct,
> |> >either.  When the parent died memory for its task_struct was released.
> |> >This is ungood.
> |>
> |> Wrap the reference to the parent task structure with exception table
> |> recovery code, like copy_from_user().
> 
> Exception tables only protect accesses to user virtual memory.  Kernel
> memory references must always be valid in the first place.
> 
> Andreas.

The virtual address being accessed is irrelevant.  It's the address of
the faulting instruction that determines what the kernel will do if it
can't deal with a page fault.  If the access was made from kernel mode
the exception handler (if there is one) always gets invoked, otherwise
it oopses.

--

				Brian Gerst

  reply	other threads:[~2001-05-04 13:40 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-05-01 14:30 SMP races in proc with thread_struct Todd Inglett
2001-05-01 16:50 ` Alexander Viro
2001-05-03 11:47   ` Todd Inglett
2001-05-04 12:34     ` Todd Inglett
2001-05-04 12:46       ` Keith Owens
2001-05-04 13:11         ` Andreas Schwab
2001-05-04 13:38           ` Brian Gerst [this message]
2001-05-04 23:27           ` Keith Owens
2001-05-04 14:21         ` Andreas Ferber
2001-05-04 15:18           ` Todd Inglett
2001-05-04 16:04       ` Alexander Viro
2001-05-04 17:52       ` [PATCH][RFC] " Alexander Viro

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=3AF2B0EC.F576090F@didntduck.org \
    --to=bgerst@didntduck.org \
    --cc=kaos@ocs.com.au \
    --cc=linux-kernel@vger.kernel.org \
    --cc=schwab@suse.de \
    --cc=tinglett@vnet.ibm.com \
    --cc=viro@math.psu.edu \
    /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