From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.6 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 35EE4C433E7 for ; Mon, 19 Oct 2020 22:02:31 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id BF7BF2237B for ; Mon, 19 Oct 2020 22:02:30 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="DVWtZVhp" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2387748AbgJSWCa (ORCPT ); Mon, 19 Oct 2020 18:02:30 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:56258 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729617AbgJSWCa (ORCPT ); Mon, 19 Oct 2020 18:02:30 -0400 Received: from mail-lj1-x22d.google.com (mail-lj1-x22d.google.com [IPv6:2a00:1450:4864:20::22d]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C4348C0613CE for ; Mon, 19 Oct 2020 15:02:29 -0700 (PDT) Received: by mail-lj1-x22d.google.com with SMTP id 23so2111232ljv.7 for ; Mon, 19 Oct 2020 15:02:29 -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=7II6SS5VqohjtAxbqQemDFOC71upiwxLecRxANCNdAA=; b=DVWtZVhp0ODdbWPZM/uqX8YbYkBHXbrwLrbJfPocE1kwxKCgDZMaRqKX4soNAaDpsd L/z78idFgbA+twmnc68FAKtzKK5uWMY7/642sb964f/GeK4fdOsGlqfqRPM49T2Z3zxe SRwhkuzRslWMP+73uhoWsVPvvdJQ/ZYairmNreiXRPpc+DL4FtG6JKV9iwBCupsDdqHd CrfNFjfVdkQO2rQogYCY/MuYpgW3F7ot3h0QqdKyqHWnO9LZBQ8yA3a++2mE4bPt7mAG hgfsKhdI6ZD0T/9WI1gMu3bxbco/6zKtnf4wfTELgQAu7FOt2mgj/UC6G0BKgTnTlKBc Fi8g== 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=7II6SS5VqohjtAxbqQemDFOC71upiwxLecRxANCNdAA=; b=p/XnoZoM9Px9T9Iz38z/6OX/C448svZ+Ev4qfuq+VVwez9mZn7+RY5r8XuY1A9k4I6 DEXC4leBoERoUivxFVVbqvaScdWRbv0KcOJues034wKzCKEFqRXigkfRdbp2KAZHlv9e QBTD8EY/Lasrk5nUUZFl2JxLL3CGE45GCw3s5FCLIAodX3z+dlXPqBVRxeKKyclTYJni RilM8tuxCxUSoZN3yBo4uRpPAYXHN9rMZoLOo8imDIg1ZIEcijhcAE551eTImx7xFt67 5fE0ll76MBHdLeLvOiVhU4QwcoZJn4MYG8flAHiDufOxaAKvalBnwri10zRH6UBZ4MG+ GNSQ== X-Gm-Message-State: AOAM530hMh/wV0XugJABMxxWBxw4Y8sOpQfLiOXsiEirmLPtbJUuD1Kv 79gk0Tx98vYYx28Klqh9/6RvqnOSar8CNNZ0mkEPs2rmJAo= X-Google-Smtp-Source: ABdhPJz9p1UoghsGE2UfVR/QxeYyYAQzBsqu0W/cOzuTyfKKZDHIOTbKZ3o/lQgX/eBsk1Noe12WNdLuirrFBK/GQB4= X-Received: by 2002:a2e:9015:: with SMTP id h21mr845674ljg.450.1603144947830; Mon, 19 Oct 2020 15:02:27 -0700 (PDT) MIME-Version: 1.0 References: <8cc1629c-8a85-2d84-f779-6a20bb5d36bd@iogearbox.net> In-Reply-To: From: Alexei Starovoitov Date: Mon, 19 Oct 2020 15:02:16 -0700 Message-ID: Subject: Re: Running JITed and interpreted programs simultaneously To: Andrii Nakryiko Cc: Daniel Borkmann , Juraj Vijtiuk , bpf , Luka Perkov , David Marcinkovic Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: bpf@vger.kernel.org On Mon, Oct 19, 2020 at 11:26 AM Andrii Nakryiko wrote: > > That wasn't happening last time people reported this on ARM32. > BPF_XADD was causing load failure, no fail back to interpreter mode. > > > > > Wrt force-interpret vs force-jit BPF_PROG_LOAD flag, I'm more concerned that this > > decision will then be pushed to the user who should not have to care about these > > internals. And how would generic loaders try to react if force-jit fails? They would > > then fallback to force-interpret same way as kernel does? > > The way I imagined this was if the user wants to force the mode and > the kernel doesn't support it (or the program can't be loaded in that > mode), then it's a fail-stop, no fall back. And it's strictly an > opt-in flag, if nothing is specified then it's current behavior with > fallback (which apparently doesn't always work). That doesn't sound right. Fallback to interpreter should always work unless features like trampoline are used. But that's not the case for arm32. Missing xadd support shouldn't cause load failure.