All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
To: "Pavel V. Panteleev" <panteleevp@gmail.com>
Cc: linux-rt-users@vger.kernel.org, tglx@linutronix.de
Subject: Re: schedule under irqs_disabled in SLUB problem
Date: Thu, 2 Nov 2017 17:50:10 +0100	[thread overview]
Message-ID: <20171102165009.u7a7ahmmywo2qugd@linutronix.de> (raw)
In-Reply-To: <CADF-jezvVP2O++FR2KiRSSSJF7oObjy8LSP3-yj1HCmxyTzB_Q@mail.gmail.com>

On 2017-11-01 12:41:33 [+0300], Pavel V. Panteleev wrote:
> Hello! I have a problem on kernel 3.14.79-rt85 and I don't know, if it's
> solved on current kernel or, may be, it's our additions problem. Could you
> help me, please?

will do my best.

> Kernel is broken in migrate_enable():
>         WARN_ON_ONCE(p->migrate_disable <= 0);
> 
> I have a trace, where I see, that it happened, because few
> migrate_disable() were called under irqs_disabled (migrate_disable counter
> wasn't changed). But after schedule() call irqs were enabled and the
> following migrate_disable() and migrate_enable() changed migrate_disable
> counter. I suppose, that problem is schedule() call under irqs_disabled.

that is basically what happens if the counter goes negative.

…
> As I see, in allocate_slab() kernel could be under irqs_disabled. And irqs
> would be enabled in case of SYSTEM_RUNNING (why only in case of
> SYSTEM_RUNNING?). But in our case system isn't running yet (it's always
> before /sbin/init), so irqs wouldn't be enabled:

ideally the interrupts would be always enabled because they have to on
-RT but we can't do so early in the boot process.

>         enableirqs = (flags & __GFP_WAIT) != 0;
>         #ifdef CONFIG_PREEMPT_RT_FULL
>         enableirqs |= system_state == SYSTEM_RUNNING;
>         #endif
>         if (enableirqs)
>                 local_irq_enable();
> P. S.
> Today I reproduced this on 4.9.47-rt37. Try to reproduce on x86.

In newer -RT we have
	if (system_state > SYSTEM_BOOTING)
instead but this won't work even in v4.9 because it does not have
SYSTEM_SCHEDULING yet. So v4.11/v4.13 should not be affected.

If that is true, then something like

diff --git a/init/main.c b/init/main.c
index 6470deef01c9..362761effeac 100644
--- a/init/main.c
+++ b/init/main.c
@@ -379,6 +379,7 @@ static void __init setup_command_line(char *command_line)
  */
 
 static __initdata DECLARE_COMPLETION(kthreadd_done);
+extern bool slab_do_irq_on;
 
 static noinline void __ref rest_init(void)
 {
@@ -396,6 +397,7 @@ static noinline void __ref rest_init(void)
 	rcu_read_lock();
 	kthreadd_task = find_task_by_pid_ns(pid, &init_pid_ns);
 	rcu_read_unlock();
+	slab_do_irq_on = true;
 	complete(&kthreadd_done);
 
 	/*
diff --git a/mm/slub.c b/mm/slub.c
index 67eb368b9314..22ec805130e5 100644
--- a/mm/slub.c
+++ b/mm/slub.c
@@ -1527,6 +1527,7 @@ static inline bool shuffle_freelist(struct kmem_cache *s, struct page *page)
 	return false;
 }
 #endif /* CONFIG_SLAB_FREELIST_RANDOM */
+bool slab_do_irq_on;
 
 static struct page *allocate_slab(struct kmem_cache *s, gfp_t flags, int node)
 {
@@ -1543,7 +1544,7 @@ static struct page *allocate_slab(struct kmem_cache *s, gfp_t flags, int node)
 	if (gfpflags_allow_blocking(flags))
 		enableirqs = true;
 #ifdef CONFIG_PREEMPT_RT_FULL
-	if (system_state == SYSTEM_RUNNING)
+	if (slab_do_irq_on)
 		enableirqs = true;
 #endif
 	if (enableirqs)

might just work. Can you test this please?

Sebastian

       reply	other threads:[~2017-11-02 16:50 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CADF-jezvVP2O++FR2KiRSSSJF7oObjy8LSP3-yj1HCmxyTzB_Q@mail.gmail.com>
2017-11-02 16:50 ` Sebastian Andrzej Siewior [this message]
2017-11-02 20:55   ` schedule under irqs_disabled in SLUB problem Grygorii Strashko
     [not found]   ` <CADF-jexLs9vRuiuoRmcA+0L6Mp-XxW75okheWV+ipGf1b_Ua1w@mail.gmail.com>
2017-11-03 10:23     ` Pavel V. Panteleev
2017-11-07  9:00       ` Pavel V. Panteleev
2017-11-07  9:14       ` Pavel V. Panteleev
2017-11-07  9:47       ` Pavel V. Panteleev
2017-11-16 16:08         ` Sebastian Andrzej Siewior
2017-11-16 16:39           ` Pavel V. Panteleev
2017-11-17 17:38           ` Julia Cartwright
2017-11-24  6:39             ` Sam Kappen
2017-11-24  9:37               ` Sebastian Andrzej Siewior
2017-11-27  6:46                 ` Sam Kappen
2017-12-04  9:59                   ` Sebastian Andrzej Siewior
2017-12-05 16:31                     ` Sam Kappen
2017-12-12 10:18                       ` Sebastian Andrzej Siewior
2018-03-05  8:47                         ` Sam Kappen
2018-03-05 17:40                           ` Sebastian Andrzej Siewior
2017-11-24  9:35             ` [PATCH] mm/slub: enable IRQs once scheduling is working Sebastian Andrzej Siewior
2017-11-01 11:31 schedule under irqs_disabled in SLUB problem Pavel V. Panteleev

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20171102165009.u7a7ahmmywo2qugd@linutronix.de \
    --to=bigeasy@linutronix.de \
    --cc=linux-rt-users@vger.kernel.org \
    --cc=panteleevp@gmail.com \
    --cc=tglx@linutronix.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.