Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp2852765imu; Thu, 29 Nov 2018 11:14:39 -0800 (PST) X-Google-Smtp-Source: AFSGD/XzbpVMuBIBhepxmHPaJRs4A2ch7yCE0duao3Y3UQum8iT3SaJEMJH++3o132R6AWaLScd4 X-Received: by 2002:a63:f65:: with SMTP id 37mr2265612pgp.238.1543518879785; Thu, 29 Nov 2018 11:14:39 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1543518879; cv=none; d=google.com; s=arc-20160816; b=ntZoCi62x6aqdn3jjj1Z/vR+LQzfbFWkwLQQ/osCQLUVFQKLOn5ViPx0gbJjnXRWlJ 8y5NpZ/gmo3ZlCc9SmlY2Irex+Qk4gsAwrTYJeYmGMSFQq2drVbQ+yz25cZ/7fTTSvML SP/7mYNoV9vq6fTqAgqAW/YSx8U2fw9fyR9ta2INVGZrqS27S0nzNDE/llQ9OOSKEmZf xho9V8cmoEz59D4Yr7A4KhVHm29g3qLNtXEPEH9Yd/QYGg5jiz31/Wg/Do1cTtPFMmNo 87n4UZkZYgRA5Mjlg25dRsqW00uDSp/SN4RJGqR5cv4kmLb4vzOkRw0HlVxVATDew2YH qEJg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-language :content-transfer-encoding:in-reply-to:mime-version:user-agent:date :message-id:organization:autocrypt:openpgp:from:references:cc:to :subject; bh=vFbyqoTPgP7+Lc+sp1zhE9WNkTRG1ZQjVpG/qtYid1Y=; b=MEnOOOQP7bsOz7tQ3Ayrc/7PKnDcwFsCQvK4E19xy6B5l3UdrmPpPy6Vn7X9UQjr5+ KgamUZcEt+Ifk/IKmD9DmSMuauKYuckduPIX6bTVab6Tdz9sH9gkhOc4/CSWqJBNw2R7 sQH4cgZ0ZMMUNGIN+OY+bRjvfk30sJ5EarEkBMumSoq39cTH4pWL7CCii1wht7xjyjJO pkX7lFNHbA7t2QiSudohBj6QatU2hicdCGtVdEmTMVgL5hU0UyQktUsUyVuydzoJoblk 0Hma6BFmZjZGavR6pS/mN8l+WyTMWftoWmu3rn6aGIxlRWlzXJH0phZROXtEMq7lNu6C lQ6w== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id m23si2314446pgb.479.2018.11.29.11.14.23; Thu, 29 Nov 2018 11:14:39 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728322AbeK3Fcx convert rfc822-to-8bit (ORCPT + 99 others); Fri, 30 Nov 2018 00:32:53 -0500 Received: from mx1.redhat.com ([209.132.183.28]:60802 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726652AbeK3Fcx (ORCPT ); Fri, 30 Nov 2018 00:32:53 -0500 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 65B0B58E22; Thu, 29 Nov 2018 18:26:36 +0000 (UTC) Received: from llong.remote.csb (dhcp-17-8.bos.redhat.com [10.18.17.8]) by smtp.corp.redhat.com (Postfix) with ESMTP id 000F261081; Thu, 29 Nov 2018 18:26:34 +0000 (UTC) Subject: Re: [RFC] locking/rwsem: Avoid issuing wakeup before setting the reader waiter to nil To: Peter Zijlstra Cc: Yongji Xie , mingo@redhat.com, will.deacon@arm.com, linux-kernel@vger.kernel.org, xieyongji@baidu.com, zhangyu31@baidu.com, liuqi16@baidu.com, yuanlinsi01@baidu.com, nixun@baidu.com, lilin24@baidu.com, Davidlohr Bueso References: <1543495830-2644-1-git-send-email-xieyongji@baidu.com> <20181129131232.GN2131@hirez.programming.kicks-ass.net> <5598cd71-c3c8-d6ef-eb30-777cf901a2ef@redhat.com> <20181129160627.GU2131@hirez.programming.kicks-ass.net> <8cc45695-b325-a219-8b46-d5da6ddfdd63@redhat.com> <20181129172700.GA11632@hirez.programming.kicks-ass.net> <20181129180828.GA11650@hirez.programming.kicks-ass.net> From: Waiman Long Openpgp: preference=signencrypt Autocrypt: addr=longman@redhat.com; prefer-encrypt=mutual; keydata= xsFNBFgsZGsBEAC3l/RVYISY3M0SznCZOv8aWc/bsAgif1H8h0WPDrHnwt1jfFTB26EzhRea XQKAJiZbjnTotxXq1JVaWxJcNJL7crruYeFdv7WUJqJzFgHnNM/upZuGsDIJHyqBHWK5X9ZO jRyfqV/i3Ll7VIZobcRLbTfEJgyLTAHn2Ipcpt8mRg2cck2sC9+RMi45Epweu7pKjfrF8JUY r71uif2ThpN8vGpn+FKbERFt4hW2dV/3awVckxxHXNrQYIB3I/G6mUdEZ9yrVrAfLw5M3fVU CRnC6fbroC6/ztD40lyTQWbCqGERVEwHFYYoxrcGa8AzMXN9CN7bleHmKZrGxDFWbg4877zX 0YaLRypme4K0ULbnNVRQcSZ9UalTvAzjpyWnlnXCLnFjzhV7qsjozloLTkZjyHimSc3yllH7 VvP/lGHnqUk7xDymgRHNNn0wWPuOpR97J/r7V1mSMZlni/FVTQTRu87aQRYu3nKhcNJ47TGY evz/U0ltaZEU41t7WGBnC7RlxYtdXziEn5fC8b1JfqiP0OJVQfdIMVIbEw1turVouTovUA39 Qqa6Pd1oYTw+Bdm1tkx7di73qB3x4pJoC8ZRfEmPqSpmu42sijWSBUgYJwsziTW2SBi4hRjU h/Tm0NuU1/R1bgv/EzoXjgOM4ZlSu6Pv7ICpELdWSrvkXJIuIwARAQABzR9Mb25nbWFuIExv bmcgPGxsb25nQHJlZGhhdC5jb20+wsF/BBMBAgApBQJYLGRrAhsjBQkJZgGABwsJCAcDAgEG FQgCCQoLBBYCAwECHgECF4AACgkQbjBXZE7vHeYwBA//ZYxi4I/4KVrqc6oodVfwPnOVxvyY oKZGPXZXAa3swtPGmRFc8kGyIMZpVTqGJYGD9ZDezxpWIkVQDnKM9zw/qGarUVKzElGHcuFN ddtwX64yxDhA+3Og8MTy8+8ZucM4oNsbM9Dx171bFnHjWSka8o6qhK5siBAf9WXcPNogUk4S fMNYKxexcUayv750GK5E8RouG0DrjtIMYVJwu+p3X1bRHHDoieVfE1i380YydPd7mXa7FrRl 7unTlrxUyJSiBc83HgKCdFC8+ggmRVisbs+1clMsK++ehz08dmGlbQD8Fv2VK5KR2+QXYLU0 rRQjXk/gJ8wcMasuUcywnj8dqqO3kIS1EfshrfR/xCNSREcv2fwHvfJjprpoE9tiL1qP7Jrq 4tUYazErOEQJcE8Qm3fioh40w8YrGGYEGNA4do/jaHXm1iB9rShXE2jnmy3ttdAh3M8W2OMK 4B/Rlr+Awr2NlVdvEF7iL70kO+aZeOu20Lq6mx4Kvq/WyjZg8g+vYGCExZ7sd8xpncBSl7b3 99AIyT55HaJjrs5F3Rl8dAklaDyzXviwcxs+gSYvRCr6AMzevmfWbAILN9i1ZkfbnqVdpaag QmWlmPuKzqKhJP+OMYSgYnpd/vu5FBbc+eXpuhydKqtUVOWjtp5hAERNnSpD87i1TilshFQm TFxHDzbOwU0EWCxkawEQALAcdzzKsZbcdSi1kgjfce9AMjyxkkZxcGc6Rhwvt78d66qIFK9D Y9wfcZBpuFY/AcKEqjTo4FZ5LCa7/dXNwOXOdB1Jfp54OFUqiYUJFymFKInHQYlmoES9EJEU yy+2ipzy5yGbLh3ZqAXyZCTmUKBU7oz/waN7ynEP0S0DqdWgJnpEiFjFN4/ovf9uveUnjzB6 lzd0BDckLU4dL7aqe2ROIHyG3zaBMuPo66pN3njEr7IcyAL6aK/IyRrwLXoxLMQW7YQmFPSw drATP3WO0x8UGaXlGMVcaeUBMJlqTyN4Swr2BbqBcEGAMPjFCm6MjAPv68h5hEoB9zvIg+fq M1/Gs4D8H8kUjOEOYtmVQ5RZQschPJle95BzNwE3Y48ZH5zewgU7ByVJKSgJ9HDhwX8Ryuia 79r86qZeFjXOUXZjjWdFDKl5vaiRbNWCpuSG1R1Tm8o/rd2NZ6l8LgcK9UcpWorrPknbE/pm MUeZ2d3ss5G5Vbb0bYVFRtYQiCCfHAQHO6uNtA9IztkuMpMRQDUiDoApHwYUY5Dqasu4ZDJk bZ8lC6qc2NXauOWMDw43z9He7k6LnYm/evcD+0+YebxNsorEiWDgIW8Q/E+h6RMS9kW3Rv1N qd2nFfiC8+p9I/KLcbV33tMhF1+dOgyiL4bcYeR351pnyXBPA66ldNWvABEBAAHCwWUEGAEC AA8FAlgsZGsCGwwFCQlmAYAACgkQbjBXZE7vHeYxSQ/+PnnPrOkKHDHQew8Pq9w2RAOO8gMg 9Ty4L54CsTf21Mqc6GXj6LN3WbQta7CVA0bKeq0+WnmsZ9jkTNh8lJp0/RnZkSUsDT9Tza9r GB0svZnBJMFJgSMfmwa3cBttCh+vqDV3ZIVSG54nPmGfUQMFPlDHccjWIvTvyY3a9SLeamaR jOGye8MQAlAD40fTWK2no6L1b8abGtziTkNh68zfu3wjQkXk4kA4zHroE61PpS3oMD4AyI9L 7A4Zv0Cvs2MhYQ4Qbbmafr+NOhzuunm5CoaRi+762+c508TqgRqH8W1htZCzab0pXHRfywtv 0P+BMT7vN2uMBdhr8c0b/hoGqBTenOmFt71tAyyGcPgI3f7DUxy+cv3GzenWjrvf3uFpxYx4 yFQkUcu06wa61nCdxXU/BWFItryAGGdh2fFXnIYP8NZfdA+zmpymJXDQeMsAEHS0BLTVQ3+M 7W5Ak8p9V+bFMtteBgoM23bskH6mgOAw6Cj/USW4cAJ8b++9zE0/4Bv4iaY5bcsL+h7TqQBH Lk1eByJeVooUa/mqa2UdVJalc8B9NrAnLiyRsg72Nurwzvknv7anSgIkL+doXDaG21DgCYTD wGA5uquIgb8p3/ENgYpDPrsZ72CxVC2NEJjJwwnRBStjJOGQX4lV1uhN1XsZjBbRHdKF2W9g weim8xU= Organization: Red Hat Message-ID: <729ceddb-dd9a-ec2a-f74e-03fa4d7e65e8@redhat.com> Date: Thu, 29 Nov 2018 13:26:34 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <20181129180828.GA11650@hirez.programming.kicks-ass.net> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8BIT Content-Language: en-US X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.39]); Thu, 29 Nov 2018 18:26:36 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 11/29/2018 01:08 PM, Peter Zijlstra wrote: > On Thu, Nov 29, 2018 at 06:27:00PM +0100, Peter Zijlstra wrote: >> wake_up_q() should, per the barriers in wake_up_process, ensure that if >> wake_a_add() fails, there will be a wakeup of that task after that >> point. >> >> So if we put wake_up_q() at the location where wake_up_process() should >> be, it should all work. >> >> The bug in question is that it can happen at any time after >> wake_q_add(), not necessarily at wake_up_q(). > Hmm, I think we're missing a barrier in wake_q_add(); when cmpxchg() > fails we still need an smp_mb(). > > Something like so. > > diff --git a/kernel/sched/core.c b/kernel/sched/core.c > index 3d87a28da378..69def558edf6 100644 > --- a/kernel/sched/core.c > +++ b/kernel/sched/core.c > @@ -400,6 +400,13 @@ void wake_q_add(struct wake_q_head *head, struct task_struct *task) > { > struct wake_q_node *node = &task->wake_q; > > + /* > + * Ensure, that when the below cmpxchg() fails, the corresponding > + * wake_up_q() will observe our prior state. > + * > + * Pairs with the smp_mb() from wake_up_q()'s wake_up_process(). > + */ > + smp_mb(); > /* > * Atomically grab the task, if ->wake_q is !nil already it means > * its already queued (either by us or someone else) and will get the > @@ -408,7 +415,7 @@ void wake_q_add(struct wake_q_head *head, struct task_struct *task) > * This cmpxchg() executes a full barrier, which pairs with the full > * barrier executed by the wakeup in wake_up_q(). > */ > - if (cmpxchg(&node->next, NULL, WAKE_Q_TAIL)) > + if (cmpxchg_relaxed(&node->next, NULL, WAKE_Q_TAIL)) > return; > > get_task_struct(task); That can be costly for x86 which will now have 2 locked instructions. Should we introduce a kind of special cmpxchg (e.g. cmpxchg_mb) that will guarantee a memory barrier whether the operation fails or not? Cheers, Longman