linux-kernel - Re: [PATCH 08/22] gpiolib: cdev: complete the irq/thread timestamp handshake

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]

Date:   Wed, 24 Jun 2020 22:08:06 +0800
From:   Kent Gibson <warthog618@...il.com>
To:     Bartosz Golaszewski <bgolaszewski@...libre.com>
Cc:     LKML <linux-kernel@...r.kernel.org>,
        linux-gpio <linux-gpio@...r.kernel.org>,
        Linus Walleij <linus.walleij@...aro.org>
Subject: Re: [PATCH 08/22] gpiolib: cdev: complete the irq/thread timestamp
 handshake

On Wed, Jun 24, 2020 at 04:00:42PM +0200, Bartosz Golaszewski wrote:
> wt., 23 cze 2020 o 06:02 Kent Gibson <warthog618@...il.com> napisał(a):
> >
> > Reset the timestamp field to 0 after using it in lineevent_irq_thread.
> >
> > The timestamp is set by lineevent_irq_handler and is tested by
> > lineevent_irq_thread to determine if it is called from a nested theaded
> > interrupt.
> > lineevent_irq_thread is assuming that the nested, or otherwise, status
> > of the IRQ is static, i.e. it is either always nested or never nested.
> > This change removes that assumption, resetting the timestamp so it can
> > be re-used to determine the nested state of subsequent interrupts.
> >
> > Signed-off-by: Kent Gibson <warthog618@...il.com>
> >
> 
> This change makes sense to me but I'm having a hard time processing
> the explanation. If we're requesting the interrupt and allocating the
> lineevent state in the same function - how can we run into a situation
> here the status of the irq would change like what you describe?
> 

I'm not totally sure myself, as my understanding of how interrupts are
shared in the kernel is pretty sketchy, but my concern is that if we
are sharing the irq then whoever we are sharing with may release the irq
and we go from nested to unnested.  Or vice versa.  Not sure if that is
valid, but that was my concern, and it seemed like a minor change to
cover it just in case.

Cheers,
Kent.