Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1448105

Re: [PATCH v4] ipc/msg: Implement lockless pipelined wakeups

From Davidlohr Bueso <dave@stgolabs.net>
Newsgroups linux.kernel
Subject Re: [PATCH v4] ipc/msg: Implement lockless pipelined wakeups
Date 2016-07-21 21:50 +0200
Message-ID <rXs8O-3wK-25@gated-at.bofh.it> (permalink)
References <rX1UZ-3fU-9@gated-at.bofh.it> <rX9Sx-8tT-1@gated-at.bofh.it> <rXjoS-6b9-19@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


On Thu, 21 Jul 2016, Sebastian Andrzej Siewior wrote:

>* Davidlohr Bueso | 2016-07-20 17:16:12 [-0700]:
>
>>Just as with expunge_all and the E2BIG case, could you remove that explicit
>>barrier (B) and just rely on wake_q_add?
>
>Just did. So we have just a smp_rmb() on the reader side and the
>comment talks about smb_wmb() and at the spot where we should have the
>smb_wmb we have a comment why we don't have one :)
>For my understanding: we need that smp_rmb() to ensure that everything
>past that cmpxchg() is visible on all other CPUs so we don't have the
>wakeup before we r_msg reads != -EAGAIN, right?

Hmm I'm having second thoughts about the need for barrier (A). As you know,
originally we had it to prevent races with do_exit() from the receiver thread
if the r_msg was set before doing the wakeup, we could face a use-after-free
scenario.

Now, by delaying the wakeup, the receiver task should always see whatever r_msg
is set to by the waker, even if we get reordered with wake_q_add() as the
actual wakeup_process() does not occur yet, and hence the receiver is still
blocked while this is going on -- iow, we avoid entirely the need to explicitly
wait until pipelined_send/expunge_all are done.  Similarly, "barrier (B)" simply
serves to pair with wake_up_q() such that we don't miss wakeups, but that's
always handled by the wake_q machinery anyway.

So if this is the case (which is how you had it in some previous version of this
patch), we can get rid of the pair diagram altogether as well. Manfred, Peter, does
all this make sense to you guys?

Thanks,
Davidlohr

Back to linux.kernel | Previous | Next — Previous in thread | Find similar | Unroll thread


Thread

[PATCH v4] ipc/msg: Implement lockless pipelined wakeups Sebastian Andrzej Siewior <bigeasy@linutronix.de> - 2016-07-20 17:50 +0200
  Re: [PATCH v4] ipc/msg: Implement lockless pipelined wakeups Davidlohr Bueso <dave@stgolabs.net> - 2016-07-21 02:20 +0200
    [PATCH v5] ipc/msg: Implement lockless pipelined wakeups Sebastian Andrzej Siewior <bigeasy@linutronix.de> - 2016-07-21 12:10 +0200
    Re: [PATCH v4] ipc/msg: Implement lockless pipelined wakeups Sebastian Andrzej Siewior <bigeasy@linutronix.de> - 2016-07-21 12:30 +0200
      Re: [PATCH v4] ipc/msg: Implement lockless pipelined wakeups Davidlohr Bueso <dave@stgolabs.net> - 2016-07-21 21:50 +0200

csiph-web