Andrea's pending 2.2.x patches

Andrea Arcangeli (andrea@suse.de)
Mon, 11 Oct 1999 16:03:46 +0200 (CEST)


These are all the patches that I would like to see included into 2.2.x.
They are all against 2.2.13pre15.

Of course the oom patch for example is not suggested to be included into
the soon 2.2.13 as it breaks all archs except Alpha and i386 (the only two
ones I have just fixed myself), but I would like to see it included into
the future 2.2.14. Also the SMP scheduler is only an improvement and so it
can be delayed too even if it replaces some SMP not optimal heuristc.

o buffer-races-2.2.10-A -> set_blocksize and invalidate_buffers
may follow a refiled buffer on
a wrong buffer lru list.
o free_page-2.2.12 -> cleanedup the new page_alloc
__free_page code (see the
patch, it's strightforward).
o oom-2.2.12-I -> oom fixes for potential DoS
that can lockup the machine
also incidentally due OOM. Avoid
init to get a sigsegv during OOM.
Fix alpha sigbus with shared
mappings. On i386 avoid sigkill
to iopl() tasks.
Breaks all arch except Alpha and
i386.
o probe-irq-2.3.14-pre2-1 -> If an irq was pending right now
it's marked as spurious.
o mknod-unixsock-nosymlink -> Avoid mknod and bind on
unix sockets to follow symlinks
(obviously right one liner).
Probably you just did that
in your tree as I seen
you said Linux will do that too.
o smp-reschedule-boot-2.3.13-1 -> Avoid to lockup at boot due
the idle task of a secondary
cpu rescheduled on the master
cpu due too long SMP
boot time (lots of CPUs).
o wait-event-smp-races -> obviously right necessary mb()s.
o wait4-smp-race -> Fix for a subtle wait4() race
that will show up as an userspace
deadlock where the parent remains
blocked in wait4() while
the zombie child exited under the
parent. (can happen only if
the parent masks SIGCHLD before
calling wait4, exactly as
bash does every time it spawn
a task).
o wakeup_bdflush-2.2.10-A -> avoid deadlock with blocking
request_fn callbacks (e.g.
lo_request).
o zmagic-only-fix -> fix a bug in the a.out code that
will cause a segfault if triggers.
o clear-backlog-2 -> fix a SMP race in the common
device backlog (where the irq
queue packets that will be
processed from net_bh()).
o hashed-buffers-2.2.10 -> increase decrease the stats
in the right place (can't harm
as the stats will show up only
in SYSRQ+M).
o kupdate-sigstop-2.2.11 -> allow to stop/start kupdate
with a SIGSTOP/SIGCONT
(right now you must set the
interval to zero to stop it).
o no-needed-comment-2.2.12-final3 -> reverse some code merged
from the large-fd set patch
(make no assembler difference).
o no-swapout-2.2.10-B -> allow 2.2.x to run on big
machines during heavy I/O load
without swapin/swapouts all the
time.
o shrink_all_cache-2.2.10-A -> avoid limits to the minimum level
of cache (iteresting for
big memory machines, for others
won't make a real difference).
o trashing-mem-2.2.10-A -> use a per-TASK lowmemory bit
instead of a global low_on_memory.
This block very much the hog
and let the system to run
smootly under swap. The algorithm
is the same, only a bit more
biased.
o xtime-lock-alpha -> allow alpha to compile
kernel/time.c (you just know
about that, my due, sorry).
o SMP-scheduler-2.2.11-E -> reschedule_idle SMP rewrite
(SMP performance patch).
o endbase-2.2.10 -> use the EDBA to know the
endbase address, but this patch
won't break the old machines and
it allows some new machine to
run fine.
The endbase address can also
be overidden with the endbase
kernel parameter (I updated
also the Documentation/ relevant
txt file).
o inode-leak-2.2.10 -> avoid any kind of inode leak
(problem with sockets). I don't
consider this one optimal of
course (2.3.20 with dynamic
inodes is better ;), but
at least the kernel won't silenty
leak memory.

You'll find all the patches I described above in this directory:

ftp://ftp.*.kernel.org/pub/linux/kernel/people/andrea/proposed/v2.2/2.2.13pre15/

As they are not controversial they can be applyed with any order.

Andrea

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