Re: TM Bad Thing exception easily raised from userspace

On Fri, 2016-08-19 at 19:21 +0200, Laurent Dufour wrote:

Hi,

While working on the TM support for CRIU, I faced a TM Bad Thing
exception.

Digging further, I found that it is *easy* to raised it from the user
space. I attached below a simple program which raise it all the time,
like this :

[12045.221359] Kernel BUG at c000000000050a40 [verbose debug info
unavailable]
[12045.221470] Unexpected TM Bad Thing exception at c000000000050a40
(msr 0x201033)
[12045.221540] Oops: Unrecoverable exception, sig: 6 [#1]
[12045.221586] SMP NR_CPUS=2048 NUMA PowerNV
[12045.221634] Modules linked in: xt_CHECKSUM iptable_mangle
ipt_MASQUERADE nf_nat_masquerade_ipv4 iptable_nat nf_nat_ipv4 nf_nat
nf_conntrack_ipv4 nf_defrag_ipv4 xt_conntrack nf_conntrack ipt_REJECT
nf_reject_ipv4 xt_tcpudp bridge stp llc ebtable_filter ebtables
ip6table_filter ip6_tables iptable_filter ip_tables x_tables kvm_hv
kvm
uio_pdrv_genirq ipmi_powernv uio powernv_rng ipmi_msghandler autofs4
ses
enclosure scsi_transport_sas bnx2x ipr mdio libcrc32c
[12045.222167] CPU: 68 PID: 6178 Comm: sigreturnpanic Not tainted
4.7.0 #34
[12045.222224] task: c0000000fce38600 ti: c0000000fceb4000 task.ti:
c0000000fceb4000
[12045.222293] NIP: c000000000050a40 LR: c0000000000163bc CTR:
0000000000000000
[12045.222361] REGS: c0000000fceb7ac0 TRAP: 0700   Not
tainted  (4.7.0)
[12045.222418] MSR: 9000000300201033
<SF,HV,ME,IR,DR,RI,LE,TM[SE]>  CR:
28444280  XER: 20000000
[12045.222625] CFAR: c0000000000163b8 SOFTE: 0
PACATMSCRATCH: 900000014280f033
GPR00: 01100000b8000001 c0000000fceb7d40 c00000000139c100
c0000000fce390d0
GPR04: 900000034280f033 0000000000000000 0000000000000000
0000000000000000
GPR08: 0000000000000000 b000000000001033 0000000000000001
0000000000000000
GPR12: 0000000000000000 c000000002926400 0000000000000000
0000000000000000
GPR16: 0000000000000000 0000000000000000 0000000000000000
0000000000000000
GPR20: 0000000000000000 0000000000000000 0000000000000000
0000000000000000
GPR24: 0000000000000000 00003ffff98cadd0 00003ffff98cb470
0000000000000000
GPR28: 900000034280f033 c0000000fceb7ea0 0000000000000001
c0000000fce390d0
[12045.223535] NIP [c000000000050a40] tm_restore_sprs+0xc/0x1c
[12045.223584] LR [c0000000000163bc] tm_recheckpoint+0x5c/0xa0
[12045.223630] Call Trace:
[12045.223655] [c0000000fceb7d80] [c000000000026e74]
sys_rt_sigreturn+0x494/0x6c0
[12045.223738] [c0000000fceb7e30] [c0000000000092e0]
system_call+0x38/0x108
[12045.223806] Instruction dump:
[12045.223841] 7c800164 4e800020 7c0022a6 f80304a8 7c0222a6 f80304b0
7c0122a6 f80304b8
[12045.223955] 4e800020 e80304a8 7c0023a6 e80304b0 <7c0223a6>
e80304b8
7c0123a6 4e800020
[12045.224074] ---[ end trace cb8002ee240bae76 ]---

The exception is raised when the kernel is restoring the TM SPRS from
the signal stack. But this operation is not allowed while in a
transaction.

The sampler test is ending the signal handler with a pending
transaction
while the signal got caught during a transaction itself.

I can't see any straight way to get rid of that, except by clearing
the
transactional state in the path of sigreturn....

This is correct - I have a patch.

Please advise.

I'm happy to do it if you don't have time (I pretty much already have
for my testing), do you want to send your test case in as a
selftest/powerpc? It is good to have these to guard against regressions
as these kinds of pathes aren't often exercised.

Cheers,
Laurent.