Thread (15 messages) flat view 15 messages, 7 authors, 2018-12-12

Re: [PATCH v5 24/25] ptrace: add PTRACE_GET_SYSCALL_INFO request

From: Oleg Nesterov <oleg@redhat.com>
Date: 2018-12-12 18:00:26
Also in: lkml

On 12/11, Dmitry V. Levin wrote:
quoted
quoted
Still can't understand... are you saying that without (say) __pad2[4]
sizeof(ptrace_syscall_info) or offsetofend(ptrace_syscall_info, seccomp)
will depend on arch? Or what? I am just curious.
Yes, without padding these sizes will depend on architecture:
quoted
$ cat t.c
#include <linux/types.h>
int main() {
	struct s {
		__u64 nr;
		__u64 args[6];
		__u32 ret_data;
	};
	return sizeof(struct s);
}

$ gcc -m64 -Wall -O2 t.c && ./a.out; echo $?
64
$ gcc -m32 -Wall -O2 t.c && ./a.out; echo $?
60

This happens because __u64 has 32-bit alignment on some 32-bit
architectures like x86.

There is also m68k where __u32 has 16-bit alignment.
OK, thanks,
Said that, I think it would be better if PTRACE_GET_SYSCALL_INFO
did not take these trailing pads into account, e.g.

-       return offsetofend(struct ptrace_syscall_info, seccomp);
+       return offsetofend(struct ptrace_syscall_info, seccomp.ret_data);
...
-       return offsetofend(struct ptrace_syscall_info, exit);
+       return offsetofend(struct ptrace_syscall_info, exit.is_error);

The reason is that it would allow to fill these trailing pads with
something useful in the future.
Agreed.

But this way everything looks even more confusing. To me it would be
better to simply remove these pads, but I won't insist.

Oleg.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help