Received: by 2002:a05:6a10:1287:0:0:0:0 with SMTP id d7csp1673030pxv; Fri, 16 Jul 2021 15:07:43 -0700 (PDT) X-Google-Smtp-Source: ABdhPJz7XkEFKNlii66ThZAUj4KeTyB3b6fy6iWME2UQLxFvzDBnySzAmcZyMOG3AO/eqximCaG4 X-Received: by 2002:a92:a806:: with SMTP id o6mr8210561ilh.53.1626473263147; Fri, 16 Jul 2021 15:07:43 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1626473263; cv=none; d=google.com; s=arc-20160816; b=fide8GeqVo6LiIRBxltWU6DKEp1gTwXc40WDu/O0rJwnnYNpXOdbL5XLQsboLWzRxs RAY62md//Q7FuVCRpJ+KShVGggIHxDZlaZZfVROzYSS31qfxiGKLKAr19L1l1LiD6mY7 Sd0mY/7aOrvPhpSo3yGBB6yeoIYz8WE8WcTqv6eDil+ESDpMXO3Lx8cJkg72gRgdIQye tR0e6wbZVZWrKSa8EhDaPXZ4SGBenGQMqzcIzqGujZnKUmASfAvxHHtDYPLCvTu9JRC6 Uw9Dtn1gC61mkBJSixqwRwze3oAwE3fx+Ni18u4zeCB1t/LCDm5q+G4YB2r7VZZsSqDS x8hA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=5LsAbpTyGpoMSPy6kuRB4pyfS/wxP9D1ajlZsdQwkJ8=; b=c8vmCrcxYiAYiMwK35QGkIl641JckMBHU5F/k6qswxrpuwVv04wwrK64yoJ7Hc5mR4 9NHRvpCuF03m/3XPcAaycYoyCD13vNdRsc0Heag6L6qkskMoUBCpp5FiZ5ZVWP93DdLH tUdp6eDJzg1TgnuHL6eWQHA76x6YvOEy9tI69Tr0l7b22XMsejQVJ3dxL67+pB6PKUmC Fwee6/7jwKGqJ/BbtUR4HPJ9ss+/Mgg90/9m/z82/U6EsEi8Uoizr3BJiQtOQb2CHmcM P2O6gI2rY1JK9LStbTvFKvCq7jSY2K3j0/6f6XwxG1v5EkpWGuRBS+a2JpZSie04qhnP 9GBw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=qqxNjdpW; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id v1si5154950iot.7.2021.07.16.15.07.29; Fri, 16 Jul 2021 15:07:43 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=qqxNjdpW; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S237210AbhGPWIv (ORCPT + 99 others); Fri, 16 Jul 2021 18:08:51 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33436 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230318AbhGPWIv (ORCPT ); Fri, 16 Jul 2021 18:08:51 -0400 Received: from mail-yb1-xb30.google.com (mail-yb1-xb30.google.com [IPv6:2607:f8b0:4864:20::b30]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B7507C06175F; Fri, 16 Jul 2021 15:05:54 -0700 (PDT) Received: by mail-yb1-xb30.google.com with SMTP id g19so17171070ybe.11; Fri, 16 Jul 2021 15:05:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=5LsAbpTyGpoMSPy6kuRB4pyfS/wxP9D1ajlZsdQwkJ8=; b=qqxNjdpW1LCG1+QjMqzatt42SvMUj+/is8XU7Fmr8H1GvmhPKNgeLeht2ozSeVXx2Y BB1Yd0mFrqNH6kY6dz4cSvmwE4g8a10n1h9b9hlJyPJnIV8ArwVKx0QWApfj3Q8b5KLG v+8a22vJY2TBF0XMitibR0gY6+Ni+tXRCRLafoiXpHKz8C8qQlDSeJA3ZXmI9iCuuIoG QR8xp5cE13WudGGYnzdnjEI9gGS582C0I375ui2Q4N2vFqwb4/S5iPJG+l8KIosPG8Xl 8PAgNJW5RgHcDfZxkxu+HGxci3ILC2huZWHJUAEpOMRzCqU5tahv/kTHY09kIUcGylAm 6SaA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=5LsAbpTyGpoMSPy6kuRB4pyfS/wxP9D1ajlZsdQwkJ8=; b=h9VwPXckTESDTkv6pEZ1aVmzPqh82Hy6XeXsHbRrY/GUPbbfZGVlxDkU0Y7ACGHzvs X6W/BjALQK08Mtu7aBUdwlc3PsUImVWk41QYI7EmLJiiYwbbyzedcAgnpCNYQpoPRa59 MKdQxsGl38ipvrjsmmjQHfvFn8caT0tzYtAjNg1752UY1TIeYueDUGQxMrz9W3+wUPHR m8AHdhV2fqQ2Y4IdqKHdFYqgxDkSlv9+YiAZvqiCrz0iXb2UJkcKFWIgh6+hldcIbN3x pa7pIYCUv0OylGvECOv6dmyt30EkNpNKLb98HnijGUoQTe+5S4nloz/01Ppmu6tG9pqk KpaQ== X-Gm-Message-State: AOAM533uMJ4G6nJODgTZT/XPtcE2zNTgQTuv4eX0hSJ9Agq1FXfBE9+7 oB2kl2g/1K5H6ygQA9Hx6ixG25bxTAulhUwIkqo= X-Received: by 2002:a25:b203:: with SMTP id i3mr15658989ybj.260.1626473154041; Fri, 16 Jul 2021 15:05:54 -0700 (PDT) MIME-Version: 1.0 References: <1626471813-17736-1-git-send-email-alan.maguire@oracle.com> In-Reply-To: <1626471813-17736-1-git-send-email-alan.maguire@oracle.com> From: Andrii Nakryiko Date: Fri, 16 Jul 2021 15:05:43 -0700 Message-ID: Subject: Re: [PATCH bpf-next] libbpf: clarify/fix unaligned data issues for btf typed dump To: Alan Maguire Cc: Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , Martin Lau , Song Liu , Yonghong Song , john fastabend , KP Singh , Bill Wendling , Shuah Khan , bpf , Networking , "open list:KERNEL SELFTEST FRAMEWORK" , open list Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Jul 16, 2021 at 2:44 PM Alan Maguire wrote: > > If data is packed, data structures can store it outside of usual > boundaries. For example a 4-byte int can be stored on a unaligned > boundary in a case like this: > > struct s { > char f1; > int f2; > } __attribute((packed)); > > ...the int is stored at an offset of one byte. Some platforms have > problems dereferencing data that is not aligned with its size, and > code exists to handle most cases of this for BTF typed data display. > However pointer display was missed, and a simple macro to test if > "data_is_unaligned(data, data_sz)" would help clarify this code. > > Suggested-by: Andrii Nakryiko > Signed-off-by: Alan Maguire > --- > tools/lib/bpf/btf_dump.c | 13 +++++++++---- > 1 file changed, 9 insertions(+), 4 deletions(-) > > diff --git a/tools/lib/bpf/btf_dump.c b/tools/lib/bpf/btf_dump.c > index 929cf93..9dfe9c1 100644 > --- a/tools/lib/bpf/btf_dump.c > +++ b/tools/lib/bpf/btf_dump.c > @@ -1654,6 +1654,8 @@ static int btf_dump_base_type_check_zero(struct btf_dump *d, > return 0; > } > > +#define data_is_unaligned(data, data_sz) (((uintptr_t)data) % data_sz) > + there is no need for macro, please use static function. And ptr_is_aligned() is probably a better form: if (!ptr_is_aligned(data, sz)) { /* handle uncommon case */ } ptr_is_aligned() can be probably reused more readily in some other places later. > static int btf_dump_int_data(struct btf_dump *d, > const struct btf_type *t, > __u32 type_id, > @@ -1672,7 +1674,7 @@ static int btf_dump_int_data(struct btf_dump *d, > /* handle packed int data - accesses of integers not aligned on > * int boundaries can cause problems on some platforms. > */ > - if (((uintptr_t)data) % sz) > + if (data_is_unaligned(data, sz)) > return btf_dump_bitfield_data(d, t, data, 0, 0); > > switch (sz) { > @@ -1739,7 +1741,7 @@ static int btf_dump_float_data(struct btf_dump *d, > int sz = t->size; > > /* handle unaligned data; copy to local union */ > - if (((uintptr_t)data) % sz) { > + if (data_is_unaligned(data, sz)) { > memcpy(&fl, data, sz); > flp = &fl; > } > @@ -1897,7 +1899,10 @@ static int btf_dump_ptr_data(struct btf_dump *d, > __u32 id, > const void *data) > { > - btf_dump_type_values(d, "%p", *(void **)data); > + void *ptrval; sizeof(void *) could be 4 on the host system and 8 in BTF. If you want to preserve the speed, I'd do something like: if (ptr_is_aligned(data, sizeof(void *)) && sizeof(void *) == d->ptr_sz) { btf_dump_type_values(d, "%p", *(void **)data); } else { /* fetch pointer value as unaligned integer */ if (d->ptr_sz == 4) printf("0x%x") else printf("0x%llx") } Maybe there is some cleaner way. But that should work, no? > + > + memcpy(&ptrval, data, d->ptr_sz); > + btf_dump_type_values(d, "%p", ptrval); > return 0; > } > > @@ -1910,7 +1915,7 @@ static int btf_dump_get_enum_value(struct btf_dump *d, > int sz = t->size; > > /* handle unaligned enum value */ > - if (((uintptr_t)data) % sz) { > + if (data_is_unaligned(data, sz)) { > *value = (__s64)btf_dump_bitfield_get_data(d, t, data, 0, 0); > return 0; > } > -- > 1.8.3.1 >