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: <45cee3c7-e1b2-4058-bc81-c6eb5935fad0@o2.pl>
Date: Sun, 30 Mar 2025 14:32:19 +0200
From: Mateusz Jończyk <mat.jonczyk@...pl>
To: Borislav Petkov <bp@...en8.de>, linux-rtc@...r.kernel.org,
 Alexandre Belloni <alexandre.belloni@...tlin.com>
Cc: lkml <linux-kernel@...r.kernel.org>,
 Anna-Maria Behnsen <anna-maria@...utronix.de>,
 Frederic Weisbecker <frederic@...nel.org>,
 Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [ BUG: Invalid wait context ] rtc_lock at: mc146818_avoid_UIP

W dniu 30.03.2025 o 14:23, Mateusz Jończyk pisze:
> W dniu 30.03.2025 o 13:32, Borislav Petkov pisze:
>> So,
>>
>> 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...
>>
>> Thx.
>
> Hello,
>
> This problem has been reported before, see
>
> https://lore.kernel.org/all/463fbc29-b41f-4d2d-a869-108114000cdb@o2.pl/
>
> I started work on converting rtc_lock to a raw spinlock, but got stuck 
> mostly to a lack
> of time etc. Only did some MIPS patches (unpublished).
>
> The problem is that timekeeping_suspend() takes a raw spinlock called 
> "tk_core.lock".
> With this lock taken, this function indirectly calls 
> mc146818_avoid_UIP(), which takes
> a normal spinlock called "rtc_lock". It is necessary to take the 
> rtc_lock while accessing
> the RTC: the RTC access cycle consists of writing to an index register 
> and then accessing
> the data register. If something else touches the index register in the 
> middle, we get garbage.
>
> During a RTC tick, the RTC date/time registers are in an unspecified 
> state - roughly during this
> time the UIP (Update In Progress) bit in an RTC register A is set. 
> This is handled by
> mc146818_avoid_UIP(). This function takes and releases the rtc_lock 
> multiple times,
> in order not to hold it for too long a time (while sleeping).

I meant "while waiting / while calling udelay()". mc146818_avoid_UIP() 
does not sleep.

> But the rtc_lock does need to be taken anyway.
>
> So the solutions would be:
>
> 1. Change the rtc_lock to a raw spinlock.
>
> 2. Change the tick_freeze_lock to a normal spinlock (if possible).
>
> 3. Possibly rewrite mc146818_avoid_UIP to avoid taking the rtc_lock if 
> the tick_freeze_lock is held (likely ugly).
>
> 4. Maybe something else I haven't thought about.
>
> Thanks,
>
> Mateusz

Greetings,

Mateusz