Mark Gross posted a patch to implement multithreaded core dump support in 2.5.14 and 2.5.15 kernels. He explained, This work has been tested on the 2.5.14 kernel using a few pthread applications to dump core, from SIGQUIT and SIGSEV. This unit test has been done on both 2 and 4 way systems. Further, some stress testing has been done where, the core files have been created while the system is under schedule stress from the chat room benchmark running while creating the core files. This implementation seems to be quit stable under a busy scheduler, YMMV.

Erich Focht asked how the patch would handle the case in which the suspended thread happened to be in kernel mode, a possibility in the 2.5 kernels. A couple posts later, Vamsi Krishna S. replied, if a thread happens to be in kernel mode when some other thread is dumping core (capturing register state of other threads, to be more accurate) then we would capture the _user mode_ register of that thread from the bottom of it's kernel stack. GDB will show back trace untill the thread entered kernel (int 0x80), eip will be pointing to the instruction after the system call (return address). Pavel Machek thought he found a problem with this. He described his exploit, Thread 1 is in kernel and holds lock A. You need lock A to dump state. When you move 1 to phantom runqueue, you loose ability to get A and deadlock. But Mark replied:

Pavel and Andi Kleen both took exception to Mark's statement that no driver should hold a lock across a sleep_on() call. As Andi put it, That's true for spinlocks, but not for semaphores. The mm layer and the vfs layer both use semaphores extensively and sleep with them hold, also some other subsystems (like networking) use sleeping locks. He and Mark and a couple other folks went back and forth on this for a few posts. At first, Mark was still unconvinced there was a problem, but after awhile he did start to see some areas that would need to be fixed. He posted a new patch, and said:

This apparently fixed the problems folks had with it, and there was a brief integration discussion, and various talk of possible problems that might arise.

At one point Mark remarked that he hoped to have the patch working on 2.4 soon as well.

Ed Tomlinson posted a patch, and explained, I have never been happy with the way slab cache shrinking worked. This is an attempt to make it better. Benjamin LaHaise clapped Ed on the back, and said, Thank you! This is should help greatly with some of the vm imbalances by making slab reclaim part of the self tuning dynamics instead of hard coded magic numbers. Do you have any plans to port this patch to 2.5 for inclusion? It would be useful to get testing in the 2.5 before merging in 2.4. Over the next few days, Ed replied with updated versions of the patch.

In the course of discussion some new patches for disk quotas, Linus Torvalds suggested removing some specific code that only provided backward compatibility to older kernels. He asked, Are there _any_ reasons to use the old stuff, if the fix is just to upgrade to a newer quota tool? And Alan Cox added, Most people use 2.4 with quota tools and 32bit uid quota already, so its not much of a breakage at all. The 2.4 quota base code is unusable in the real world so the problem got settled by the vendor trees.

Jan Kara said he'd send a patch to Linus to remove the extra code, and Martin Dalecki suggested, If we can do it for quota - we could possible remove the IPC_OLD variant away as well. It's looong overdue by now, becouse the IPC_OLD was not standard conformant anyway. But Alan replied that it was:

Martin replied, It is an illusion to think that you can actually run *that old* a.out binaries on a modern kernel I think. And Christoph Hellwig rejoined, Of course you can. Even the latest OpenLinux release (shipping 2.4.13-ac) uses a libc4/a.out based installer fo space reasons. Not to forget the old quake1 binary from some redhat 4.x CD I run from time to time :) Martin was impressed to hear that these things actually worked, and Alan told him he should have tested the idea before making his suggestion. Alan added, It btw goes beyond Libc4. Currently we have almost 100% compatibility back to libc 2.2.2. The dated libc before that doesn't work because we dropped some very very early obscure versions of a few syscalls.

At this point Christoph remarked, For 2.5 I have some plans to make obsolete syscalls depend on CONFIG_COMPAT_*, this allows to compile big and bloated kernel for compatiblity and smaller kernels without that (e.g. for embedded devices). And in fact we have quite a loft of cruft that can go away for setups only having very modern userspace.. Martin and Alan both approved of this idea, and Alan added, For embedded you also want config options to remove the block layer and so forth. I'd been thinking about a set of options buried in a config menu item like "Fine tune configuration for small/embedded devices" CONFIG_SMALL.

Linus Torvalds announced 2.5.17 and there was a ton of discussion about it. In one subthread, Martin Dalecki posted a patch to completely get rid of the /dev/port interface. He argued:

   text    data     bss     dec     hex filename
1480587  243280  259628 1983495  1e4407 vmlinux

[root@kozaczek linux]# size vmlinux
   text    data     bss     dec     hex filename
1480229  243184  259628 1983041  1e4241 vmlinux

Paul Mackerras and David S. Miller both thought this was a fantastic idea, but there was some speculation that Martin would be flamed to Hell and back for making the suggestion. Several hours later folks started expressing surprise at the absense of the expected flame-war. But at one point Alan Cox did point out, The /dev/port interface is used by various apps and its a traditional x86 in paticular unix thing. For platforms like ARM its poorly implemented since it ought to turn into a fraction of /dev/mem and support mmap for speedier user space in/out emulation.. Martin raised an eyebrow at this; he'd thought /dev/port was entirely Linux-specific. But Alan went on, The /dev/port interface is in a whole variety of older Unixen for x86, and also in systems like Minix. And elsewhere he came down more firmly against the whole idea. At this point the temperature did start to rise slightly, until Paul Rusty Russell suggested that this entire issue would be better discussed at the Kernel Summit rapidly approaching. That pretty much ended that subthread.

However, elsewhere, Linus Torvalds weighed in on the issue, saying he was OK with getting rid of /dev/port. He explained, It was done purely because Minix did it that way, and it wasn't even compatible with Minix (I think Minix actually supoorted 2- and 4-byte accesses by just doign 2- and 4-byte read/write calls, the Linux code never did). He added, Anybody: if you've ever used /dev/ports, holler _now_. Alan replied:

Pete Zaitcev also said to Linus:

Martin replied, if someone want's to use /dev/port for developement on some slow control experimental hardware for example. Why doesn't he just [...] compile it as a *separate* character device module ? That's linux - you have the source, so use it. You wan't to cheat around the OS abstractions - do it for yourself! There is no requirement that it has to be permanently in the mainline kernel where it tends to attract people who shouldn't have used it in first place for generic stuff like kbd rate settings and clock device manipulation. But Linus said:

Jon Hedlund seemed to remember hearing some warnings not to use ext3 with RAID in 2.2 kernels; but he'd been using ext3 and RAID 1 with almost no problems for over nine months. He asked if this was normal, or had he just been lucky? Andreas Dilger replied, You've just been lucky. I forget the exact scenario, but it is something like if journal replay is happening while the RAID is being reconstructed after a crash you can get garbage written to your disk. And Stephen C. Tweedie added:

Elsewhere, Mike Fedyk took credit for warning people against using those two patches in combination, and suggested:

But Stephen put in, Actually, you just need to renumber one of the conflicting #defines to something unused, and it will work fine. Soft raid0 or linear mode will work quite happily with ext3 on 2.2 after you do that, it's only the resync after a crash that you get with raid1 or raid5 that is dangerous. Later, he reiterated that this fix would only work for RAID 0.

Also in reply to Mike, Tomas Szepe objected that the recommendation to just use 2.4 was not feasible on a Sparc 32 system because of some bugs that had surfaced recently. But David S. Miller replied, There have been several patches posted to deal with that problem, you can apply them yourself or grab Marcelo's current 2.4.x BK tree. After some work, Tomas also offered:

Anders Gustafsson announced, I have started cleaning up lvm. The following patch contains the first steps. It disables a lot of functionallity but the basic things are there, I'm actually running a kernel with this patch right now, with /home and /var on lvm. The vg_t/lv_t..-structures are now available in to versions, one exported to userspace (and that should remain constant through versions) and one used in kernelspace containing stuff that should not be exposed to userspace (struct block_device, kdev_t and such). (this also allows more flexibillity making changes in the driver without changing the userspace interface). Alexander Viro was very pleased to see this, and gave some advice for the ongoing work. And Joe Thornber also said to Anders:

There was no reply.

Larry McVoy announced:

There was no reply.

Alan Cox announced:

There was no reply.

In the course of discussion, Tomas Szepe was unable to find evidence of a patch he'd been certain had been applied. He could not find it using the web interface to the BitKeeper tree David S. Miller replied:

But David Woodhouse at one point gave a link to his own BitKeeper web interface, and said That web stuff is updated by cron and is as a result never more than an hour out of date (w.r.t. bk//linux.bkbits.net/linux-2.4) unless something breaks.