From mboxrd@z Thu Jan  1 00:00:00 1970
From: Peter Zijlstra <peterz@infradead.org>
Subject: Re: [PATCH 1/6] perf: Add new type PERF_TYPE_PROBE
Date: Fri, 24 Nov 2017 09:28:27 +0100
Message-ID: <20171124082827.nvgr3bfu3bidfdjx@hirez.programming.kicks-ass.net>
References: <20171115172339.1791161-1-songliubraving@fb.com>
 <20171115172339.1791161-3-songliubraving@fb.com>
 <20171123100214.qm3s4h5b6i4r2iaa@hirez.programming.kicks-ass.net>
 <adfbe341-7599-6819-27ef-4bc13cb65d6d@fb.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Cc: Song Liu <songliubraving@fb.com>, rostedt@goodmis.org,
        mingo@redhat.com, davem@davemloft.net, netdev@vger.kernel.org,
        linux-kernel@vger.kernel.org, daniel@iogearbox.net,
        kernel-team@fb.com
To: Alexei Starovoitov <ast@fb.com>
Return-path: <netdev-owner@vger.kernel.org>
Received: from merlin.infradead.org ([205.233.59.134]:58154 "EHLO
        merlin.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S1752432AbdKXI2r (ORCPT
        <rfc822;netdev@vger.kernel.org>); Fri, 24 Nov 2017 03:28:47 -0500
Content-Disposition: inline
In-Reply-To: <adfbe341-7599-6819-27ef-4bc13cb65d6d@fb.com>
Sender: netdev-owner@vger.kernel.org
List-ID: <netdev.vger.kernel.org>

On Thu, Nov 23, 2017 at 10:31:29PM -0800, Alexei Starovoitov wrote:
> unfortunately 32-bit is more screwed than it seems:
> 
> $ cat align.c
> #include <stdio.h>
> 
> struct S {
>   unsigned long long a;
> } s;
> 
> struct U {
>   unsigned long long a;
> } u;
> 
> int main()
> {
>         printf("%d, %d\n", sizeof(unsigned long long),
>                __alignof__(unsigned long long));
>         printf("%d, %d\n", sizeof(s), __alignof__(s));
>         printf("%d, %d\n", sizeof(u), __alignof__(u));
> }
> $ gcc -m32 align.c
> $ ./a.out
> 8, 8
> 8, 4
> 8, 4

*blink* how is that even correct? I understood the spec to say the
alignment of composite types should be the max alignment of any of its
member types (otherwise it cannot guarantee the alignment of its
members).

> so we have to use __aligned_u64 in uapi.

Ideally yes, but effectively it most often doesn't matter.

> Otherwise, yes, we could have used config1 and config2 to pass pointers
> to the kernel, but since they're defined as __u64 already we cannot
> change them and have to do this ugly dance around 'config' field.

I don't understand the reasoning why you cannot use them. Even if they
are not naturally aligned on x86_32, why would it matter?

x86_32 needs two loads in any case, but there is no concurrency, so
split loads is not a problem. Add to that that 'intptr_t' on ILP32
is in fact only a single u32 and thus the other u32 will always be 0.

So yes, alignment is screwy, but I really don't see who cares and why it
would matter in practise.

Please explain.