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
next prev parent 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 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.