linux-kernel - Re: [RFC PATCH v4 7/8] pwm: Add dummy pwmchip for orphan pwms

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]

Message-ID: <CAKdAkRRm9aK3KmPTqtD0d1dENyAq7aXrSEjKXZQMXuJin2hoUA@mail.gmail.com>
Date:   Tue, 17 Oct 2017 11:24:24 -0700
From:   Dmitry Torokhov <dmitry.torokhov@...il.com>
To:     Brian Norris <briannorris@...omium.org>
Cc:     Thierry Reding <thierry.reding@...il.com>,
        Jeffy Chen <jeffy.chen@...k-chips.com>,
        lkml <linux-kernel@...r.kernel.org>,
        Heiko Stübner <heiko@...ech.de>,
        "Rafael J. Wysocki" <rjw@...ysocki.net>,
        Doug Anderson <dianders@...omium.org>, tfiga@...omium.org,
        Mark Brown <broonie@...nel.org>, seanpaul@...omium.org,
        "linux-pwm@...r.kernel.org" <linux-pwm@...r.kernel.org>
Subject: Re: [RFC PATCH v4 7/8] pwm: Add dummy pwmchip for orphan pwms

On Tue, Oct 17, 2017 at 10:04 AM, Brian Norris <briannorris@...omium.org> wrote:
> Hi,
>
> On Tue, Oct 17, 2017 at 02:40:31PM +0200, Thierry Reding wrote:
>> On Tue, Oct 17, 2017 at 06:16:23PM +0800, Jeffy Chen wrote:
>> > When the pwm driver is unbound while the pwm is still requested, the
>> > pwm core would not actually remove the pwmchip(return -EBUSY instead).
>> >
>> > So it would hold some references to the invalid resources(e.g. pwmchip).
>> >
>> > And the customer who requested the pwm would have those references too,
>> > and may crash the kernel when trying to access them later.
>> >
>> > Add a dummy pwmchip, and assign orphan pwms to it to avoid that.
>> >
>> > Signed-off-by: Jeffy Chen <jeffy.chen@...k-chips.com>
>> > ---
>> >
>> > Changes in v4:
>> > Fix compile warning.
>> >
>> > Changes in v3:
>> > Assign orphan pwms to dummy pwmchip instead of adding device link in the
>> > customer driver.
>>
>> What happened to this? Device links were specifically designed to avoid
>> situations like these.
>
> I think Jeffy came up with this as an odd response to my suggestion on
> v2 that we could just handle the device links in the PWM core. I don't
> fully understand why the complete change in direction...
>
> BTW, since you seem to have an opinion about device links: is it
> expected that all consumer drivers will make explicit calls to
> device_link_add()? I thought this should be avoided, if possible (e.g.,
> this can be handled in pwm_get()).

Ideally we would not have this in core kernel API (pwm_get, gpiod_get,
regulator_get, etc) but retrieve it form the firmware (device tree,
ACPI) and use this data not only on suspend/resume but for probing as
well. *How exactly* can we do that is still not clear though, so maybe
we could plug the biggest holes by actually adding device links calls
to the main devm_<object>_get() users...

Thanks.

-- 
Dmitry