Since I've been talking with George off-list about trying to merge the various versions of KGDB around, and I just read the thread between Andy and Jim about conflicting on KGDB work, I've put up a BitKeeper repository (If anyone here won't / can't use BitKeeper, I'll happily move over to a repo someone else sets up in something else.) to try and coordinate things.

What's in there right now is Amit's kgdb 2.1.0, without the ethernet patch. There's also all of the changes for PPC and for generic stuffs that I've been doing of late.

What I'll be doing shortly (this afternoon even) is to change from a struct of function pointers, for the arch specific functions, into a set of provided, weak, variants and then allow arches to override as needed.

What I'd like is for someone to move the ethernet bits from the -mm tree into here, and for people to merge the fixes / enhancements that're in their per-arch stubs in the -mm tree into the split design that Amit's version has.

here's the highlights of what I've done so far:

ChangeSet@1.1510, 2004-01-30 11:14:44-07:00, trini@kernel.crashing.org
  Lots of changes to the serial stub driver.
  In sum, it's got many of the features (but not all) of George
  Anzginer's version (+ fix or two), and fully flushed out and tested
  support for SERIAL_IOMEM.

ChangeSet@1.1509, 2004-01-30 11:10:03-07:00, trini@kernel.crashing.org
  Change *kgdb_serial into kgdb_serial_driver.  We will now have
  only one serial driver.

ChangeSet@1.1508, 2004-01-30 10:44:55-07:00, trini@kernel.crashing.org
  Convert the kgdb ethernet driver over to netpoll.
  Patch from Pavel Machek <pavel@suse.cz>, who warns this probably
  doesn't work.

ChangeSet@1.1505, 2004-01-29 14:30:47-07:00, trini@kernel.crashing.org
  Move all KGDB questions into kernel/Kconfig.kgdb.

ChangeSet@1.1504, 2004-01-27 16:59:06-07:00, trini@kernel.crashing.org
  - PPC32: Add KGDB support for PRePs (part of MULTIPLATFORM).
  - PPC32: Add a choice of baud rate for the gen550 backend.

ChangeSet@1.1503, 2004-01-27 14:44:54-07:00, trini@kernel.crashing.org
  Remove the function pointers from kgdb_ops.
  Most have become kgdb_foo, instead of foo.  The exceptions
  are the gdb/kgdb register fiddling functions.
  kgdb_gdb_regs_to_regs makes my head hurt.

ChangeSet@1.1502, 2004-01-27 11:46:13-07:00, trini@kernel.crashing.org
  Merge by hand to current 2.6 bk.
  --- UNTESTED, x86_64 might be broken ---

ChangeSet@1.1474.149.3, 2004-01-27 11:32:54-07:00, trini@kernel.crashing.org
  - Send a 'T' packet initially, not an 'S' followed by 'p'
  - On PPC32, try to pass in the correct signal back.

I'm mostly happy with the serial changes (and I'll set aside the user console bits from George's version for now), but comments and criticisms would be welcome. And as a reminder the BitKeeper version is bk://ppc.bkbits.net/linux-2.6-kgdb and there's snapshots (thanks Dave!) at http://www.codemonkey.org.uk/projects/bitkeeper/kgdb

ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.3-rc1/2.6.3-rc1-mm1/

• NFSD update
• MD update
• Added Randy's include/linux/syscalls.h work, to address a pet peeve.
• Various fixes
• Added early printk for ia32. It simply does #include "x86_64's version".
• I'll probably drop the CPU hotplug patches next time. They've been tested and they now appear to be obsolete.
• Unless suddenly persuaded otherwise I shall also drop the enhanced ia32 CPU-type selection patches (retaining pentium-M support). Sorry Adrian, but they do not seem to have sufficient value, given the general intrusiveness and patch footprint.

Boggle. That thing is 1.8MB.

163 files changed, 25877 insertions(+), 22424 deletions(-)

This is the first time that anyone told me that it even existed. How on earth could a patch to a major subsystem grow to such a size in such isolation? When we're at kernel version 2.6.3!

How mature is this code? What is its testing status? What is the size of its user base? Is it available as individual, changelogged patches?

It would be crazy to simply shut our eyes and slam something of this magnitude into the tree. And it is totally unreasonable to expect interested parties to be able to review and understand it.

Could someone please tell me how this situation came about, and what we can do to prevent any reoccurrence?

I don't know more than this:

http://marc.theaimsgroup.com/?l=linux-kernel&m=107523583528989&w=2

But I _do_ know that ISDN is non-working for me with 2.6.x kernels without this patch.

We've had this discussion before, haven't we? And all the solutions seemed to involve not having just one person approve things, which isn't likely to change. I don't recall seeing WHEN it was sent to Linus, but clearly something working in 2.4 and not in 2.6 probably shouldn't wait years for 2.8.

I guess the real question is how invasive it is, this isn't the first time I've heard that 2.6 ISDN doesn't work, so it's not as if putting it in -mm would break ISDN, the question is how many other things are touched and might break.

At least it seems to have been widely tested, and is based on something which is in a stable kernel. A maintainer's lot is not a happy one, and you have my sympathy.

Maybe leave it in -mm for a bit and not promote it until people have a chance to really beat on it?

here is a really big patch for ISDN in kernel 2.6. The reason for this big patch is, that I give up to fix the bugs in the new implementation of the obsolate (but currently most used) I4L code. Here are too much changes that never work in this code and since the authors of the new implementations don't have time (here was no real effort since half an year) I started a new port of the well working and stable 2.4 I4L code to 2.6.

Note: The new port is only for the old I4L part, which is common used up to now, not for the new CAPI like interface, which got a new design in 2.5 and should become the successor of I4L, but here are only few cards with CAPI drivers at the moment. This will change soon, but since all distributions depend on the old I4L stuff at the moment, here is a strong need to have a working I4L part in the kernel now. Since new year I got ~500 mails dialing with ISDN problems and kernel 2.6.

This stuff is well tested on my equipment (~40 different cards) and also tested by few other people.

The diff is against the current patch-2.6.2-rc1-bk3 version and should apply clean.

Kai Germaschewski was maintaining the ISDN code in 2.4/2.5 and did a big redesign in all parts in 2.5, to prepare ISDN4Linux for the CAPI interface, which should make the I4L interface obsolate (CAPI Common ISDN API, is a common standard for ISDN application), my job was to develop a CAPI hardware driver for passive cards as a replacement of hisax, this is known now as mISDN driver (modular ISDN driver), but this driver supports only few of the cards which are supported by hisax at the moment.

Kai did a good job, but he changed also lot of the old (coming obsolate) code in incompatible ways and his changes never were complete and tested in practice, also not from himself, his changes were only academic, because he left Germany to a study in US and in US he had never access to ISDN. I was aware that he is in US, but I was to stupid to recognise this missing ISDN problem, I thought he had some NI1 line in US too. Since also I was too busy to play with his 2.5/2.6 stuff last year and also nobody else did (I got only compiling fixes during 2.5/6) we run into this situation. After first 2.6 versions came out I got many reports about ISDN and 2.6 issues in last august. Since then I tried to fix the code and get a partial working version in october??, but as I had more time during XMas I did lot of regression test and run into lot of problems with the new code, and even fixing some of these bring up a bundle of new problems. So I ask all remaining I4l developers for help, but nobody take care/has time.

So I make a proposal to start a new 2.4 -> 2.6 port of the old I4L interface, since I know the 2.4 code very well (since most of the driver code is from me) and 2.4 ISDN is known as very stable and has got also some certification from telecomunication authorities.

Nobody of the other I4L developers complain and the result was this patch.

I was preparing new patch last days against current 2.6 version but since I got ill last weekend, it is not finished yet, but hopefully during next houres. I have also BitKeeper running here with a clone of the linux-2.5 tree, so if you prefer a bk diff I can also prepare one (but note, I'm a BK beginner).

Here are the latest versions, since they are so big only as reference: Linus tree:
ftp://ftp.isdn4linux.de/pub/isdn4linux/kernel/v2.6/i4l-2.6.3-rc1-bk2.gz

Andrew tree:
ftp://ftp.isdn4linux.de/pub/isdn4linux/kernel/v2.6/i4l-2.6.3-rc1-mm1.gz

The result of both patches are the same source, but in Andrews tree some smaller fixes were already included, to avoid rejects I created patches for both trees.

ChangeLog:

• new port of 2.4 I4L core to 2.6
• new port of 2.4 I$L HiSax to 2.6
• fixes for I4L CAPI subsystem to make it stable in 2.6
• fix parameter handling of AVM ISA cards (calle)
• cleanup ISDN config variables

These patches are in sync with I4L cvs (kernel 2.6 branch).

How about including the NFSACL patch from acl.bestbits.at? One reason for people to move to 2.6 from 2.4 is that they no longer need to patch the kernel to get ACL support. Unless they want to have ACL support over NFSv3 that is... NFSACL support is quite an argument for Linux in an existing Solaris production environments, so i would like to see it included into the mainstream kernel ASAP (Note: I am not speaking for Andreas and the other people working on the ACL code!). Including it into -mm would give it the necessary exposure.

The patch is available in broken up form at:
http://acl.bestbits.at/current/diff/nfsacl-2.6.1-0.8.67.tar.gz

And before somebody mentions NFSv4: This is not (yet) an option for production environments.

Uhhuh. There was a bit more pending, so here's a -rc2. Now please calm down, I'd like this to have some time to stabilize..

The rc1->rc2 changes are mostly driver side stuff: PnP update, USB, ACPI, IRDA, i2c, hotplug-PCI and netdrivers etc. But there's a NFSv4 update and soem XFS fixes there too.

And some ARM and sparc updates.

I have setup a cvs repository for kgdb at sourceforge. Those who plan to contribute to kgdb on a regular basis, feel free become add yourself as developers to this project and checkin changes yourself.

Here is cvs access information for users of kgdb:

kgdb project page includes instructions for accessing kgdb cvs tree. Here is a quick download guide for users of kgdb.

cvs -d:pserver:anonymous@cvs.sourceforge.net:/cvsroot/kgdb login

cvs -z3 -d:pserver:anonymous@cvs.sourceforge.net:/cvsroot/kgdb co .

These instructions will fetch latest kgdb development version in current directory. The directory kgdb-2 contains kgdb for 2.6 kernels. For further updates, go to the same directory and run cvs update

I'm doing some work where it would simplify things greatly to have copy-on-write semantics available.

I've seen overlayfs and the proposed "-union" option for mount, but there doesn't seem to be anything thats really ready for serious use.

Am I missing something? Is someone working on this?

http://vserver.13thfloor.at/TBVFS

no active work atm, but some info/links maybe

During the last two years, we have deployed some 400+ linux firewall machines, all of which use reiserfs 3.6 for all of their filesystems. While some of these boxes live in very wild environments (attics, cellars, under the bed, in public block-of-flats corridors, ...) and we've seen hardware die, there have been zero filesystem problems. I think I can say we're happy with how reiser3 has fared so far.

Sounds a bit like from your favorite marketing department, but still I thought you might want to know.

Here goes -rc2, with small number of fixes and corrections.

Most notably acpi4asus and toshiba ACPI updates.

In almost all distributions, the kernel asks for modules which don't exist, such as "net-pf-10" or whatever. Changing "modprobe -q" to "succeed" in this case is hacky and breaks some setups, and also we want to know if it failed for the fallback code for old aliases in fs/char_dev.c, for example.

Just remove the debugging message which fill people's logs: the correct way of debugging module problems is something like this:

echo '#! /bin/sh' > /tmp/modprobe
echo 'echo "$@" >> /tmp/modprobe.log' >> /tmp/modprobe
echo 'exec /sbin/modprobe "$@"' >> /tmp/modprobe
chmod a+x /tmp/modprobe
echo /tmp/modprobe > /proc/sys/kernel/modprobe

I couldn't think of, or find a good place to put this, so I put the information in it's own file. I'm only moderately sure I've generated the patch correctly. However, it does apply with patch -p1 to a clean 2.6.3-rc2-bk2 tree, so it should be fine.

The wording is a slightly changed version of what Rusty said at the start of this thread.

Userspace probes the kernel to see if IPv6 is available by trying to create an IPv6 socket.

The correct solution is to fix /etc/modprobe.conf such that it doesn't try to load the module when you don't have it configured:

install net-pf-10 /bin/true

Note that if you alias net-pf-10 to ipv6 before this install line, you need to replace net-pf-10 with ipv6 in the install line.

PS, I notice Arjan's RPM packages don't seem to contain the modprobe.conf manual page... maybe this is what's causing some of the confusion?

PPS, It might also help to either mention in the man page that the above corresponds to the original "alias modulename off" _or_ add "install off /bin/true" into modprobe.conf.dist such that the old alias line works as expected.

If Andrew prefers keeping it into -mm for a while, I can do a big patch from the bk tree, though this patch is putting other ppc64 stuffs on hold for now, so it shall go in asap (as it would be too nasty to deal with conflicts if other things went in at this point).

Linus: you will probably need an updated radeonfb anyway as I told you. I'll start working on it now and will post a patch separately.

Also, there is currently a known build problem with the zImage wrapper in 2.6.3-rc2, unrelated to this patch, it doesn't prevent the build of the plain vmlinux which is what yaboot uses on the G5.

Finally, ieee1394 triggers an oops in kobject since 2.6.3-rc2, 100% reproduceable for me (and apparently x86 users too), so that's also unrelated to the G5 code.

Actually, at least for me, the _old_ radeon driver works without any modifications at all in text mode. Rock stable image, unlike the new one that needed the clock fixes.

But trying to start X hangs the system hard, which may well be an issue with the old radeonfb. Whenever you have a new driver, I will test.

Here is the new radeonfb. It doesn't remove the old one, just in case, though CONFIG_FB_RADEON now builds the new one.

I also had to add an empty fb_set_suspend() function to fbmem.c (the real implementation is in James tree and will be here soon). That means that Power Management on Apple laptops isn't completely right yet until the core fbdev fixes get in, but that's probably enough for 2.6.3.

The patch is too big to put in the email text uncompressed, so here it is as a bzip2 attachment.

James: The version in your tree is good too, when merging your stuff, you should ignore the few radeonfb diffs and let me deal with them.

Linus: This new driver uses framebuffer_alloc/release, so if you back out the fb sysfs patch, make sure to replace it with wrapper functions that just kmalloc/kfree

ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.3-rc2/2.6.3-rc2-mm1/

• Added the big ISDN update
• Device Mapper update

"I think the 90x25 requirement is silly"

"I think the 100x25 requirement is silly"

And so it goes. You get into an xterm arms race wherein everyone has to make their terminal as wide as the widest guy so anyone can get any work done.

Yes, 80 cols sucks and the world would be a better place had CodingStyle mandated 96 columns five years ago. But it didn't happen.

I've released the 017 version of udev. It can be found at:
kernel.org/pub/linux/utils/kernel/hotplug/udev-017.tar.gz

rpms built against Red Hat FC1 are available at:
kernel.org/pub/linux/utils/kernel/hotplug/udev-017-1.i386.rpm
with the source rpm at:
kernel.org/pub/linux/utils/kernel/hotplug/udev-017-1.src.rpm

udev allows users to have a dynamic /dev and provides the ability to have persistent device names. It uses sysfs and /sbin/hotplug and runs entirely in userspace. It requires a 2.6 kernel with CONFIG_HOTPLUG enabled to run. Please see the udev FAQ for any questions about it:
kernel.org/pub/linux/utils/kernel/hotplug/udev-FAQ

For any udev vs devfs questions anyone might have, please see:
kernel.org/pub/linux/utils/kernel/hotplug/udev_vs_devfs

Major changes from the 015 version:

• lots of udevd and udevsend cleanups and tweaks. udevd can now be built with klibc, and doesn't need a lock file anymore to work.
• lots of bug fixes and other cleanups.
• shrink the size of the database by a large amount.

In all, there is nothing major in this release, but any current users of udev will want this version for all of the bugfixes if for nothing else.

Thanks a lot to Chris Friesen and Kay Sievers for cleaning up the udevd and udevsend communication path and code so much. I really appreciate it.

Thanks also to everyone who has send me patches for this release, a full list of everyone, and their changes is below.

udev development is done in a BitKeeper repository located at:
bk://linuxusb.bkbits.net/udev

Daily snapshots of udev from the BitKeeper tree can be found at:
http://www.codemonkey.org.uk/projects/bitkeeper/udev/
If anyone ever wants a tarball of the current bk tree, just email me.

Martin J. Bligh has for some time been producing results of a benchmark he devised called "kernbench" which is designed to measure cpu throughput, with emphasis on SMP systems.

I set out to make this benchmark a portable and easy to use script for anyone with adequate hardware to perform kernbench, after some feedback from MJB. All the SMP work currently underway inspired this. So here is the first public release:

http://ck.kolivas.org/kernbench/

What it does:

It runs the venerable kernel compile a number of different ways: It cleans and primes a kernel tree with a make defconfig. Then it reads all the kernel source to cache it in ram. Then it will perform a number of different kernel compiles after a warmup run compile the same as the one it is about to test. Then it times the following runs 5 times:

half load: make -j (NR_CPUS/2)
optimal load: make -j (NR_CPUS*4)
maximum load: make -j

Optionally it can also perform a single threaded make, the number of jobs for optimal can be defined, the number of runs can be defined, and any of the default runs can be disabled.

Then it will print out an average of each of the loads with some useful statistics. A sample from an IBM X440 8x1.5Ghz P4HT on linux-2.6.3-rc2 follows:

Average Single Threaded Run:
Elapsed Time 1069.65
User Time 965.894
System Time 117.856
Percent CPU 101
Context Switches 6223.2
Sleeps 23056.4

Average Half Load Run:
Elapsed Time 120.808
User Time 802.428
System Time 92.072
Percent CPU 740
Context Switches 10613.6
Sleeps 26667

Average Optimum Load Run:
Elapsed Time 81.59
User Time 1007.89
System Time 112.36
Percent CPU 1372.6
Context Switches 63006.2
Sleeps 40406

Average Maximum Load Run:
Elapsed Time 82.944
User Time 1012.33
System Time 122.424
Percent CPU 1367.6
Context Switches 44822.2
Sleeps 22161

A few points:

Do not try to run the maximum load on a machine with less than 2Gb ram, as swap thrashing is likely, so the benchmark will not be a cpu throughput one but a vm benchmark (of course you may want to do this too).

It is best run on a non-journalled filesystem to minimise the effects of the journal write-out; although this is probably not greatly important.

If run on a 4x box, the half load will be make -j2. The problem with compiling a kernel at make -j2 is that usually only one job spawns so the results may not be very useful.

Cliff if you want to wrap this into an OSDL benchmark, it may be worthwhile profiling each group of runs together and using the -s option by default as a separate "kernbench-long" to include the single threaded runs.

Thanks, Martin for the idea and feedback. Thanks osdl for the hardware for development, and others for code help.

This patch updates UML to 2.6.3-rc2. This breaks with my usual practice of ignoring test patches. However, when I updated my UML tree, I had forgotten that my stock Linus tree was up to 2.6.3-rc2. I took this as a sign from a higher power that this was Meant To Be.

As well as catching up, there are some bug fixes and cleanups -
modules should now work
worked around a process start time bug
fixed a bug which caused ps to divide by zero

The 2.6.3-rc2-1 UML patch is available at
http://www.user-mode-linux.org/mirror/uml-patch-2.6.3-rc2-1.bz2

BK users can pull my 2.5 repository from
http://www.user-mode-linux.org:5000/uml-2.5

For the other UML mirrors and other downloads, see
http://user-mode-linux.sourceforge.net/dl-sf.html

Other links of interest:

The UML project home page : http://user-mode-linux.sourceforge.net
The UML Community site : http://usermodelinux.org

this patch backs out James' sysfs support for fbdev again. It introduces a big, race for every driver not converted to framebuffer_{alloc,release} (that is every driver but Ben's new radeonfb).

I've left in framebuffer_{alloc,release} as stubs so drivers can be converted to it gradually and once all drivers are done it can be enabled again.

<rant>
James, what about pushing the 2GB worth of fbdev driver fixes in your tree to Linus so people actually get working fb support again instead of adding new holes? A maintainers job can't be to apply patches to his personal CVS repository and sitting on them forever
</rant>

at this point I WOULD NOT EVEN TAKE IT ANY MORE.

That's just how I work: if somebody maintains his own tree and builds up a lot of patches, that's _his_ problem. I'm not going to replace things totally unless there is some really fundamental reason I would have to. And quite frankly, the most common "fundamental reason" is that the maintainer has not done his job.

I want controlled patches that do one thing at a time. Not a 2GB untested dump.

These things need to be done in a timely fashion, incrementally, one thing at a time. Anything else does not work.

And btw, for anybody who is impacted by this: you are encouraged to help. If you have a machine that works with some out-of-tree code but does _not_ work with the in-tree code, send a patch that fixes JUST THAT BUG.

Because if James can't trickle them in, somebody else will have to. That's what happened with the new radeon driver.

More merges, although most of them are architecture updates. IA64, ppc32/64, SuperH and ARM.

But also some cpufreq, watchdog and ACPI updates.

This patch updates the PowerMac-only platinumfb driver to use the new mac-io device infrastructure. It also switch allocation to the new framebuffer_alloc/release and fix a couple of bugs.

I finally found the old hardware to really test it so please apply :)

ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.3-rc3/2.6.3-rc3-mm1/

• New hotplug CPU implementation from Rusty
• Dropped the x86 CPU-type selection patches
• Added support for dynamic allocation of unix98 ptys.

Here goes the third 2.4.25 release candidate.

This release includes a few important net fixes, amongst others.

ftp://oss.sgi.com/projects/kdb/download/v4.3/

With many thanks to Jim Houston and Xavier Bru.

Current versions are :
kdb-v4.3-2.6.3-rc3-common-1.bz2
kdb-v4.3-2.6.3-rc3-i386-1.bz2
kdb-v4.3-2.6.3-rc3-ia64-1.bz2

Warning: the 2.6 versions of kdb have had minimal testing. In particular they have not been tested with CONFIG_PREEMPT.

I'm planning on doing the final 2.6.3 tomorrow, so please test this final -rc.

Most notably, this should support ppc/ppc64 out-of-the-box, complete with G5 support (64-bit). Special thanks to BenH who made sure the new radeonfb driver works on a wide variety of hardware (a number of the fixes here relative to -rc3 was making sure the driver works on regular x86 laptops).

Apart from the radeon updates, there's some IDE oops fixes (and cleanups), and a SELinux update.

And yes, document the fact that sparc is no longer f*cked up (both atomics and irq save/restore now work the way they always did everywhere else).

ftp://oss.sgi.com/projects/kdb/download/v4.3/

Current versions are :

kdb-v4.3-2.6.3-rc4-common-1.bz2
kdb-v4.3-2.6.3-rc3-i386-1.bz2
kdb-v4.3-2.6.3-rc3-ia64-1.bz2

The arch specific i386 and ia64 patches have not changed between rc3 and rc4. Use the arch rc3 patches with rc4-common-1.

Warning: the 2.6 versions of kdb have had minimal testing. In particular they have not been tested with CONFIG_PREEMPT.

The following is my next attempt at a different KGDB stub for your tree (and then hopefully into kernel.org). This is against 2.6.3-rc4 + bk-netdev-rc3 (from your tree), and nothing else. This has been tested on PPC32 (KGDB=y/n) and i386 (KGDB=y and allmodconfig) and not at all on x86_64 (no time to build a toolchain yet). Since the last time, I've done the following:

• SysRq-G is always part of SYSRQ && KGDB.
• choice for I/O (8250 serial, kgdboe and PPC 'simple' serial, for now).
• On x86_64 / PPC32, we don't bother with CHK_DEBUGGER, but instead always use the arch provided debugger hooks.

Thre are 6 different patches:

core.patch: All of the non-arch specific bits, that aren't drivers.
8250.patch: The i/o driver for KGDB, via a standard PC uart.
kgdboe.patch: The i/o driver for KGDB, via netpoll.
i386.patch: The i386-specific code, tested.
ppc32.patch: The ppc32-specific code, tested.
x86_64.patch: The x86_64-specific bits, untested.

One last note. For some reason, kgdboe isn't working for me right now. But it doesn't look like it's something specific to the kgdboe driver (Dropping in the -mm one and changing names to match still shows it, and the serial driver is solid) so I'm not sure if it's anything other than my bad luck today. So if nothing else, if someone else could give this a shot and let me know if it works for them...

I don't agree. I did a few more cleanups after Andi expressed concerns over globals kgdb_memerr and debugger_memerr_expected.

I liked Pavel's approach. Let's first get a minimal kgdb stub into mainline kernel. Even this much is going to involve some effort. We can merge other features later.

Let's create a cvs tree at kgdb.sourceforge.net for kgdb components to be pushed int mainline kernel. This split is to keep current kgdb unaffected. People who are already using it won't be affected.

May I suggest we breakup this task into following tasklets. I have expanded item 1 because Pavel has something that's already close. The rest of the items can be discussed in detail later. These need not be done in this order except for first 2 whose sequence is fixed.

1. A minimal kgdb stub

   core.patch:

   kgdbstub.c full.
   No changes to module.c
   No changes for CONFIG_KGDB_THREAD
   No changes to calling convention of do_IRQ (Needs to be done)
   CONFIG_KGDB_CONSOLE removed i386.patch
   No changes for CONFIG_KGDB_THREAD
   No manipulation of kernel stack before entry into do_IRQ
   No non-source level CFI directives.

2. Minimal x86_64.patch
3. Patch to sync ppc kgdb with arch independent stub
4. Patch to sync other architecture kgdbs with arch independent stub on help from maintainers of those architectures.

5. KGDB_CONSOLE patch

   This is a must for embedded boards that have only one serial port

6. gdb automatic module loading

7. CONFIG_KGDB_THREAD patch

   This may or may not be a separate config option. This patch will include x86_64 support required to enable threads.

8. i386 thread support
9. Ethernet interface based on netconsole
10. ... Any other features

final:

- 2.4.25-rc4 was released as 2.4.25 with no changes.

I've just grepped over the tree for reamining MOD_INC_USE_COUNT users, and ftape is a really horrible one, it relies on MOD_{INC,DEV}_USE_COUNT in the most horrible places + it's own bookkepping and the <= 2.4 may unload hooks. And although I don't have the hardware I can guarantee it doesn't work as expected.

So let's just remove the module_exit handler and mark it unremovable, if someone wants to fix up ftape later it's fine with me, but it's a really scary driver..

Since it seems nobody posted it yet (at least I hope so) :

http://www.isec.pl/vulnerabilities/isec-0014-mremap-unmap.txt

It is a local root exploit.

There was also a Proof-of-concept exploit released:

http://www.derkeiler.com/Mailing-Lists/Securiteam/2004-02/0052.html

There is still a call to do_munmap() that does not check the return code, called from move_vma(), which in turn is called in do_mremap().

Can that call ever fail and cause Bad Things to happen?

This patch against 2.6.3 implements Netlink based notifications for SELinux kernel events. This will allow SELinux userspace components to maintain synchronization with kernel state.

For example, a userspace AVC (Access Vector Cache, the component that makes access control decisions) is being implemented for use by Security Enhanced X and SE-DBUS. These applications will request access control decisions from the usersapce AVC, which will relay and cache decisions from the kernel AVC.

When the security policy is reloaded or the enforcing mode is changed in the kernel, the userspace AVC can be notified and take appropriate action (e.g. flush cache).

KDB (Linux Kernel Debugger) has been updated.

ftp://oss.sgi.com/projects/kdb/download/v4.3/

Current versions are :

kdb-v4.3-2.4.25-common-1.bz2
kdb-v4.3-2.4.25-i386-1.bz2
kdb-v4.3-2.4.25-ia64-040218-1.bz2

The ia64 patch has changed slightly since kdb-v4.3-2.4.25-rc1, due to more clean ups in the base arch/ia64/kernel/mca.c file. Apart from that, the only changes are to the target kernel name in the change logs.