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.
Cyril
>
> Thanks,
> - Simon
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
