On Sun, Oct 06, 2013 at 03:22:40PM +0200, Oleg Nesterov wrote:
> On 10/04, Peter Zijlstra wrote:
> > That would yield something like so I suppose:
> >
> > void rcu_sync_enter(struct rcu_sync_struct *rss)
> > {
> > bool need_wait, need_sync;
> >
> > spin_lock_irq(&rss->rss_lock);
> > if (rss->exclusive && rss->gp_count) {
> > __wait_event_locked(rss->gp_wait, rss->gp_count);
> ^^^^^^^^^^^^^
> I guess you meant !rss->gp_count.
Uh yes, obviously :-)
> I am obviously biased, but imho the code looks worse this way.
> I like the current simple "need_wait" and "gp_count != 0" logic.
Yeah, I know.. but it doesn't add the extra variable and doesn't play
games with the completion implementation.
> And afaics this is racy,
>
> Yes, but if rcu_sync_exit() does __wake_up_locked(), then
> autoremove_wake_function() makes waitqueue_active() == F. If the pending
> rcu_sync_func() takes ->rss_lock first we have a problem.
Ah indeed, it seems I got confused between DECLARE_WAITQUEUE and
DEFINE_WAIT; there's too damn many variants there :/
> Easy to fix, but needs more complications.
>
> Or we can simply ignore the fact that rcu_sync_func() can race with
> wakeup. This can lead to unnecessary sched_sync() but this case is
> unlikely. IOW,
>
> spin_lock_irq(&rss->rss_lock);
> if (rss->exclusive)
> wait_event_locked(rss->gp_wait, !rss->gp_count);
> need_wait = rss->gp_count++;
> need_sync = rss->gp_state == GP_IDLE;
> if (need_sync)
> rss->gp_state = GP_PENDING;
> spin_unlock_irq(&rss->lock);
>
> But still I don't like the (imho) unnecessary complications. And the
> fact we can race with rcu_sync_func() even if this is very unlikely,
> this just doesn't look good.
OK.. I'll give up trying to wreck this stuff ;-)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
