Re: [v6 PATCH 04/21] x86/mpx, x86/insn: Relocate insn util functions to a new insn-kernel

Ricardo Neri <[email protected]>
Newsgroups gmane.linux.kernel,gmane.linux.msdos.general,gmane.comp.emulators.wine.devel
Message-ID <1493172353.36058.27.camel@ranerica-desktop>
On Wed, 2017-04-12 at 12:03 +0200, Borislav Petkov wrote:
> > +              * If mod is 0 and register R/EBP (regno=5) is
> indicated in the
> > +              * base part of the SIB byte, the value of such
> register should
> > +              * not be used in the address computation. Also, a
> 32-bit
> > +              * displacement is expected in this case; the
> instruction
> > +              * decoder takes care of it. This is true for both R13
> and
> > +              * R/EBP as REX.B will not be decoded.
> > +              */
> > +             if (regno == 5 && X86_MODRM_MOD(insn->modrm.value) ==
> 0)
> > +                     return -EDOM;
> > +
> > +             if (X86_REX_B(insn->rex_prefix.value))
> > +                     regno += 8;
> > +             break;
> > +
> > +     default:
> > +             pr_err("invalid register type");
> > +             BUG();
> 
> WARNING: Avoid crashing the kernel - try using WARN_ON & recovery code
> rather than BUG() or BUG_ON()
> #211: FILE: arch/x86/lib/insn-eval.c:90:
> +               BUG();
> 
> And checkpatch is kinda right. We need to warn here, not explode. Oh
> and
> that function returns negative values on error...
> 
> Please change that with a patch ontop of the move.

Sure, I will change it.
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.