linux-kernel - Re: [ BUG: Invalid wait context ] rtc_lock at: mc146818_avoid

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: <87sempv17b.ffs@tglx>
Date: Thu, 03 Apr 2025 15:12:08 +0200
From: Thomas Gleixner <tglx@...utronix.de>
To: Borislav Petkov <bp@...en8.de>, linux-rtc@...r.kernel.org, Alexandre
 Belloni <alexandre.belloni@...tlin.com>, Mateusz Jończyk
 <mat.jonczyk@...pl>
Cc: lkml <linux-kernel@...r.kernel.org>, Anna-Maria Behnsen
 <anna-maria@...utronix.de>, Frederic Weisbecker <frederic@...nel.org>,
 Peter Zijlstra <peterz@...radead.org>, Sebastian Andrzej Siewior
 <bigeasy@...utronix.de>
Subject: Re: [ BUG: Invalid wait context ] rtc_lock at: mc146818_avoid_UIP

On Sun, Mar 30 2025 at 13:32, Borislav Petkov wrote:
> while playing with suspend to RAM, I got this lockdep splat below.
>
> Poking around I found:
>
> ec5895c0f2d8 ("rtc: mc146818-lib: extract mc146818_avoid_UIP")
>
> which is doing this funky taking and dropping the rtc_lock and I guess that's
> inherited from ye olde times.
>
> I "fixed" it so lockdeup doesn't warn by converting rtc_lock to a raw spinlock
> but this is definitely not the right fix so let me bounce it off to the folks
> on Cc who might have a better idea perhaps...

Converting it to a raw lock "fixes" the problem, but RT people will hunt
you down with a big latency bat.

But this is not related to the commit above and not new.

timekeeping_suspend() has always invoked mach_get_cmos_time() with the
freeze lock held and mc146818_get_time() has always locked rtc_lock.

I wonder, why this splat hasn't popped before. On RT lockdep should have
complained forever. Sebastian???

Suspend, whether it's suspend to idle or regular suspend, are weird
contexts as there is no concurrency possible because interrupts are
disabled and it is guaranteed that there is only a single CPU which is
operational. The other CPUs are either in a deep idle state or when they
are on the way back, they serialize on tick_freeze_lock.

So taking the non-raw spinlock in that context is safe, but obviously
lockdep does not know about that.

Peter, any ideas?

Thanks,

        tglx