Hello, Thank you for your comment! > > - if (system_state == SYSTEM_RUNNING) > > + if (system_state > SYSTEM_BOOTING) > > > > This avoids the problem by enabling IRQ after SYSTEM_SCHEULDING. > > Yes. Once scheduling is enabled any sleeping lock might be contended so > interrupts must be enabled. This is not done done unconditionally > because early boot code expects to run with disabled interrupts. > This "system_state == SYSTEM_RUNNING" looked like a sane state in > between. However, once the scheduler is up and running, interrupts in > the system are enabled and so the slub allocator needs to always enable > interrupts. Appreciate sharing the background. This is helpful to understand what was happening around v4.14-rt. > The proposal looks okay. However the verified upstream version not only > addresses your issue but also makes smp_processor_id() and might_sleep() > work in the early phase. I would prefer the upstream solution for those > two reasons. Thanks for your opinion. Just for your reference, I've shared another (revised) patch series[1] which is based on the upstream series[2]. It has been tested on several environments similarly to the draft version[3]. Yes, the current proposal only focuses on resolving the WARNING issue. At the same time, I think it would be also possible to apply the other improvements for smp_processor_id() and might_sleep(), which means 1/17 and 17/17 of the mainline patch series[2], on top of the current way i.e. using the custom flag system_scheduling. The question here is whether to insert SYSTEM_SCHEDULING is acceptable or not in LTS phase. This addition would change behavior of future fixes or out-of-tree codes that check system_state, so adjustments similar to the mainline series[2] (2/17 ~ 15/17) are needed for them. Can I ask if it's recommended to introduce SYSTEM_SCHEDULING even in LTS? It's v4.4-rt specific topic but I think similar discussion is regularly happening in newer -rt branches and LTS branches where PREEMPT_RT is merged. [1] https://lore.kernel.org/linux-rt-devel/1739170545-25011-1-git-send-email-kazuhiro3.hayashi@xxxxxxxxxxxxx/T/ [2] https://lore.kernel.org/all/20170516184231.564888231@xxxxxxxxxxxxx/T/ [2] https://lore.kernel.org/all/TYCPR01MB1138579CA7612B568BB880652E1272@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx/ Best regards, Kazu
