Eric W. Biederman wrote:
Below is a preliminary patch. It solves the directory issue but it doesn't
play well with proc_mnt and proc_flush_task. It works by simply caching the
network namespace when we mount proc so we don't have to be fancy and dynamic.
Nice... Where should we apply this
Rafael J. Wysocki wrote:
On Monday, 19 of November 2007, Pavel Machek wrote:
Hi!
I think that this worked before:
[EMAIL PROTECTED]:/proc# find . -name timer_info
find: WARNING: Hard link count is wrong for ./net: this may be a bug
in your filesystem driver. Automatically turning on
Pavel Emelyanov [EMAIL PROTECTED] writes:
Rafael J. Wysocki wrote:
On Monday, 19 of November 2007, Pavel Machek wrote:
Hi!
I think that this worked before:
[EMAIL PROTECTED]:/proc# find . -name timer_info
find: WARNING: Hard link count is wrong for ./net: this may be a bug
in your
* Eric W. Biederman [EMAIL PROTECTED] wrote:
lr-x-- 1 root root 64 Nov 20 18:03 3 - /proc/net
...
Yes all of those are nasty. So much for my clever way of implementing
these things. Grr. Simple hacks that almost work!
btw., in case you feel inclined, i recently did some
Ingo Molnar [EMAIL PROTECTED] writes:
* Eric W. Biederman [EMAIL PROTECTED] wrote:
lr-x-- 1 root root 64 Nov 20 18:03 3 - /proc/net
...
Yes all of those are nasty. So much for my clever way of implementing
these things. Grr. Simple hacks that almost work!
btw., in case you
these are all questions for Ulrich and Roland - Cc:-ed them.
* Eric W. Biederman [EMAIL PROTECTED] wrote:
Ingo Molnar [EMAIL PROTECTED] writes:
* Eric W. Biederman [EMAIL PROTECTED] wrote:
lr-x-- 1 root root 64 Nov 20 18:03 3 - /proc/net
...
Yes all of those are nasty.
* Roland McGrath [EMAIL PROTECTED] wrote:
When did /proc/self get changed to follow tgid instead of pid? glibc
uses /proc/self to refer to various things that are usually shared
anyway (fd, maps, cwd, exe), but I think the expectation has always
been that this refers to the same calling
On 11/21/07, Ingo Molnar [EMAIL PROTECTED] wrote:
i guess it was a v2.6.24 change, hence a regression that needs to be
fixed?
It seems to be
http://git.kernel.org/?p=linux/kernel/git/tglx/history.git;a=commitdiff;h=01660410
So, linux 2.6.0-test6
--
Guillaume
-
To unsubscribe from this list:
When did /proc/self get changed to follow tgid instead of pid? glibc uses
/proc/self to refer to various things that are usually shared anyway (fd,
maps, cwd, exe), but I think the expectation has always been that this
refers to the same calling thread, not the group leader. e.g., if one
thread
Oh, it seems it has indeed been that way for a very long time, so I was
mistaken. It still seems a little odd to me. Ulrich can say definitively
whether the kind of concern I mentioned really matters one way or the other
for glibc.
Thanks,
Roland
-
To unsubscribe from this list: send the line
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Roland McGrath wrote:
Oh, it seems it has indeed been that way for a very long time, so I was
mistaken. It still seems a little odd to me. Ulrich can say definitively
whether the kind of concern I mentioned really matters one way or the other
* Guillaume Chazarain [EMAIL PROTECTED] wrote:
On 11/21/07, Ingo Molnar [EMAIL PROTECTED] wrote:
i guess it was a v2.6.24 change, hence a regression that needs to be
fixed?
It seems to be
http://git.kernel.org/?p=linux/kernel/git/tglx/history.git;a=commitdiff;h=01660410
So, linux
* Ulrich Drepper [EMAIL PROTECTED] wrote:
Oh, it seems it has indeed been that way for a very long time, so I
was mistaken. It still seems a little odd to me. Ulrich can say
definitively whether the kind of concern I mentioned really matters
one way or the other for glibc.
glibc
can you see any danger to providing a /proc/self_task/ link? (or can you
think of a better name/API/approach)
That is a poor name to choose given /proc/self/task exists as something
else (just try writing a sentence comparing them and then read it aloud).
Probably /proc/self/task/self is what
On Wednesday, 21 of November 2007, Roland McGrath wrote:
can you see any danger to providing a /proc/self_task/ link? (or can you
think of a better name/API/approach)
That is a poor name to choose given /proc/self/task exists as something
else (just try writing a sentence comparing them
Roland McGrath [EMAIL PROTECTED] writes:
can you see any danger to providing a /proc/self_task/ link? (or can you
think of a better name/API/approach)
That is a poor name to choose given /proc/self/task exists as something
else (just try writing a sentence comparing them and then read it
Pavel Emelyanov [EMAIL PROTECTED] writes:
Rafael J. Wysocki wrote:
On Monday, 19 of November 2007, Pavel Machek wrote:
Hi!
I think that this worked before:
[EMAIL PROTECTED]:/proc# find . -name timer_info
find: WARNING: Hard link count is wrong for ./net: this may be a bug
in your
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
Robert Hancock [EMAIL PROTECTED] 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
Below is a preliminary patch. It solves the directory issue but it doesn't
play well with proc_mnt and proc_flush_task. It works by simply caching the
network namespace when we mount proc so we don't have to be fancy and dynamic.
Something for the discussion anyway.
I will start sorting out
On Monday, 19 of November 2007, Pavel Machek wrote:
Hi!
I think that this worked before:
[EMAIL PROTECTED]:/proc# find . -name timer_info
find: WARNING: Hard link count is wrong for ./net: this may be a bug
in your filesystem driver. Automatically turning on find's -noleaf
option.
21 matches
Mail list logo
