(Cc: Jeff)
* Thorsten Knabe ([email protected]) wrote:
> [5.] Most recent kernel version which did not have the bug:
> 2.6.23.17 does not leak task_structs.
> 2.6.24 - 2.6.25.3 has not been tested
Would you be able bisect this (or even just narrow it down a bit)?
> Running 2.6.23.16 i386 UML on a 2.6.25.4 i386 host does NOT leak
> task_structs.
> Running 64-bit UML guests has not been tested.
On Sun, Jun 01, 2008 at 02:31:39PM -0700, Chris Wright wrote:
> * Thorsten Knabe ([email protected]) wrote:
> > [5.] Most recent kernel version which did not have the bug:
> > 2.6.23.17 does not leak task_structs.
> > 2.6.24 - 2.6.25.3 has not been tested
Has this been seen on non-UML?
Jeff
--
Work email - jdike at linux dot intel dot com
Jeff Dike wrote:
> On Sun, Jun 01, 2008 at 02:31:39PM -0700, Chris Wright wrote:
>> * Thorsten Knabe ([email protected]) wrote:
>>> [5.] Most recent kernel version which did not have the bug:
>>> 2.6.23.17 does not leak task_structs.
>>> 2.6.24 - 2.6.25.3 has not been tested
>
> Has this been seen on non-UML?
Hello Jeff.
I'm not sure, if I understood your question correctly. The task_struct
leak is on the host running a vanilla Linux 2.6.25.4 x86_64 on real
hardware and not within the UML instances. I'll try to describe the
situation more precisely:
The host system is a vanilla Linux 2.6.25.4 x86_64 running on real
hardware with a Debian Etch x86_64 user space. However I've created a
Debian Etch i386 (32bit) userspace chroot environment on the system,
which is used, among other things, to compile the Linux 2.6.23.17 UML
kernels and start various UML instances.
I can start other 32-bit applications, for example compile an UML
kernel, within the chroot without leaking task_structs, but as soon as I
start an UML instance, I see leaked task_structs. Starting and
immediately shutting down an UML instacne leaks approximately 2000
task_structs. The number of leaked task_structs on the host seems to be
equal to the number of processes that have been created (and destroyed)
within the UML instances.
The host system was upgraded from 2.6.23.17 x86_64 which did not leak
task_structs to 2.6.25.4 x86_64. Also running the same UML kernels and
filesystems on my laptop with a vanilla Linux 2.6.25.4 i386 kernel does
not leak task_structs. The version of the UML kernel (tested 2.6.23.17
and 2.6.25.4) does not seem to matter.
As far as I understand the UML code in the kernel, an UML kernel uses
some unusual clone() flags when creating new processes, which are seldom
used by other applications and could be related to the bug.
If there is no obvious bug in the code, I'll try to bisect that beast
next weekend as suggested by Chris.
Regards
Thorsten
--
___
| | / E-Mail: [email protected]
|horsten |/\nabe WWW: http://linux.thorsten-knabe.de
On Thu, Jun 05, 2008 at 12:40:07AM +0200, Thorsten Knabe wrote:
> I can start other 32-bit applications, for example compile an UML
> kernel, within the chroot without leaking task_structs, but as soon as I
> start an UML instance, I see leaked task_structs. Starting and
> immediately shutting down an UML instacne leaks approximately 2000
> task_structs. The number of leaked task_structs on the host seems to be
> equal to the number of processes that have been created (and destroyed)
> within the UML instances.
I misunderstood - I thought you were seeing a task_struct leak within
UML rather than a leak on the host elicited by UML.
> As far as I understand the UML code in the kernel, an UML kernel uses
> some unusual clone() flags when creating new processes, which are seldom
> used by other applications and could be related to the bug.
Yes, it does. I don't see the flags causing a leak, though. What
might be more likely (although I really have no idea) is ptrace.
Possibly a reference is held when it should have been dropped. This
might also show up with strace or gdb.
Jeff
--
Work email - jdike at linux dot intel dot com
* Jeff Dike ([email protected]) wrote:
> Yes, it does. I don't see the flags causing a leak, though. What
> might be more likely (although I really have no idea) is ptrace.
Yeah, ptrace was my guess as well, and I was hoping you'd have an idea ;-)
> Possibly a reference is held when it should have been dropped. This
> might also show up with strace or gdb.
Jeff Dike wrote:
> I misunderstood - I thought you were seeing a task_struct leak within
> UML rather than a leak on the host elicited by UML.
>
>> As far as I understand the UML code in the kernel, an UML kernel uses
>> some unusual clone() flags when creating new processes, which are seldom
>> used by other applications and could be related to the bug.
>
> Yes, it does. I don't see the flags causing a leak, though. What
> might be more likely (although I really have no idea) is ptrace.
> Possibly a reference is held when it should have been dropped. This
> might also show up with strace or gdb.
Hello Jeff.
Your assumption about ptrace causing the task_struct leak seems to be
right. I bisected the problem down to a few commits using the repository
at git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git.
Commit b7b71725fb9584454bfe5f231223bd63421798fb is the last known commit
that does not leak task_structs, whereas commit
a97f52e67890fda6b373c1c1895ff1c1c69b36c8 is leaking task_structs.
Revisions in between do not even compile.
Also I had to apply the changes from commit
f9cb02b0be4de3c51edfdd701754e13d9a2d20d6 to most of the kernels I have
tested, otherwise the UML process would crash on startup.
HTH
Thorsten
--
___
| | / E-Mail: [email protected]
|horsten |/\nabe WWW: http://linux.thorsten-knabe.de
On Sun, Jun 08, 2008 at 01:39:11PM +0200, Thorsten Knabe wrote:
>
>Hello Jeff.
>
>Your assumption about ptrace causing the task_struct leak seems to be
>right. I bisected the problem down to a few commits using the repository
>at git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git.
>
>Commit b7b71725fb9584454bfe5f231223bd63421798fb is the last known commit
>that does not leak task_structs, whereas commit
>a97f52e67890fda6b373c1c1895ff1c1c69b36c8 is leaking task_structs.
>Revisions in between do not even compile.
>Also I had to apply the changes from commit
>f9cb02b0be4de3c51edfdd701754e13d9a2d20d6 to most of the kernels I have
>tested, otherwise the UML process would crash on startup.
Add Cc to Roland McGrath <[email protected]>.
--
Hi, I'm a .signature virus, please copy/paste me to help me spread
all over the world.
Oops, mea culpa. I added the bug in commit
5a4646a4efed8c835f76c3b88f3155f6ab5b8d9b.
It's already gone for 2.6.26 with the compat_arch_ptrace cleanup.
-stable patch to follow.
Thanks,
Roland
Commit 5a4646a4efed8c835f76c3b88f3155f6ab5b8d9b introduced a leak of
task_struct refs into sys32_ptrace. This bug has already gone away in
for 2.6.26 in commit 562b80bafffaf42a6d916b0a2ee3d684220a1c10.
Signed-off-by: Roland McGrath <[email protected]>
---
arch/x86/kernel/ptrace.c | 45 ++++++++++++++++++++++++++-------------------
1 files changed, 26 insertions(+), 19 deletions(-)
diff --git a/arch/x86/kernel/ptrace.c b/arch/x86/kernel/ptrace.c
index 9003e0b..a10ba65 100644
--- a/arch/x86/kernel/ptrace.c
+++ b/arch/x86/kernel/ptrace.c
@@ -1309,42 +1309,49 @@ asmlinkage long sys32_ptrace(long request, u32 pid, u32 addr, u32 data)
break;
case PTRACE_GETREGS: /* Get all gp regs from the child. */
- return copy_regset_to_user(child, &user_x86_32_view,
- REGSET_GENERAL,
- 0, sizeof(struct user_regs_struct32),
- datap);
+ ret = copy_regset_to_user(child, &user_x86_32_view,
+ REGSET_GENERAL,
+ 0, sizeof(struct user_regs_struct32),
+ datap);
+ break;
case PTRACE_SETREGS: /* Set all gp regs in the child. */
- return copy_regset_from_user(child, &user_x86_32_view,
- REGSET_GENERAL, 0,
- sizeof(struct user_regs_struct32),
- datap);
+ ret = copy_regset_from_user(child, &user_x86_32_view,
+ REGSET_GENERAL, 0,
+ sizeof(struct user_regs_struct32),
+ datap);
+ break;
case PTRACE_GETFPREGS: /* Get the child FPU state. */
- return copy_regset_to_user(child, &user_x86_32_view,
- REGSET_FP, 0,
- sizeof(struct user_i387_ia32_struct),
- datap);
+ ret = copy_regset_to_user(child, &user_x86_32_view,
+ REGSET_FP, 0,
+ sizeof(struct user_i387_ia32_struct),
+ datap);
+ break;
case PTRACE_SETFPREGS: /* Set the child FPU state. */
- return copy_regset_from_user(
+ ret = copy_regset_from_user(
child, &user_x86_32_view, REGSET_FP,
0, sizeof(struct user_i387_ia32_struct), datap);
+ break;
case PTRACE_GETFPXREGS: /* Get the child extended FPU state. */
- return copy_regset_to_user(child, &user_x86_32_view,
- REGSET_XFP, 0,
- sizeof(struct user32_fxsr_struct),
- datap);
+ ret = copy_regset_to_user(child, &user_x86_32_view,
+ REGSET_XFP, 0,
+ sizeof(struct user32_fxsr_struct),
+ datap);
+ break;
case PTRACE_SETFPXREGS: /* Set the child extended FPU state. */
- return copy_regset_from_user(child, &user_x86_32_view,
+ ret = copy_regset_from_user(child, &user_x86_32_view,
REGSET_XFP, 0,
sizeof(struct user32_fxsr_struct),
datap);
+ break;
default:
- return compat_ptrace_request(child, request, addr, data);
+ ret = compat_ptrace_request(child, request, addr, data);
+ break;
}
out:
* Roland McGrath <[email protected]> wrote:
> Commit 5a4646a4efed8c835f76c3b88f3155f6ab5b8d9b introduced a leak of
> task_struct refs into sys32_ptrace. This bug has already gone away in
> for 2.6.26 in commit 562b80bafffaf42a6d916b0a2ee3d684220a1c10.
>
> Signed-off-by: Roland McGrath <[email protected]>
Acked-by: Ingo Molnar <[email protected]>
Ingo