Prev: [PATCH 5/5] x86-32: fix atomic64_inc_not_zero return value convention
Next: [GIT PULL] generic NMI watchdog for v2.6.34
From: Oleg Nesterov on 1 Mar 2010 14:00
On 03/02, Tejun Heo wrote:
>
> On 03/01/2010 11:53 PM, Oleg Nesterov wrote:
> >
> > and in this case we put this barrier at the head of ->scheduled list.
> >
> > This means, this barrier will run after that work W, not before it?
>
> Yes, the barrier will run after the target work as it should.

You are right. it will run after target work == current_work and before
the next pending work W.

Because,

> > Hmm. And what if there are no pending works but ->current_work == target ?
> > Again, we add the barrier to ->scheduled, but in this case worker_thread()
> > can't even notice ->scheduled is not empty because it only checks ->worklist?
>
> A worker always checks ->scheduled after a work is finished.

Yes! I missed this, thanks.



> > insert_wq_barrier() also does:
> >
> > unsigned long *bits = work_data_bits(target);
> > ...
> > *bits |= WORK_STRUCT_LINKED;
> >
> > perhaps this needs atomic_long_set(), although I am not sure this really
> > matters.
>
> Yeah, well, work->data access is pretty messed up. At this point,
> there's no reason for atomic_long_t to begin with.

grep, grep, grep... arch/sparc/lib/atomic32.c uses spinlocks for
atomic_set() and ___set_bit(). Probably that is why atomic_long_set()
is really needed to avoid the race with test_and_set_bit(PENDING).

Oleg.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
 | 
Pages: 1
Prev: [PATCH 5/5] x86-32: fix atomic64_inc_not_zero return value convention
Next: [GIT PULL] generic NMI watchdog for v2.6.34