* Oleg Nesterov <[EMAIL PROTECTED]> wrote:
> Question: should we make spinlock_t barrier-safe?
>
> Suppose that the task "p" does
>
> current->state = TASK_INTERRUPIBLE;
> mb();
>
> if (CONDITION)
> break;
>
> schedule();
>
> and another CPU does
>
>
Ingo Molnar writes:
>
> * Oleg Nesterov <[EMAIL PROTECTED]> wrote:
>
> > static inline void ccids_read_lock(void)
> > {
> > atomic_inc(&ccids_lockct);
> > spin_unlock_wait(&ccids_lock);
> > }
> >
> > This looks racy, in theory atomic_inc() and spin_unlock_wai
On 07/21, Ingo Molnar wrote:
>
> * Oleg Nesterov <[EMAIL PROTECTED]> wrote:
>
> > static inline void ccids_read_lock(void)
> > {
> > atomic_inc(&ccids_lockct);
> > spin_unlock_wait(&ccids_lock);
> > }
> >
> > This looks racy, in theory atomic_inc() and spin_un
* Oleg Nesterov <[EMAIL PROTECTED]> wrote:
> static inline void ccids_read_lock(void)
> {
> atomic_inc(&ccids_lockct);
> spin_unlock_wait(&ccids_lock);
> }
>
> This looks racy, in theory atomic_inc() and spin_unlock_wait() could
> be re-ordered. How
On 07/21, Ingo Molnar wrote:
>
> * Oleg Nesterov <[EMAIL PROTECTED]> wrote:
>
> > It is a bit annoying that do_exit() takes ->pi_lock to set PF_EXITING.
> > All we need is to synchronize with lookup_pi_state() which saw this task
> > without PF_EXITING under ->pi_lock.
> >
> > Change do_exit() t
* Oleg Nesterov <[EMAIL PROTECTED]> wrote:
> It is a bit annoying that do_exit() takes ->pi_lock to set PF_EXITING.
> All we need is to synchronize with lookup_pi_state() which saw this task
> without PF_EXITING under ->pi_lock.
>
> Change do_exit() to use spin_unlock_wait().
>
> Signed-off-by:
It is a bit annoying that do_exit() takes ->pi_lock to set PF_EXITING.
All we need is to synchronize with lookup_pi_state() which saw this task
without PF_EXITING under ->pi_lock.
Change do_exit() to use spin_unlock_wait().
Signed-off-by: Oleg Nesterov <[EMAIL PROTECTED]>
--- t/kernel/exit.c~PF_
7 matches
Mail list logo