4KB stack + irq stack for x86
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 11 lines · Benjamin LaHaise
Quoted 6 lines · Linus Torvalds
So, as far as I can tell, we now get a nasty aliasing issue on "current_thread_info()->flags", and information like
NEED_RESCHEDand SIGPENDING end up being set in the wrong place. They get set on the _interrupt_thread_info, not the "process native"thread_info.Or did I miss some subtlety?
Ah, you're right. If anyone uses
current_thread_infofrom IRQ context it will set the flags in the wrong structure. However, it actually works because nobody does that currently: all of the_thread_flagusers
preemptive kernels do use current_thread_info() for every spinlock. this required me to change its implementation on x86-64 from stack arithmetic to access the base register.
-Andi
Quoted 8 lines · Andi Kleen
Quoted 4 lines
Ah, you're right. If anyone uses
current_thread_infofrom IRQ context it will set the flags in the wrong structure. However, it actually works because nobody does that currently: all of the_thread_flaguserspreemptive kernels do use
current_thread_info()for every spinlock. this required me to change its implementation on x86-64 from stack arithmetic to access the base register.
Note that this part is ok, as long as we make sure that the irq stack gets initialized with a preempt_count > 0 (we must not preempt an interrupt handler anyway, it wouldn't work), _and_ we make sure that taking the interrupt also increments the "process native" preempt_count (so that anybody looking at that preempt_count to determine whether it could be preempted will also get a "nope, don't preempt me").
So that part doesn't look like a fundamental problem to me. It's just a "need to be careful" thing.
Linus