linux-kernel - Re: Re: [PATCH] media: vsp1: Fix runtime PM imbalance in vsp1

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20200608115457.GA5896@pendragon.ideasonboard.com>
Date:   Mon, 8 Jun 2020 14:54:57 +0300
From:   Laurent Pinchart <laurent.pinchart@...asonboard.com>
To:     Geert Uytterhoeven <geert@...ux-m68k.org>
Cc:     dinghao.liu@....edu.cn, Kangjie Lu <kjlu@....edu>,
        Kieran Bingham <kieran.bingham+renesas@...asonboard.com>,
        Mauro Carvalho Chehab <mchehab@...nel.org>,
        Linux Media Mailing List <linux-media@...r.kernel.org>,
        Linux-Renesas <linux-renesas-soc@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: Re: [PATCH] media: vsp1: Fix runtime PM imbalance in vsp1_probe

Hi Geert,

On Mon, Jun 08, 2020 at 09:39:51AM +0200, Geert Uytterhoeven wrote:
> Hi Dinghao,
> 
> On Mon, Jun 8, 2020 at 5:03 AM <dinghao.liu@....edu.cn> wrote:
> > > > I wonder how many bugs we have today, and how many bugs will keep
> > > > appearing in the future, due to this historical design mistake :-(
> >
> > Good question. It's hard to say if this is a design mistake (some use
> > of this API does not check its return value and expects it always to
> > increment the usage counter). But it does make developers misuse it easier.
> 
> On Renesas SoCs, I believe these can only fail if there's something
> seriously wrong, which means the system could never have gotten this far
> in the boot sequence anyway.  That's why I tend not to check the result
> of pm_runtime_get_sync() at all (on drivers for Renesas SoCs).

There are lots of return paths from rpm_resume() that return an error,
more than just rpm_callback(). Do you consider that none of them are
valid errors that drivers need to handle ?

-- 
Regards,

Laurent Pinchart