linux-kernel - Re: [PATCH] gpio: gpiolib-cdev: Fix potential &lr->wait.lock deadlock issue

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: <27E80FC7-7B66-4C05-9D16-690457BFE0B9@connect.ust.hk>
Date:   Mon, 26 Jun 2023 16:51:30 +0000
From:   YE Chengfeng <cyeaa@...nect.ust.hk>
To:     Bartosz Golaszewski <brgl@...ev.pl>
CC:     Kent Gibson <warthog618@...il.com>,
        "linus.walleij@...aro.org" <linus.walleij@...aro.org>,
        "andy@...nel.org" <andy@...nel.org>,
        "linux-gpio@...r.kernel.org" <linux-gpio@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] gpio: gpiolib-cdev: Fix potential &lr->wait.lock deadlock
 issue

> Yeah, I'm not sure this is correct. edge_irq_thread() runs in process
> 
> context, so the whole premise of the patch seems to be flawed. What
> tool reported this? Can this be a false positive? Have you seen this
> 
> happen in real life?

It seems like it’s my mistake, I misidentify thread_irq as runing inside
irq context. Then it’s truth that the patch is unnecessary.

The static analysis tool is built by me, I noticed lockdep occasionally reports
such similar deadlocks in other place thus intent to build a static tool to locate
such bugs. It has detected other true bugs these days but it’s a pity this
one is really a false positive.

Indeed thanks so much for your time and sorry for bothering you with the false report.

Thanks again,
Chengfeng