> -----Original Message----- > From: Christoph Hellwig <hch@xxxxxxxxxxxxx> > Sent: Monday, September 19, 2022 10:04 AM > To: Shung-Hsi Yu <shung-hsi.yu@xxxxxxxx> > Cc: Dave Thaler <dthaler@xxxxxxxxxxxxx>; bpf <bpf@xxxxxxxxxxxxxxx> > Subject: Re: FW: ebpf-docs: draft of ISA doc updates in progress > > On Wed, Sep 14, 2022 at 02:22:51PM +0800, Shung-Hsi Yu wrote: > > As discussed in yesterday's session, there's no graceful abortion on > > division by zero, instead, the BPF verifier in Linux prevents division > > by zero from happening. Here a few additional notes: > > Hmm, I thought Alexei pointed out a while ago that divide by zero is now > defined to return 0 following. Ok, reading further along I think that is what > you describe with the pseudo-code below. Based on the discussion at LPC, and the fact that older implementations, as well as uBPF and rbpf still terminate the program, I've added this text to permit both behaviors: > If eBPF program execution would result in division by zero, > the destination register SHOULD instead be set to zero, but > program execution MAY be gracefully aborted instead. > Similarly, if execution would result in modulo by zero, > the destination register SHOULD instead be set to the source value, > but program execution MAY be gracefully aborted instead. And elsewhere in the doc defined gracefully aborted as: > After execution of an eBPF program, register R0 contains the exit code > whose meaning is defined by the program type, except that an exit code > of -1 means the program was gracefully aborted. That is, if a program > is gracefully aborted for any reason, it means that no further instructions > are executed, and a value of -1 is returned in register R0 to the caller of > the program. The problem with that, as Quentin pointed out, is that -1 is a valid return code from some program types like TC. Do we suddenly declare uBPF etc as being non-compliant? My preference is just to document the issue, since such runtimes might choose to make -1 be a reserved value for all program types they support. After all the ISA does not define program type details so they can use the ISA without TC etc. > > While BPF ISA only supports direct call BPF_CALL[1], technically there > > is an opcode 0x8d (BPF_JUMP | BPF_CALL | BPF_X) that has the indirect > > call semantic, and Clang emit such indirect call instruction if user > > attempt to compile with -O0. > > > > I think it worth mentioning in this document for better clarity, > > perhaps simply saying that indirect call is not part of BPF ISA is enough. > > Which brings up another question: Do we need a list of opcodes that > someone else defined somewhere that are not considered valid eBPF? That's what my document currently does, saying: > Note that ``BPF_CALL | BPF_X | BPF_JMP`` (0x8d), where the helper > function integer would be read from a specified register, is not currently > permitted. > > **Note** > > *Clang implementation*: > Clang will generate this invalid instruction if ``-O0`` is used. The latest version can be viewed at https://github.com/dthaler/ebpf-docs/blob/update/isa/kernel.org/instruction-set.rst I can post another patchset after addressing any other comments. Dave
