lkml.org 
[lkml]   [2021]   [Feb]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [Linuxarm] Re: [PATCH for next v1 0/2] gpio: few clean up patches to replace spin_lock_irqsave with spin_lock
On Wed, Feb 10, 2021 at 11:50:45AM +0000, Song Bao Hua (Barry Song) wrote:
> > -----Original Message-----
> > From: Andy Shevchenko [mailto:andy.shevchenko@gmail.com]
> > Sent: Wednesday, February 10, 2021 11:51 PM
> > On Wed, Feb 10, 2021 at 5:43 AM luojiaxing <luojiaxing@huawei.com> wrote:
> > > On 2021/2/9 17:42, Andy Shevchenko wrote:

...

> > > Between IRQ handler A and IRQ handle A, it's no need for a SLIS.
> >
> > Right, but it's not the case in the patches you provided.
>
> The code still holds spin_lock. So if two cpus call same IRQ handler,
> spin_lock makes them spin; and if interrupts are threaded, spin_lock
> makes two threads run the same handler one by one.

If you run on an SMP system and it happens that spin_lock_irqsave() just
immediately after spin_unlock(), you will get into the troubles. Am I mistaken?

I think this entire activity is a carefully crafted mine field for the future
syzcaller and fuzzers alike. I don't believe there are no side effects in a long
term on all possible systems and configurations (including forced threaded IRQ
handlers).

I would love to see a better explanation in the commit message of such patches
which makes it clear that there are *no* side effects.

For time being, NAK to the all patches of this kind.

--
With Best Regards,
Andy Shevchenko


\
 
 \ /
  Last update: 2021-02-10 15:59    [W:0.238 / U:0.128 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site