RE: [PATCH 2.5.52] Use __set_current_state() instead of current->

Perez-Gonzalez, Inaky (inaky.perez-gonzalez@intel.com)
Wed, 18 Dec 2002 17:53:50 -0800


> > Agreed; however, I also don't want to introduce unnecessary
> > bloat, so I need to understand first what cases need it - it
> > is kind of hard for me. Care to let me know some gotchas?
>
> set_current_state() includes a write barrier to ensure the setting of
> the state is flushed before any further instructions. This is to
> provide a memory barrier for weak-ordering processors that
> can and will rearrange the writes.

It is what I was expecting, given xchg() being in the equation;
then it is reduced to a problem of guessing what can be the
delay for the flushing of the write ... beautiful ...

So, in that scenario, it means that:

- any setting before a return should be barriered unless we
return to a place[s] known to be harmless

- any setting to TASK_RUNNING should be kind of safe

- exec.c:de_thread(),

while (atomic_read(&oldsig->count) > count) {
oldsig->group_exit_task = current;
- current->state = TASK_UNINTERRUPTIBLE;
+ __set_current_state(TASK_UNINTERRUPTIBLE);
spin_unlock_irq(&oldsig->siglock);

Should be safe, as spin_unlock_irq() will do memory clobber
on sti() [undependant from UP/SMP].

- namei.c:do_follow_link()

if (current->total_link_count >= 40)
goto loop;
if (need_resched()) {
- current->state = TASK_RUNNING;
+ __set_current_state(TASK_RUNNING);
schedule();
}
err = security_inode_follow_link(dentry, nd);

There is a function for it, cond_resched().

So, sending an updated patch right now

> Not all processors like those made by your employer are
> strongly-ordered :)

You'd be surprised how little about those gory details I do know :]

Inaky Perez-Gonzalez -- Not speaking for Intel - opinions are my own [or my
fault]

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/