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.
