Received: by 2002:a05:6a10:22f:0:0:0:0 with SMTP id 15csp2368574pxk; Mon, 14 Sep 2020 11:23:44 -0700 (PDT) X-Google-Smtp-Source: ABdhPJz+keDQIaCKzLrluwMmJRS+xXpD9LhM1TsaFPZA/Ol2+vwTJLqskpOIqCUq+xmwD0qzlGnN X-Received: by 2002:a05:6402:1254:: with SMTP id l20mr18582658edw.312.1600107824596; Mon, 14 Sep 2020 11:23:44 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1600107824; cv=none; d=google.com; s=arc-20160816; b=lfKUdleV9JOjTAXd/XLB7Jb2nAWMB381RZ7Fkz0atBqdGIKTMDzHvl7Mp+sz7uYrfc aB1vl3Skqg/108DD6j8bFDam1OxdWFoBlq76r0SISPoB3pXV2i3ruwpSRNb++vg0qM+r XPK7qjZttAkwpJMHYfyHFULp7faEiMkBc3wVNlO70MHTGVIb08okNYax2orn+Z9wJJGT 4cgcMvj9ih3n6ZArgiZ+iOMNnADDtiAMb9NMLkCdt7Ch8X95GlYRq8h179PEOXuigK30 xDzQFjS6ApFmQp7pDmItS6l/+I/AcW0WiFiwGMhcjrzl/wuRRAKw/HELGDdVZh/S5SgV KtSw== 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=QwmdpKrctXZY8SsbeQhTPBt7ND8p7TZUdIMqRgAp49A=; b=pRQCGaICPjLG5l8lAU9dAZ1TX4EdVdw+WZpUhMuOPJn91xNEFNOKTAazzdPT2VLvY4 iTk0QphcFcj56kQyva0aCwXxemXmP6yGtQL1VchXIkY4+qgZRh3SMRc7T3EvoJn/1UJF vB+7DYjCxJmomF8PGY3Yag/g36JjLC8erzwKbjbZ1OceVot9t2+Ls+IYsgj9Pm0N6TaE mPeTfYdUeYq9iA96lWCj1+GKoY/LcD7F7QGLcXrvM+Ook0orcFhC8lySKbhxiehBR0ff H7jKF1/icC/beVFj+UEdE6eesdrNQpqwqlz4Kvhtib8a996ROx9zZP9TMUcYiWMm3FlA kc1A== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=Q7ZqaKpn; 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 z18si8663679edm.355.2020.09.14.11.23.22; Mon, 14 Sep 2020 11:23:44 -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=Q7ZqaKpn; 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 S1726106AbgINSWa (ORCPT + 99 others); Mon, 14 Sep 2020 14:22:30 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45810 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726023AbgINSWU (ORCPT ); Mon, 14 Sep 2020 14:22:20 -0400 Received: from mail-wm1-x344.google.com (mail-wm1-x344.google.com [IPv6:2a00:1450:4864:20::344]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 5B8EFC06174A; Mon, 14 Sep 2020 11:22:11 -0700 (PDT) Received: by mail-wm1-x344.google.com with SMTP id y15so1021277wmi.0; Mon, 14 Sep 2020 11:22:11 -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=QwmdpKrctXZY8SsbeQhTPBt7ND8p7TZUdIMqRgAp49A=; b=Q7ZqaKpnbyGyPvPJJ/i7BesuVwYV5eRqXM4dXhN/OCq1S9GrPiW1PQoD3eoi7TSQbf vb7Hv5UXRk/XE1i9Stcc75xYDV/GhLH6RC/gu6k3+cpFyfaZ65ZlbqFe4XCYrdJzI2se kNqM8UYDrm1kbvCsICZt7ryIp2NeZ6T8xIldIo5IXYFJLTtW2/IBHrNaLvW7mzo5DKxb DvoIohJ33HFLUoysYMdgVeszRwIpv+guhWLLyZRoYZQI4JiuAf4RN6R5L304OW+vEUbb dj84KuKIgnTvuB9JLmhDdFk6z3tgmb05exFWsrzzlDZvqgmLYunn1E+k2S9mFZQJPN7l UxyQ== 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=QwmdpKrctXZY8SsbeQhTPBt7ND8p7TZUdIMqRgAp49A=; b=f/cI3b9/Ga0ly7KAwQkmgo1yb+qJTjvb/anWLtAzMHrMpbIhqjLEUPVisTdKHZ/U4P kxKrnkCNWQkM7b++1jPRbmWv+DKp8v/CxqJB6cmHrh8GgzxaSfAortybJN+TztOY+cpq nmGQWhzuNccFAKe/yAjnV6ozU777lMsaxqUAzlJFIMRHt35ABo/HDz/FSG9C4XeNWDmo tp6mW2H+qckof9djDUHXrFJLcbj5u18Ew6DJXkTF3a+r/c3DJ/pjsTwzm/5iCYgzKTNV kDTrkmNg2F4sxOb+ZeKYWAHpW7UbJZnrsR8rTunh+ZJLM0K1UWftJznNHIC+Sd5WlAJY +toA== X-Gm-Message-State: AOAM530ckEeTrkpKlK5WnfxYhWOrQ2w3Qe5VsCez/EoYQmmwmpQmm0qn v4Sg96GzGzgs2lx0dgQiez74PyCEIA6ECIx7I5c= X-Received: by 2002:a1c:6254:: with SMTP id w81mr643669wmb.94.1600107729958; Mon, 14 Sep 2020 11:22:09 -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: From: Luke Nelson Date: Mon, 14 Sep 2020 11:21:58 -0700 Message-ID: Subject: Re: [PATCH] arm64: bpf: Fix branch offset in JIT To: Xi Wang Cc: Ilias Apalodimas , Jesper Dangaard Brouer , Will Deacon , bpf , 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 , Networking , linux-arm-kernel@lists.infradead.org, Linux Kernel Mailing List , Anders Roxell , =?UTF-8?B?QmrDtnJuIFTDtnBlbA==?= 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 11:08 AM Xi Wang wrote: > 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. As I understand it, there are two strategies JITs use to keep track of the ctx->offset table. Some JITs (RV32, RV64, arm32, arm64 currently, x86-32) track the end of each instruction (e.g., ctx->offset[i] marks the beginning of instruction i + 1). This requires care to handle jumps to the first instruction to avoid using ctx->offset[-1]. The RV32 and RV64 JITs have special handling for this case, while the arm32, arm64, and x86-32 JITs appear not to. The arm32 and x32 probably need to be fixed for the same reason arm64 does. The other strategy is for ctx->offset[i] to track the beginning of instruction i. The x86-64 JIT currently works this way. This can be easier to use (no need to special case -1) but looks to be trickier to construct. This patch changes the arm64 JIT to work this way. I don't think either strategy is inherently better, both can be "correct" as long as the JIT uses ctx->offset in the right way. This might be a good opportunity to change the JITs to be consistent about this (especially if the arm32, arm64, and x32 JITs all need to be fixed anyways). Having all JITs agree on the meaning of ctx->offset could help future readers debug / understand the code, and could help to someday verify the ctx->offset construction. Any thoughts? - Luke