Received: by 2002:a05:6a10:22f:0:0:0:0 with SMTP id 15csp2386577pxk; Mon, 14 Sep 2020 11:54:06 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzS6Pc7KdqzLdOal7tofrD/sbHntc/nYrjeliY+jy1Q+8TTgTmyhuqDaoyBK1XhD4Lh64KY X-Received: by 2002:a50:baed:: with SMTP id x100mr3583083ede.384.1600109646182; Mon, 14 Sep 2020 11:54:06 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1600109646; cv=none; d=google.com; s=arc-20160816; b=ZgH5HmiGwmH6zxOEA94awedF6HRJrK7lX96Fb+ObOgZU+h+ui2wM+d/2IjySk6Ydds rlxqqDmFOAivAGj4bisvMHVGETGv1PiQQBk1Z+RubfCwN6aiEWWqZfBZMiX7Z5xybCR4 In6v9Dqo/4v0x0sIgxjc3Eucj/oBhuLtoC7wHnINQYWt3XjZlqXrRKMBCDMloxc/cb3d 3NzF5wt3fr1T/ouwgEeM3dsTInJfLF0hqkfRhq7rv2O9DFD+PYLwPiJwN479/CwEOOP0 4ixfoLS9maqlprLWr19QJxUFscfkqEmDHg39iwPSqQ0odJ4SLuUL58ugHdCaOLBEKmfX dBvw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=cRuE7ghYmX/MnQQcJBt4NDc6WttGR8e1vIUwI+1gPGA=; b=yZsSlq2H8apR4WzFFHNqDL8YdOgzJMOH12/ePHy74/mpnf5QN+2Cj3N59ba6idbWtF fC2LZiXDH0LIh1+sESis4Sfso9tQXLB2UipOdZBMiC8MJcCoBwf5xeTtH63FjEAYikHS VY0xGS9YLU874axROg7KuCPNVl8+AziY7/olRD/IfxXkMwUblmGM5W0ABWpvle5Pov6D OCjj6wAGp9qiKTGLAfl7U+eGJjJe6zGcSKIJwRByIx/9KJ/pWooblbIUdF1yKyex30qV K3/9h90X00VKeGpCAo889cRsXxtwNNXoE4d+bmqvur048cJVclDjy9wkWhZACOwa38Hu kY/w== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=UkRrlE0m; 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 u16si8228255edo.487.2020.09.14.11.53.43; Mon, 14 Sep 2020 11:54:06 -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=UkRrlE0m; 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 S1725992AbgINSw7 (ORCPT + 99 others); Mon, 14 Sep 2020 14:52:59 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:50578 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725914AbgINSw4 (ORCPT ); Mon, 14 Sep 2020 14:52:56 -0400 Received: from mail-qt1-x841.google.com (mail-qt1-x841.google.com [IPv6:2607:f8b0:4864:20::841]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 6A0CDC06174A; Mon, 14 Sep 2020 11:52:55 -0700 (PDT) Received: by mail-qt1-x841.google.com with SMTP id k25so860186qtu.4; Mon, 14 Sep 2020 11:52:55 -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=cRuE7ghYmX/MnQQcJBt4NDc6WttGR8e1vIUwI+1gPGA=; b=UkRrlE0m1+WF9msVPr5gid8roJaZt1r/OaDQRSyARhhE2uG/LpFzV4A8O2BgFe9IPV s/YYuXXzYjOA3bwgt09LzqgiryW058mZ9M6MLiucyIRnfOm88EEn+a8byN4gdrQGKsmY Be3s2tamJOxHcVFHpaamPWM5+tfrwYeKrz/lkszY7r+8ifHgRJ6WT6RRXfQuPLz5Hheo tRj5diMAy/AmHvYFGYQQ5CNF+T7P86ExaIUB/fG0TiYfTXjbWqU9Km8WIZUn+x1pOpr4 s6MDO2GzC631it4Y5UlFJziZ67zBVHiqY8hcvQj6GREu6JNTf5npc33KFXPB1XL9XjZz 4Vig== 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=cRuE7ghYmX/MnQQcJBt4NDc6WttGR8e1vIUwI+1gPGA=; b=TRHWDDcKX17GIBWIC2DpPM95S5tLCtTJtiy0WbzDAsGSSkI3FhrNqzJ2m26YIcWLoC IVJCHdv+hn+aGShafRNCUn+iB9nZubhWH2ID3lmuf8hTfIwomn5/Ma0+aXTTWQ+MrVzS YSPuZIukp0xRAWI5ZKYsI3u91uN9/ToUxlPJiQwdAvy/ESgobgfYpN6AGChHw8G6//lL VMMR7oYMPpj4bxn89dty705atTrlcnDuCIbJrpgRvrddkZF4bRghALJGrIbrTmHWG74c ldJu8nYQA5KG3lN2aW6ZjBf+I1E32GINz4lhm8A0Tk9pV28HxpIAXququJxSUAaKFWeD Cq8g== X-Gm-Message-State: AOAM532E0mvgWI0fHQzn9smLcVa2CHyvLGUlaxKYamCbG/memdLI5Sap ZVmvT54H4KEsvXcYOGnOTJGskuO6lEVJqq+j3UU= X-Received: by 2002:ac8:660a:: with SMTP id c10mr2319819qtp.300.1600109572562; Mon, 14 Sep 2020 11:52:52 -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> <20200914182756.GA22294@apalos.home> In-Reply-To: <20200914182756.GA22294@apalos.home> From: Xi Wang Date: Mon, 14 Sep 2020 11:52:16 -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" 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:28 AM Ilias Apalodimas wrote: > Even if that's true, is any reason at all why we should skip the first element > of the array, that's now needed since 7c2e988f400 to jump back to the first > instruction? > Introducing 2 extra if conditions and hotfix the array on the fly (and for > every future invocation of that), seems better to you? My point was that there's no inherently correct/wrong way to construct offsets. As Luke explained in his email, 1) there are two different strategies used by the JITs and 2) there are likely similar bugs beyond arm64. Each strategy has pros and cons, and I'm fine with either. I like the strategy used in your patch because it's more intuitive (offset[i] is the start of the emitted instructions for BPF instruction i, rather than the end), though the changes to the construction process are trickier. If we decide to patch the arm64 JIT the way you proposed, we should consider whether to change other JITs consistently.