linux-kernel - Re: [PATCH anybus v3 4/6] bus: support HMS Anybus-S bus

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: <CAGngYiXEsg-6MXK60s8gOq2d8LGq+USTk1FC3GYqy2TQheaxHg@mail.gmail.com>
Date:   Thu, 8 Nov 2018 10:47:20 -0500
From:   Sven Van Asbroeck <thesven73@...il.com>
To:     Arnd Bergmann <arnd@...db.de>
Cc:     Sven Van Asbroeck <svendev@...x.com>, robh+dt@...nel.org,
        Linus Walleij <linus.walleij@...aro.org>,
        Lee Jones <lee.jones@...aro.org>, mark.rutland@....com,
        Andreas Färber <afaerber@...e.de>,
        treding@...dia.com, David Lechner <david@...hnology.com>,
        noralf@...nnes.org, johan@...nel.org,
        Michal Simek <monstr@...str.eu>, michal.vokac@...ft.com,
        gregkh@...uxfoundation.org, john.garry@...wei.com,
        geert+renesas@...der.be, robin.murphy@....com,
        paul.gortmaker@...driver.com,
        sebastien.bourdelin@...oirfairelinux.com, icenowy@...c.io,
        Stuart Yoder <stuyoder@...il.com>, maxime.ripard@...tlin.com,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        devicetree <devicetree@...r.kernel.org>
Subject: Re: [PATCH anybus v3 4/6] bus: support HMS Anybus-S bus

On Thu, Nov 8, 2018 at 9:07 AM Arnd Bergmann <arnd@...db.de> wrote:
>
> It looks like you build your own object management here. Maybe
> use kobject, or at least kref instead of the refcount_t based
> low-level implementation?

Excellent point. I'll replace with krefs.

>
>
> I see this is called from the interrupt handler at the moment, which
> means you cannot call sleeping functions, but it also means that
> the timeout may never happen because the timer tick IRQ cannot
> get through. That means you may have to change the irq handler
> logic, e.g. to try this a few times but then defer to a bottom half
> if it fails for a long time.

Touche ! Yes, this is very likely a big problem.

What if I converted the interrupt handler into a threaded interrupt handler?
That would allow the timer tick to get through, correct?

Point taken about cpu_relax(), I will fix.