On Tue, Sep 10, 2024 at 7:21 AM Yonghong Song <yonghong.song@xxxxxxxxx> wrote: > > > On 9/9/24 10:29 AM, Alexei Starovoitov wrote: > > On Mon, Sep 9, 2024 at 10:21 AM Zac Ecob <zacecob@xxxxxxxxxxxxxx> wrote: > >> Hello, > >> > >> I recently received a kernel 'oops' about a divide error. > >> After some research, it seems that the 'div64_s64' function used for the 'MOD'/'REM' instructions boils down to an 'idiv'. > >> > >> The 'dividend' is set to INT64_MIN, and the 'divisor' to -1, then because of two's complement, there is no corresponding positive value, causing the error (at least to my understanding). > >> > >> > >> Apologies if this is already known / not a relevant concern. > > Thanks for the report. This is a new issue. > > > > Yonghong, > > > > it's related to the new signed div insn. > > It sounds like we need to update chk_and_div[] part of > > the verifier to account for signed div differently. > > In verifier, we have > /* [R,W]x div 0 -> 0 */ > /* [R,W]x mod 0 -> [R,W]x */ the verifier is doing what hw does. In this case this is arm64 behavior. > What the value for > Rx_a sdiv Rx_b -> ? > where Rx_a = INT64_MIN and Rx_b = -1? Why does it matter what Rx_a contains ? What cpus do in this case? > Should we just do > INT64_MIN sdiv -1 -> -1 > or some other values? >
