[PATCH] ppc64: allow ptrace to set TM bits

[Laurent Dufour]

On 22/08/2016 03:01, Cyril Bur wrote:
> On Tue, 2016-08-02 at 13:43 +0800, Simon Guo wrote:
>> Hi Laurent,
>> On Fri, Jul 29, 2016 at 11:51:22AM +0200, Laurent Dufour wrote:
>>>
>>>  static int set_user_msr(struct task_struct *task, unsigned long
>>> msr)
>>>  {
>>> +#ifdef CONFIG_PPC_TRANSACTIONAL_MEM
>>> +	if (!(task->thread.regs->msr & MSR_TM)) {
>>> +		/* If TM is not available, discard TM bits changes
>>> */
>>> +		msr &= ~(MSR_TM | MSR_TS_MASK);
>>> +	}
>>> +#endif
>>
>> I am not sure whether following is an issue:
>> Per PowerISA, any exception/interrupt will disable MSR[TM] bit 
>> automatically and mark MSR_TS to be suspended when it is 
>> transactional. It is possible that MSR[TM] = 0 and MSR[MSR_TS] != 0
>> (suspended). 
>>
>> Will set_user_msr() be able to escape from the above?
>>  For example, one user space application encountered 
>> page fault during transaction, its task->thread.regs->msr & MSR_TM ==
>> 0
>> and MSR[MSR_TS] == suspended.  Then it is being traced and 
>> set_user_msr() is invoked on it. I think it will be incorrect to 
>> clear its  MSR_TS_MASK bits.....
>>
>> (suspended).ible that MSRTM] = 0 and MSR[MSR_TS] != 0> (suspended).
> 
>> Please correct me if I am wrong.
> 
> I'm not very familiar with ptracing and exactly what can happen but I
> agree with Simon. Trying to change an MSR with that possible condition
> stated ("It is possible that MSR[TM] = 0 and MSR[MSR_TS] !=
> 0> (suspended)") to MSR_TS and MSR_TS_MASK bits all 0 will cause a Bad
> Thing.

I don't think this may happen since from the user space point of view,
we can't have MSR[TM]=0 & MSR[MSR_TS]=1, because MSR[TM] will be set
once the transaction is initiated.

Anyway, this patch is no more required since the recent patch
http://patchwork.ozlabs.org/patch/661358/ is now dropping the TM state
form the signal return path, which is enough fof CRIU to work fine.

Cheers,
Laurent.