Ingo has raid and PIII diff merging queued to do. The old raid code isnt worth
fixing on that basis.
> CODA - will need serious testing after the expected large patch.
CODA is the sort of thing that can be fixed up later.
> procfs - needs decision on namespace policy/namespace rework. And
> proper dealing with races on module offloading, but that's old story.
We have a ton of other user exploitable races with module load/unload including
basic stuff like open which with a bit of care you can use to crash the machine
as any user. Procfs is only a part of this.
Taking my working list the key items seem to be
About 70% of device drivers dont have the setup code fixed. In many cases that
makes them unusable non modular
About 1/3rd of the ISA device drivers using memory mapped IO are still broken
AF_UNIX sockets are broken, and there are numerous IP layer bugs only fixed
in DaveM's trees that have to be fixed, either by extracting them
or going softnet.
The SPX sockets are totally broken
The PIII/Athlon/K6/Pentium memcpy etc acceleration code needs merging
NCR5380 is broken for SMP
AHA152x is broken for SMP
Anyuser can crash the code due to module races (eg open)
RAID 0.90 needs merging
Vmalloc needs to take flags for DMA optionally (for 32bit PCI scatter gather)
Getblk/mark buffer races in most file systems
Protection for inode size fields is wrong right now
Less critical stuff
Switching to the new i2c code core and the new bttv driver. Affects only some
tv cards so is ok
Per process rt signal queue limits
Syncppp should use the new generic ppp code
Back merge 2.2.13/2.2.14 fixes
I have the i2c stuff sorted mostly (thanks to Gerd and co), the 2.2.13/14 stuff
I will do next week and is all bug fixes, Im still trying to stomp all the isa
memory mapped I/O issues. I'll also sort the vmalloc cases out.
Most of the above is bug fixing or driver stuff so is post freeze work. The
raid and PIII stuff are not. I'd also prefer you to look at the core softnet
changes and say yes/no, then draw your line the side of it you choose. The
softnet work is the other 50% of the scaling work, without it 2.4 wont scale
much better than 2.2 for real world situations. That bothers me.
I've got a list of other stuff (Erez stackable fs, telephony API work,
performance counters, lm-sensors, ibcs) that are in the nice but so be it
category. I have no problem with those landing outside of 2.4.0 or staying
as add ons. Skipping softnet though would I think be a mistake.
Alan
-
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/