From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-ej1-x62b.google.com (mail-ej1-x62b.google.com [IPv6:2a00:1450:4864:20::62b]) by mail.toke.dk (Postfix) with ESMTPS id EFB099C2840 for ; Tue, 15 Nov 2022 23:54:17 +0100 (CET) Authentication-Results: mail.toke.dk; dkim=pass (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.a=rsa-sha256 header.s=20210112 header.b=DYqo9KKn Received: by mail-ej1-x62b.google.com with SMTP id f18so6903847ejz.5 for ; Tue, 15 Nov 2022 14:54:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=tS7itbUVU0VT0dkwZPn1BAAjaVKk6+KaYVTgLf/SfTo=; b=DYqo9KKntKJjmEdFY8Pi0MZOMz1ZtOgJkp/EkvXbcw2fMSAox+swrc6SoOaTAEvCVW 0W+/2g8gPfIeIbtkTk6liz+UZz100NuyHMaq1d/9c48i9GOHv5lDryGHj7fA/53AZ6wA N02KoGIJ8VNY5RL6sn+77iRa8+gzD1LoMlnEfvxOPsmDE01dviDTI8f5IARg37MJdaQg 8Cd2oxwTz8BJaOeHTSeQmdRl4TxOdydRDb+/Z80Nefi2yC0tj7kSqgSUomoDjJSnwiDJ u+Gf55yXuhanUIt336yDfQAfhxdUYEUlhIVQkb1YKX0wcM9GCDJ7v00Huu9//cvvIMXe dpRg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=tS7itbUVU0VT0dkwZPn1BAAjaVKk6+KaYVTgLf/SfTo=; b=e9pOh8Nu1Fr65ikfmbRlFPW3H/gA9m+L5PjLl/K9OsrQ7QNvvv++0Ptnz7CM7ZVPmy apUjIAkYuu0i9QWCk49O/2Ilay/b+76XMn3hglaMN5hGd90Y0Gg9qeyTu9Aai8Nxu4yu 5tMDTWhGRCUNfIw8U4DV9Kvrybnlc3yi3HHAc92W1jXxd5TYFwf9EN0sHDIW13tZ8mSD MChmYBJ3TSd9htXfggCnPgNa2bUAYk7yjGJumkSqNgIkuGqKtWv844YShi3p+X6+QhBO 80zz8pO8+j6af4786PF64YoqLrupkMLPVqeuu88XNB3f6H5jxQreg5nvhk/h89zUtzSM XaJg== X-Gm-Message-State: ANoB5pkxLVKsAL8ppWDGPDH+VZ6Gk9Oe53otTO9QxpYI2PVFI+bk1EFM MpbMsfFBNK0ogSDBmf8NbaiH7n/Gss6YCRrcyxg= X-Google-Smtp-Source: AA0mqf6sPgQHEUxw4WJdC/SaR9y5RJiZLK4nfQ6acj7MHepRTEu8qIhCXM99URaFwS4AFQRfLUFZlkFvd3gnGQLsYKk= X-Received: by 2002:a17:907:a701:b0:78d:9858:e538 with SMTP id vw1-20020a170907a70100b0078d9858e538mr16152395ejc.502.1668552854643; Tue, 15 Nov 2022 14:54:14 -0800 (PST) MIME-Version: 1.0 References: <20221115030210.3159213-1-sdf@google.com> <87mt8si56i.fsf@toke.dk> In-Reply-To: From: Alexei Starovoitov Date: Tue, 15 Nov 2022 14:54:03 -0800 Message-ID: To: Stanislav Fomichev Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Message-ID-Hash: K7VFEW55UBV2OE4SM54QLLOOPSORXQQD X-Message-ID-Hash: K7VFEW55UBV2OE4SM54QLLOOPSORXQQD X-MailFrom: alexei.starovoitov@gmail.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: =?UTF-8?B?VG9rZSBIw7hpbGFuZC1Kw7hyZ2Vuc2Vu?= , bpf , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , Martin KaFai Lau , Song Liu , Yonghong Song , John Fastabend , KP Singh , Hao Luo , Jiri Olsa , David Ahern , Jakub Kicinski , Willem de Bruijn , Jesper Dangaard Brouer , Anatoly Burakov , Alexander Lobakin , Magnus Karlsson , Maryam Tahhan , xdp-hints@xdp-project.net, Network Development X-Mailman-Version: 3.3.6 Precedence: list Subject: [xdp-hints] Re: [PATCH bpf-next 00/11] xdp: hints via kfuncs List-Id: XDP hardware hints design discussion Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: On Tue, Nov 15, 2022 at 10:38 AM Stanislav Fomichev wrote: > > On Tue, Nov 15, 2022 at 7:54 AM Toke H=C3=B8iland-J=C3=B8rgensen wrote: > > > > Stanislav Fomichev writes: > > > > > - drop __randomize_layout > > > > > > Not sure it's possible to sanely expose it via UAPI. Because every > > > .o potentially gets its own randomized layout, test_progs > > > refuses to link. > > > > So this won't work if the struct is in a kernel-supplied UAPI header > > (which would include the __randomize_layout tag). But if it's *not* in = a > > UAPI header it should still be included in a stable form (i.e., without > > the randomize tag) in vmlinux.h, right? Which would be the point: > > consumers would be forced to read it from there and do CO-RE on it... > > So you're suggesting something like the following in the uapi header? > > #ifndef __KERNEL__ > #define __randomize_layout > #endif > 1. __randomize_layout in uapi header makes no sense. 2. It's supported by gcc plugin and afaik that plugin is broken vs debug info, so dwarf is broken, hence BTF is broken too, and CO-RE doesn't work on kernels compiled with that gcc plugin.