From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id F1AC7370D54 for ; Fri, 24 Jul 2026 15:45:01 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.133.124 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784907903; cv=none; b=SvBEZ9o5y1LwbwPvrBMF7HXhiDONJ1V/lYxYcDbXNdIhfoHsAy9ud0oAl9sM6zIEJmIDFQXN7dRXLBgT73YaYGt8NSCtLQD3KZMrXU6jUpA/NkPshZbwwZLQVNx3gqLPwiLyv4jMYhPP5GU7AxVqeK1+WlC8XWAneyr17rKfNR4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784907903; c=relaxed/simple; bh=UxTQdA2isgDvgKmYscfzhqJ851W9NSTq2A3T2NK1VT8=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=feMxtsDgn9t3nSXJF8SvS1SBq5YnNtlj7bDFkw9SzmPFcUJ+ZWpG5lbW6wtyaMPKfPElVN6ItumYOVjmMKbLx4plNr/PZ+pz1C4lzYLmKeoopgJeE2/0yNpsy6r5Rf5uag0eLzE2lK7HfEkE6V78XlNgh5ymO71XhZJ/m4WeISY= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=PaggLQGX; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b=Yiu/puFU; arc=none smtp.client-ip=170.10.133.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="PaggLQGX"; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b="Yiu/puFU" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1784907901; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=w5JjSXmoKI6gVlxYEYG5ahHmEi75NF5JvrpIqRPpGtc=; b=PaggLQGX4GHUY1Zb+SaJ4hyNZVMGKvcvAteQFYpNY9b2iLezUN0EaPZO72Q44ysisfNdwt rcuETtP7ILi/memXTYwdYVvCxBvXHN8URBo9maGBQl5Ftp52+8sf/SIvC3AVlbNQMdWIKJ 5dFTuvtqiMxKhV7b2J9sVeiF/YkumKg= Received: from mail-qk1-f199.google.com (mail-qk1-f199.google.com [209.85.222.199]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-582-8OQRbTpmNImTGm-96L9OEQ-1; Fri, 24 Jul 2026 11:44:59 -0400 X-MC-Unique: 8OQRbTpmNImTGm-96L9OEQ-1 X-Mimecast-MFC-AGG-ID: 8OQRbTpmNImTGm-96L9OEQ_1784907899 Received: by mail-qk1-f199.google.com with SMTP id af79cd13be357-93106d8af18so67072885a.0 for ; Fri, 24 Jul 2026 08:44:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=google; t=1784907899; x=1785512699; darn=vger.kernel.org; h=user-agent:in-reply-to:content-transfer-encoding :content-disposition:content-type:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to :content-type; bh=w5JjSXmoKI6gVlxYEYG5ahHmEi75NF5JvrpIqRPpGtc=; b=Yiu/puFUmzMVw4S1BlJ2UOFJybT6zGnzpvQQ+4nZ2A1RAituohMFk2n4AOvWkil+r+ bIX26oZZqzTY0575uEBLiDnLybJC643cNV7Q89Mr6km5MqH9Zf8TqLdZyE4zj5EodVbS WrWI5s8lUcS7uXekqfr77owoEboqSopCwrXULdyjXi8L6geqwPupGCmcYSe+gCPT0Njf nMAsgyDBbxxzeh2Qd0XiO9cBSe4fg5Qaahd939PbWXU6vuauabqWE5NI4M5SVbe3vcE/ 3v1GHRp2D3KknoF00Y2xw7QWys7u8QryfY3qRGpAAGTZgEifOvHPtKUdQ1BlS8jP/57w 2rIQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1784907899; x=1785512699; h=user-agent:in-reply-to:content-transfer-encoding :content-disposition:content-type:mime-version:references:message-id :subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to:content-type; bh=w5JjSXmoKI6gVlxYEYG5ahHmEi75NF5JvrpIqRPpGtc=; b=CjS8Y0i9eURxaogpHeocimdld3rDgvXGDz8gRLWcHUbDzkL9oMj7XKuQIysurQMBgN HbrEd3ggZ1EDt8/6zBQRQuuRnvONQ7qie6ARKtdViG0NZCEoX8zQyeLQa0bk7EDmxr6z +Felu8lm11dV1UxJNEuGXNi95B5ezr3PS07OtLlGYsqQVJHjlsY0+O7ImClU7xWPncol PlFJ8LWYGxryNY43BLb4EzIXcu/ae08r379dAuowFutBmsprtro2rflT6hGCZ/HWdcuH Hrp3kzaTlt/Nu8yZ9Hi9mrZK0Xdw4Y+GmD1ZdtsWYlLLu13NP+E5BkSXQY0e2u8Zj4/w DRtg== X-Forwarded-Encrypted: i=1; AHgh+RrXQlV9oeufVfSX/F/VYI8+vS/HVBRJZ69M268SBdZED+OeGkswGq0a+8eRx9qdxXTKNDcDGJe8R1qJ3m4=@vger.kernel.org X-Gm-Message-State: AOJu0Yy8etmsBzIq+bUmiSPI2oJhUte2i0KGpmu4YAq9VxBJrPFlNoFa wsbU/r5GYc0PwxmJgIg8un1p8LcPzHXJwCx4SawEsIzNEKFyv6juBadHDSV6sRgfTUJ+ZEmfdBZ JZOYsoyK709LGyF56233cNS+8wj49LmeG730GzPZYZDMiN+/JsoIFWJJhAi4xW9JilQ== X-Gm-Gg: AR+sD10i97VtDRUsNmo8pPwzH9bc5EQwydGnStAc6/Gu3nVQLt1qL9qLkX5kGxn/Pjc ydJHMYpbcgFvNtE3RIBWd21nxIMjGpXr6LIbsWSJYmpYQey3zKEuuaHAr6kjuLkyYSFByDE+hES CmV85BV9jgGeqyRhGhwzBAIwfGmVebWbgGaugjSw4e8Ib7pCedS343WaAJ4Uiv87EZe5KHLC8mk EFxDSZwJnKS9BJYiRMQrOe5vMFxRSgrsZhK3Ct8ILXjWjCs1Kq+1/X0ql+s/eiR+wVH8FHhN4yE dAv8XNgTTLg6E7F3ytn5FSq76npadQntsNBWvu6xF3mgR7HHZU4saj3oMnEqvTZysrDQCrWVa4C Engv5TETO1Lijcaie5kOgU2IrZfK7HugVOZA= X-Received: by 2002:a05:622a:2b4f:b0:517:7d9a:a88 with SMTP id d75a77b69052e-5283de69606mr71786231cf.37.1784907899006; Fri, 24 Jul 2026 08:44:59 -0700 (PDT) X-Received: by 2002:a05:622a:2b4f:b0:517:7d9a:a88 with SMTP id d75a77b69052e-5283de69606mr71785901cf.37.1784907898485; Fri, 24 Jul 2026 08:44:58 -0700 (PDT) Received: from redhat.com (c-73-183-53-213.hsd1.pa.comcast.net. [73.183.53.213]) by smtp.gmail.com with ESMTPSA id d75a77b69052e-529a27f4346sm2103881cf.8.2026.07.24.08.44.56 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 24 Jul 2026 08:44:57 -0700 (PDT) Date: Fri, 24 Jul 2026 11:44:55 -0400 From: Brian Masney To: Praveen Talari Cc: bjorn.andersson@oss.qualcomm.com, Michael Turquette , Stephen Boyd , konrad.dybcio@oss.qualcomm.com, mukesh.savaliya@oss.qualcomm.com, linux-clk@vger.kernel.org, linux-kernel@vger.kernel.org, chandana.chiluveru@oss.qualcomm.com Subject: Re: [PATCH] clk: Guard clk_round_rate() against error pointers Message-ID: References: <20260723-fix_ptr_check_on_clk-v1-1-568a7ed87746@oss.qualcomm.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/2.4.0 (2026-06-19) Hi Praveen, On Thu, Jul 23, 2026 at 10:10:06PM +0530, Praveen Talari wrote: > On 23-07-2026 19:59, Brian Masney wrote: > > On Thu, Jul 23, 2026 at 11:40:47AM +0530, Praveen Talari wrote: > > > clk_round_rate() only checks for a NULL clk pointer before > > > dereferencing it, but callers such as dev_pm_opp_set_rate() can pass > > > it an error pointer (e.g. ERR_PTR(-ENOENT) left behind by > > > clk_get() when a device has no Linux clock and is instead managed by > > > firmware via a genpd/OPP performance domain). > > > > > > Dereferencing that error pointer to read clk->exclusive_count > > > crashes with an unhandled kernel NULL pointer dereference, since > > > ERR_PTR(-ENOENT) plus the field's offset lands on a small, unmapped > > > address: > > > > > > Unable to handle kernel NULL pointer dereference at virtual > > > address 000000000000002e > > > ... > > > pc : clk_round_rate+0x3c/0x188 > > > ... > > > Call trace: > > > clk_round_rate+0x3c/0x188 (P) > > > dev_pm_opp_set_rate+0x114/0x33c > > > > > > Change the guard from "if (!clk)" to "if (IS_ERR_OR_NULL(clk))", > > > matching the pattern already used by other clk consumer API > > > functions such as clk_unprepare(), so an error pointer is rejected > > > the same way a NULL pointer is. > > > > > > Signed-off-by: Praveen Talari > > > --- > > > drivers/clk/clk.c | 2 +- > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c > > > index 048adfa86a5d..8c1ad3d10284 100644 > > > --- a/drivers/clk/clk.c > > > +++ b/drivers/clk/clk.c > > > @@ -1780,7 +1780,7 @@ long clk_round_rate(struct clk *clk, unsigned long rate) > > > struct clk_rate_request req; > > > int ret; > > > - if (!clk) > > > + if (IS_ERR_OR_NULL(clk)) > > Can you provide more details about the clk_get() call point that starts this > > error? Specifically which driver this occurs in and the exact scenario that > > triggers this. > > On SA8255P platform there is no Linux > clock for the SE, and the perf domain device's OPPs are populated entirely > from firmware via devm_pm_opp_of_add_table() (through > of_genpd_add_provider_simple()/onecell()), so the perf domain's OPP table > has entries even though no clk_get() ever succeeds for it. > > The clk_get(-ENOENT) case comes from _update_opp_table_clk() in > drivers/opp/core.c: > >     opp_table->clk = clk_get(dev, NULL); >     ret = PTR_ERR_OR_ZERO(opp_table->clk); >     ... >     if (ret == -ENOENT) { >         /* ... no clk provided ... */ >         opp_table->clk_count = 1; >         return opp_table;   /* opp_table->clk left as ERR_PTR(-ENOENT) */ >     } > > Because the perf domain device has no "clocks" property (its OPPs are > supplied purely as performance states by firmware/genpd), clk_get() > returns -ENOENT, and opp_table->clk is left holding that error pointer > rather than being reset to NULL. This looks to be a reasonable change. Thanks. Reviewed-by: Brian Masney