>> Have you tried running with KVM? OK, I ran a UBSAN kvm guest on a UBSAN host and I ran trinity inside the guest. It all appears to work as usual.
I really don't have the knowledge to determine what we should exclude, but I'm very very happy to respin with a greater list of excludes if you think that's a good idea. Regards, Daniel >> >> I'm wondering if we should be excluding some of the KVM code that runs in >> real mode, eg: >> >> arch/powerpc/kvm/book3s_hv_rm_mmu.c >> arch/powerpc/kvm/book3s_hv_rm_xics.c >> >> And maybe some other bits. >> >> Also the early setup code, a/p/k/setup*.c might be dicey. > > My philosphy was just to copy the GCOV excludes, although you're right > that perhaps we want to be more aggressive in excluding here given that > the UBSAN handlers print a bunch of stuff. I'm happy to respin with > further exclusions - they're really easy to add. > >> In all of the above it's probably OK unless you actually hit a warning at the >> wrong point, so testing will probably not find problems. Although I guess we >> could add some deliberatly incorrect code at certain points and check we >> survive the warning. > > Yep. I'll run a kvm guest on an instrumented kernel and let you know > what happens! > >> >> Is there an easy way to spot the calls to UBSAN in the generated code? > > Yes - because of the handler functions, they're *really* easy to spot. > Here's some assembly for GregorianDay(): > > > c00000000002924c: 6d 26 7e 48 bl c00000000080b8b8 > <__ubsan_handle_mul_overflow+0x8> > c000000000029250: 00 00 00 60 nop > c000000000029254: 38 fe ff 4b b c00000000002908c > <GregorianDay+0xdc> > c000000000029258: 8c ff 62 3c addis r3,r2,-116 > c00000000002925c: 01 00 a0 38 li r5,1 > c000000000029260: 78 db 64 7f mr r4,r27 > c000000000029264: 50 9c 63 38 addi r3,r3,-25520 > c000000000029268: 41 26 7e 48 bl c00000000080b8a8 > <__ubsan_handle_sub_overflow+0x8> > c00000000002926c: 00 00 00 60 nop > c000000000029270: 44 fe ff 4b b c0000000000290b4 > <GregorianDay+0x104> > c000000000029274: 8c ff 62 3c addis r3,r2,-116 > c000000000029278: 78 d3 45 7f mr r5,r26 > c00000000002927c: e0 9c 63 38 addi r3,r3,-25376 > c000000000029280: 19 26 7e 48 bl c00000000080b898 > <__ubsan_handle_add_overflow+0x8> > c000000000029284: 00 00 00 60 nop > c000000000029288: 94 fe ff 4b b c00000000002911c > <GregorianDay+0x16c> > c00000000002928c: 8c ff 62 3c addis r3,r2,-116 > c000000000029290: 78 f3 c4 7f mr r4,r30 > c000000000029294: 68 9c 63 38 addi r3,r3,-25496 > c000000000029298: b1 21 7e 48 bl c00000000080b448 > <__ubsan_handle_out_of_bounds+0x8> > c00000000002929c: 00 00 00 60 nop > c0000000000292a0: 20 fe ff 4b b c0000000000290c0 > <GregorianDay+0x110> > c0000000000292a4: 14 4a 24 7d add r9,r4,r9 > c0000000000292a8: 40 48 a4 7f cmpld cr7,r4,r9 > c0000000000292ac: 2c fe fd 41 bgt+ cr7,c0000000000290d8 > <GregorianDay+0x128> > > You can see that there are lots of calls to __ubsan_handle_blah_blah > inserted. > > Regards, > Daniel > >> >> cheers >> >> -- >> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in >> the body of a message to majord...@vger.kernel.org >> More majordomo info at http://vger.kernel.org/majordomo-info.html >> Please read the FAQ at http://www.tux.org/lkml/
signature.asc
Description: PGP signature
