The 2.6 "must fix" list

On May 14, a number of developers met via IRC to discuss this list; the IRC log is available for those who would like to see how the discussion went. A detailed writeup will be made available; briefly, the main points discussed were:

• The TTY drivers need a lot of work; there are lots of locking and other problems. Some of the problems are denial-of-service holes, so fixes will have to be backported to 2.4 as well. It's on Alexander Viro's list.

• BIO splitting (with the ability to split on non-page boundaries) is still needed, to fix the RAID problems if nothing else.

• The input layer also still has problems, including locking and difficult configuration options.

• Merging the ARM code, including a bunch of drivers that could, perhaps, be useful beyond the ARM architecture. The real question there is where they should go in the tree...hardly a 2.6 show stopper.

• CardBus problems; this is a locking issue again.

• Lots of framebuffer work remains; it has been proceeding slowly.

• SCSI: the discussion was mostly about which drivers should be merged and/or need fixing.

• Races involving direct I/O and the truncate() system call which can destroy filesystems. This one looks hard to fix, but something needs to be done. In the worst case, direct I/O could be disabled for regular files, but nobody likes that option.

• Some scheduling problems remain; Ingo Molnar has patches, but nobody is sure how many of the problems those patches fix.

• Networking: the big problem is one where TCP sessions occasionally hang. More traces of hung connections will be needed to track this one down.

• Process accounting is broken for 32-bit user IDs. This one looks like it can be fixed using some padding in the accounting record structure. Alan Cox (conveniently absent) was nominated to do the fix.

• The 1000HZ clock on the i386 architecture is creating some timekeeping problems that need to be fixed. In the worst case, the clock frequency would have to go back to 100, but there should be a better way.

• 64-bit dev_t: Al Viro wants to do quite a bit of work, still, with device number allocation (especially for char devices) and Andries Brouwer is still looking for problems in ioctl() calls. It was asked whether this work could be decoupled from the size change; as was pointed out, going ahead and changing the size of dev_t would make many of the problems more apparent. The /proc/devices file poses some interesting compatibility problems in the new device number scheme.

The discussion did not get through the entire list before time ran out (the Europeans were getting seriously tired, since it was after midnight there, and even kernel hackers begin to slow down about then). Another discussion next week is likely.