Received: by 2002:a05:6a10:5bc5:0:0:0:0 with SMTP id os5csp882792pxb; Wed, 27 Oct 2021 14:24:44 -0700 (PDT) X-Google-Smtp-Source: ABdhPJytJwNJTaodJbJogmcVytyw+xQDB3p+JzMwfN+5T2zTV5kx+PkshBl//WFAtIZEccNsUFTX X-Received: by 2002:a17:906:2653:: with SMTP id i19mr50131ejc.193.1635369884699; Wed, 27 Oct 2021 14:24:44 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1635369884; cv=none; d=google.com; s=arc-20160816; b=deedgOHYqNg+4+hUuCSsAQOrwagsJ9UYC6LXNX83nUuyUyW2b8QkhOhMOLxUlvpHM3 qXeF0QGazQaP5dNwthpe6S34wWkMQWpSHDYcAJvTv0uksGUi6UHcwhNC93ROifsz83qN 0k33aTfsKRgsrXkAiXHX8voG0K31kOd30rgTeC9g7ODeRmQqNo0rcm/jy0lnmBCKVIrg Y2S1hppeSv6Grwj/N9AVMYaW57PwbkikDK3nO7WzBvVGR8Cp9XjhI/US4XANxogNsBvj QNPQh395mrueBGemrJkq2/H9I+FrTkDmYU98m+XsDxxX02RkKRQvDI6ZbyzD+UNhct6X H8og== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date; bh=e8g8gHlmlJmw7G38DK1ky58+VvdYNbkuNTLVqcRgiUk=; b=Z4ZrnzSQKJK6S8CCJihnx3HSJsZxSph8CsO8HWJR62kstOlOrf400AFh2Yxl0/8ai1 4jwAEZsWtF0iK8Y+mNx8waxOD13IMqGOLt6ZrGBpwWsm0D8RxN7zYliOOWgjK3NEuX20 g2HdOTgciaW26Ab3AEouN0FhCylZ+uHR1meTJNpBU30CZLcyGGnCBZCbaAWJ+9Ip7Fts nU4rHJ1baD8HOOJXznq0Cy7FF8FVi2TCo+/L2gzMX2T1WvMCrCH8Id4YE5KwtGfCJ/m3 BIE9SUgqLm5gXEKH5JH/Sz5ZfqNa0Ktn5VYJsrTcla2op5ahVZ4u+rqArhU1ahJK73m9 puGw== ARC-Authentication-Results: i=1; mx.google.com; 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=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id dm8si1557687ejc.614.2021.10.27.14.24.21; Wed, 27 Oct 2021 14:24: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; 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=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S241726AbhJ0LxW (ORCPT + 97 others); Wed, 27 Oct 2021 07:53:22 -0400 Received: from foss.arm.com ([217.140.110.172]:42440 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S240073AbhJ0LxR (ORCPT ); Wed, 27 Oct 2021 07:53:17 -0400 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id B9AD31FB; Wed, 27 Oct 2021 04:50:51 -0700 (PDT) Received: from C02TD0UTHF1T.local (unknown [10.57.72.240]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 51AF43F73D; Wed, 27 Oct 2021 04:50:47 -0700 (PDT) Date: Wed, 27 Oct 2021 12:50:43 +0100 From: Mark Rutland To: Tong Tiangen Cc: Paul Walmsley , Palmer Dabbelt , Palmer Dabbelt , Albert Ou , =?utf-8?B?QmrDtnJuIFTDtnBlbA==?= , Luke Nelson , Xi Wang , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , Martin KaFai Lau , Song Liu , Yonghong Song , John Fastabend , KP Singh , linux-riscv@lists.infradead.org, linux-kernel@vger.kernel.org, netdev@vger.kernel.org, bpf@vger.kernel.org Subject: Re: [PATCH bpf-next,v3] riscv, bpf: Add BPF exception tables Message-ID: <20211027115043.GB54628@C02TD0UTHF1T.local> References: <20211027111822.3801679-1-tongtiangen@huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20211027111822.3801679-1-tongtiangen@huawei.com> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Oct 27, 2021 at 11:18:22AM +0000, Tong Tiangen wrote: > When a tracing BPF program attempts to read memory without using the > bpf_probe_read() helper, the verifier marks the load instruction with > the BPF_PROBE_MEM flag. Since the riscv JIT does not currently recognize > this flag it falls back to the interpreter. > > Add support for BPF_PROBE_MEM, by appending an exception table to the > BPF program. If the load instruction causes a data abort, the fixup > infrastructure finds the exception table and fixes up the fault, by > clearing the destination register and jumping over the faulting > instruction. > > A more generic solution would add a "handler" field to the table entry, > like on x86 and s390. > > The same issue in ARM64 is fixed in: > commit 800834285361 ("bpf, arm64: Add BPF exception tables") > +#ifdef CONFIG_BPF_JIT > +int rv_bpf_fixup_exception(const struct exception_table_entry *ex, struct pt_regs *regs); > +#endif > + > int fixup_exception(struct pt_regs *regs) > { > const struct exception_table_entry *fixup; > > fixup = search_exception_tables(regs->epc); > - if (fixup) { > - regs->epc = fixup->fixup; > - return 1; > - } > - return 0; > + if (!fixup) > + return 0; > + > +#ifdef CONFIG_BPF_JIT > + if (regs->epc >= BPF_JIT_REGION_START && regs->epc < BPF_JIT_REGION_END) > + return rv_bpf_fixup_exception(fixup, regs); > +#endif > + > + regs->epc = fixup->fixup; > + return 1; > } As a heads-up, on the extable front, both arm64 and x86 are moving to having an enumerated "type" field to select the handler: x86: https://lore.kernel.org/lkml/20210908132525.211958725@linutronix.de/ arm64: https://lore.kernel.org/linux-arm-kernel/20211019160219.5202-11-mark.rutland@arm.com/ ... and going forwards, riscv might want to do likewise. Thanks, Mark.