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] [thread-next>] [day] [month] [year] [list]
Date:   Tue, 1 Sep 2020 15:15:33 +0530
From:   Rajendra Nayak <rnayak@...eaurora.org>
To:     Viresh Kumar <viresh.kumar@...aro.org>
Cc:     Rob Clark <robdclark@...il.com>, Sean Paul <sean@...rly.run>,
        linux-pm@...r.kernel.org,
        Vincent Guittot <vincent.guittot@...aro.org>,
        Rafael Wysocki <rjw@...ysocki.net>,
        Stephen Boyd <sboyd@...nel.org>, Nishanth Menon <nm@...com>,
        Douglas Anderson <dianders@...omium.org>,
        Naresh Kamboju <naresh.kamboju@...aro.org>,
        linux-arm-msm@...r.kernel.org, dri-devel@...ts.freedesktop.org,
        freedreno@...ts.freedesktop.org, linux-kernel@...r.kernel.org,
        saiprakash.ranjan@...eaurora.org
Subject: Re: [PATCH V2 3/8] drm/msm: Unconditionally call
 dev_pm_opp_of_remove_table()


On 9/1/2020 2:08 PM, Viresh Kumar wrote:
> On 01-09-20, 13:01, Rajendra Nayak wrote:
>> So FWIU, dpu_unbind() gets called even when dpu_bind() fails for some reason.
> 
> Ahh, I see.
> 
>> I tried to address that earlier [1] which I realized did not land.
> 
> I don't think that patch was required, as you can call
> dev_pm_opp_put_clkname() multiple times and it will return without any
> errors/crash.

We did see a crash (Sai had reported it), perhaps with dsi [1] and not this
driver. But it was the same scenario that was possible here as well, which is
dev_pm_opp_put_clkname() getting called without dev_pm_opp_set_clkname()
being done. I think we ended up passing a NULL as opp_table in that case
and the function tries de-referencing it.

> 
>> But with these changes
>> it will be even more broken unless we identify if we failed dpu_bind() before
>> adding the OPP table, while adding it, or all went well with opps and handle things
>> accordingly in dpu_unbind.
> 
> Maybe not as dev_pm_opp_of_remove_table() can be called multiple times
> as well without any errors or crash.

Can it be called without the driver ever doing a dev_pm_opp_of_add_table()?

[1] https://lore.kernel.org/patchwork/patch/1275628/
-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ