From: Peter Zijlstra <peterz@infradead.org> To: monstr@monstr.eu Cc: Russell King - ARM Linux <linux@arm.linux.org.uk>, Ingo Molnar <mingo@elte.hu>, Catalin Marinas <catalin.marinas@arm.com>, Marc Zyngier <Marc.Zyngier@arm.com>, Frank Rowand <frank.rowand@am.sony.com>, Oleg Nesterov <oleg@redhat.com>, linux-kernel@vger.kernel.org, Yong Zhang <yong.zhang0@gmail.com>, linux-arm-kernel@lists.infradead.org Subject: Re: [BUG] "sched: Remove rq->lock from the first half of ttwu()" locks up on ARM Date: Tue, 31 May 2011 16:29:54 +0200 [thread overview] Message-ID: <1306852194.2353.135.camel@twins> (raw) In-Reply-To: <4DE4F66D.9040101@monstr.eu> On Tue, 2011-05-31 at 16:08 +0200, Michal Simek wrote: > Peter Zijlstra wrote: > >> I would like to also check some things. > >> 1. When schedule should be called from arch specific code? > >> Currently we are calling schedule after syscall/exception/interrupt happen. > >> Is there any place where schedule should/shouldn't be called? > > > > It should be called on the return to userspace path when > > TIF_NEED_RESCHED is set. > > Yes, we do that. (PTO + PT_MODE stores if return is to kernel or user space) > > It should not be called from non-preemptible > > contexts like non-zero preempt_count or IRQ-disabled. > > Is this even when the return is to userspace? Well, return to userspace should have preempt_count == 0 and IRQs enabled, right? > PREEMPT is not well tested feature but maybe it is right time to do so. > There is only small part of code (ifdef CONFIG_PREEMPT) when irq happen and > there is return to the kernel. Is this correct? I think so, never looked too closely, Ingo? > > [ with the exception of CONFIG_PREEMPT which calls preempt_schedule() > > which checks both those things ] > > This is called only when IRQ happen right? We call preempt_schedule_irq because > irq are off and IRQ is ON by rtid below IRQ_return label. Ah, there's also preempt_schedule_irq(), which can be called with IRQs-disabled, not sure about the rules there though, Ingo? > > > >> 2. For syscall and exception handling - interrupt is ON but it is only masked. > > > > I'm having trouble understanding: on but masked. > > Interrupt can't happen because some masking bits are setup. If you call > irgs_disabled() or others you will get that IRQ is ON but can't happen. Ah, we generally ignore that state and only rely on state modified by local_irq_enable/disable(), eg. your MSR_IE bit. > >> When schedule is called from that any code has to enable IRQ if generic code > >> doesn't do that. Not sure if it does. > > > > generic code isn't supposed to call schedule() with IRQs disabled (and > > doesn't afaik) > > OK. Which means I have to disable IRQ before schedule is called. Is that correct? Hum, I might have mis-understood. No, schedule() assumes IRQs are enabled and will disable IRQs itself quite early: raw_spin_lock_irq(&rq->lock);
WARNING: multiple messages have this Message-ID (diff)
From: peterz@infradead.org (Peter Zijlstra) To: linux-arm-kernel@lists.infradead.org Subject: [BUG] "sched: Remove rq->lock from the first half of ttwu()" locks up on ARM Date: Tue, 31 May 2011 16:29:54 +0200 [thread overview] Message-ID: <1306852194.2353.135.camel@twins> (raw) In-Reply-To: <4DE4F66D.9040101@monstr.eu> On Tue, 2011-05-31 at 16:08 +0200, Michal Simek wrote: > Peter Zijlstra wrote: > >> I would like to also check some things. > >> 1. When schedule should be called from arch specific code? > >> Currently we are calling schedule after syscall/exception/interrupt happen. > >> Is there any place where schedule should/shouldn't be called? > > > > It should be called on the return to userspace path when > > TIF_NEED_RESCHED is set. > > Yes, we do that. (PTO + PT_MODE stores if return is to kernel or user space) > > It should not be called from non-preemptible > > contexts like non-zero preempt_count or IRQ-disabled. > > Is this even when the return is to userspace? Well, return to userspace should have preempt_count == 0 and IRQs enabled, right? > PREEMPT is not well tested feature but maybe it is right time to do so. > There is only small part of code (ifdef CONFIG_PREEMPT) when irq happen and > there is return to the kernel. Is this correct? I think so, never looked too closely, Ingo? > > [ with the exception of CONFIG_PREEMPT which calls preempt_schedule() > > which checks both those things ] > > This is called only when IRQ happen right? We call preempt_schedule_irq because > irq are off and IRQ is ON by rtid below IRQ_return label. Ah, there's also preempt_schedule_irq(), which can be called with IRQs-disabled, not sure about the rules there though, Ingo? > > > >> 2. For syscall and exception handling - interrupt is ON but it is only masked. > > > > I'm having trouble understanding: on but masked. > > Interrupt can't happen because some masking bits are setup. If you call > irgs_disabled() or others you will get that IRQ is ON but can't happen. Ah, we generally ignore that state and only rely on state modified by local_irq_enable/disable(), eg. your MSR_IE bit. > >> When schedule is called from that any code has to enable IRQ if generic code > >> doesn't do that. Not sure if it does. > > > > generic code isn't supposed to call schedule() with IRQs disabled (and > > doesn't afaik) > > OK. Which means I have to disable IRQ before schedule is called. Is that correct? Hum, I might have mis-understood. No, schedule() assumes IRQs are enabled and will disable IRQs itself quite early: raw_spin_lock_irq(&rq->lock);
next prev parent reply other threads:[~2011-05-31 14:30 UTC|newest] Thread overview: 102+ messages / expand[flat|nested] mbox.gz Atom feed top 2011-05-24 18:13 [BUG] "sched: Remove rq->lock from the first half of ttwu()" locks up on ARM Marc Zyngier 2011-05-24 18:13 ` Marc Zyngier 2011-05-24 21:32 ` Peter Zijlstra 2011-05-24 21:32 ` Peter Zijlstra 2011-05-24 21:39 ` Ingo Molnar 2011-05-24 21:39 ` Ingo Molnar 2011-05-25 12:23 ` Marc Zyngier 2011-05-25 12:23 ` Marc Zyngier 2011-05-25 17:08 ` Peter Zijlstra 2011-05-25 17:08 ` Peter Zijlstra 2011-05-25 21:15 ` Peter Zijlstra 2011-05-25 21:15 ` Peter Zijlstra 2011-05-26 7:29 ` Yong Zhang 2011-05-26 7:29 ` Yong Zhang 2011-05-26 10:32 ` Peter Zijlstra 2011-05-26 10:32 ` Peter Zijlstra 2011-05-26 11:02 ` Marc Zyngier 2011-05-26 11:02 ` Marc Zyngier 2011-05-26 11:32 ` Peter Zijlstra 2011-05-26 11:32 ` Peter Zijlstra 2011-05-26 12:21 ` Peter Zijlstra 2011-05-26 12:21 ` Peter Zijlstra 2011-05-26 12:26 ` Ingo Molnar 2011-05-26 12:26 ` Ingo Molnar 2011-05-26 12:31 ` Russell King - ARM Linux 2011-05-26 12:31 ` Russell King - ARM Linux 2011-05-26 12:37 ` Peter Zijlstra 2011-05-26 12:37 ` Peter Zijlstra 2011-05-26 12:50 ` Ingo Molnar 2011-05-26 12:50 ` Ingo Molnar 2011-05-26 13:36 ` Russell King - ARM Linux 2011-05-26 13:36 ` Russell King - ARM Linux 2011-05-26 14:45 ` Catalin Marinas 2011-05-26 14:45 ` Catalin Marinas 2011-05-27 12:06 ` Ingo Molnar 2011-05-27 12:06 ` Ingo Molnar 2011-05-27 17:55 ` Russell King - ARM Linux 2011-05-27 17:55 ` Russell King - ARM Linux 2011-05-27 19:41 ` Nicolas Pitre 2011-05-27 19:41 ` Nicolas Pitre 2011-05-27 20:52 ` Russell King - ARM Linux 2011-05-27 20:52 ` Russell King - ARM Linux 2011-05-28 13:13 ` Peter Zijlstra 2011-05-28 13:13 ` Peter Zijlstra 2011-05-31 11:08 ` Michal Simek 2011-05-31 11:08 ` Michal Simek 2011-05-31 13:22 ` Peter Zijlstra 2011-05-31 13:22 ` Peter Zijlstra 2011-05-31 13:37 ` Michal Simek 2011-05-31 13:37 ` Michal Simek 2011-05-31 13:52 ` Peter Zijlstra 2011-05-31 13:52 ` Peter Zijlstra 2011-05-31 14:08 ` Michal Simek 2011-05-31 14:08 ` Michal Simek 2011-05-31 14:29 ` Peter Zijlstra [this message] 2011-05-31 14:29 ` Peter Zijlstra 2011-05-29 10:21 ` Catalin Marinas 2011-05-29 10:21 ` Catalin Marinas 2011-05-29 10:26 ` Russell King - ARM Linux 2011-05-29 10:26 ` Russell King - ARM Linux 2011-05-29 12:01 ` Catalin Marinas 2011-05-29 12:01 ` Catalin Marinas 2011-05-29 13:19 ` Russell King - ARM Linux 2011-05-29 13:19 ` Russell King - ARM Linux 2011-05-29 21:21 ` Catalin Marinas 2011-05-29 21:21 ` Catalin Marinas 2011-05-29 9:51 ` Catalin Marinas 2011-05-29 9:51 ` Catalin Marinas 2011-06-06 10:29 ` Pavel Machek 2011-06-06 10:29 ` Pavel Machek 2011-05-26 14:56 ` Marc Zyngier 2011-05-26 14:56 ` Marc Zyngier 2011-05-26 15:45 ` Oleg Nesterov 2011-05-26 15:45 ` Oleg Nesterov 2011-05-26 15:59 ` Peter Zijlstra 2011-05-26 15:59 ` Peter Zijlstra 2011-05-26 16:09 ` Peter Zijlstra 2011-05-26 16:09 ` Peter Zijlstra 2011-05-26 16:20 ` Marc Zyngier 2011-05-26 16:20 ` Marc Zyngier 2011-05-26 16:32 ` Peter Zijlstra 2011-05-26 16:32 ` Peter Zijlstra 2011-05-27 8:01 ` Marc Zyngier 2011-05-27 8:01 ` Marc Zyngier 2011-05-26 16:22 ` Marc Zyngier 2011-05-26 16:22 ` Marc Zyngier 2011-05-26 17:04 ` Oleg Nesterov 2011-05-26 17:04 ` Oleg Nesterov 2011-05-26 17:17 ` Peter Zijlstra 2011-05-26 17:17 ` Peter Zijlstra 2011-05-26 17:23 ` Peter Zijlstra 2011-05-26 17:23 ` Peter Zijlstra 2011-05-26 17:49 ` Oleg Nesterov 2011-05-26 17:49 ` Oleg Nesterov 2011-05-27 7:01 ` Yong Zhang 2011-05-27 7:01 ` Yong Zhang 2011-05-27 15:23 ` Santosh Shilimkar 2011-05-27 15:23 ` Santosh Shilimkar 2011-05-27 15:29 ` Marc Zyngier 2011-05-27 15:29 ` Marc Zyngier 2011-05-27 15:30 ` Santosh Shilimkar 2011-05-27 15:30 ` Santosh Shilimkar
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=1306852194.2353.135.camel@twins \ --to=peterz@infradead.org \ --cc=Marc.Zyngier@arm.com \ --cc=catalin.marinas@arm.com \ --cc=frank.rowand@am.sony.com \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux@arm.linux.org.uk \ --cc=mingo@elte.hu \ --cc=monstr@monstr.eu \ --cc=oleg@redhat.com \ --cc=yong.zhang0@gmail.com \ /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: linkBe 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.