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,URIBL_BLOCKED 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 A27BFC04EBF for ; Mon, 3 Dec 2018 21:05:12 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 67FB22082F for ; Mon, 3 Dec 2018 21:05:12 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 67FB22082F 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 S1726156AbeLCVFL convert rfc822-to-8bit (ORCPT ); Mon, 3 Dec 2018 16:05:11 -0500 Received: from mx1.redhat.com ([209.132.183.28]:55426 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725908AbeLCVFH (ORCPT ); Mon, 3 Dec 2018 16:05:07 -0500 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 7180A81DEB; Mon, 3 Dec 2018 21:05:06 +0000 (UTC) Received: from llong.remote.csb (dhcp-17-55.bos.redhat.com [10.18.17.55]) by smtp.corp.redhat.com (Postfix) with ESMTP id 5968D5D778; Mon, 3 Dec 2018 21:05:05 +0000 (UTC) Subject: Re: [PATCH] clocksource/arm_arch_timer: fix a lockdep warning To: Qian Cai , mark.rutland@arm.com, marc.zyngier@arm.com Cc: daniel.lezcano@linaro.org, tglx@linutronix.de, peterz@infradead.org, mingo@kernel.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org References: <1543865624-17301-1-git-send-email-cai@gmx.us> <11876b19-ec16-c7c5-4b21-c45c2b0f7244@redhat.com> <1543869063.12945.46.camel@gmx.us> 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: Date: Mon, 3 Dec 2018 16:05:04 -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: <1543869063.12945.46.camel@gmx.us> 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.15 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.25]); Mon, 03 Dec 2018 21:05:07 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 12/03/2018 03:31 PM, Qian Cai wrote: > On Mon, 2018-12-03 at 15:07 -0500, Waiman Long wrote: >> On 12/03/2018 02:33 PM, Qian Cai wrote: >>> Booting this Huawei TaiShan 2280 arm64 server generated this lockdep >>> warning. >>> >>> [    0.000000]  lockdep_assert_cpus_held+0x50/0x60 >>> [    0.000000]  static_key_enable_cpuslocked+0x30/0xe8 >>> [    0.000000]  arch_timer_check_ool_workaround+0x128/0x2d0 >>> [    0.000000]  arch_timer_acpi_init+0x274/0x6ac >>> [    0.000000]  acpi_table_parse+0x1ac/0x218 >>> [    0.000000]  __acpi_probe_device_table+0x164/0x1ec >>> [    0.000000]  timer_probe+0x1bc/0x254 >>> [    0.000000]  time_init+0x44/0x98 >>> [    0.000000]  start_kernel+0x4ec/0x7d4 >>> >>> This is due to the commit cb538267ea1e ("jump_label/lockdep: Assert we hold >>> the hotplug lock for _cpuslocked() operations"). Therefore, it will check >>> if it is really in the CPU hotplug path or not, and work around this >>> problem by using cpus_read_trylock(). The chance of not getting the read >>> lock is very small. If that happens, it will report a lockdep warning at >>> most. >>> >>> Signed-off-by: Qian Cai >>> --- >>>  drivers/clocksource/arm_arch_timer.c | 9 +++++++++ >>>  1 file changed, 9 insertions(+) >>> >>> diff --git a/drivers/clocksource/arm_arch_timer.c >>> b/drivers/clocksource/arm_arch_timer.c >>> index 9a7d4dc..5c9acbd 100644 >>> --- a/drivers/clocksource/arm_arch_timer.c >>> +++ b/drivers/clocksource/arm_arch_timer.c >>> @@ -497,11 +497,20 @@ void arch_timer_enable_workaround(const struct >>> arch_timer_erratum_workaround *wa >>>   per_cpu(timer_unstable_counter_workaround, i) = wa; >>>   } >>>   >>> +#ifdef CONFIG_HOTPLUG_CPU >> If HOTPLUG_CPU isn't defined, all the cpus_lock() and related functions >> are just no-op. You don't need to use conditional compilation directive >> here. > Make sense. > >>> + i = 0; >>> + >>>   /* >>>    * Use the locked version, as we're called from the CPU >>>    * hotplug framework. Otherwise, we end-up in deadlock-land. >>>    */ >> I think the main problem is the above comment may not be true anymore or >> is only occasionally true. We need to audit the code to find the root cause. > This was a commit introduced in Aug. 2017, 450f9689f294 > (clocksource/arm_arch_timer: Use static_branch_enable_cpuslocked()) which > basically drop the cpus_read_lock(). May I ask what changes made you think the > above comment incorrect now? > If the above comment is true, you won't have the lockdep splat in the first place. I think the most likely case is that the  function can be called from both a hotplug path and a non-hotplug path. So the comment needs to be updated to reflect that. >>> + i = cpus_read_trylock(); >>>   static_branch_enable_cpuslocked(&arch_timer_read_ool_enabled); >>> + if (i) >>> + cpus_read_unlock(); >> This is not the right way of fixing the lockdep splash. >> > I should had said it is a workaround. I am all-ears for a proper way to fix > this. When the above commit 450f9689f294 was merged, there was no cb538267ea1e > so no lockdep warning. As a workaround, you should better document that in the code. Thinking about it some more, your workaround seems to be valid. Recursive cpus_read_lock() is allowed. If it is called from a hotplug path, cpus_write_lock() should have been taken and cpus_read_trylock() will failed. Of course, we will have to assume that the current CPU is the one that has taken the write lock in this case. Cheers, Longman