Re: [ BUG: Invalid wait context ] rtc_lock at: mc146818_avoid_UIP

[Mateusz Jończyk]

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@xxxxx/

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).
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