public inbox for glibc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "mtk.manpages at gmail dot com" <sourceware-bugzilla@sourceware.org>
To: glibc-bugs@sourceware.org
Subject: [Bug libc/6399] gettid() should have a wrapper
Date: Sat, 09 Feb 2013 02:53:00 -0000	[thread overview]
Message-ID: <bug-6399-131-c5JiytuXsD@http.sourceware.org/bugzilla/> (raw)
In-Reply-To: <bug-6399-131@http.sourceware.org/bugzilla/>

http://sourceware.org/bugzilla/show_bug.cgi?id=6399

--- Comment #17 from Michael Kerrisk <mtk.manpages at gmail dot com> 2013-02-09 02:53:06 UTC ---
(In reply to comment #16)
> I don't see how caching could have any effect on namespaces. Any application is
> able (and entitled) to store its own pid and assume that remains constant for
> the lifetime of the process. Whether this happens in application-level code or
> libc-level code is rather irrelevant.

So, a possible implementation of PID namespaces would have allowed setns() to
change the caller's PID namespace, which in effect would change the caller's
PID. Of course, this is not done. Instead, setns() into a PID namespace only
changes the PID namespace of children subsequently created by the caller. 

One of the cited reasons that setns() didn't change the PID namespace of the
caller is because glibc caches PIDs, and the result of getpid() would thus no
longer be correct. 

Now, you could say that the issue equally affects the application itself, but
there is a difference: if an application calls setns(), then it would know (in
that alternative implementation model) that its PID was about to change and
that any PID that *it* had cached was now invalid.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.


  parent reply	other threads:[~2013-02-09  2:53 UTC|newest]

Thread overview: 53+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <bug-6399-131@http.sourceware.org/bugzilla/>
2012-03-28 23:29 ` mtk.manpages at gmail dot com
2012-07-07  6:37 ` mtk.manpages at gmail dot com
2012-07-12 12:48 ` wbrana at gmail dot com
2012-11-05 20:57 ` bugdal at aerifal dot cx
2013-02-03 22:21 ` mtk.manpages at gmail dot com
2013-02-03 22:55 ` bugdal at aerifal dot cx
2013-02-03 23:11 ` mtk.manpages at gmail dot com
2013-02-08 21:20 ` desrt at desrt dot ca
2013-02-08 23:26 ` mtk.manpages at gmail dot com
2013-02-09  0:01 ` bugdal at aerifal dot cx
2013-02-09  0:19 ` desrt at desrt dot ca
2013-02-09  0:40 ` bugdal at aerifal dot cx
2013-02-09  0:42 ` desrt at desrt dot ca
2013-02-09  2:06 ` mtk.manpages at gmail dot com
2013-02-09  2:39 ` bugdal at aerifal dot cx
2013-02-09  2:53 ` mtk.manpages at gmail dot com [this message]
2013-02-09  3:24 ` bugdal at aerifal dot cx
2013-02-09 23:05 ` mtk.manpages at gmail dot com
2013-02-28 15:18 ` gabriele.svelto at gmail dot com
2013-09-21  0:15 ` justin.lebar at gmail dot com
2013-10-09 19:32 ` neleai at seznam dot cz
2014-01-10 20:45 ` carlos at redhat dot com
2014-01-10 20:56 ` bugdal at aerifal dot cx
2014-01-10 23:52 ` mtk.manpages at gmail dot com
2014-01-11  0:17 ` nmiell at gmail dot com
2014-01-11  3:03 ` carlos at redhat dot com
2014-01-11  3:41 ` mtk.manpages at gmail dot com
2014-01-11  4:09 ` nmiell at gmail dot com
2014-01-11  7:30 ` justin.lebar at gmail dot com
2014-01-11  7:38 ` justin.lebar at gmail dot com
2014-01-11  7:41 ` nmiell at gmail dot com
2014-01-11  9:16 ` gabriele.svelto at gmail dot com
2014-01-11  9:43 ` nmiell at gmail dot com
2014-01-11 10:07 ` gabriele.svelto at gmail dot com
2014-01-11 15:17 ` bugdal at aerifal dot cx
2014-01-11 19:48 ` mtk.manpages at gmail dot com
2014-01-11 20:01 ` bugdal at aerifal dot cx
2014-01-12 17:05 ` carlos at redhat dot com
2014-02-16 17:47 ` jackie.rosen at hushmail dot com
2014-05-28 19:43 ` schwab at sourceware dot org
2014-06-13 14:57 ` fweimer at redhat dot com
2015-10-07  7:51 ` fweimer at redhat dot com
2015-10-07  8:02 ` fweimer at redhat dot com
2015-10-09 12:39 ` mtk.manpages at gmail dot com
2015-10-09 18:52 ` carlos at redhat dot com
2015-10-09 19:01 ` nmiell at gmail dot com
2015-10-09 19:16 ` mtk.manpages at gmail dot com
2015-10-09 19:42 ` bugdal at aerifal dot cx
2021-05-19 20:14 ` fweimer at redhat dot com
2008-04-14 13:04 [Bug libc/6399] New: " mtk dot manpages at gmail dot com
2008-04-14 13:05 ` [Bug libc/6399] " mtk dot manpages at gmail dot com
2008-04-14 14:04 ` drepper at redhat dot com
2008-04-14 14:46 ` mtk dot manpages at gmail dot com
2008-04-16 10:37 ` michael dot kerrisk at gmail dot com

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=bug-6399-131-c5JiytuXsD@http.sourceware.org/bugzilla/ \
    --to=sourceware-bugzilla@sourceware.org \
    --cc=glibc-bugs@sourceware.org \
    /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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).