From: Manfred Spraul <manfred@colorfullife.com>
To: Sebastian Andrzej Siewior <bigeasy@linutronix.de>,
linux-kernel@vger.kernel.org
Cc: Peter Zijlstra <peterz@infradead.org>,
Ingo Molnar <mingo@redhat.com>,
Thomas Gleixner <tglx@linutronix.de>,
Darren Hart <darren@dvhart.com>,
Steven Rostedt <rostedt@goodmis.org>,
fredrik.markstrom@windriver.com,
Davidlohr Bueso <davidlohr@hp.com>
Subject: Re: [PATCH 3/3] ipc/mqueue: remove STATE_PENDING
Date: Tue, 07 Apr 2015 19:48:01 +0200 [thread overview]
Message-ID: <55241851.7060704@colorfullife.com> (raw)
In-Reply-To: <1428419030-20030-4-git-send-email-bigeasy@linutronix.de>
On 04/07/2015 05:03 PM, Sebastian Andrzej Siewior wrote:
> This patch moves the wakeup_process() invocation so it is not done under
> the info->lock. With this change, the waiter is woken up once it is
> "ready" which means its state is STATE_READY and it does not need to loop
> on SMP if it is still in STATE_PENDING.
> In the timeout case we still need to grab the info->lock to verify the state.
>
> This change should also avoid the introduction of preempt_disable() in
> -RT which avoids a busy-loop which pools for the STATE_PENDING -> STATE_READY
> change if the waiter has a higher priority compared to the waker.
> @@ -909,9 +905,8 @@ SYSCALL_DEFINE1(mq_unlink, const char __user *, u_name)
> * bypasses the message array and directly hands the message over to the
> * receiver.
> * The receiver accepts the message and returns without grabbing the queue
> - * spinlock. Therefore an intermediate STATE_PENDING state and memory barriers
> - * are necessary. The same algorithm is used for sysv semaphores, see
> - * ipc/sem.c for more details.
> + * spinlock. The same algorithm is used for sysv semaphores, see ipc/sem.c
> + * for more details.
No. With your change, ipc/sem.c and ipc/msg.c use different algorithms.
Please update the comment and describe the new approach:
Current approach:
- set pointer to message
- STATE_PENDING
- wake_up_process()
- STATE_READY
(now the receiver can continue)
New approach:
- set pointer to message
- get_task_struct
- STATE_READY
(now the receiver can continue, e.g. woken up due to an unrelated
SIGKILL)
- wake_up_process()
- put_task_struct()
> + if (r_sender) {
> + wake_up_process(r_sender);
> + put_task_struct(r_sender);
> + }
> ret = 0;
Could you double-check that it is safe to call wake_up_process on a
killed and reaped thread, only with a get_task_struct reference?
And: please test it, too. (patch the kernel so that you can trigger this
case).
--
Manfred
next prev parent reply other threads:[~2015-04-07 17:48 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-04-07 15:03 improve futex on -RT by avoiding the double wake-up Sebastian Andrzej Siewior
2015-04-07 15:03 ` [PATCH 1/3] futex: avoid double wake up in PI futex wait / wake on -RT Sebastian Andrzej Siewior
2015-04-07 18:41 ` Thomas Gleixner
2015-04-10 14:42 ` [PATCH 1/3 v2] " Sebastian Andrzej Siewior
2015-04-07 15:03 ` [PATCH 2/3] futex: avoid double wake up in futex_wake() " Sebastian Andrzej Siewior
2015-04-07 19:47 ` Thomas Gleixner
2015-04-10 16:11 ` [PATCH 2/3 v2] " Sebastian Andrzej Siewior
2015-04-13 3:02 ` Davidlohr Bueso
2015-04-16 5:09 ` Davidlohr Bueso
2015-04-16 9:19 ` Thomas Gleixner
2015-04-16 10:16 ` Peter Zijlstra
2015-04-16 10:49 ` Thomas Gleixner
2015-04-16 14:42 ` Davidlohr Bueso
2015-04-16 15:54 ` Peter Zijlstra
2015-04-16 16:22 ` Davidlohr Bueso
2015-04-07 15:03 ` [PATCH 3/3] ipc/mqueue: remove STATE_PENDING Sebastian Andrzej Siewior
2015-04-07 17:48 ` Manfred Spraul [this message]
2015-04-07 18:28 ` Thomas Gleixner
2015-04-10 14:37 ` [PATCH v2] " Sebastian Andrzej Siewior
2015-04-23 22:18 ` Thomas Gleixner
2015-04-28 3:24 ` Davidlohr Bueso
2015-04-28 12:37 ` Peter Zijlstra
2015-04-28 16:36 ` Davidlohr Bueso
2015-04-28 16:43 ` Peter Zijlstra
2015-04-28 16:59 ` Davidlohr Bueso
2015-04-29 19:44 ` Manfred Spraul
2015-04-30 18:46 ` Davidlohr Bueso
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=55241851.7060704@colorfullife.com \
--to=manfred@colorfullife.com \
--cc=bigeasy@linutronix.de \
--cc=darren@dvhart.com \
--cc=davidlohr@hp.com \
--cc=fredrik.markstrom@windriver.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=rostedt@goodmis.org \
--cc=tglx@linutronix.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.