linux-kernel - Re: [PATCH] staging: vt6655: replace spin_lock_irqsave with spin

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:   Thu, 15 Sep 2022 19:14:10 +0200
From:   Nam Cao <namcaov@...il.com>
To:     Greg KH <gregkh@...uxfoundation.org>
Cc:     forest@...ttletooquiet.net, philipp.g.hortmann@...il.com,
        linux-kernel@...r.kernel.org, linux-staging@...ts.linux.dev
Subject: Re: [PATCH] staging: vt6655: replace spin_lock_irqsave with spin_lock

On Thu, Sep 15, 2022 at 10:44 AM Greg KH <gregkh@...uxfoundation.org> wrote:
>
> On Wed, Sep 14, 2022 at 10:00:17AM +0200, Nam Cao wrote:
> > In vt6655 driver, there is a single interrupt handler: vnt_interrupt(),
> > and it does not take the spinlock. The interrupt handler only schedules
> > a workqueue, and the spinlock is taken in this workqueue. Thus, there is
> > no need to use spin_lock_irqsave, as the spinlock is never taken by an
> > interrupt. Replace spin_lock_irqsave (and spin_unlock_irqsave) with
> > spin_lock (and spin_unlock).
>
> What is the speed difference before and after this change?  And how are
> interrupts properly handled anymore in this driver if you took away the
> lock that was being accessed in the irq?

My understanding is that no lock is accessed in the irq in this driver. But
it seems like I am wrong. Sorry for sending a buggy patch, I may follow-up with
this later when I figure out what I did wrong.

Best regards,
Nam.