linux-kernel - Re: [PATCH v1 2/3] iio: add MEMSensing MSA311 3-axis accelerometer driver

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]

Date:   Wed, 25 May 2022 17:53:11 +0000
From:   Dmitry Rokosov <DDRokosov@...rdevices.ru>
To:     Jonathan Cameron <jic23@...nel.org>
CC:     Jonathan Cameron <Jonathan.Cameron@...wei.com>,
        "robh+dt@...nel.org" <robh+dt@...nel.org>,
        "stano.jakubek@...il.com" <stano.jakubek@...il.com>,
        "shawnguo@...nel.org" <shawnguo@...nel.org>,
        "lars@...afoo.de" <lars@...afoo.de>,
        "andy.shevchenko@...il.com" <andy.shevchenko@...il.com>,
        "stephan@...hold.net" <stephan@...hold.net>,
        "linux-iio@...r.kernel.org" <linux-iio@...r.kernel.org>,
        "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
        kernel <kernel@...rdevices.ru>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v1 2/3] iio: add MEMSensing MSA311 3-axis accelerometer
 driver

On Sun, May 22, 2022 at 11:36:54AM +0100, Jonathan Cameron wrote:
> > Syscall delete_module() tries to stop module first and after calls
> > driver exit() function (which executes devm_* handlers inside, including IIO
> > trigger unregister). It means we have the chicken or the egg dilemma here.
> > Module can't be unloaded until module refcnt is not zero and we can't
> > execute IIO trigger unregister (decrease module refcnt) only when module
> > refcnt is zero.
> > I suppose the possible solution to such a problem is a different semantic
> > for internal triggers (inside driver itself) and external drivers (like
> > hwtimer trigger). What do you think?
> 
> Potentially though it's going to be tricky as a driver doesn't generally
> have any way to know they are internal and we need to be careful not to
> underflow the reference counts.  We could hid a flag somewhere and
> add an iio_trigger_get_same_owner() or something that sets that flag allowing
> us to decide not to drop the reference count it if is automatically unassociated.
> In the path where you get:
> 1) iio_trigger_get_same_owner() on probe
> 2) sysfs write changes to another trigger.
> 3) sysfs write back to original trigger
> it is reasonable to assume the need to clear the trigger
> before driver removal is possible, whereas clearing the trigger association
> if only step 1 happened is no intuitive.

I will try to prepare the rfc patch if you don't mind. I propose to
continue further discussion there.

> 
> > 
> > The second one issue is located in the different IIO drivers. Some modules
> > call iio_trigger_get() before iio_trigger_register(), trig->owner is not
> > initialized to the right value (THIS_MODULE) and we don't acquire refcnt
> > for proper driver object.
> 
> Ah. Good point. I guess we missed that when we were moving over to
> automated setting of the module.
> 

Already submitted v2 patchset here:
https://lore.kernel.org/linux-iio/20220524181150.9240-1-ddrokosov@sberdevices.ru/

-- 
Thank you,
Dmitry