Re: [PATCH -mm 09/43] compat_sys_ptrace
> Nice, we should have unified the compat ptrace code long ago. There is still more consolidation that can be done, but this is a first step. > Any chance you could make the ifdef symetric to the native ptrace > where an arch defines a symbol if it has it's own ptrace? That would require touching each and every arch's headers so as not to break it with the generic changes. I seem to get berated for that sort of thing more often than asked for it. > Also when prototyping something like this I was wondering whether we > really want a separate compat function. Lots of the ptrace requests > mostly depend on the target processes abi, not the ptrace caller, [...] That's not really true of any ptrace request that isn't already wholly arch-dependent, and not true of any majority of those either. For all of the things that are likely to be handled in generic code any time soon, it's the caller of ptrace whose natural data formats reign. > [...] Anyway, that's probably something to worry about > later one the arch-specific compat ptrace implementations are gone. Indeed. Thanks, Roland -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH -mm 09/43] compat_sys_ptrace
Nice, we should have unified the compat ptrace code long ago. There is still more consolidation that can be done, but this is a first step. Any chance you could make the ifdef symetric to the native ptrace where an arch defines a symbol if it has it's own ptrace? That would require touching each and every arch's headers so as not to break it with the generic changes. I seem to get berated for that sort of thing more often than asked for it. Also when prototyping something like this I was wondering whether we really want a separate compat function. Lots of the ptrace requests mostly depend on the target processes abi, not the ptrace caller, [...] That's not really true of any ptrace request that isn't already wholly arch-dependent, and not true of any majority of those either. For all of the things that are likely to be handled in generic code any time soon, it's the caller of ptrace whose natural data formats reign. [...] Anyway, that's probably something to worry about later one the arch-specific compat ptrace implementations are gone. Indeed. Thanks, Roland -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH -mm 09/43] compat_sys_ptrace
On Thu, Dec 20, 2007 at 03:55:51AM -0800, Roland McGrath wrote: > This adds a generic definition of compat_sys_ptrace that calls > compat_arch_ptrace, parallel to sys_ptrace/arch_ptrace. Some > machines needing this already define a function by that name. > The new generic function is defined only on machines that > put #define __ARCH_WANT_COMPAT_SYS_PTRACE into asm/ptrace.h. Nice, we should have unified the compat ptrace code long ago. Any chance you could make the ifdef symetric to the native ptrace where an arch defines a symbol if it has it's own ptrace? Also when prototyping something like this I was wondering whether we really want a separate compat function. Lots of the ptrace requests mostly depend on the target processes abi, not the ptrace caller, so maybe doing it like s390 and handle both in the same function might actually be cleaner. Anyway, that's probably something to worry about later one the arch-specific compat ptrace implementations are gone. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH -mm 09/43] compat_sys_ptrace
This adds a generic definition of compat_sys_ptrace that calls
compat_arch_ptrace, parallel to sys_ptrace/arch_ptrace. Some
machines needing this already define a function by that name.
The new generic function is defined only on machines that
put #define __ARCH_WANT_COMPAT_SYS_PTRACE into asm/ptrace.h.
Signed-off-by: Roland McGrath <[EMAIL PROTECTED]>
Signed-off-by: Ingo Molnar <[EMAIL PROTECTED]>
Signed-off-by: Thomas Gleixner <[EMAIL PROTECTED]>
---
include/linux/compat.h |7 +++
kernel/ptrace.c| 46 ++
2 files changed, 53 insertions(+), 0 deletions(-)
diff --git a/include/linux/compat.h b/include/linux/compat.h
index e70a2a1..aa3a55e 100644
--- a/include/linux/compat.h
+++ b/include/linux/compat.h
@@ -275,5 +275,12 @@ extern int compat_ptrace_request(struct task_struct *child,
compat_long_t request,
compat_ulong_t addr, compat_ulong_t data);
+#ifdef __ARCH_WANT_COMPAT_SYS_PTRACE
+extern long compat_arch_ptrace(struct task_struct *child, compat_long_t
request,
+ compat_ulong_t addr, compat_ulong_t data);
+asmlinkage long compat_sys_ptrace(compat_long_t request, compat_long_t pid,
+ compat_long_t addr, compat_long_t data);
+#endif /* __ARCH_WANT_COMPAT_SYS_PTRACE */
+
#endif /* CONFIG_COMPAT */
#endif /* _LINUX_COMPAT_H */
diff --git a/kernel/ptrace.c b/kernel/ptrace.c
index bc1a764..319ab4a 100644
--- a/kernel/ptrace.c
+++ b/kernel/ptrace.c
@@ -642,4 +642,50 @@ int compat_ptrace_request(struct task_struct *child,
compat_long_t request,
return ret;
}
+
+#ifdef __ARCH_WANT_COMPAT_SYS_PTRACE
+asmlinkage long compat_sys_ptrace(compat_long_t request, compat_long_t pid,
+ compat_long_t addr, compat_long_t data)
+{
+ struct task_struct *child;
+ long ret;
+
+ /*
+* This lock_kernel fixes a subtle race with suid exec
+*/
+ lock_kernel();
+ if (request == PTRACE_TRACEME) {
+ ret = ptrace_traceme();
+ goto out;
+ }
+
+ child = ptrace_get_task_struct(pid);
+ if (IS_ERR(child)) {
+ ret = PTR_ERR(child);
+ goto out;
+ }
+
+ if (request == PTRACE_ATTACH) {
+ ret = ptrace_attach(child);
+ /*
+* Some architectures need to do book-keeping after
+* a ptrace attach.
+*/
+ if (!ret)
+ arch_ptrace_attach(child);
+ goto out_put_task_struct;
+ }
+
+ ret = ptrace_check_attach(child, request == PTRACE_KILL);
+ if (!ret)
+ ret = compat_arch_ptrace(child, request, addr, data);
+
+ out_put_task_struct:
+ put_task_struct(child);
+ out:
+ unlock_kernel();
+ return ret;
+}
+#endif /* __ARCH_WANT_COMPAT_SYS_PTRACE */
+
#endif /* CONFIG_COMPAT */
--
1.5.3.6
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH -mm 09/43] compat_sys_ptrace
This adds a generic definition of compat_sys_ptrace that calls
compat_arch_ptrace, parallel to sys_ptrace/arch_ptrace. Some
machines needing this already define a function by that name.
The new generic function is defined only on machines that
put #define __ARCH_WANT_COMPAT_SYS_PTRACE into asm/ptrace.h.
Signed-off-by: Roland McGrath [EMAIL PROTECTED]
Signed-off-by: Ingo Molnar [EMAIL PROTECTED]
Signed-off-by: Thomas Gleixner [EMAIL PROTECTED]
---
include/linux/compat.h |7 +++
kernel/ptrace.c| 46 ++
2 files changed, 53 insertions(+), 0 deletions(-)
diff --git a/include/linux/compat.h b/include/linux/compat.h
index e70a2a1..aa3a55e 100644
--- a/include/linux/compat.h
+++ b/include/linux/compat.h
@@ -275,5 +275,12 @@ extern int compat_ptrace_request(struct task_struct *child,
compat_long_t request,
compat_ulong_t addr, compat_ulong_t data);
+#ifdef __ARCH_WANT_COMPAT_SYS_PTRACE
+extern long compat_arch_ptrace(struct task_struct *child, compat_long_t
request,
+ compat_ulong_t addr, compat_ulong_t data);
+asmlinkage long compat_sys_ptrace(compat_long_t request, compat_long_t pid,
+ compat_long_t addr, compat_long_t data);
+#endif /* __ARCH_WANT_COMPAT_SYS_PTRACE */
+
#endif /* CONFIG_COMPAT */
#endif /* _LINUX_COMPAT_H */
diff --git a/kernel/ptrace.c b/kernel/ptrace.c
index bc1a764..319ab4a 100644
--- a/kernel/ptrace.c
+++ b/kernel/ptrace.c
@@ -642,4 +642,50 @@ int compat_ptrace_request(struct task_struct *child,
compat_long_t request,
return ret;
}
+
+#ifdef __ARCH_WANT_COMPAT_SYS_PTRACE
+asmlinkage long compat_sys_ptrace(compat_long_t request, compat_long_t pid,
+ compat_long_t addr, compat_long_t data)
+{
+ struct task_struct *child;
+ long ret;
+
+ /*
+* This lock_kernel fixes a subtle race with suid exec
+*/
+ lock_kernel();
+ if (request == PTRACE_TRACEME) {
+ ret = ptrace_traceme();
+ goto out;
+ }
+
+ child = ptrace_get_task_struct(pid);
+ if (IS_ERR(child)) {
+ ret = PTR_ERR(child);
+ goto out;
+ }
+
+ if (request == PTRACE_ATTACH) {
+ ret = ptrace_attach(child);
+ /*
+* Some architectures need to do book-keeping after
+* a ptrace attach.
+*/
+ if (!ret)
+ arch_ptrace_attach(child);
+ goto out_put_task_struct;
+ }
+
+ ret = ptrace_check_attach(child, request == PTRACE_KILL);
+ if (!ret)
+ ret = compat_arch_ptrace(child, request, addr, data);
+
+ out_put_task_struct:
+ put_task_struct(child);
+ out:
+ unlock_kernel();
+ return ret;
+}
+#endif /* __ARCH_WANT_COMPAT_SYS_PTRACE */
+
#endif /* CONFIG_COMPAT */
--
1.5.3.6
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH -mm 09/43] compat_sys_ptrace
On Thu, Dec 20, 2007 at 03:55:51AM -0800, Roland McGrath wrote: This adds a generic definition of compat_sys_ptrace that calls compat_arch_ptrace, parallel to sys_ptrace/arch_ptrace. Some machines needing this already define a function by that name. The new generic function is defined only on machines that put #define __ARCH_WANT_COMPAT_SYS_PTRACE into asm/ptrace.h. Nice, we should have unified the compat ptrace code long ago. Any chance you could make the ifdef symetric to the native ptrace where an arch defines a symbol if it has it's own ptrace? Also when prototyping something like this I was wondering whether we really want a separate compat function. Lots of the ptrace requests mostly depend on the target processes abi, not the ptrace caller, so maybe doing it like s390 and handle both in the same function might actually be cleaner. Anyway, that's probably something to worry about later one the arch-specific compat ptrace implementations are gone. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
