softirq in pre3 and all linux ports

From: Andrea Arcangeli (andrea@suse.de)
Date: Tue Jun 19 2001 - 14:03:12 EST


With pre3 there are bugs introduced into mainline that are getting
extended to all architectures.

First of all nucking the handle_softirq from entry.S is wrong. ppc
copied without thinking and we'll need to resurrect it too for example
so please arch maintainers don't kill that check (alpha in pre3 by luck
didn't killed it I think).

Without such check before returning to userspace any tasklet or softirq
posted by kernel code will get a latency of 1/HZ.

Secondly the pre3 softirq re-enables irqs before returning from
do_softirq which is wrong as well because it can generate irq flood and
stack overflow and do_softirq run not at the first not nested irq layer.

Third if a softirq or a tasklet post itself running again the do_softirq
can starve userspace in one or more cpus.

Fourth if the tasklet or softirq or bottom half hander is been marked
running again because of another even (like a nested irq) the kernel can
starve userspace too. (softirqs are much heavier than the irq handler so
it can also live lockup much more easily this way)

This patch that I have in my tree since some day fixes all those issues.

The assmembler changes needed in the entry.S files while returning to
userspace can be described in C code this way, this is the 2.4.5 way:

        if (softirq_active(cpu) & softirq_mask(cpu))
                do_softirq();

This is the 2.4.6pre3+belowfix way:

        if (softirq_pending(cpu))
                do_softirq()

pending doesn't need to be a 64bit integer (it can though) but it needs
to be at least a 32bit integer. An `int' is fine for most archs, on
alpha we use a long though and that's fine too.

So I recommend Linus merging this patch that fixes all the above
mentioned bugs (the anti starvation/live lockup logic is called
ksoftirqd):

        ftp://ftp.us.kernel.org/pub/linux/kernel/people/andrea/kernels/v2.4/2.4.6pre3aa1/00_ksoftirqd-6

Plus those SMP race fixes for archs where atomic operations aren't
implicit memory barriers:

        ftp://ftp.us.kernel.org/pub/linux/kernel/people/andrea/kernels/v2.4/2.4.6pre3aa1/00_softirq-fixes-4

Plus this scheduler generic cpu binding fix to avoid ksoftirqd
deadlocking at boot:

        ftp://ftp.us.kernel.org/pub/linux/kernel/people/andrea/kernels/v2.4/2.4.6pre3aa1/00_cpus_allowed-1

I verified the patches applies just fine to 2.4.6pre3 and they're not
controversial.

If you've any question on how to update a certain kernel port I will do
my best to help in the update process!

Andrea
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/



This archive was generated by hypermail 2b29 : Sat Jun 23 2001 - 21:00:25 EST