linux-kernel - Re: [PATCH] staging: most: dim2: fix device registration

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: <YVxcCpuz9C6XpEex@kroah.com>
Date:   Tue, 5 Oct 2021 16:07:06 +0200
From:   Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To:     Nikita Yushchenko <nikita.yoush@...entembedded.com>
Cc:     Lee Jones <lee.jones@...aro.org>, linux-staging@...ts.linux.dev,
        linux-kernel@...r.kernel.org,
        Christian Gromm <christian.gromm@...rochip.com>
Subject: Re: [PATCH] staging: most: dim2: fix device registration

On Tue, Oct 05, 2021 at 03:49:09PM +0200, Greg Kroah-Hartman wrote:
> On Tue, Oct 05, 2021 at 04:33:02PM +0300, Nikita Yushchenko wrote:
> > > > Commit 723de0f9171e ("staging: most: remove device from interface
> > > > structure") moved registration of driver-provided struct device to
> > > > the most subsystem, but did not properly update dim2 driver to
> > > > work with that change.
> > > > 
> > > > After most subsystem passes driver's dev to register_device(), it
> > > > becomes refcounted, and can be only deallocated in the release method.
> > > > Provide that by:
> > > > - not using devres to allocate the device,
> > > > - moving shutdown actions from _remove() to the device release method,
> > > > - not calling shutdown actions in _probe() after the device becomes
> > > >    refcounted.
> > > 
> > > Should this be 3 patches?
> > 
> > But these three items are deeply interconnected, and fix the issue together.
> > Must not manually free device structure passed to register_device(), thus
> > must not allocate via devres (because otherwise, devres will free it). Once
> > not using devres for it, must deallocate it somehow else, thus must rework
> > the release paths.
> 
> Ok, but that was obvious.

That was *not* obvious.