All of lore.kernel.org
 help / color / mirror / Atom feed
From: Hans de Goede <hdegoede@redhat.com>
To: Pavel Machek <pavel@ucw.cz>
Cc: Jens Axboe <axboe@kernel.dk>, Dan Murphy <dmurphy@ti.com>,
	linux-ide@vger.kernel.org, linux-leds@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: 5.11 new lockdep warning related to led-class code (also may involve ata / piix controller)
Date: Thu, 28 Jan 2021 14:02:25 +0100	[thread overview]
Message-ID: <cc1cac99-e3de-9585-bfa0-db7b013e8a80@redhat.com> (raw)
In-Reply-To: <20210127220134.GC23419@amd>

Hi,

On 1/27/21 11:01 PM, Pavel Machek wrote:
> Hi!
> 
>>>>> Booting a 5.11-rc2 kernel with lockdep enabled inside a virtualbox vm (which still
>>>>> emulates good old piix ATA controllers) I get the below lockdep splat early on during boot:
>>>>>
>>>>> This seems to be led-class related but also seems to have a (P)ATA
>>>>> part to it. To the best of my knowledge this is a new problem in
>>>>> 5.11 .
>>>>
>>>> This is on my for-next branch:
>>>>
>>>> commit 9a5ad5c5b2d25508996f10ee6b428d5df91d9160 (HEAD -> for-next, origin/for-next)
>>>>
>>>>     leds: trigger: fix potential deadlock with libata
>>>>     
>>>>     We have the following potential deadlock condition:
>>>>     
>>>>      ========================================================
>>>>      WARNING: possible irq lock inversion dependency detected
>>>>      5.10.0-rc2+ #25 Not tainted
>>>>      --------------------------------------------------------
>>>>      swapper/3/0 just changed the state of lock:
>>>>      ffff8880063bd618 (&host->lock){-...}-{2:2}, at: ata_bmdma_interrupt+0x27/0x200
>>>>      but this lock took another, HARDIRQ-READ-unsafe lock in the past:
>>>>       (&trig->leddev_list_lock){.+.?}-{2:2}
>>>>
>>>> If I'm not mistaken, that should fix your issue.
>>>
>>> I can confirm that this fixes things, thanks.
>>>
>>> I assume that this will be part of some future 5.11 fixes pull-req?
>>
>> This *regression* fix seems to still have not landed in 5.11-rc5, can
>> we please get this on its way to Linus ?
> 
> Is it a regression? AFAIK it is a bug that has been there
> forever... My original plan was to simply wait for 5.12, so it gets
> full release of testing...

It may have been a pre-existing bug which got triggered by libata changes?

I don't know. I almost always run all my locally build kernels with lockdep
enabled and as the maintainer of the vboxvideo, vboxguest and vboxsf guest
drivers in the mainline kernel I quite often boot local build kernels inside
a vm.

So I believe that lockdep tripping over this is new in 5.11, which is why
I called it a regression.

And the fix seems very safe and simple, so IMHO it would be good to get
this into 5.11

Regards,

Hans


  reply	other threads:[~2021-01-28 13:04 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-12 21:18 5.11 new lockdep warning related to led-class code (also may involve ata / piix controller) Hans de Goede
2021-01-12 22:30 ` Pavel Machek
2021-01-13  8:59   ` Hans de Goede
2021-01-25 13:15     ` Hans de Goede
2021-01-27 22:01       ` Pavel Machek
2021-01-28 13:02         ` Hans de Goede [this message]
2021-02-02  9:32           ` Pavel Machek
2021-02-02 10:33             ` Hans de Goede

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=cc1cac99-e3de-9585-bfa0-db7b013e8a80@redhat.com \
    --to=hdegoede@redhat.com \
    --cc=axboe@kernel.dk \
    --cc=dmurphy@ti.com \
    --cc=linux-ide@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-leds@vger.kernel.org \
    --cc=pavel@ucw.cz \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.