All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jeff Dike <jdike@addtoit.com>
To: John Reiser <jreiser@BitWagon.com>
Cc: uml-devel <user-mode-linux-devel@lists.sourceforge.net>
Subject: Re: [uml-devel] should there be os_clone() analogous to os_getpid() ?
Date: Sun, 9 Dec 2007 10:10:54 -0500	[thread overview]
Message-ID: <20071209151054.GA4368@c2.user-mode-linux.org> (raw)
In-Reply-To: <475B6E19.6040200@BitWagon.com>

On Sat, Dec 08, 2007 at 08:24:57PM -0800, John Reiser wrote:
>In source file arch/um/os-Linux/process.c there is a warning:
>-----
>/* Don't use the glibc version, which caches the result in TLS. It misses some
> * syscalls, and also breaks with clone(), which does not unshare the TLS.
> */
> 
>int os_getpid(void)

AFAIK, there are two reasons that we make sure we call the system call
getpid -
	when we're testing ptrace, we want getpid to result in exactly
one system call
	there was a brief bug in libc where getpid returned the wrong
answer due to caching across a clone

This bug did get into the wild, and people did try to run UML on such
systems, so that's why the code is careful about making the system call.

> I see no os_clone(), yet the glibc clone() does the same caching of pid in
> ThreadLocalStorage [TLS], and the TLS still may be shared.  If nobody reads
> glibc's shared TLS slot for PID then an actual bug will be avoided.  However,
> it is unsafe to leave such a tempting pitfall.

What's the actual bug, exactly?  As long as libc's getpid gives us the
right answer, we're happy.

> Also, if you are ptrace()ing
> through a glibc clone(), then in many cases you will see syscall(__NR_getpid)
> *from glibc* immediately following!  There is an "extra" getpid()
> that the tracking logic might not expect.

Where do we care about how clone translates into a system call?

>    arch/um/drivers/ubd_user.c
>    arch/um/kernel/tt/tracer.c
>    arch/um/os/tt.c
>    arch/um/os/start_up.c
>    arch/um/os/skas/process.c

These guys all just want a new process - they don't care how it
happens.

Is something in here causing valgrind some trouble?

				Jeff

-- 
Work email - jdike at linux dot intel dot com

-------------------------------------------------------------------------
SF.Net email is sponsored by: 
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

  reply	other threads:[~2007-12-09 15:11 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-12-09  4:24 [uml-devel] should there be os_clone() analogous to os_getpid() ? John Reiser
2007-12-09 15:10 ` Jeff Dike [this message]
2007-12-09 20:58   ` John Reiser
2007-12-10 17:09     ` Jeff Dike

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=20071209151054.GA4368@c2.user-mode-linux.org \
    --to=jdike@addtoit.com \
    --cc=jreiser@BitWagon.com \
    --cc=user-mode-linux-devel@lists.sourceforge.net \
    /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.