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

[Fenghua Yu <fenghua.yu@intel.com>]

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