From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753444AbbCEXsw (ORCPT ); Thu, 5 Mar 2015 18:48:52 -0500 Received: from mail.efficios.com ([78.47.125.74]:51407 "EHLO mail.efficios.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751197AbbCEXsu (ORCPT ); Thu, 5 Mar 2015 18:48:50 -0500 Date: Thu, 5 Mar 2015 23:48:51 +0000 (UTC) From: Mathieu Desnoyers To: "Paul E. McKenney" Cc: Huang Ying , Lai Jiangshan , Lai Jiangshan , Peter Zijlstra , LKML , Ingo Molnar , Steven Rostedt , Linus Torvalds Message-ID: <950470583.228004.1425599331454.JavaMail.zimbra@efficios.com> In-Reply-To: <995381344.227770.1425597484864.JavaMail.zimbra@efficios.com> Subject: Possible lock-less list race in scheduler_ipi() MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [173.246.22.116] X-Mailer: Zimbra 8.0.7_GA_6021 (ZimbraWebClient - FF36 (Linux)/8.0.7_GA_6021) Thread-Topic: Possible lock-less list race in scheduler_ipi() Thread-Index: C6LKgjBwrF9KnET2jlvieuuVl0bxUQ== Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, I recently reviewed the scheduler_ipi() code by coincidence, and noticed that the use of llist.h in there seemed a bit odd. So I'd like to have more eyes to help me look into this. I've been told that there has been issues with IPIs lately, so here is one possible scenario I think might be possible: - scheduler_ipi() - sched_ttwu_pending() - llist_del_all() (grabs the wake_list with xchg()) - raw_spin_lock_irqsave(&rq->lock, flags); - iteration on the llist (owned locally by interrupt handler) (for each item) p = llist_entry(llist, struct task_struct, wake_entry); llist = llist_next(llist); ttwu_do_activate(rq, p, 0); - raw_spin_unlock_irqrestore(&rq->lock, flags); ttwu_do_activate() ends up calling ttwu_activate() and ttwu_do_wakeup(), I'm worried that ttwu_do_wakeup() might end up indirectly handing off the task to the following functions (within another execution context): - try_to_wake_up() - ttwu_queue() - ttwu_queue_remote adds the process to another wake_list with a cmpxchg() llist_next() is pretty simple: static inline struct llist_node *llist_next(struct llist_node *node) { return node->next; } It is so simple that I wonder if the compiler would be within its rights to reorder the load of node->next after some operations within ttwu_do_activate(), thus causing corruption of this linked-list due to a concurrent try_to_wake_up() performed by another core. Am I too paranoid about the possible compiler mishaps there, or are my concerns justified ? Thanks, Mathieu -- Mathieu Desnoyers EfficiOS Inc. http://www.efficios.com