03:22 <palmer> FWIW: when we merged the RISC-V stuff we the uABI bits before we took a lot of other stuff, though not entirely sure that was a good idea because everything was broken for quite a while

13:59 <arnd> ardb: I checked how __current is accessed in Yegor's kernel build: musb is a loadable module, but only uses __current in tracepoints to record current->cpu, but that should all be disabled at runtime. the usb-serial driver has an ioctl that uses copy_to_user() and needs to look up current_thread_info()->cpu_domain.

13:59 <arnd> I don't think it's that either

13:59 <ardb> arnd: yeah i don't think that matters in particular, but it's something i wanted to check

14:00 <arnd> the CAN networking code uses rcu_read_lock(), which modifies current->preempt_count

14:00 <arnd> if that gets out of sync, I can imaging observing an RCU stall

14:00 <ardb> my current hypothesis is that the larger size of the asm() block in get_current() when v6+SMP is enabled results in different behavior in GCC when it comes to spilling vs reloading the value of current

14:01 <ardb> and we may end up using a stale value of current somewher

14:01 <arnd> the preempt count is also modified in softirqs, which is how the dmaengine code may factor in

14:01 <ardb> hence the suggestion to add the dummy asm constraint

14:02 <ardb> only his config does not enable PREEMPT afaict

14:02 <arnd> CONFIG_PREEMPT_NONE=y

14:03 <arnd> right, but there is still CONFIG_PREEMPT_COUNT=y

14:03 <arnd> Selected by [y]: PROVE_LOCKING [=y] && DEBUG_KERNEL [=y] && LOCK_DEBUGGING_SUPPORT [=y] && !ARCH_NO_PREEMPT [=n]

14:03 <ardb> ah ok

14:03 <arnd> lockdep is also what turns on the tracepoints in the musb code

14:37 <arnd> ardb: here is a theory: one broken get_current() makes current->preempt_count gets out of sync, so softirqs remain disabled in the idle task, and the rcu timer never gets scheduled. After 2.6 seconds, some timeout hits in cpufreq, which wakes up the workqueue thread to changes. In the middle of that worker, the timer tick hits the next time, and the softirq finally wakes up, noticing the stall

14:39 <ardb> arnd: could be