Received: by 2002:a25:2c96:0:0:0:0:0 with SMTP id s144csp122409ybs; Tue, 26 May 2020 05:20:27 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyC4SQwXP26q8cBHX7b855FQ7hWkkMNcxtfnLhbZriYJCJxev6jsOFabpz+CY0g5woLWlxr X-Received: by 2002:a50:e808:: with SMTP id e8mr7621005edn.258.1590495627810; Tue, 26 May 2020 05:20:27 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1590495627; cv=none; d=google.com; s=arc-20160816; b=vMSQT27V6xOyfLLK5m/fOZbEE90F8mnBjo+JctaDqv9Ygt81ZrV4JLqJCD3GIQGWwp NrBy0ZOG3J4VlkdeLy+VeWEL8/5Dhy3JYbo/iSAHoUJt1d8/KsA9SeDIemGM5R6DDYfy twvsTOHP9uirMZrl1tTIKH0qLAM+zRM2NFBte43OnJvL8Hyb7l7DnqJNXQZqCX44GgRX gXu5Juh1ROkxxXnnSXE471NvQfvZxXSttkLYxPETaK4AdGKi65PbyXH9z1c7Z9b3sPv5 A0o54vepb+utCMFjcP/bQWaYQY/8UwMSQNocV7LEt8rry4EMkCcIa0Z6ue5iFc3tA664 +yEg== 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; bh=oGPpj4I3FcCpdQx07sSJRfqTAreoAbABjbVK8kbfFPY=; b=h5waWIUntT1aE39jLIzhoJmn7SiGYS663dAAj6p/jmsUw21LRWmz55kWML8E6J6yvD r1SNOA/eWJBUoFE8sDuKM/CqRcY+aeMYJy/JWQwik8elpNh4mEoWEKnRZUVCGazGi8c+ QIpl/pTGDklOUdOSsmDVF9QY/Iu1e5OxXsnk5CsTR1dn71OjKXyaJoW6UiuPVSLPn3zU 3qSN15uBMfpcjSRb6xfxKpkDWEkA05mn03iHKavo+LyqhJbmVrP5rhNbtzPjrVubW0O3 NgiEswPZBKbLlxBdgUPMvANVyCKMc6VfmOzm95cvKZs7FNwARtlkFCzs4pF5MpzRXjLQ PbZA== ARC-Authentication-Results: i=1; mx.google.com; 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=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id v22si11217936ejx.259.2020.05.26.05.20.03; Tue, 26 May 2020 05:20:27 -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; 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=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1731512AbgEZIwg (ORCPT + 99 others); Tue, 26 May 2020 04:52:36 -0400 Received: from mail-oi1-f194.google.com ([209.85.167.194]:43275 "EHLO mail-oi1-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726926AbgEZIwg (ORCPT ); Tue, 26 May 2020 04:52:36 -0400 Received: by mail-oi1-f194.google.com with SMTP id i22so17997140oik.10; Tue, 26 May 2020 01:52:35 -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=oGPpj4I3FcCpdQx07sSJRfqTAreoAbABjbVK8kbfFPY=; b=FTV4aHn/webGuehlJulougjjsptJ067ki0VsZmMlUPoSu8EJWnnfEOG53dTYylZpHa +oJ9Nx3S76xl44y57HQdXBQvDmT0RuIfscQibck8fXamz0T/Mq9Lu1tvPOERBlEzgoND PEx2N100d4pKhTi6XGQ3f+aKcPSzYvuMTuw/o1AyS5Vq7hHTE03B1WC2/i5+3Q83iyFG 0WRwmAjLf7vOFz+I2gK/FzJAPSPOAS0KHD+5RF2/7mMfxk4FPnpHI0ysFolm5jWFtpFs CAa1HPjzv/yk6fHM6aOv/CjJd0dKiCuGwH8tmy81T2yudk8LrMeeTVXrX4uMHlejGZLW t7ZQ== X-Gm-Message-State: AOAM531pvMByO9WO/gxUbT2m/S6+4OIoC8zllqpJxx+JvepUASVvYoUL U1O97rpqAePJgE5ariaPnqVn5ig6JHU+esuwSBg= X-Received: by 2002:aca:eb56:: with SMTP id j83mr14057671oih.110.1590483155441; Tue, 26 May 2020 01:52:35 -0700 (PDT) MIME-Version: 1.0 References: <5127441.yGvM1JjtLk@kreacher> In-Reply-To: From: "Rafael J. Wysocki" Date: Tue, 26 May 2020 10:52:23 +0200 Message-ID: Subject: Re: [PATCH] PM: runtime: clk: Fix clk_pm_runtime_get() error path To: Ulf Hansson Cc: "Rafael J. Wysocki" , Marek Szyprowski , "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 Mon, May 25, 2020 at 11:31 AM Ulf Hansson wrote: > > 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 Thanks! Given the lack of other comments, I'm applying this patch as 5.8 material.