Received: by 2002:a05:6a10:22f:0:0:0:0 with SMTP id 15csp2359907pxk; Mon, 14 Sep 2020 11:10:24 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzVD7TNU0/JalqI65y9C83gzf1UBH1bW+rmtrxSSY8MkudWwUcadKwfWf8S3ocRa5VhrqRc X-Received: by 2002:a17:906:2c14:: with SMTP id e20mr16667959ejh.205.1600107024766; Mon, 14 Sep 2020 11:10:24 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1600107024; cv=none; d=google.com; s=arc-20160816; b=U7k+x9BzlOAbudND8tET1gJsgYcPQZSAKvmToDr9ks7mml9UPsmqGBkP5CIt5yPAM2 xSv/uRHieS3Gdgx4BY6GYZCRzn76eZ41WSMLzks0MvvsDdnvPHnCIctMtehU2EaGeyYR yKOu9i2vKVBzvwUOYKXzH/KcArT/2ax7uuzD+qRvaJZSW0VG+eEPJq5KK8OJIYkxwCsF sHLHS/p86w6VwKyYR1BqtpOR0udAW1jAMJ5HRfw5scNmLVJak5/vXkjWQJQyAU6tyP+8 ta259Tkk6LiIlkX8XDIGcKFEmn8PfbyjMJqsuCE5D+kr1jXISIZwRC8ltk2L4qVz36st WbFA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:cc:to:subject :message-id:date:from:in-reply-to:references:mime-version :dkim-signature; bh=24YFM+Nh7pEwkm7cAsSqCM3onePtrQOnKk+utLA7aiY=; b=M4w5brr40qc5RoTI1pIXyCRQK5uXQIZW8/h/bJBtLn17ye9VtB/aoh+r4i1psOyAsl RYrrFKKJ11T05FmIh0pn6/T/3gmfd+k0WomglpyNiTtu49X/gJm1lhN1zT4zb9z0PLKR OUYeYwITi9dzBivGeCfdHP7FBHkeBDSrABI5uy3+I7lQbpXlyCTzzzUkcTe//Th9f3O0 IrCmdb7gt9WQ7PIMMQSLYIelejzYdDEiqF/hVsJTLX36Jw37zrX5MmkBekbIRubUHLIQ lpBo8CP3goEbR7zCO+l2a/WRwg9WJI8kDPXYSewDVVrzTx5yHlnK/xmJDYtve1ovOSS8 8qQg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=EJk+odAG; 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 d25si8544204edn.340.2020.09.14.11.09.56; Mon, 14 Sep 2020 11:10:24 -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=EJk+odAG; 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 S1726192AbgINSJN (ORCPT + 99 others); Mon, 14 Sep 2020 14:09:13 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43760 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726100AbgINSIu (ORCPT ); Mon, 14 Sep 2020 14:08:50 -0400 Received: from mail-qk1-x744.google.com (mail-qk1-x744.google.com [IPv6:2607:f8b0:4864:20::744]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id CD939C06174A; Mon, 14 Sep 2020 11:08:49 -0700 (PDT) Received: by mail-qk1-x744.google.com with SMTP id o5so1011539qke.12; Mon, 14 Sep 2020 11:08:49 -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:content-transfer-encoding; bh=24YFM+Nh7pEwkm7cAsSqCM3onePtrQOnKk+utLA7aiY=; b=EJk+odAGXK43RKGanFbisPiaXuq0ehzeSoY8YXMqQa7nw+Vrq3q3BhC08XmjawK3n2 1fxNcbU7QPtiuIkz3i8Z/GM0CqZOcKHZO436S6nJq6maBwVecKzAXr1TnJslzPISotH2 0OPxJMsfteTOJ2EHC2N3DLPaN6E2bYkUv5bXv+rHjrUoBXTHZOid9PYOPWFZ2NLENyqB 3U+2iz1go2bgWiWgDFz2nHG5QDzV0LYa+pDXtbGsB5h2W/DgLaGkhdspgawBuX8L+c3v j8O461fd9dUqoEF+i/dwXrwDC5I3rM1hBSqqC4F6XmYUTXE8F87D98brktjjGKerEXHV ol8A== 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:content-transfer-encoding; bh=24YFM+Nh7pEwkm7cAsSqCM3onePtrQOnKk+utLA7aiY=; b=NFVtwVLShgibBE05Eo4kt86rD7R2lZq+/T38sFwTLo20feHKNh9HKoi/Q5fyQtQ0VQ F9Xneo6qGXuExw/1Lblrhym3J37iqJsdJPXHG/Dzny1HHfasJkyjFeBwM3jZqqlwWdwA iQiWdlWjHIgyiLruu7+mZ94qFfcroPN1Pwd8H97FH2pZvKMgtQ1wx79/7meTgsk/YvC2 iw/muy5XtKhF9D6Vgh0w8GKO5F5poVWUGxPhAMiTnNI8In/wE11eWF9u/UA4U3YlmcrA urZAPF921uhi/PADvJGnNdHFeyD0lgsEuiKrItN6gdUQs9/+StBC7RqBAQT7XfPYWLLC afSA== X-Gm-Message-State: AOAM531LNJ196yCMomfmveW511LZI3ZeEMWFNVODPmyytf5uVYycprUN +MOYJRZ3dztEpYK2tAVWy4rUt4pLENzyZ5UQCEY= X-Received: by 2002:a05:620a:2291:: with SMTP id o17mr13963182qkh.476.1600106928920; Mon, 14 Sep 2020 11:08:48 -0700 (PDT) MIME-Version: 1.0 References: <20200914083622.116554-1-ilias.apalodimas@linaro.org> <20200914122042.GA24441@willie-the-truck> <20200914123504.GA124316@apalos.home> <20200914132350.GA126552@apalos.home> <20200914140114.GG24441@willie-the-truck> <20200914181234.0f1df8ba@carbon> <20200914170205.GA20549@apalos.home> <20200914175516.GA21832@apalos.home> In-Reply-To: <20200914175516.GA21832@apalos.home> From: Xi Wang Date: Mon, 14 Sep 2020 11:08:13 -0700 Message-ID: Subject: Re: [PATCH] arm64: bpf: Fix branch offset in JIT To: Ilias Apalodimas Cc: Jesper Dangaard Brouer , Will Deacon , bpf@vger.kernel.org, ardb@kernel.org, naresh.kamboju@linaro.org, Jean-Philippe Brucker , Yauheni Kaliuta , Daniel Borkmann , Alexei Starovoitov , Zi Shen Lim , Catalin Marinas , Martin KaFai Lau , Song Liu , Yonghong Song , Andrii Nakryiko , John Fastabend , KP Singh , "David S. Miller" , Jakub Kicinski , Jesper Dangaard Brouer , netdev@vger.kernel.org, linux-arm-kernel@lists.infradead.org, Linux Kernel Mailing List , Anders Roxell , =?UTF-8?B?QmrDtnJuIFTDtnBlbA==?= , Luke Nelson Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Sep 14, 2020 at 10:55 AM Ilias Apalodimas wrote: > We've briefly discussed this approach with Yauheni while coming up with t= he > posted patch. > I think that contructing the array correctly in the first place is better= . > Right now it might only be used in bpf2a64_offset() and bpf_prog_fill_jit= ed_linfo() > but if we fixup the values on the fly in there, everyone that intends to = use the > offset for any reason will have to account for the missing instruction. I don't understand what you mean by "correctly." What's your correctness s= pec? I don't think there's some consistent semantics of "offsets" across the JITs of different architectures (maybe it's good to clean that up). RV64 and RV32 JITs are doing something similar to arm64 with respect to offsets. CCing Bj=C3=B6rn and Luke.