From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-7.0 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_PASS autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id E1F73C43441 for ; Thu, 29 Nov 2018 15:29:13 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 9584721019 for ; Thu, 29 Nov 2018 15:29:13 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 9584721019 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728739AbeK3Ce4 (ORCPT ); Thu, 29 Nov 2018 21:34:56 -0500 Received: from mx1.redhat.com ([209.132.183.28]:47706 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728128AbeK3Cez (ORCPT ); Thu, 29 Nov 2018 21:34:55 -0500 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id C988A30001EF; Thu, 29 Nov 2018 15:29:10 +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 8345E608DA; Thu, 29 Nov 2018 15:29:09 +0000 (UTC) Subject: Re: [RFC] locking/rwsem: Avoid issuing wakeup before setting the reader waiter to nil From: Waiman Long To: Peter Zijlstra , Yongji Xie Cc: 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> 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: <2ab06fe3-049e-2bcb-ae10-6ebe487c1820@redhat.com> Date: Thu, 29 Nov 2018 10:29:09 -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: <5598cd71-c3c8-d6ef-eb30-777cf901a2ef@redhat.com> 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.13 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.46]); Thu, 29 Nov 2018 15:29:10 +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 10:21 AM, Waiman Long wrote: > On 11/29/2018 08:12 AM, Peter Zijlstra wrote: >> +Cc davidlohr and waiman >> >> On Thu, Nov 29, 2018 at 08:50:30PM +0800, Yongji Xie wrote: >>> From: Xie Yongji >>> >>> Our system encountered a problem recently, the khungtaskd detected >>> some process hang on mmap_sem. But the odd thing was that one task which >>> is not on mmap_sem.wait_list still sleeps in rwsem_down_read_failed(). >>> Through code inspection, we found a potential bug can lead to this. >>> >>> Imaging this: >>> >>> Thread 1 Thread 2 >>> down_write(); >>> rwsem_down_read_failed() >>> raw_spin_lock_irq(&sem->wait_lock); >>> list_add_tail(&waiter.list, &wait_list); >>> raw_spin_unlock_irq(&sem->wait_lock); >>> __up_write(); >>> rwsem_wake(); >>> __rwsem_mark_wake(); >>> wake_q_add(); >>> list_del(&waiter->list); >>> waiter->task = NULL; >>> while (true) { >>> set_current_state(TASK_UNINTERRUPTIBLE); >>> if (!waiter.task) // true >>> break; >>> } >>> __set_current_state(TASK_RUNNING); >>> >>> Now Thread 1 is queued in Thread 2's wake_q without sleeping. Then >>> Thread 1 call rwsem_down_read_failed() again because Thread 3 >>> hold the lock, if Thread 3 tries to queue Thread 1 before Thread 2 >>> do wakeup, it will fail and miss wakeup: >>> >>> Thread 1 Thread 2 Thread 3 >>> down_write(); >>> rwsem_down_read_failed() >>> raw_spin_lock_irq(&sem->wait_lock); >>> list_add_tail(&waiter.list, &wait_list); >>> raw_spin_unlock_irq(&sem->wait_lock); >>> __rwsem_mark_wake(); >>> wake_q_add(); >>> wake_up_q(); >>> waiter->task = NULL; >>> while (true) { >>> set_current_state(TASK_UNINTERRUPTIBLE); >>> if (!waiter.task) // false >>> break; >>> schedule(); >>> } >>> wake_up_q(&wake_q); >>> >>> In another word, that means we might issue the wakeup before setting the reader >>> waiter to nil. If so, the wakeup may do nothing when it was called before reader >>> set task state to TASK_UNINTERRUPTIBLE. Then we would have no chance to wake up >>> the reader any more, and cause other writers such as "ps" command stuck on it. >>> >>> This patch is not verified because we still have no way to reproduce the problem. >>> But I'd like to ask for some comments from community firstly. >> Urgh; so the case where the cmpxchg() fails because it already has a >> wakeup in progress, which then 'violates' our expectation of when the >> wakeup happens. >> >> Yes, I think this is real, and worse, I think we need to go audit all >> wake_q_add() users and document this behaviour. > Yes, I also think this is a valid race scenario that can cause missed > wakeup. Actually, I had bug reports of similar symptom of sleeping > reader not in a wait queue.  I was puzzled by how that could happen. > That clearly is one possible cause of that. > > >> In the ideal case we'd delay the actual wakeup to the last wake_up_q(), >> but I don't think we can easily fix that. >> >>> Signed-off-by: Xie Yongji >>> Signed-off-by: Zhang Yu >>> --- >>> kernel/locking/rwsem-xadd.c | 11 +++++++++-- >>> 1 file changed, 9 insertions(+), 2 deletions(-) >>> >>> diff --git a/kernel/locking/rwsem-xadd.c b/kernel/locking/rwsem-xadd.c >>> index 09b1800..50d9af6 100644 >>> --- a/kernel/locking/rwsem-xadd.c >>> +++ b/kernel/locking/rwsem-xadd.c >>> @@ -198,15 +198,22 @@ static void __rwsem_mark_wake(struct rw_semaphore *sem, >>> woken++; >>> tsk = waiter->task; >>> >>> - wake_q_add(wake_q, tsk); >>> + get_task_struct(tsk); >>> list_del(&waiter->list); >>> /* >>> - * Ensure that the last operation is setting the reader >>> + * Ensure calling get_task_struct() before setting the reader >>> * waiter to nil such that rwsem_down_read_failed() cannot >>> * race with do_exit() by always holding a reference count >>> * to the task to wakeup. >>> */ >>> smp_store_release(&waiter->task, NULL); >>> + /* >>> + * Ensure issuing the wakeup (either by us or someone else) >>> + * after setting the reader waiter to nil. >>> + */ >>> + wake_q_add(wake_q, tsk); >>> + /* wake_q_add() already take the task ref */ >>> + put_task_struct(tsk); >>> } >>> >>> adjustment = woken * RWSEM_ACTIVE_READ_BIAS - adjustment; > I doubt putting wake_q_add() after clearing waiter->task can really fix > the problem. The wake_up_q() function happens asynchronous to the > detection of NULL waiter->task in __rwsem_down_read_failed_common(). I > believe the same scenario may still happen. > > One possible solution that I can think of is as follows: > > diff --git a/include/linux/sched/wake_q.h b/include/linux/sched/wake_q.h > index 10b19a1..1513cdc 100644 > --- a/include/linux/sched/wake_q.h > +++ b/include/linux/sched/wake_q.h > @@ -47,6 +47,14 @@ static inline void wake_q_init(struct wake_q_head *head) >         head->lastp = &head->first; >  } >   > +/* > + * Return true if the current task is on a wake_q. > + */ > +static inline bool wake_q_pending(void) > +{ > +       return !!current->wake_q.next; > +} > + >  extern void wake_q_add(struct wake_q_head *head, >                        struct task_struct *task); >  extern void wake_up_q(struct wake_q_head *head); > diff --git a/kernel/locking/rwsem-xadd.c b/kernel/locking/rwsem-xadd.c > index 3dbe593..b656777 100644 > --- a/kernel/locking/rwsem-xadd.c > +++ b/kernel/locking/rwsem-xadd.c > @@ -269,7 +269,7 @@ static void __rwsem_mark_wake(struct rw_semaphore *sem, >         /* wait to be given the lock */ >         while (true) { >                 set_current_state(state); > -               if (!waiter.task) > +               if (!smp_load_acquire(&waiter.task)) >                         break; >                 if (signal_pending_state(state, current)) { >                         raw_spin_lock_irq(&sem->wait_lock); > @@ -282,6 +282,15 @@ static void __rwsem_mark_wake(struct rw_semaphore *sem, >         } >   >         __set_current_state(TASK_RUNNING); > + > +       /* > +        * If waiter is still queuing in a wake_q somewhere, we have to wait > +        * until the wake_up_q() process is complete as the memory of the > +        * waiter structure will no longer be valid when we return. > +        */ Sorry, the comment is wrong. I should say something like /*  * If we are still queuing in a wake_q somewhere, we have to wait until the wake_up_q() function is complete to prevent against concurrent wake_q operation.  */ > +       while (wake_q_pending()) > +               cpu_relax(); > + >         return sem; >  out_nolock: >         list_del(&waiter.list); > > Cheers, Longman