Received: by 2002:a05:6a10:22f:0:0:0:0 with SMTP id 15csp2405563pxk; Mon, 14 Sep 2020 12:25:40 -0700 (PDT) X-Google-Smtp-Source: ABdhPJz3aRMHVDte9HLZ77Y0/RPXUIwYtPYIZX6m7i2q9IGv0gjEd8cHiYpl2eSjSfY3E6kwcWpb X-Received: by 2002:a50:abc3:: with SMTP id u61mr18294801edc.129.1600111540500; Mon, 14 Sep 2020 12:25:40 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1600111540; cv=none; d=google.com; s=arc-20160816; b=zbJHq54k2Ek94CEMafxlnQdmtqy1TKcc1UO4jeG9tmgMc7Szj3G2krqRDUMI2nDSiW /HGDiCwW1NZ4P9LlNvCjGwoA7EozNRzMOp1eGJMcIsJiinzpmsVoT8/Jm/2Twg/OLQ3+ Bg+Ea6OU1mbDcvAmcdTtlJx2TTX+ZK2vCN5erprCKnZPU3u0K+nMSBDhxfJZ2w81vdvA 0+5l6IUIiD51l/dVCDvhFpfv0KIDnb1QoMuT9B4fKgD1OcrgjQ36rj7Bl+5irDz5Occ0 U9Bn6vykXRyBI5i6hRaAAVg1cq0ZAWYJozuV5fgwmpv46pS9ohB3zvRkuxChVhh0/yo0 aUWw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :dkim-signature; bh=GGDNGPz53jgjUxkKKetTXhXWNvLgdULWZECcE+Svp2E=; b=m4Vm+Q45a1WuAirsh3mlsH2zvgCDdO67SY5z8rHAgZNYuSCI6XDngJEAeB/E+vcU6l KByIlGmZ6xT7oSrMWkDDdWYMKYrZeIxPdBvrVTvGH0KfI5w8ij4+HyAm3R8zb3AuST5t Kgz8Wg8TbnCdcGB28OcCtQu8afGQb7Ph2XmN3vDUbFrFCG5g2ArpRKbKraBE+bLVHDfd DmlypUpNYBYcwaOM9geTJpXSjartIBnWQt/Km+ybQcvzWrz9aZVq761LbR5YOQTAUK/D GJwcxbaDee5rBcw9EbOQ/p5F4hXBuwfwg//9C+DZZ4BOCDwqyJ+PYHJrtBSFlr110Zec jL7g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b="NufJBOf/"; 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=NONE dis=NONE) header.from=linaro.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id i7si8404895edg.600.2020.09.14.12.25.18; Mon, 14 Sep 2020 12:25:40 -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=@linaro.org header.s=google header.b="NufJBOf/"; 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=NONE dis=NONE) header.from=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726024AbgINTYQ (ORCPT + 99 others); Mon, 14 Sep 2020 15:24:16 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:55350 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725914AbgINTYN (ORCPT ); Mon, 14 Sep 2020 15:24:13 -0400 Received: from mail-wm1-x341.google.com (mail-wm1-x341.google.com [IPv6:2a00:1450:4864:20::341]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B6C73C061788 for ; Mon, 14 Sep 2020 12:24:12 -0700 (PDT) Received: by mail-wm1-x341.google.com with SMTP id x23so1109938wmi.3 for ; Mon, 14 Sep 2020 12:24:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=GGDNGPz53jgjUxkKKetTXhXWNvLgdULWZECcE+Svp2E=; b=NufJBOf/E8NSsdIG8e8b5H0IeV+0Slk/9hNZeoq5bbabzJZedrlt3VEn7pryX3kMkq +CH15314AzGYpQ6LrnFATXjZn5Pm6aVxlW7PkWhz4ImJs2nMciZs1JvFIyaQD29ggZJd I1RJ1DN+nAGX09eAWy0dLmqgoD60IGFQounoNTK0xpMvyv5iIz6MJuykjkPIhdWd0DcZ aw28WXewFpIMSzpAzy19jH1FgcSfiPvObOlqxIwaPBiF18gBIGwn+dOHURzao4zB7tkC I6NPDhfdUfoTDmBa7yNqzajtnMFw8yB50Nx6PkUrm3YqYnsD5WRFEEyYw6gBOGnLKscn haMg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=GGDNGPz53jgjUxkKKetTXhXWNvLgdULWZECcE+Svp2E=; b=UUVOrmRj8wC+DEz+2Gd2uisnuUl9Zo84z2k5MJW5+EFIvdZAjOM8nqoy59ziEtKmCe Bng+DY5qKsuVnLxw90qidyYBzxoB4QdTV+j+ucjoAPJOF1avs2GKaXYvmbcLq7AfDpoq /xvhOAFiVyCIhq1uGBGOnNHI7m2EZRmjdgOJb0qIUXK29rsvJC/l4b/RpNc+VZtW1h93 HBlD3nOG+FlDBIjY9gyylsYKy5rpPHWi+b2k3NiF8hTSHbmgJq2GNUb4nUCHGC/SqPcP H4pOxcTxYsnZt2Ybz6iQRwGKGhnwN0TG98JxkTSJO1wAphqNNZHtJOQ0z4YR8UCe01mt Ac/Q== X-Gm-Message-State: AOAM532NKBqovcfZpSdA3wj5GH1EndK3yU7lcSsE9i698ohhkb+Cfr7Z OAmlZBxIW9XREcSKNKAQFE2n6Q== X-Received: by 2002:a1c:c90d:: with SMTP id f13mr881140wmb.25.1600111450968; Mon, 14 Sep 2020 12:24:10 -0700 (PDT) Received: from apalos.home (athedsl-246545.home.otenet.gr. [85.73.10.175]) by smtp.gmail.com with ESMTPSA id t15sm20771064wmj.15.2020.09.14.12.24.08 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 14 Sep 2020 12:24:10 -0700 (PDT) Date: Mon, 14 Sep 2020 22:24:07 +0300 From: Ilias Apalodimas To: Xi Wang 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 , =?iso-8859-1?Q?Bj=F6rn_T=F6pel?= , Luke Nelson Subject: Re: [PATCH] arm64: bpf: Fix branch offset in JIT Message-ID: <20200914192407.GB22481@apalos.home> References: <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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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:52:16AM -0700, Xi Wang wrote: > 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. > Well the arm64 was literally a 'save the idx before building the instruction', and add another element on the array. So it's not that trickier, especially if we document it properly. I haven't checked the rest of the architectures tbh (apart from x86). I assumed the tracking used in arm64 at that point, was a result of how eBPF worked before bounded loops were introduced. Maybe I was wrong. It felt a bit more natural to track the beginning of the emitted instructions rather than the end. > If we decide to patch the arm64 JIT the way you proposed, we should > consider whether to change other JITs consistently. I think this is a good idea. Following the code is not exactly a stroll in the park, so we can at least make it consistent across architectures. Thanks /Ilias