[PATCH] ppc64: allow ptrace to set TM bits

Laurent Dufour ldufour at linux.vnet.ibm.com
Thu Aug 18 00:40:45 AEST 2016


On 02/08/2016 07:43, 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.....

You raised a good point, but I'm not sure this case is valid.
The interrupt case you described is happening in the kernel, not in user
space, and set_user_msr() is dealing with the user space register's
state, not the kernel's one.
So it can't apply and I can't see how in user space MSR[TM]=0 and
MSR[TS]=1 could happen.

Am I missing something here ?

Thanks,
Laurent.



More information about the Linuxppc-dev mailing list