linux-kernel - RE: [PATCH 4.4 4.9 v1 2/2] mm: slub: allocate_slab() enables IRQ right after scheduler starts

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: 
 <TYCPR01MB11385E033624D2D9D93992A95E1F22@TYCPR01MB11385.jpnprd01.prod.outlook.com>
Date: Mon, 10 Feb 2025 07:20:35 +0000
From: <kazuhiro3.hayashi@...hiba.co.jp>
To: <bigeasy@...utronix.de>
CC: <linux-kernel@...r.kernel.org>, <linux-rt-devel@...ts.linux.dev>,
        <cip-dev@...ts.cip-project.org>, <tglx@...utronix.de>,
        <rostedt@...dmis.org>, <linux-rt-users@...r.kernel.org>,
        <pavel@...x.de>
Subject: RE: [PATCH 4.4 4.9 v1 2/2] mm: slub: allocate_slab() enables IRQ
 right after scheduler starts

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@toshiba.co.jp/T/
[2] https://lore.kernel.org/all/20170516184231.564888231@linutronix.de/T/
[2] https://lore.kernel.org/all/TYCPR01MB1138579CA7612B568BB880652E1272@TYCPR01MB11385.jpnprd01.prod.outlook.com/

Best regards,
Kazu