Just a note regarding the shared memory changes. The Gimp (1.1.18) broke
initially but has worked fine since being recompiled with the new kernel
and headers installed. Don't ask me why, I didn't investigate. :o)
I don't know if that helps tracing the problem at all.
John Cavan
Alan Cox wrote:
>
> In Progress
> -----------
> Merge the network fixes (DaveM)
> Merge 2.2.15 changes (Alan)
> Get RAID 0.90 in (Ingo)
>
> Fix Exists But Isnt Merged
> --------------------------
> Signals leak kernel memory (security)
> msync fails on NFS
> Semaphore races
> Sempahore memory leak
> Exploitable leak in file locking
>
> To Do
> -----
> Restore O_SYNC functionality
> Fix eth= command line
> vmalloc(GFP_DMA) is needed for DMA drivers
> VM needs rebalancing
> Fix SPX socket code
> put_user appears to be broken for i386 machines
> Fix module remove race bug
> Test other file systems on write
> Directory race fix for UFS
> Audit all char and block drivers to ensure they are safe with the 2.3
> locking - a lot of them are not especially on the open() path.
> Stick lock_kernel() calls around driver with issues to hard to fix nicely
> for 2.4 itself
> PCMCIA/Cardbus hangs, IRQ problems, Keyboard/mouse problem (related ?)
> Tulip hang on rmmod
> Use PCI DMA by default in IDE is unsafe (must not do so on via VPx x<3)
> Use PCI DMA 'lost interrupt' problem with some hw [which ?]
>
> To Do But Non Showstopper
> -------------------------
> Make syncppp use new ppp code
> Finish 64bit vfs merges (lockf64 and friends missing)
> NCR5380 isnt smp safe
> DMFE is not SMP safe
> ACPI hangs on boot for some systems
> Get the Emu10K merged
> Finish I2O merge
> Go through as 2.4pre kicks in and figure what we should mark obsolete for
> the final 2.4
> Per Process rtsigio limit
> Boot hangs on a range of Dell docking stations (Latitude)
> Port SGI VisWS to 2.3.x or mark obsolete
> S/390 Merge
> HFS is still broken
> iget abuse in knfsd
> Mark NTFS as obsolete
> via rhine oopses under load (softnet ?)
> Symbol clashes and other mess from _three_ copies of zlib!
> Paride seems to need fixes for the block changes yet
> PIII FXSAVE/FXRESTORE support
>
> Compatibility Errors
> --------------------
> Shared memory changes change the API breaking applications (eg gimp)
>
> Probably Post 2.4
> -----------------
> per super block write_super needs an async flag
> addres_space needs a VM pressure/flush callback
> per file_op rw_kiovec
> enhanced disk statistics
> AFFS fixups
> UMSDOS fixups resync
>
> To Check
> --------
> Truncate races (Debian apt shows it nicely) [done ? - all but Coda]
> Elevator and block handling queue change errors are all sorted
> Check O_APPEND atomicity bug fixing is complete
> Incredibly slow loopback tcp bug
> Make sure all drivers return 1 from their __setup functions
> Finish softnet driver port over and cleanups
> Page cache high on PAE36 boxes is very slow, maybe disable ?
> Protection on isize (sct) [Al Viro mostly done]
> Mikulas claims we need to fix the getblk/mark_buffer_uptodate thing for
> 2.3.x as well
> Network block device seems broken by block device changes
> Fbcon races
> Fix all remaining PCI code to use new resources and enable_Device
> VFS?VM - mmap/write deadlock
> initrd is bust
> rw sempahores on page faults (mmap_sem)
> kiobuf seperate lock functions/bounce/page_address fixes
> Fix routing by fwmark
> Some FB drivers check the A000 area and find it busy then bomb out
> rw semaphores on inodes to fix read/truncate races ? [Probably fixed]
> Not all device drivers are safe now the write inode lock isnt taken on write
> File locking needs checking for races
> Multiwrite IDE breaks on a disk error
> AFFS doesn't work on current page cache
>
> -
> 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/
-- *********************************Tell me and I may forget, Show me and I may remember, Involve me and I will understand.
*********************************
- 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/
This archive was generated by hypermail 2b29 : Wed Mar 15 2000 - 21:00:22 EST