Re: [PATCH v3 3/3] sched, x86: Check that we're on the right stack in schedule and __might_sleep

On Mon, May 23, 2016 at 7:09 PM, Andy Lutomirski wrote: > > What about this silly fix? (Pardon the probable whitespace damage.) That looks fine to me, and has a reason for it. That said, I'm not convinced about the preempt_enable/preempt_disable excuse: that would be

Re: [PATCH v3 3/3] sched, x86: Check that we're on the right stack in schedule and __might_sleep

On Mon, May 23, 2016 at 7:09 PM, Andy Lutomirski wrote: > > What about this silly fix? (Pardon the probable whitespace damage.) That looks fine to me, and has a reason for it. That said, I'm not convinced about the preempt_enable/preempt_disable excuse: that would be horribly buggy anyway, and

Re: [PATCH v3 3/3] sched, x86: Check that we're on the right stack in schedule and __might_sleep

On Mon, May 23, 2016 at 6:48 PM, Linus Torvalds wrote: > On Mon, May 23, 2016 at 6:23 PM, Andy Lutomirski wrote: >>> >>> Or we could just let ksoftirqd do its thing and stop raising >>> HARDIRQ_COUNT. We could add a new preempt count field

Re: [PATCH v3 3/3] sched, x86: Check that we're on the right stack in schedule and __might_sleep

On Mon, May 23, 2016 at 6:48 PM, Linus Torvalds wrote: > On Mon, May 23, 2016 at 6:23 PM, Andy Lutomirski wrote: >>> >>> Or we could just let ksoftirqd do its thing and stop raising >>> HARDIRQ_COUNT. We could add a new preempt count field just for IST >>> (yuck). We could try to hijack a

Re: [PATCH v3 3/3] sched, x86: Check that we're on the right stack in schedule and __might_sleep

On Mon, May 23, 2016 at 6:23 PM, Andy Lutomirski wrote: >> >> Or we could just let ksoftirqd do its thing and stop raising >> HARDIRQ_COUNT. We could add a new preempt count field just for IST >> (yuck). We could try to hijack a different preempt count field >> (NMI?). But

Re: [PATCH v3 3/3] sched, x86: Check that we're on the right stack in schedule and __might_sleep

On Mon, May 23, 2016 at 6:23 PM, Andy Lutomirski wrote: >> >> Or we could just let ksoftirqd do its thing and stop raising >> HARDIRQ_COUNT. We could add a new preempt count field just for IST >> (yuck). We could try to hijack a different preempt count field >> (NMI?). But I kind of like the

Re: [PATCH v3 3/3] sched, x86: Check that we're on the right stack in schedule and __might_sleep

On Sun, Feb 28, 2016 at 9:27 PM, Andy Lutomirski wrote: > On Wed, Nov 19, 2014 at 11:44 AM, Linus Torvalds > wrote: >> On Wed, Nov 19, 2014 at 11:29 AM, Andi Kleen wrote: >>> >>> The exception handlers which use the IST

Re: [PATCH v3 3/3] sched, x86: Check that we're on the right stack in schedule and __might_sleep

On Sun, Feb 28, 2016 at 9:27 PM, Andy Lutomirski wrote: > On Wed, Nov 19, 2014 at 11:44 AM, Linus Torvalds > wrote: >> On Wed, Nov 19, 2014 at 11:29 AM, Andi Kleen wrote: >>> >>> The exception handlers which use the IST stacks don't necessarily >>> set irq count. Maybe they should. >> >> Hmm. I

Re: [PATCH v3 3/3] sched, x86: Check that we're on the right stack in schedule and __might_sleep

On Wed, Nov 19, 2014 at 11:44 AM, Linus Torvalds wrote: > On Wed, Nov 19, 2014 at 11:29 AM, Andi Kleen wrote: >> >> The exception handlers which use the IST stacks don't necessarily >> set irq count. Maybe they should. > > Hmm. I think they

Re: [PATCH v3 3/3] sched, x86: Check that we're on the right stack in schedule and __might_sleep

On Wed, Nov 19, 2014 at 11:44 AM, Linus Torvalds wrote: > On Wed, Nov 19, 2014 at 11:29 AM, Andi Kleen wrote: >> >> The exception handlers which use the IST stacks don't necessarily >> set irq count. Maybe they should. > > Hmm. I think they should. Since they clearly must not schedule, as > they

Re: [PATCH v3 3/3] sched, x86: Check that we're on the right stack in schedule and __might_sleep

On Nov 20, 2014 2:28 AM, "Borislav Petkov" wrote: > > On Wed, Nov 19, 2014 at 04:46:29PM -0800, Andy Lutomirski wrote: > > So we'd do, in do_machine_check: > > > > irq_enter(); > > > > do atomic stuff; > > > > ist_stop_being_atomic(regs); > > local_irq_enable(); > > ... > > local_irq_disable(); >

Re: [PATCH v3 3/3] sched, x86: Check that we're on the right stack in schedule and __might_sleep

On Wed, Nov 19, 2014 at 04:46:29PM -0800, Andy Lutomirski wrote: > So we'd do, in do_machine_check: > > irq_enter(); > > do atomic stuff; > > ist_stop_being_atomic(regs); > local_irq_enable(); > ... > local_irq_disable(); > ist_start_being_atomic_again(); Well, why would I want to go atomic

Re: [PATCH v3 3/3] sched, x86: Check that we're on the right stack in schedule and __might_sleep

On Wed, Nov 19, 2014 at 04:46:29PM -0800, Andy Lutomirski wrote: So we'd do, in do_machine_check: irq_enter(); do atomic stuff; ist_stop_being_atomic(regs); local_irq_enable(); ... local_irq_disable(); ist_start_being_atomic_again(); Well, why would I want to go atomic again? We

Re: [PATCH v3 3/3] sched, x86: Check that we're on the right stack in schedule and __might_sleep

On Nov 20, 2014 2:28 AM, Borislav Petkov b...@alien8.de wrote: On Wed, Nov 19, 2014 at 04:46:29PM -0800, Andy Lutomirski wrote: So we'd do, in do_machine_check: irq_enter(); do atomic stuff; ist_stop_being_atomic(regs); local_irq_enable(); ... local_irq_disable();

Re: [PATCH v3 3/3] sched, x86: Check that we're on the right stack in schedule and __might_sleep

* Andy Lutomirski wrote: > On Wed, Nov 19, 2014 at 3:59 PM, Linus Torvalds > wrote: > > On Wed, Nov 19, 2014 at 3:49 PM, Andy Lutomirski > > wrote: > >> > >> My only real objection is that it's going to be ugly and > >> error prone. It'll have to be something like: > > > > No. > > > >>

Re: [PATCH v3 3/3] sched, x86: Check that we're on the right stack in schedule and __might_sleep

On Wed, Nov 19, 2014 at 5:09 PM, Linus Torvalds wrote: > On Wed, Nov 19, 2014 at 4:46 PM, Andy Lutomirski wrote: >> >> I'm very hesitant to use irq_enter for this, though. I think we want >> just the irq_count part. > > Oh, I agree. I mentioned irq_enter/exit() just as the place the > preempt

Re: [PATCH v3 3/3] sched, x86: Check that we're on the right stack in schedule and __might_sleep

On Wed, Nov 19, 2014 at 4:46 PM, Andy Lutomirski wrote: > > I'm very hesitant to use irq_enter for this, though. I think we want > just the irq_count part. Oh, I agree. I mentioned irq_enter/exit() just as the place the preempt count increment normally happens. I have nothing against doing it

Re: [PATCH v3 3/3] sched, x86: Check that we're on the right stack in schedule and __might_sleep

On Wed, Nov 19, 2014 at 4:37 PM, Linus Torvalds wrote: > On Wed, Nov 19, 2014 at 4:13 PM, Andy Lutomirski wrote: >> >> No drugs, just imprecision. This series doesn't change NMI handling >> at all. It only changes machine_check int3, debug, and stack_segment. >> (Why is #SS using IST stacks

Re: [PATCH v3 3/3] sched, x86: Check that we're on the right stack in schedule and __might_sleep

On Wed, Nov 19, 2014 at 4:13 PM, Andy Lutomirski wrote: > > No drugs, just imprecision. This series doesn't change NMI handling > at all. It only changes machine_check int3, debug, and stack_segment. > (Why is #SS using IST stacks anyway?) .. ok, we were talking about adding an explicit

Re: [PATCH v3 3/3] sched, x86: Check that we're on the right stack in schedule and __might_sleep

On Wed, Nov 19, 2014 at 3:59 PM, Linus Torvalds wrote: > On Wed, Nov 19, 2014 at 3:49 PM, Andy Lutomirski wrote: >> >> My only real objection is that it's going to be ugly and error prone. >> It'll have to be something like: > > No. > >> because the whole point of this series is to make the IST

Re: [PATCH v3 3/3] sched, x86: Check that we're on the right stack in schedule and __might_sleep

On Wed, Nov 19, 2014 at 3:49 PM, Andy Lutomirski wrote: > > My only real objection is that it's going to be ugly and error prone. > It'll have to be something like: No. > because the whole point of this series is to make the IST entries not > be atomic when they come from userspace. Andy, you

Re: [PATCH v3 3/3] sched, x86: Check that we're on the right stack in schedule and __might_sleep

On Wed, Nov 19, 2014 at 3:23 PM, Linus Torvalds wrote: > On Wed, Nov 19, 2014 at 3:04 PM, Andy Lutomirski wrote: >> >> Does that include nmi? I'm a bit afraid of touching that code. > > NMI is kind of special, since it's really not supposed to touch > 'current' or anything like that, and that's

Re: [PATCH v3 3/3] sched, x86: Check that we're on the right stack in schedule and __might_sleep

On Wed, Nov 19, 2014 at 3:32 PM, Thomas Gleixner wrote: > > preempt_count is a per cpu variable at least on x86 since: Oh, goodie. I hadn't tracked that it went in, I just remembered the discussion. I should have looked. And apparently we do it in nmi_enter too, so NMI is already ok. Don't know

Re: [PATCH v3 3/3] sched, x86: Check that we're on the right stack in schedule and __might_sleep

On Wed, 19 Nov 2014, Linus Torvalds wrote: > On Wed, Nov 19, 2014 at 3:04 PM, Andy Lutomirski wrote: > > > > Does that include nmi? I'm a bit afraid of touching that code. > > NMI is kind of special, since it's really not supposed to touch > 'current' or anything like that, and that's how we

Re: [PATCH v3 3/3] sched, x86: Check that we're on the right stack in schedule and __might_sleep

On Wed, Nov 19, 2014 at 3:04 PM, Andy Lutomirski wrote: > > Does that include nmi? I'm a bit afraid of touching that code. NMI is kind of special, since it's really not supposed to touch 'current' or anything like that, and that's how we do preempt-count (and that's where irq-count is) right

Re: [PATCH v3 3/3] sched, x86: Check that we're on the right stack in schedule and __might_sleep

On Wed, Nov 19, 2014 at 11:44 AM, Linus Torvalds wrote: > On Wed, Nov 19, 2014 at 11:29 AM, Andi Kleen wrote: >> >> The exception handlers which use the IST stacks don't necessarily >> set irq count. Maybe they should. > > Hmm. I think they should. Since they clearly must not schedule, as > they

Re: [PATCH v3 3/3] sched, x86: Check that we're on the right stack in schedule and __might_sleep

On Wed, Nov 19, 2014 at 11:29 AM, Andi Kleen wrote: > > The exception handlers which use the IST stacks don't necessarily > set irq count. Maybe they should. Hmm. I think they should. Since they clearly must not schedule, as they use a percpu stack. Which exceptions use IST? [ grep grep ]

Re: [PATCH v3 3/3] sched, x86: Check that we're on the right stack in schedule and __might_sleep

On Wed, Nov 19, 2014 at 10:40:10AM -0800, Linus Torvalds wrote: > On Tue, Nov 18, 2014 at 3:15 PM, Andy Lutomirski wrote: > > On x86, sleeping while on an IST or irq stack has a surprisingly > > good chance of working, but it can also fail dramatically. Add an > > arch hook to allow schedule and

Re: [PATCH v3 3/3] sched, x86: Check that we're on the right stack in schedule and __might_sleep

On Wed, Nov 19, 2014 at 10:40 AM, Linus Torvalds wrote: > On Tue, Nov 18, 2014 at 3:15 PM, Andy Lutomirski wrote: >> On x86, sleeping while on an IST or irq stack has a surprisingly >> good chance of working, but it can also fail dramatically. Add an >> arch hook to allow schedule and

Re: [PATCH v3 3/3] sched, x86: Check that we're on the right stack in schedule and __might_sleep

On Tue, Nov 18, 2014 at 3:15 PM, Andy Lutomirski wrote: > On x86, sleeping while on an IST or irq stack has a surprisingly > good chance of working, but it can also fail dramatically. Add an > arch hook to allow schedule and __might_sleep to catch sleeping on > the wrong stack. Why doesn't the

Re: [PATCH v3 3/3] sched, x86: Check that we're on the right stack in schedule and __might_sleep

On Tue, Nov 18, 2014 at 3:15 PM, Andy Lutomirski l...@amacapital.net wrote: On x86, sleeping while on an IST or irq stack has a surprisingly good chance of working, but it can also fail dramatically. Add an arch hook to allow schedule and __might_sleep to catch sleeping on the wrong stack.

Re: [PATCH v3 3/3] sched, x86: Check that we're on the right stack in schedule and __might_sleep

On Wed, Nov 19, 2014 at 10:40 AM, Linus Torvalds torva...@linux-foundation.org wrote: On Tue, Nov 18, 2014 at 3:15 PM, Andy Lutomirski l...@amacapital.net wrote: On x86, sleeping while on an IST or irq stack has a surprisingly good chance of working, but it can also fail dramatically. Add an

Re: [PATCH v3 3/3] sched, x86: Check that we're on the right stack in schedule and __might_sleep

On Wed, Nov 19, 2014 at 10:40:10AM -0800, Linus Torvalds wrote: On Tue, Nov 18, 2014 at 3:15 PM, Andy Lutomirski l...@amacapital.net wrote: On x86, sleeping while on an IST or irq stack has a surprisingly good chance of working, but it can also fail dramatically. Add an arch hook to allow

Re: [PATCH v3 3/3] sched, x86: Check that we're on the right stack in schedule and __might_sleep

On Wed, Nov 19, 2014 at 11:29 AM, Andi Kleen a...@firstfloor.org wrote: The exception handlers which use the IST stacks don't necessarily set irq count. Maybe they should. Hmm. I think they should. Since they clearly must not schedule, as they use a percpu stack. Which exceptions use IST? [

Re: [PATCH v3 3/3] sched, x86: Check that we're on the right stack in schedule and __might_sleep

On Wed, Nov 19, 2014 at 11:44 AM, Linus Torvalds torva...@linux-foundation.org wrote: On Wed, Nov 19, 2014 at 11:29 AM, Andi Kleen a...@firstfloor.org wrote: The exception handlers which use the IST stacks don't necessarily set irq count. Maybe they should. Hmm. I think they should. Since

Re: [PATCH v3 3/3] sched, x86: Check that we're on the right stack in schedule and __might_sleep

On Wed, Nov 19, 2014 at 3:04 PM, Andy Lutomirski l...@amacapital.net wrote: Does that include nmi? I'm a bit afraid of touching that code. NMI is kind of special, since it's really not supposed to touch 'current' or anything like that, and that's how we do preempt-count (and that's where

Re: [PATCH v3 3/3] sched, x86: Check that we're on the right stack in schedule and __might_sleep

On Wed, 19 Nov 2014, Linus Torvalds wrote: On Wed, Nov 19, 2014 at 3:04 PM, Andy Lutomirski l...@amacapital.net wrote: Does that include nmi? I'm a bit afraid of touching that code. NMI is kind of special, since it's really not supposed to touch 'current' or anything like that, and

Re: [PATCH v3 3/3] sched, x86: Check that we're on the right stack in schedule and __might_sleep

On Wed, Nov 19, 2014 at 3:32 PM, Thomas Gleixner t...@linutronix.de wrote: preempt_count is a per cpu variable at least on x86 since: Oh, goodie. I hadn't tracked that it went in, I just remembered the discussion. I should have looked. And apparently we do it in nmi_enter too, so NMI is

Re: [PATCH v3 3/3] sched, x86: Check that we're on the right stack in schedule and __might_sleep

On Wed, Nov 19, 2014 at 3:23 PM, Linus Torvalds torva...@linux-foundation.org wrote: On Wed, Nov 19, 2014 at 3:04 PM, Andy Lutomirski l...@amacapital.net wrote: Does that include nmi? I'm a bit afraid of touching that code. NMI is kind of special, since it's really not supposed to touch

Re: [PATCH v3 3/3] sched, x86: Check that we're on the right stack in schedule and __might_sleep

On Wed, Nov 19, 2014 at 3:49 PM, Andy Lutomirski l...@amacapital.net wrote: My only real objection is that it's going to be ugly and error prone. It'll have to be something like: No. because the whole point of this series is to make the IST entries not be atomic when they come from

Re: [PATCH v3 3/3] sched, x86: Check that we're on the right stack in schedule and __might_sleep

On Wed, Nov 19, 2014 at 3:59 PM, Linus Torvalds torva...@linux-foundation.org wrote: On Wed, Nov 19, 2014 at 3:49 PM, Andy Lutomirski l...@amacapital.net wrote: My only real objection is that it's going to be ugly and error prone. It'll have to be something like: No. because the whole

Re: [PATCH v3 3/3] sched, x86: Check that we're on the right stack in schedule and __might_sleep

On Wed, Nov 19, 2014 at 4:13 PM, Andy Lutomirski l...@amacapital.net wrote: No drugs, just imprecision. This series doesn't change NMI handling at all. It only changes machine_check int3, debug, and stack_segment. (Why is #SS using IST stacks anyway?) .. ok, we were talking about adding an

Re: [PATCH v3 3/3] sched, x86: Check that we're on the right stack in schedule and __might_sleep

On Wed, Nov 19, 2014 at 4:37 PM, Linus Torvalds torva...@linux-foundation.org wrote: On Wed, Nov 19, 2014 at 4:13 PM, Andy Lutomirski l...@amacapital.net wrote: No drugs, just imprecision. This series doesn't change NMI handling at all. It only changes machine_check int3, debug, and

Re: [PATCH v3 3/3] sched, x86: Check that we're on the right stack in schedule and __might_sleep

On Wed, Nov 19, 2014 at 4:46 PM, Andy Lutomirski l...@amacapital.net wrote: I'm very hesitant to use irq_enter for this, though. I think we want just the irq_count part. Oh, I agree. I mentioned irq_enter/exit() just as the place the preempt count increment normally happens. I have nothing

Re: [PATCH v3 3/3] sched, x86: Check that we're on the right stack in schedule and __might_sleep

On Wed, Nov 19, 2014 at 5:09 PM, Linus Torvalds torva...@linux-foundation.org wrote: On Wed, Nov 19, 2014 at 4:46 PM, Andy Lutomirski l...@amacapital.net wrote: I'm very hesitant to use irq_enter for this, though. I think we want just the irq_count part. Oh, I agree. I mentioned

Re: [PATCH v3 3/3] sched, x86: Check that we're on the right stack in schedule and __might_sleep

* Andy Lutomirski l...@amacapital.net wrote: On Wed, Nov 19, 2014 at 3:59 PM, Linus Torvalds torva...@linux-foundation.org wrote: On Wed, Nov 19, 2014 at 3:49 PM, Andy Lutomirski l...@amacapital.net wrote: My only real objection is that it's going to be ugly and error prone. It'll

[PATCH v3 3/3] sched, x86: Check that we're on the right stack in schedule and __might_sleep

On x86, sleeping while on an IST or irq stack has a surprisingly good chance of working, but it can also fail dramatically. Add an arch hook to allow schedule and __might_sleep to catch sleeping on the wrong stack. This will also catch do_exit from a funny stack, which could leave an IST stack

[PATCH v3 3/3] sched, x86: Check that we're on the right stack in schedule and __might_sleep

On x86, sleeping while on an IST or irq stack has a surprisingly good chance of working, but it can also fail dramatically. Add an arch hook to allow schedule and __might_sleep to catch sleeping on the wrong stack. This will also catch do_exit from a funny stack, which could leave an IST stack