Received: by 2002:a25:2c96:0:0:0:0:0 with SMTP id s144csp919686ybs; Mon, 25 May 2020 02:33:52 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxEtQkq3+w8QMR3uamzcqpjrhvfpGztjR1yRrOXB/tyvvqY1SD0G9XsL/oAAanJfoUWlFsZ X-Received: by 2002:a50:d65c:: with SMTP id c28mr13733988edj.21.1590399232368; Mon, 25 May 2020 02:33:52 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1590399232; cv=none; d=google.com; s=arc-20160816; b=V0LS5/VuILr/B/QyBpty2bZt69Z8OtDS/cSZNuerxR9c1BN3yfKi/3y8idAoaZe5ID 1p5Fm5r3M9g5WWn8NnbJ+GUmwXQ8lC97dddcELuw4tWuaM233jcJakywlmHZnYKMxLLO vJUvUdUqDodYv+o3yrNU2t11D3xYoXeVdd6WijXXyHVA9hYPFo/UrzuOmtv0x/JG8lG+ 5nLsjeN4goIih1ixNiGP336oyDe/yNqiAn1KkChOh5Dyyec8WdDayXsckW/0//n3NXuf BKY07tzQdAZlaHzYGs4WzYHxUQWQF08QEGbQI9i9co3+Q75me0urIQoWJC2JhrxAYKzh XhVg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=2SJy3teeS/DAEycN8FRbgylUfmtHnW0QUGPznK0vKdk=; b=nzFK8KcilOFfJB1/rckXY9zZb/t2pNW87zWMyVH6Ll3gEcdTAa4Bw8U5xqgEl/Nf4k oxbUV+v7vKuOJ7gUcmrfG1W9KqTVklmS3CQSfgHMEGwYt5M7Qur/85ZC9Y9aY9LmNyFs UxbvsBGRSiLLzFT4pNY+bdWx+Nztp7NKw0sWmbRjcAN3orXcxzR1gdvqbGiRh8OMJqMt lxeOnesD88FvNf8v+c0MJQs0bG0sUXoSgoWsh0ZTb/lv5plKiofru2YeZh20aN9zdXXM TYQV7XDMlzUI/6dIyt+3brWIo+pb2CF0nycR54h49JoCtl1MNmCot4dYtseoltsR0Bj8 KD8A== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=oOVlDGly; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id q15si9615400edi.367.2020.05.25.02.33.29; Mon, 25 May 2020 02:33:52 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=oOVlDGly; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2389500AbgEYJb2 (ORCPT + 99 others); Mon, 25 May 2020 05:31:28 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:55948 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2389192AbgEYJb1 (ORCPT ); Mon, 25 May 2020 05:31:27 -0400 Received: from mail-vs1-xe41.google.com (mail-vs1-xe41.google.com [IPv6:2607:f8b0:4864:20::e41]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C5CF1C061A0E for ; Mon, 25 May 2020 02:31:25 -0700 (PDT) Received: by mail-vs1-xe41.google.com with SMTP id l15so9607777vsr.3 for ; Mon, 25 May 2020 02:31:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=2SJy3teeS/DAEycN8FRbgylUfmtHnW0QUGPznK0vKdk=; b=oOVlDGlyYvsjt9O70aWettNvYp5QuWpirQw83njS4tN9OVs1QOHpQ6l4kTXcQxSSyH Nhslhcled0cALdykwKEM9G2EaYphVlW+R4mq2rsKBu1pBFetLlagvOXR8qS+HhpbLsfv EfsZ8lsKt84cOgjPFwv4DmDm0ZPvnauZJpxKpOo+OpMGpvtMwjQ6XKPlh3MotvunFVL9 WD2yTLvNTyCG/2t90ne8LWfZc32BozQ1R2+QEeYjj/yC2M0mLjdFEr7Rpjxhx3xSEYoq 8v/VxK+F4xDjizjBPUPqFQu56jScEuiwTQ1LcqmVtKUa1VPGxM84KBhaYWAlwlkXpfRC itEA== 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=2SJy3teeS/DAEycN8FRbgylUfmtHnW0QUGPznK0vKdk=; b=gSI2OCue7c98Q/oHEGTwCW2jsBprENbcirQQIkxBFqGwH52DYDZPde6DWnYAvKc7uA QiQwwlCztAAVNOHuYSNR2/LArh6wh4Lku+pGz/05U2zN37kj8c5Xxo+etwh6ZvpSV6zD qLB2JCdCAWfri09XN6Pn5PKFU953u6d8a1q2FeTtPFcO1oH6CqyqCQtLimDLywstBcGK uOLjKJ6qHiU5ajTEj99QRlJrY4mhA8lHRmJREwTwYTtLIGyUtuskoxRDMF814GpXQR7k l9Yg+p12WD4d8vtFHraXCexYScckA/Zt1HcIFmlkLuayohspopeOK+St1PM8+Z84CSaR N7/A== X-Gm-Message-State: AOAM533Drel2/EHVKPQWf4v1nMWbmiBBNqfV+4mPtiqvU9tJaZOQW6OR uokL3uNRa1y5fFKgRvkoB4GdEC3EIihVb8Va5xew+A== X-Received: by 2002:a67:1486:: with SMTP id 128mr13187332vsu.191.1590399084957; Mon, 25 May 2020 02:31:24 -0700 (PDT) MIME-Version: 1.0 References: <5127441.yGvM1JjtLk@kreacher> In-Reply-To: From: Ulf Hansson Date: Mon, 25 May 2020 11:30:48 +0200 Message-ID: Subject: Re: [PATCH] PM: runtime: clk: Fix clk_pm_runtime_get() error path To: "Rafael J. Wysocki" , Marek Szyprowski Cc: "Rafael J. Wysocki" , Linux PM , LKML , Krzysztof Kozlowski , Michael Turquette , Bartlomiej Zolnierkiewicz 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 Fri, 22 May 2020 at 20:39, Rafael J. Wysocki wrote: > > On Fri, May 22, 2020 at 7:19 AM Marek Szyprowski > wrote: > > > > Hi Rafael, > > > > On 21.05.2020 19:08, Rafael J. Wysocki wrote: > > > From: Rafael J. Wysocki > > > > > > clk_pm_runtime_get() assumes that the PM-runtime usage counter will > > > be dropped by pm_runtime_get_sync() on errors, which is not the case, > > > so PM-runtime references to devices acquired by the former are leaked > > > on errors returned by the latter. > > > > > > Fix this by modifying clk_pm_runtime_get() to drop the reference if > > > pm_runtime_get_sync() returns an error. > > > > > > Fixes: 9a34b45397e5 clk: Add support for runtime PM > > > Cc: 4.15+ # 4.15+ > > > Signed-off-by: Rafael J. Wysocki > > > > Frankly, I would rather fix the runtime_get_sync() instead of fixing the > > return path everywhere in the kernel. The current behavior of the > > pm_runtime_get_sync() is completely counter-intuitive then. I bet that > > in the 99% of the places where it is being called assume that no special > > fixup is needed in case of failure. This is one of the most common > > runtime PM related function and it is really a common pattern in the > > drivers to call: > > > > pm_runtime_get_sync() > > > > do something with the hardware > > > > pm_runtime_put() > > > > Do you really want to fix the error paths of the all such calls? > > No, I don't, and that's why I'm proposing this patch. > > The caller that does what you said above is OK now and if the behavior > of pm_runtime_get_sync() changed, that caller would need to be > updated. > > OTOH, a caller that fails to drop the reference on an error returned > by pm_runtime_get_sync() is buggy (and has ever been so). > > I'd rather update the buggy callers than the ones that are OK. I agree. In hindsight we should have dropped the usage count in pm_runtime_get_sync(), when it fails. However, that's too late, especially since there are many cases having no error handling at all - and in those cases, that would mean the subsequent call to pm_runtime_put() can mess up the usage count (if pm_runtime_get_sync() failed and has already dropped the count). So, feel free to add: Reviewed-by: Ulf Hansson [...] Kind regards Uffe