linux-kernel - Re: BUG: Invalid wait context at: mc146818_avoid_UIP tick

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]

Message-ID: <463fbc29-b41f-4d2d-a869-108114000cdb@o2.pl>
Date: Thu, 26 Dec 2024 18:48:25 +0100
From: Mateusz Jończyk <mat.jonczyk@...pl>
To: Chris Bainbridge <chris.bainbridge@...il.com>, linux-rtc@...r.kernel.org
Cc: LKML <linux-kernel@...r.kernel.org>, alexandre.belloni@...tlin.com,
 Mario Limonciello <mario.limonciello@....com>
Subject: Re: BUG: Invalid wait context at: mc146818_avoid_UIP tick_freeze

W dniu 1.12.2024 o 18:05, Chris Bainbridge pisze:
> This splat happens on suspend/resume on a HP laptop. It doesn't appear
> to be a recent regression, as a bisect only leads to 560af5dc839e
> ("lockdep: Enable PROVE_RAW_LOCK_NESTING with PROVE_LOCKING.") - so
> most likely the issue has been around for a while, but a recent kernel
> build with lockdep enabled will now show it.

Hello,

Thank you for this bug report.

The cause is that timekeeping_suspend takes a raw spinlock called "tick_freeze_lock". With this lock taken, this function indirectly calls mc146818_avoid_UIP, which takes a normal spinlockcalled
"rtc_lock".

It is not permissible to take a normal spinlock while holding a raw spinlock due to issues on PREEMPT_RT kernels:

https://docs.kernel.org/locking/locktypes.html#raw-spinlock-t-on-rt

>From what I can see, this has been so for a very long time. I was able to trigger the bug on Linux 6.1.0 with CONFIG_PROVE_RAW_LOCK_NESTING enabled.

A solution to the problem would be to turn the rtc_lock into a raw spinlock. This requires that the critical section (during which the lock is held) is small. Reading full time from the RTC requires
in one critical section over 10 CMOS_READ invocations, writing full time - around 15 CMOS_READ/CMOS_WRITE invocations. This cannot really be broken down AFAIK - I hope that the critical section would
be small enough.

The rtc_lock is used on 7 architectures (mips, sparc64, powerpc, alpha, x86, arm, m68k/atari), so this will require a bit of work. I'll try and see what I'll be able to do.

Greetings & merry Christmas,

Mateusz