From: "Dmitry V. Levin" <ldv-u2l5PoMzF/Vg9hUCZPvPmw@public.gmane.org>
To: Oleg Nesterov <oleg-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
Cc: Kees Cook <keescook-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>,
Jann Horn <jannh-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>,
linux-api-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Eugene Syromyatnikov
<esyr-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Andy Lutomirski <luto-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
strace-devel-3+4lAyCyj6AWlMsSdNXQLw@public.gmane.org
Subject: Re: [PATCH v5 24/25] ptrace: add PTRACE_GET_SYSCALL_INFO request
Date: Tue, 11 Dec 2018 19:23:05 +0300 [thread overview]
Message-ID: <20181211162305.GA480@altlinux.org> (raw)
In-Reply-To: <20181211152953.GA8504-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
[-- Attachment #1.1: Type: text/plain, Size: 2652 bytes --]
On Tue, Dec 11, 2018 at 04:29:54PM +0100, Oleg Nesterov wrote:
> On 12/10, Dmitry V. Levin wrote:
> > On Mon, Dec 10, 2018 at 03:11:07PM +0100, Oleg Nesterov wrote:
> > > On 12/10, Dmitry V. Levin wrote:
> > > >
> > > > +struct ptrace_syscall_info {
> > > > + __u8 op; /* PTRACE_SYSCALL_INFO_* */
> > > > + __u8 __pad0[3];
> > > > + __u32 arch;
> > > > + __u64 instruction_pointer;
> > > > + __u64 stack_pointer;
> > > > + __u64 frame_pointer;
> > > > + union {
> > > > + struct {
> > > > + __u64 nr;
> > > > + __u64 args[6];
> > > > + } entry;
> > > > + struct {
> > > > + __s64 rval;
> > > > + __u8 is_error;
> > > > + __u8 __pad1[7];
> > > > + } exit;
> > > > + struct {
> > > > + __u64 nr;
> > > > + __u64 args[6];
> > > > + __u32 ret_data;
> > > > + __u8 __pad2[4];
> > > > + } seccomp;
> > > > + };
> > > > +};
> > >
> > > Could you explain why ptrace_syscall_info needs __pad{0,1,2} ? I simply can't
> > > understand why...
> >
> > I suppose the idea behind the use of these pads was to make the structure
> > arch-independent.
>
> 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:
$ 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.
> > I don't think we really need to keep it exactly the same on all
> > architectures - the only practical requirement is to avoid any compat
> > issues, but I don't mind keeping the structure arch-independent.
>
> OK, but may be you can add a short comment to explain these pads.
Alternatively, we could use __attribute__((aligned(N))), e.g.
struct ptrace_syscall_info {
__u8 op; /* PTRACE_SYSCALL_INFO_* */
__u32 arch __attribute__((aligned(4)));
__u64 instruction_pointer;
__u64 stack_pointer;
union {
struct {
__u64 nr __attribute__((aligned(8)));
__u64 args[6];
} entry;
struct {
__s64 rval __attribute__((aligned(8)));
__u8 is_error;
} exit;
struct {
__u64 nr __attribute__((aligned(8)));
__u64 args[6];
__u32 ret_data;
} seccomp;
};
};
Do you prefer __attribute__((aligned(N))) to padding?
--
ldv
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
[-- Attachment #2: Type: text/plain, Size: 137 bytes --]
--
Strace-devel mailing list
Strace-devel-3+4lAyCyj6AWlMsSdNXQLw@public.gmane.org
https://lists.strace.io/mailman/listinfo/strace-devel
next prev parent reply other threads:[~2018-12-11 16:23 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-12-10 4:23 [PATCH v5 00/25] ptrace: add PTRACE_GET_SYSCALL_INFO request Dmitry V. Levin
2018-12-10 4:31 ` [PATCH v5 24/25] " Dmitry V. Levin
2018-12-10 14:11 ` Oleg Nesterov
[not found] ` <20181210141107.GB4177-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2018-12-10 16:21 ` Dmitry V. Levin
2018-12-11 15:29 ` Oleg Nesterov
[not found] ` <20181211152953.GA8504-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2018-12-11 16:23 ` Dmitry V. Levin [this message]
2018-12-11 20:27 ` Dmitry V. Levin
2018-12-12 18:00 ` Oleg Nesterov
2018-12-10 14:26 ` kbuild test robot
[not found] ` <201812102200.snodXJSH%fengguang.wu-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
2018-12-10 16:09 ` Dmitry V. Levin
2018-12-10 18:04 ` Paul Burton
2018-12-10 21:04 ` Palmer Dabbelt
[not found] ` <20181210160940.GF14149-u2l5PoMzF/Vg9hUCZPvPmw@public.gmane.org>
2018-12-10 19:38 ` Andy Lutomirski
2018-12-10 17:44 ` Kees Cook
2018-12-12 9:28 ` kbuild test robot
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20181211162305.GA480@altlinux.org \
--to=ldv-u2l5pomzf/vg9huczpvpmw@public.gmane.org \
--cc=esyr-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org \
--cc=jannh-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org \
--cc=keescook-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org \
--cc=linux-api-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=luto-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org \
--cc=oleg-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org \
--cc=strace-devel-3+4lAyCyj6AWlMsSdNXQLw@public.gmane.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).