Re: Debugging Thinkpad T430s occasional suspend failure.

From: Frederic Weisbecker
Date: Sun Feb 17 2013 - 16:02:16 EST

2013/2/17 Frederic Weisbecker <fweisbec@xxxxxxxxx>:
> 2013/2/17 Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>:
>> On Sun, Feb 17, 2013 at 7:11 AM, Frederic Weisbecker <fweisbec@xxxxxxxxx> wrote:
>>> preempt_value_in_interrupt() looks buggy in your patch: it makes
>>> invoke_softirq() returning if (val & HARDIRQ_MASK). But that's always
>>> true since you have moved further the sub_preempt_count(IRQ_EXIT)
>>> further.
>> No, that's not it. The value hasn't been written back yet, but it already did:
>> + int offset = IRQ_EXIT_OFFSET;
>> + int count = preempt_count() - offset;
>> so the 'count' has the IRQ_EXIT_OFFSET already subtracted. So no,
>> HARDIRQ_MASK is *not* always set.
> Another thing. Perhaps we can push the idea of your patch a little
> further by re-entering HARDIRQ_OFFSET at the end of the softirq
> processing and do the final sub_preempt_count(HARDIRQ_OFFSET) at the
> very end of irq_exit().
> This way irq_exit() looks a bit more simple to me: everything there
> becomes considered as in hardirq: (ie: rcu_irq_exit() and
> tick_nohz_irq_exit() won't appear anymore as weird special cases) and
> we get rid of that IRQ_EXIT_OFFSET hack that fixes the CONFIG_PREEMPT
> case.
> I'm attaching an untested patch that modify yours. It's probably
> missing some corner cases that rely on in_interrupt() value in
> rcu_irq_exit() and tick_nohz_irq_exit() and may be other things.

I messed up preempt_offset_in_interrupt() with in_atomic() code
instead of in_interrupt(). Anyway the patch is untested and is more
there to get your opinion for now. I'll put some more care on it if
people like it.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at