linux-kernel - Re: [PATCH] spi: Fix spi device unregister flow

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAGETcx-eyP4vLn+qMN4nxMJg_0uAjP1YJqko86CivizSEf817Q@mail.gmail.com>
Date:   Tue, 27 Apr 2021 08:02:30 -0700
From:   Saravana Kannan <saravanak@...gle.com>
To:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc:     Andy Shevchenko <andy.shevchenko@...il.com>,
        Mark Brown <broonie@...nel.org>,
        Lukas Wunner <lukas@...ner.de>,
        "Rafael J. Wysocki" <rafael@...nel.org>,
        Guenter Roeck <linux@...ck-us.net>,
        Marek Szyprowski <m.szyprowski@...sung.com>,
        Android Kernel Team <kernel-team@...roid.com>,
        linux-spi <linux-spi@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] spi: Fix spi device unregister flow

On Tue, Apr 27, 2021 at 4:49 AM Greg Kroah-Hartman
<gregkh@...uxfoundation.org> wrote:
>
> On Tue, Apr 27, 2021 at 02:42:19PM +0300, Andy Shevchenko wrote:
> > On Tue, Apr 27, 2021 at 1:49 PM Mark Brown <broonie@...nel.org> wrote:
> > >
> > > On Tue, Apr 27, 2021 at 09:52:48AM +0300, Andy Shevchenko wrote:
> > > > +Cc Lukas
> > >
> > > The cleanup callback has been in release() since the framework was
> > > merged AFAICT.
> >
> > Yep.
> >
> > Personally it feels to me wrong to require device_release() being
> > atomic. It might be that I missed something in documentation or
> > somewhere else that suggests the opposite.
> > But let's wait for other comments if any.
>
> There is no requirement from the driver core to have the release
> callback be "atomic", you should be able to sleep just fine in there.
>
> If not, something is wrong and has changed...

This patch is not just about the atomic thing though. I can drop that
from the commit text and I think this still fixes a real issue.
Calling code from another driver (not even the device's own driver)
during a device's release is not guaranteed to work at all (what if
the module gets unloaded?). And this patch also fixes some mismatched
setup/cleanup calls. Using device release for the cleanup() isn't
necessary and we can avoid this bug. This patch tries to fix that too.

As for the atomic thing, that seems to be a generic device link SRCU
implementation issue. It does a put_device() in an atomic context. I'm
not too familiar with the SRCU implementation or why it was needed.
Rafael would have a better idea on that. I can drop that part from the
commit text and move the atomic discussion back to Andy's "atomic
context" thread[1].

-Saravana