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
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
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
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
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
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
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
Ulrich Drepper <[EMAIL PROTECTED]> writes:
> 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
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
> 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
* 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.
* 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
>
-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
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
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
* 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
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
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
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!
>
>
* 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
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
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
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
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
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:
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
Ulrich Drepper [EMAIL PROTECTED] writes:
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
for
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
>
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. Earlier results may have failed to include directories that
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. Earlier results may have failed to include directories that
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.
46 matches
Mail list logo
