Re: [PATCH] proc: Fix the threaded /proc/self.

* Eric W. Biederman <[EMAIL PROTECTED]> wrote: > We may be stuck with the current broken behavior for backwards > compatibility reasons but lets try fixing our ancient bug for the > 2.6.25 time frame and see if anyone screams. to make sure i got you right - do you agree that this is a

Re: [PATCH] proc: Fix the threaded /proc/self.

Hello Eric, This fills a need I had to get the current TID in a Java program, so I'm very interested in this change. OTOH, how will someone not reading LKML discover that the current TID is now in /proc/self and that it was not always the case? I would put my 2 cents in /proc/self/task/self,

[PATCH] proc: Fix the threaded /proc/self.

Long ago when the CLONE_THREAD support first went it someone thought it would be wise to point /proc/self at /proc/ instead of /proc/. Given that /proc/ can return information about a very different task (if enough things have been unshared) then our current process /proc/ seems blatantly wrong.

[PATCH] proc: Fix the threaded /proc/self.

Long ago when the CLONE_THREAD support first went it someone thought it would be wise to point /proc/self at /proc/tgid instead of /proc/pid. Given that /proc/tgid can return information about a very different task (if enough things have been unshared) then our current process /proc/tgid seems

Re: [PATCH] proc: Fix the threaded /proc/self.

Hello Eric, This fills a need I had to get the current TID in a Java program, so I'm very interested in this change. OTOH, how will someone not reading LKML discover that the current TID is now in /proc/self and that it was not always the case? I would put my 2 cents in /proc/self/task/self,

Re: [PATCH] proc: Fix the threaded /proc/self.

* Eric W. Biederman [EMAIL PROTECTED] wrote: We may be stuck with the current broken behavior for backwards compatibility reasons but lets try fixing our ancient bug for the 2.6.25 time frame and see if anyone screams. to make sure i got you right - do you agree that this is a regression