Andrew Haley <aph@xxxxxxxxxx> writes: > > while hunting down a strange Linux kernel bug I saw this in the > > disassemblie: > > > > <radix_tree_insert>: > > ... > > c01ccf21: 0f 84 bd fe ff ff je c01ccde4 <radix_tree_insert+0x64> > > c01ccf27: 0f 0b ud2a > > c01ccf29: 1b 01 sbb (%ecx),%eax > > c01ccf2b: ab stos %eax,%es:(%edi) > > c01ccf2c: 78 31 js c01ccf5f <radix_tree_insert+0x1df> > > c01ccf2e: c0 e9 b0 shr $0xb0,%cl > > c01ccf31: fe (bad) # <<< here > > c01ccf32: ff (bad) > > c01ccf33: ff c6 inc %esi > > c01ccf35: 04 0a add $0xa,%al > > c01ccf37: 01 e9 add %ebp,%ecx > > > > WRT to the two (bad) opcodes, should I start to worry? > > Looks like data to me, not code. Do you think this is intended? According to the Intel x86 documentation the 'count' argument of the 'shr' instruction is mapped down to 5 bits (0 - 31), so that seems to be fine.
