Received: by 2002:a05:6a10:a841:0:0:0:0 with SMTP id d1csp1200974pxy; Fri, 23 Apr 2021 02:44:22 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwalShkdcYNc1b6hONK6hCVPN5hR1Q2VnO92FOzmFebJ+R/jnGb9U3/Idom4hLXsCUlR0A5 X-Received: by 2002:a17:902:6b8c:b029:ea:f54f:c330 with SMTP id p12-20020a1709026b8cb02900eaf54fc330mr3196049plk.10.1619171062214; Fri, 23 Apr 2021 02:44:22 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1619171062; cv=none; d=google.com; s=arc-20160816; b=rhwXU93pO8dBCkHDswK+nfxxaNJ8OruKuB3DFEXDiumaiCyFOw2ywhk+QHumWt7wmU 6dmppkFA6ecJPwAFUydQW/xIA96a+ln2bHt2vGW3ivxWxPqlsP3jO/Ay/wddtnZhgKBB LsMe6X+/B3i59+bfdj/nT+tkH24yXvXY/4kkjKRnELyBCAFqV/o56UU15ctbqYiwwVsC 8vMXXh9belRvCGFNP3r62tig2GD75lkjULv278OkB/b/kuBiHR0AoCyvEY5pYxMLfHtu 3HwaV23wM+K4mL5Iq/Al54fLlZl9n/RZaHE9yya6kpoPpFAom2iEL8QSMeTr/iTsJ+RK Rlcw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:subject:cc:to:from:date :dkim-signature; bh=byMnrAUzwbluaT9SUdbpfqrPPZgI2pR8uJOzTrCzKEc=; b=svJcm9flB93xeDr6bg0VBqQ4K9HsZTUDuhHqYNqDezOkKD+aO0k550izQjppzDrNqa bUtPkLq+wsXIzk0TtZ0yUinTFvThDHR2NOUq8M0zs/MTubiH6AqP37r0RTc6JQSSNoXM VPaARI+SRgLa1QpXMfJGm74trh9wZlqXX+OjET9Gs6Ulvnf08NQEbVgb+k/oryZGiINm Ddr8DPlzPtXpY6MhwnjyTNUXy9l37QU2lT7b+0/637czpWXIH9beJ+AjJxWmJNyjTXlH XQwpiK/m7nKpU/h+xHSdPF4nPPB0OLeOPlpkWu4TzyTCVeYJ1/7SwKFK2TKmenY78XoP 7ALA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=T9j6vCTG; 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 z11si6230248plk.233.2021.04.23.02.44.09; Fri, 23 Apr 2021 02:44:22 -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=@kernel.org header.s=k20201202 header.b=T9j6vCTG; 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 S241859AbhDWJng (ORCPT + 99 others); Fri, 23 Apr 2021 05:43:36 -0400 Received: from mail.kernel.org ([198.145.29.99]:33120 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230418AbhDWJnf (ORCPT ); Fri, 23 Apr 2021 05:43:35 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id CD33461458; Fri, 23 Apr 2021 09:42:57 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1619170979; bh=ohNDdgyCEYPEiMXGQqQtgVLZH4NRJYTRwIqMUaOw+Kk=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=T9j6vCTGdxYLgrTRnzRw4yysUwhUqA3VTN81m/a2lwIGqTPBcww45JNr0dCInKBTR 1fSVVjoRZP2bGJrU5Wz5TQW6Ud7yEVmVGt5A9Eop5NYfGlnlmi7sz1KLNidROhg/fO hDUsllRIyvmjY6gN5xbhvKQ1JiJkJplkPwkkS16tP0CHZsFRhXu0cT79uTzsg5SQTW 3tBadEXxGr8vR93vevpD1/bDN9pht98zrzNdizU+l3E62t09m7YbQhYwtXwdhgrPcr ye6taQ19vHiKwoaZacQOeAZxZubxg5FXuYh+2AlLV7k8RmR4oIYglNiT8gOQg9h9T1 IQltg7a8+c64g== Date: Fri, 23 Apr 2021 11:42:55 +0200 From: Mauro Carvalho Chehab To: Julia Lawall Cc: Krzysztof Kozlowski , Hans Verkuil , Greg Kroah-Hartman , linux-kernel@vger.kernel.org, "Rafael J. Wysocki" Subject: Re: [PATCH 009/190] Revert "media: s5p-mfc: Fix a reference count leak" Message-ID: <20210423114241.29cf1ab3@coco.lan> In-Reply-To: References: <20210421130105.1226686-1-gregkh@linuxfoundation.org> <20210421130105.1226686-10-gregkh@linuxfoundation.org> <20210423100727.5a999c2e@coco.lan> <02966f20-342d-cf21-8216-d364b67753b7@xs4all.nl> X-Mailer: Claws Mail 3.17.8 (GTK+ 2.24.33; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org (adding c/c to Rafael) Em Fri, 23 Apr 2021 10:41:32 +0200 (CEST) Julia Lawall escreveu: > On Fri, 23 Apr 2021, Krzysztof Kozlowski wrote: > > > On 23/04/2021 10:10, Hans Verkuil wrote: > > > On 23/04/2021 10:07, Mauro Carvalho Chehab wrote: > > >> Em Fri, 23 Apr 2021 09:10:32 +0200 > > >> Greg Kroah-Hartman escreveu: > > >> > > >>> On Fri, Apr 23, 2021 at 09:04:27AM +0200, Krzysztof Kozlowski wrote: > > >>>> On 21/04/2021 14:58, Greg Kroah-Hartman wrote: > > >>>>> This reverts commit 78741ce98c2e36188e2343434406b0e0bc50b0e7. > > >>>>> > > >>>>> Commits from @umn.edu addresses have been found to be submitted in "bad > > >>>>> faith" to try to test the kernel community's ability to review "known > > >>>>> malicious" changes. The result of these submissions can be found in a > > >>>>> paper published at the 42nd IEEE Symposium on Security and Privacy > > >>>>> entitled, "Open Source Insecurity: Stealthily Introducing > > >>>>> Vulnerabilities via Hypocrite Commits" written by Qiushi Wu (University > > >>>>> of Minnesota) and Kangjie Lu (University of Minnesota). > > >>>>> > > >>>>> Because of this, all submissions from this group must be reverted from > > >>>>> the kernel tree and will need to be re-reviewed again to determine if > > >>>>> they actually are a valid fix. Until that work is complete, remove this > > >>>>> change to ensure that no problems are being introduced into the > > >>>>> codebase. > > >>>>> > > >>>>> Cc: Qiushi Wu > > >>>>> Cc: Hans Verkuil > > >>>>> Cc: Mauro Carvalho Chehab > > >>>>> Signed-off-by: Greg Kroah-Hartman > > >>>>> --- > > >>>>> drivers/media/platform/s5p-mfc/s5p_mfc_pm.c | 4 +--- > > >>>>> 1 file changed, 1 insertion(+), 3 deletions(-) > > >>>>> > > >>>> > > >>>> This looks like a good commit but should be done now in a different way > > >>>> - using pm_runtime_resume_and_get(). Therefore I am fine with revert > > >>>> and I can submit later better fix. > > >>> > > >>> Great, thanks for letting me know, I can have someone work on the > > >>> "better fix" at the same time. > > >> > > >> IMO, it is better to keep the fix. I mean, there's no reason to > > >> revert a fix that it is known to be good. > > >> > > >> The "better fix" patch can be produced anytime. A simple coccinelle > > >> ruleset can replace patterns like: > > >> > > >> ret = pm_runtime_get_sync(pm->device); > > >> if (ret < 0) { > > >> pm_runtime_put_noidle(pm->device); > > >> return ret; > > >> } > > >> > > >> and the broken pattern: > > >> > > >> ret = pm_runtime_get_sync(pm->device); > > >> if (ret < 0) > > >> return ret; > > >> > > >> to: > > >> > > >> ret = pm_runtime_resume_and_get(pm->device); > > >> if (ret < 0) > > >> return ret; > > > > > > That's my preference as well. > > > > It won't be that easy because sometimes the error handling is via goto > > (like in other patches here) but anyway I don't mind keeping the > > original commits. > > I tried the following semantic patch: > > @@ > expression ret,e; > @@ > > - ret = pm_runtime_get_sync(e); > + ret = pm_resume_and_get(e); > if (ret < 0) { > ... > ?- pm_runtime_put_noidle(e); > ... > return ret; > } > > It has the following features: > > * The ? means that if pm_runtime_put_noidle is absent, the transformation > will happen anyway. > > * The ... before the return means that the matching will jump over a goto. > > It makes a lot of changes (in a kernel I had handy from March). I would expect lots of changes, as the pm_runtime_resume_and_get() was only recently introduced on this changeset: commit dd8088d5a8969dc2b42f71d7bc01c25c61a78066 Author: Zhang Qilong Date: Tue Nov 10 17:29:32 2020 +0800 PM: runtime: Add pm_runtime_resume_and_get to deal with usage counter In many case, we need to check return value of pm_runtime_get_sync, but it brings a trouble to the usage counter processing. Many callers forget to decrease the usage counter when it failed, which could resulted in reference leak. It has been discussed a lot[0][1]. So we add a function to deal with the usage counter for better coding. [0]https://lkml.org/lkml/2020/6/14/88 [1]https://patchwork.ozlabs.org/project/linux-tegra/list/?series=178139 Signed-off-by: Zhang Qilong Acked-by: Rafael J. Wysocki Signed-off-by: Jakub Kicinski > This is a > complicated API, however, and I don't know if there are any other issues > to take into account, especially in the case where the call to > pm_runtime_put_noidle is not present. I double-checked the code, despite its name, pm_runtime_put_noidle() just changes the refcount. See, the relevant code is here: static inline void pm_runtime_put_noidle(struct device *dev) { atomic_add_unless(&dev->power.usage_count, -1, 0); } static inline int pm_runtime_get_sync(struct device *dev) { return __pm_runtime_resume(dev, RPM_GET_PUT); } int __pm_runtime_resume(struct device *dev, int rpmflags) { unsigned long flags; int retval; might_sleep_if(!(rpmflags & RPM_ASYNC) && !dev->power.irq_safe && dev->power.runtime_status != RPM_ACTIVE); if (rpmflags & RPM_GET_PUT) atomic_inc(&dev->power.usage_count); spin_lock_irqsave(&dev->power.lock, flags); retval = rpm_resume(dev, rpmflags); spin_unlock_irqrestore(&dev->power.lock, flags); return retval; } Not being an expert at the PM runtime API, at least on my eyes, replacing pm_runtime_get_sync() by pm_runtime_resume_and_get() seems to be the right thing to do, but Rafael should know more. Thanks, Mauro