[RFC patch] use thread.on_ustack to determine if on user stack

[RFC patch] use thread.on_ustack to determine if on user stack

[Luming Yu]

[-- Attachment #1: Type: text/plain, Size: 454 bytes --]

Hello list,

The PSR.lp bit of kernel thread kondemand sometimes would be set, then
causes set_pstate PAL call fails with invalid argument. I tracked down
to the place that the PSR.lp was set in do_notify_resume_user. I don't
understand why not use task->thread.on_ustack to
check if on user stack.in the first place. For optimization?

Signed-off-by: Yu Luming <luming.yu@intel.com>


  ptrace.h |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: user_stack.patch --]
[-- Type: text/x-patch; name="user_stack.patch", Size: 670 bytes --]

--- linux-2.6.18.ia64/include/asm-ia64/ptrace.h.0	2007-09-28 21:41:19.000000000 +0800
+++ linux-2.6.18.ia64/include/asm-ia64/ptrace.h	2007-09-28 21:41:40.000000000 +0800
@@ -257,7 +257,7 @@
 # define task_pt_regs(t)		(((struct pt_regs *) ((char *) (t) + IA64_STK_OFFSET)) - 1)
 # define ia64_psr(regs)			((struct ia64_psr *) &(regs)->cr_ipsr)
 # define user_mode(regs)		(((struct ia64_psr *) &(regs)->cr_ipsr)->cpl != 0)
-# define user_stack(task,regs)	((long) regs - (long) task == IA64_STK_OFFSET - sizeof(*regs))
+# define user_stack(task,regs)  (task->thread.on_ustack)
 # define fsys_mode(task,regs)					\
   ({								\
 	  struct task_struct *_task = (task);			\

Re: [RFC patch] use thread.on_ustack to determine if on user stack

[Fenghua Yu]

On 9/29/07, Luming Yu <luming.yu@gmail.com> wrote:
>Hello list,

>The PSR.lp bit of kernel thread kondemand sometimes would be set, then
>causes set_pstate PAL call fails with invalid argument. I tracked down
>to the place that the PSR.lp was set in do_notify_resume_user. I don't
>understand why not use task->thread.on_ustack to
>check if on user stack.in the first place. For optimization?

The reason for not using on_ustack is because stack in fsys is a mixture of
kernel states and user states. on_ustack is not a correct way to reflect fsys
stack usage. It's cleared to 0 during fsys which can not be explained as it's
not user stack.

The current implementation of checking user_stack() is correct. Though it would
be better to change user_stack()'s name to something like fsys_stack() to avoid
future confusion.

The patch actually always makes user_stack()=0 and fsys_mode()=0 during fsys
execution. Thus there is no psr.lp=1 during fsys execution. And signal is always
delivered during fsys execution.This masks the "Transition failure" issue
instead of fixing it. The patch might cause issues in some stress tests.

Could you please provide more debug info on the issue?

Thanks.

-Fenghua

Re: [RFC patch] use thread.on_ustack to determine if on user stack

[Luming Yu]

I'm __not__ quite sure, in this case, by reading source code, the code
path for the problem would be:
user_stack check <- fsys_mode check < - do_notify_resume_user
<-notify_resume_user <--
(pUStk) br.call.spnt.many rp=notify_resume_user  (ia64_leave_kernel)

So on this code path, if fsys_mode is invoked, the pUStk should be TRUE.
if pUStk = thread.on_ustack, then thread.on_ustack should be TRUE too.
So my problem is I don't know if it is  true that pUStk =
thread.on_ustack in fsys mode. And I didn't locate the code that the
thread.on_ustack is cleared to 0 during fsys mode.
So please help.

Thanks,
Luming



On 10/13/07, Fenghua Yu <fenghua.yu@intel.com> wrote:
> On 9/29/07, Luming Yu <luming.yu@gmail.com> wrote:
> >Hello list,
>
> >The PSR.lp bit of kernel thread kondemand sometimes would be set, then
> >causes set_pstate PAL call fails with invalid argument. I tracked down
> >to the place that the PSR.lp was set in do_notify_resume_user. I don't
> >understand why not use task->thread.on_ustack to
> >check if on user stack.in the first place. For optimization?
>
> The reason for not using on_ustack is because stack in fsys is a mixture of
> kernel states and user states. on_ustack is not a correct way to reflect fsys
> stack usage. It's cleared to 0 during fsys which can not be explained as it's
> not user stack.
>
> The current implementation of checking user_stack() is correct. Though it would
> be better to change user_stack()'s name to something like fsys_stack() to avoid
> future confusion.
>
> The patch actually always makes user_stack()=0 and fsys_mode()=0 during fsys
> execution. Thus there is no psr.lp=1 during fsys execution. And signal is always
> delivered during fsys execution.This masks the "Transition failure" issue
> instead of fixing it. The patch might cause issues in some stress tests.
>
> Could you please provide more debug info on the issue?
>
> Thanks.
>
> -Fenghua
>

Re: [RFC patch] use thread.on_ustack to determine if on user stack

[Fenghua Yu]

On Mon, Oct 15, 2007 at 12:28:05PM +0800, Luming Yu wrote:
> So my problem is I don't know if it is  true that pUStk =
> thread.on_ustack in fsys mode. And I didn't locate the code that the
> thread.on_ustack is cleared to 0 during fsys mode.
> So please help.

In fsys call, pUStk is never equal to thread.on_ustack. Here is the code in
fsys_bubble_down() in fsys.S.

....
        st1 [r16]=r0                            // M2|3 clear current->thread.on_ustack flag
....
        cmp.ne pKStk,pUStk=r0,r0                // A    set pKStk <- 0, pUStk <- 1
....

The code shows that thread.on_ustack=0 and pUStk=1 during fsys setup phase. The
two should be equal in other cases than fsys. Seems the two similar names cause
confusion.

Thanks.

-Fenghua

Re: [RFC patch] use thread.on_ustack to determine if on user stack

[Luming Yu]

I was thinking the fsys_bubble_down is used to fall back to normal
system call entry if that don't have a ligtweight handler.
Is it right.

On 10/16/07, Fenghua Yu <fenghua.yu@intel.com> wrote:
> On Mon, Oct 15, 2007 at 12:28:05PM +0800, Luming Yu wrote:
> > So my problem is I don't know if it is  true that pUStk =
> > thread.on_ustack in fsys mode. And I didn't locate the code that the
> > thread.on_ustack is cleared to 0 during fsys mode.
> > So please help.
>
> In fsys call, pUStk is never equal to thread.on_ustack. Here is the code in
> fsys_bubble_down() in fsys.S.
>
> ....
>         st1 [r16]=r0                            // M2|3 clear current->thread.on_ustack flag
> ....
>         cmp.ne pKStk,pUStk=r0,r0                // A    set pKStk <- 0, pUStk <- 1
> ....
>
> The code shows that thread.on_ustack=0 and pUStk=1 during fsys setup phase. The
> two should be equal in other cases than fsys. Seems the two similar names cause
> confusion.
>
> Thanks.
>
> -Fenghua
>