On 06/26, Davide Libenzi wrote:

quoted text
>

> On Fri, 26 Jun 2009, Oleg Nesterov wrote:

>

> > And if we remove waitqueue_active() in xxx_update(), then lock/unlock is

> > not needed too.

> >

> > If xxx_poll() takes q->lock first, it can safely miss the changes in ->status

> > and schedule(): xxx_update() will take q->lock, notice the sleeper and wake

> > it up (ok, it will set ->triggered but this doesn't matter).

> >

> > If xxx_update() takes q->lock first, xxx_poll() must see the changes in

> > status after poll_wait()->unlock(&q->lock) (in fact, after lock, not unlock).

>

> Sure. The snippet above was just to show what typically the code does, not

> a suggestion on how to solve the socket case.

Yes, yes. I just meant you are right imho, we shouldn't add mb() into

add_wait_queue().
> But yeah, the problem in this case is the waitqueue_active() call. Without

quoted text
> that, the wait queue lock/unlock in poll_wait() and the one in wake_up()

> guarantees the necessary barriers.

> Some might argue the costs of the lock/unlock of q->lock, and wonder if

> MBs are a more efficient solution. This is something I'm not going into.

> To me, it just looked not right having cross-matching MB in different

> subsystems.

This is subjective and thus up to maintainers, but personally I think you

are very, very right.
Perhaps we can add
	void sock_poll_wait(struct file *file, struct sock *sk, poll_table *pt)

	{

		if (pt) {

			poll_wait(file, sk->sk_sleep, pt);

			/*

			 * fat comment

			 */

			smp_mb(); // or smp_mb__after_unlock();

		}

	}
Oleg.
--

To unsubscribe from this list: send the line "unsubscribe netdev" in

the body of a message to majordomo@vger.kernel.org

More majordomo info at  http://vger.kernel.org/majordomo-info.html