Re: [RFC PATCH 08/11] powerpc/tm: Do not reclaim on ptrace
From: Breno Leitao <leitao@debian.org>
Date: 2018-09-30 23:53:01
Hi Mikey, On 09/28/2018 02:36 AM, Michael Neuling wrote:
quoted
quoted
quoted
+ WARN_ON(MSR_TM_SUSPENDED(mfmsr())); + + tm_enable(); + tm_save_sprs(&(tsk->thread));Do we need to check if TM was enabled in the task before saving the TM SPRs? What happens if TM was lazily off and hence we had someone else's TM SPRs in the CPU currently? Wouldn't this flush the wrong values to the task_struct? I think we need to check the processes MSR before doing this.Yes, it is a *very* good point, and I think we are vulnerable even before this patch (in the current kernel). Take a look above, we are calling tm_save_sprs() if MSR is not TM suspended independently if TM is lazily off.I think you're right, we might already have an issue. There are some paths in here that don't check the userspace msr or any of the lazy tm enable. :(
I was able to create a test case that reproduces this bug cleanly. The testcase basically sleeps for N cycles, and then segfaults. If N is high enough to have load_tm overflowed, then you see a corrupted TEXASR value in the core dump file. If load_tm != 0 during the coredump, you see the expected TEXASR value. I wrote a small bash that check for both cases. $ git clone https://github.com/leitao/texasr_corrupt.git $ make check Anyway, I will propose a fix for this problem soon, since this whole patchset may delay to get ready. Is it OK? Thank you