From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) (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 794732F9B for ; Thu, 22 Apr 2021 13:33:56 +0000 (UTC) Received: by mail.kernel.org (Postfix) with ESMTPSA id 4314D6145B; Thu, 22 Apr 2021 13:33:53 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1619098436; bh=oISFEoZqMsjdaQDjlNExGCcoiqE5j8Cbe0igLU0p9Q0=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=sw8wbVib5p/U0VKOwx5EIhRTYJQ8e2MMLar+q0WN6Rka5TQjuLzXYbSnV9sOPP7xo G0FazoGwVXoAe1ESa1fPKisHIqpfsawt9GW7336JIODEmzr6Z/odM2fDI4lfYgJFJq LEMh7uIcxT1XYvwsWyYD3gS7CLifVnc4i29me1e3W/GZwgzQV5tXvqJD4edcRheOR3 v/AgajSHE7EUWRwMK+RYQcy6VUKXohUXCo05Ns9CrhyFiR9ena3NFkyXNl1q09lA/u fDiq5ccM5cgWUv+SuQWDVkrKIW4KLgDEUnJUKM5/PTFHq3pbc5ttZFwI6WZqbbijiq lsJfB7enH7ETw== Date: Thu, 22 Apr 2021 15:33:49 +0200 From: Mauro Carvalho Chehab To: Leon Romanovsky Cc: Mark Brown , Geert Uytterhoeven , James Morris , Julia Lawall , Stephen Hemminger , Roland Dreier , Steven Rostedt , James Bottomley , ksummit@lists.linux.dev Subject: Re: [MAINTAINER SUMMIT] Rethinking the acceptance policy for "trivial" patches Message-ID: <20210422153349.650f13b7@coco.lan> In-Reply-To: References: <20210421152209.68075314@gandalf.local.home> <20210421132824.13a70f6c@hermes.local> <20210422115511.60d1f735@coco.lan> <20210422122604.GC4572@sirena.org.uk> X-Mailer: Claws Mail 3.17.8 (GTK+ 2.24.33; x86_64-redhat-linux-gnu) X-Mailing-List: ksummit@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Em Thu, 22 Apr 2021 15:35:11 +0300 Leon Romanovsky escreveu: > On Thu, Apr 22, 2021 at 01:26:04PM +0100, Mark Brown wrote: > > On Thu, Apr 22, 2021 at 03:01:39PM +0300, Leon Romanovsky wrote: > > > On Thu, Apr 22, 2021 at 11:55:11AM +0200, Mauro Carvalho Chehab wrote: > > > > > > The reverted ones for media (29 patches) didn't contain any malicious code. > > > > One was useless (because the media core already fixes the pointed issue), > > > > but the other ones were valid patches. > > > > > And didn't you ask yourself after seeing same 29 patches that the > > > correct fix should be in another place? pm_runtime_get_sync? > > > > The runtime PM APIs are for legitimate reasons really fiddly to get > > right - there's a bunch of different ways to do things and disabling > > runtime PM in Kconfig can cause surprises. It's been identified as an > > issue for years but it's really not trivial to address it at the API > > level. > > There is no need to fix all problems at once, but seeing same mistake > over and over like in commit 57cc666d36ad ("media: st-delta: Fix reference > count leak in delta_run_work") can be fixed very easily (+grep all source > code to remove extra put): > > diff --git a/drivers/base/power/runtime.c b/drivers/base/power/runtime.c > index 18b82427d0cb..d73c967ddb80 100644 > --- a/drivers/base/power/runtime.c > +++ b/drivers/base/power/runtime.c > @@ -1089,6 +1089,9 @@ int __pm_runtime_resume(struct device *dev, int rpmflags) > retval = rpm_resume(dev, rpmflags); > spin_unlock_irqrestore(&dev->power.lock, flags); > > + if (retval && rpmflags & RPM_GET_PUT) > + atomic_dec(&dev->power.usage_count); > + > return retval; > } > EXPORT_SYMBOL_GPL(__pm_runtime_resume); This would break existing code that would try to do a _put_ themselves. > A new function was created that does the correct cleanup: > pm_runtime_resume_and_get(). > > But these patches predate that addition. Yeah, a patch changing the logic to use pm_runtime_resume_and_get() would equally solve, but, as Hans pointed, this new function is brand new: 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 Thanks, Mauro