On Tue, Sep 20, 2022 at 12:51 PM Dave Thaler <dthaler@xxxxxxxxxxxxx> wrote: > > > -----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: That's not right. ubpf and rbpf are broken. We shouldn't be adding descriptions of broken implementations to the standard. There is no way to 'gracefully abort' in eBPF. There is a way to 'return 0' in cBPF, but that's different. See below. > > > 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? yes. ubpf is non-compliant. -1 is just a radom number that ubpf picked. Classic BPF defines a certain situation for obsolete LD_ABS as 'return 0'. We had to keep it this way due to classic baggage, but, as we agreed, we're not going to define these two classic insns in the standard doc. So there should be no 'graceful abort' paragraph anywhere in the standard. > 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. We can document with certainty the returns codes of XDP prog type and stress that they should be the same across all run-times. There is no reason for windows to be different from linux in XDP progs. What to do with TC and other returns codes is a different matter.
