In arch_ptrace, task_user_regset_view is called on current. On an x86-64 kernel, that path is only reached for a 64-bit syscall. compat_arch_ptrace doesn't use it at all, always using the 32-bit view. So your change would have no effect on PTRACE_GETREGS. It would only affect PTRACE_GETREGSET, which calls task_user_regset_view on the target task. Is that what you meant? I think that would be confusing at best. A caller of PTRACE_GETREGSET is expecting a particular layout based on what type of task he thinks he's dealing with. The caller can look at the iov_len in the result to discern which layout it actually got filled in, but I don't think that's what callers expect. The other use of task_user_regset_view is in core dump (binfmt_elf.c:fill_note_info). Off hand I don't think there's a way a core dump can be started while still "inside" a syscall so that TS_COMPAT could ever be set. But that should be double-checked. As to whether it was considered before, I doubt that it was. I don't really recall the sequence of events, but I think that I did all the user_regset code before I was really cognizant of the TS_COMPAT subtleties. Thanks, Roland -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
