From: ebiederm@xmission.com (Eric W. Biederman)
To: Robert Hancock <hancockr@shaw.ca>
Cc: Ulrich Drepper <drepper@redhat.com>,
Roland McGrath <roland@redhat.com>,
Guillaume Chazarain <guichaz@yahoo.fr>,
Ingo Molnar <mingo@elte.hu>, Pavel Emelyanov <xemul@openvz.org>,
"Rafael J. Wysocki" <rjw@sisk.pl>, Pavel Machek <pavel@ucw.cz>,
kernel list <linux-kernel@vger.kernel.org>,
netdev <netdev@vger.kernel.org>
Subject: Re: 2.6.24-rc3: find complains about /proc/net
Date: Tue, 20 Nov 2007 18:41:56 -0700 [thread overview]
Message-ID: <m1pry4pe6z.fsf@ebiederm.dsl.xmission.com> (raw)
In-Reply-To: <47438820.5010300@shaw.ca> (Robert Hancock's message of "Tue, 20 Nov 2007 19:21:36 -0600")
Robert Hancock <hancockr@shaw.ca> writes:
> Eric W. Biederman wrote:
>> Could you elaborate a bit on how the semantics of returning the
>> wrong information are more useful?
>>
>> In particular if a thread does the logical equivalent of:
>> grep Pid: /proc/self/status. It always get the tgid despite
>> having a different process id.
>
> The POSIX-defined userspace concept of a PID requires that all threads appear to
> have the same PID. This is something that Linux didn't comply with under the old
> LinuxThreads implementation and was finally fixed with NPTL. This isn't a
> POSIX-defined interface, but I assume it's trying to be consistent with
> getpid(), etc.
Linux exports two fields in /proc/self/status:
Tgid: 32698
Pid: 32698
The tgid maps to the posix concept. The pid is this context is the
thread id.
So it seems broken to me to return the same thread id for different threads.
Eric
next prev parent reply other threads:[~2007-11-21 1:43 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <fa.zy7JwM3jsOSgOCtqK2+rvFfdGjQ@ifi.uio.no>
[not found] ` <fa.Zx9jkdx74KRPk1qghLrg9BCvfFU@ifi.uio.no>
[not found] ` <fa.1TKmo5fKBZfHOQYq1bH4uMxOQek@ifi.uio.no>
[not found] ` <fa.fjJG0rd93RGzZ4PSv/glscvAI0A@ifi.uio.no>
[not found] ` <fa.7XLWa+gAWL3Q6I3O+hiS4UfcWpM@ifi.uio.no>
[not found] ` <fa.QqYdKsBUWKSLLGXmxJCAtZxLYnE@ifi.uio.no>
2007-11-21 1:21 ` 2.6.24-rc3: find complains about /proc/net Robert Hancock
2007-11-21 1:41 ` Eric W. Biederman [this message]
[not found] <20071119191000.GA1560@elf.ucw.cz>
2007-11-19 22:04 ` Rafael J. Wysocki
2007-11-20 15:51 ` Pavel Emelyanov
2007-11-20 21:52 ` Eric W. Biederman
2007-11-20 21:59 ` Ingo Molnar
2007-11-20 22:17 ` Eric W. Biederman
2007-11-20 22:35 ` Ingo Molnar
2007-11-20 22:54 ` Roland McGrath
2007-11-20 23:01 ` Ingo Molnar
2007-11-20 23:06 ` Guillaume Chazarain
2007-11-20 23:26 ` Roland McGrath
2007-11-20 23:32 ` Ulrich Drepper
2007-11-20 23:45 ` Ingo Molnar
2007-11-20 23:51 ` Roland McGrath
2007-11-21 0:47 ` Eric W. Biederman
2007-11-21 1:01 ` Rafael J. Wysocki
2007-11-21 0:41 ` Eric W. Biederman
2007-11-20 23:43 ` Ingo Molnar
2007-11-21 1:19 ` Eric W. Biederman
2007-11-21 6:36 ` Eric W. Biederman
2007-11-21 9:36 ` Pavel Emelyanov
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=m1pry4pe6z.fsf@ebiederm.dsl.xmission.com \
--to=ebiederm@xmission.com \
--cc=drepper@redhat.com \
--cc=guichaz@yahoo.fr \
--cc=hancockr@shaw.ca \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=netdev@vger.kernel.org \
--cc=pavel@ucw.cz \
--cc=rjw@sisk.pl \
--cc=roland@redhat.com \
--cc=xemul@openvz.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 NNTP newsgroup(s).