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=-1.1 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED autolearn=no 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 D43F2ECE58E for ; Thu, 17 Oct 2019 16:34:44 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id A848621A49 for ; Thu, 17 Oct 2019 16:34:44 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1571330084; bh=W1fi+yiqxSMbIlkGbbuMcV9cOsU/c1cjMnKa89DCUd8=; h=References:In-Reply-To:From:Date:Subject:To:Cc:List-ID:From; b=kWrGJxHo6RYigCo+qQTBbL+kqRBQE/425M+MY8T+nqw8dyAvegOgQY1lzGXVMJmUL +zekwVEop008YZsUdx5rq1XwkqdalbbFevLB+D22LxuUGDR5CP7A1LetCHEmq3pB23 tSQ3/rCFaLIxdPkUFHrrIZzzw5rI5k7jiHB5Wzss= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2408359AbfJQQen (ORCPT ); Thu, 17 Oct 2019 12:34:43 -0400 Received: from mail-oi1-f194.google.com ([209.85.167.194]:34833 "EHLO mail-oi1-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2393857AbfJQQel (ORCPT ); Thu, 17 Oct 2019 12:34:41 -0400 Received: by mail-oi1-f194.google.com with SMTP id x3so2723353oig.2; Thu, 17 Oct 2019 09:34:40 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=PTweReGzWRV6Ob0sCHbhOekauupQAppLGL1gzS8TcKs=; b=pe9wF3D7Kl6nB4c9mowgsk+ThJW8q9PSq+ivgjpZzgoQuAtK20bJviLymZe7UKCdw0 mJVlQzxDvL9DuDg6s9DB7vkG19y/oxgWV3w6YiGH8t+a7zXbp/TGkqL1pz3R5bfwJWys +F9wJteJPyaoiXUswxnEAdFnpPj0yGYWFLgfzQ6qmtIjhNotK555sI2oDRIzxPDCzYAm hmwhcI/9x1559oUC2HxrWG7O6T21BIGT0Xj5tF6TYcXY/seo+19Z6PxYbJfeV62/gHXA rqJ1/b5wl7LBUqVpu7WSUQdksmQYUPmg8YV10wEHSCMprEpXSI+TqgI0D0rvLANqhbsQ n4iA== X-Gm-Message-State: APjAAAUeawEOwNz7YVRhZ+kYtlvXEHr6skB4Nk+n3OoHw/LeFO7k/Fa6 uN4Re11HXK3Y4GZZ3HeTvpnYXS7AUoRUpbBnUxQ= X-Google-Smtp-Source: APXvYqxdtwn4csBmwqLiWGMGaWig215MMPVHzs3sAF65tbKccsRNu9C3I2YhQmoUAwnEvbh1AfpL5ERkR4gfKHL+voQ= X-Received: by 2002:aca:b6c5:: with SMTP id g188mr4177262oif.103.1571330080233; Thu, 17 Oct 2019 09:34:40 -0700 (PDT) MIME-Version: 1.0 References: <2811202.iOFZ6YHztY@kreacher> <20191016142343.GB5330@bogus> <20191017095725.izchzl7enfylvpf3@vireshk-i7> <20191017095942.GF8978@bogus> In-Reply-To: <20191017095942.GF8978@bogus> From: "Rafael J. Wysocki" Date: Thu, 17 Oct 2019 18:34:28 +0200 Message-ID: Subject: Re: [RFT][PATCH 0/3] cpufreq / PM: QoS: Introduce frequency QoS and use it in cpufreq To: Sudeep Holla , Viresh Kumar Cc: "Rafael J. Wysocki" , Linux PM , Linux ACPI , LKML , Dmitry Osipenko Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Oct 17, 2019 at 12:00 PM Sudeep Holla wrote: > > On Thu, Oct 17, 2019 at 03:27:25PM +0530, Viresh Kumar wrote: > > On 16-10-19, 15:23, Sudeep Holla wrote: > > > Thanks for the spinning these patches so quickly. > > > > > > I did give it a spin, but unfortunately it doesn't fix the bug I reported. > > > So I looked at my bug report in detail and looks like the cpufreq_driver > > > variable is set to NULL at that point and it fails to dereference it > > > while trying to execute: > > > ret = cpufreq_driver->verify(new_policy); > > > (Hint verify is at offset 0x1c/28) > > > > > > So I suspect some race as this platform with bL switcher tries to > > > unregister and re-register the cpufreq driver during the boot. > > > > > > I need to spend more time on this as reverting the initial PM QoS patch > > > to cpufreq.c makes the issue disappear. I guess you mean commit 67d874c3b2c6 ("cpufreq: Register notifiers with the PM QoS framework")? That would make sense, because it added the cpufreq_notifier_min() and cpufreq_notifier_max() that trigger handle_update() via schedule_work(). [BTW, Viresh, it looks like cpufreq_set_policy() should still ensure that the new min is less than the new max, because the QoS doesn't do that.] > > Is this easily reproducible ? cpufreq_driver == NULL shouldn't be the case, it > > get updated only once while registering/unregistering cpufreq drivers. That is > > the last thing which can go wrong from my point of view :) > > > > Yes, if I boot my TC2 with bL switcher enabled, it always crashes on boot. It does look like handle_update() races with cpufreq_unregister_driver() and cpufreq_remove_dev (called from there indirectly) does look racy.