Received-SPF: softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) client-ip=23.128.96.19;
From:   Dmitry Rokosov <DDRokosov@sberdevices.ru>
To:     Jonathan Cameron <jic23@kernel.org>
CC:     "robh+dt@kernel.org" <robh+dt@kernel.org>,
        "lars@metafoo.de" <lars@metafoo.de>,
        "andy.shevchenko@gmail.com" <andy.shevchenko@gmail.com>,
        "noname.nuno@gmail.com" <noname.nuno@gmail.com>,
        "linux-iio@vger.kernel.org" <linux-iio@vger.kernel.org>,
        kernel <kernel@sberdevices.ru>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [RFC PATCH v1] iio: trigger: move trig->owner init to trigger
 allocate() stage
Thread-Topic: [RFC PATCH v1] iio: trigger: move trig->owner init to trigger
 allocate() stage
Thread-Index: AQHYdd/Pt2zXEFx7c0Or/RCut5+rEK0/GLKAgAL9JoA=
Date:   Mon, 6 Jun 2022 11:37:42 +0000
Message-ID: <20220606113829.kmiudrofm2s6onpc@CAB-WSD-L081021.sigma.sbrf.ru>
References: <20220601174837.20292-1-ddrokosov@sberdevices.ru>
 <20220604145955.2a1108ca@jic23-huawei>
In-Reply-To: <20220604145955.2a1108ca@jic23-huawei>
Accept-Language: ru-RU, en-US
Content-Language: en-US
Content-Type: text/plain; charset="us-ascii"
Content-ID: <6408C0C4B285DA44A2696A4DF252A12B@sberdevices.ru>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Precedence: bulk

Hello Jonathan,

Thank you for comments. I have a several questions about the flow,
please find them below.

On Sat, Jun 04, 2022 at 02:59:55PM +0100, Jonathan Cameron wrote:
> On Wed, 1 Jun 2022 17:48:32 +0000
> Dmitry Rokosov <DDRokosov@sberdevices.ru> wrote:
>=20
> > To provide a new IIO trigger to the IIO core, usually driver executes t=
he
> > following pipeline: allocate()/register()/get(). Before, IIO core assig=
ned
> > trig->owner as a pointer to the module which registered this trigger at
> > the register() stage. But actually the trigger object is owned by the
> > module earlier, on the allocate() stage, when trigger object is
> > successfully allocated for the driver.
> >=20
> > This patch moves trig->owner initialization from register()
> > stage of trigger initialization pipeline to allocate() stage to
> > eliminate all misunderstandings and time gaps between trigger object
> > creation and owner acquiring.
> >=20
> > Signed-off-by: Dmitry Rokosov <ddrokosov@sberdevices.ru>
>=20
> Hi Dmitry,
>=20
> I 'think' this is fine, but its in the high risk category that I'd like
> to keep it on list for a few weeks before applying.
>=20

Could you please explain what it means? Do you have some testing branch
with such dangerous patches or do we need just to wait other developers
for more points of view? Thanks in advance.

> Note I'm still keen that in general we keep the flow such that
> we do allocate()/register()/get() as there is no guarantee that the get()
> will never do anything that requires the trigger to be registered, even
> though that is true today.  Which is another way of saying I'm still
> keen we fix up any cases that sneak in after your fix up set dealt with
> the current ones.

I fully agree with you. I suppose to resolve such a problem we need to
have some indicators that the trigger is already registered or not.
From my point of view, trig->list entry fits well to answer this question.
Trigger is added to the global IIO triggers list during register()
execution, so we can just check that entry is not empty to make sure that
trigger is registered.

I've sent a v2 patch version, where I use trig->list entry empty status to
warn it:

https://lore.kernel.org/linux-iio/20220606111316.19265-1-ddrokosov@sberdevi=
ces.ru/

>=20
> Thanks for following up on this!
>=20
> Jonathan
>=20

--=20
Thank you,
Dmitry=