Ext2 does getblk+wait_on_buffer for new metadata blocks before filling them with zeroes. While that is enough for single-processor, on SMP we have the following race:

	CPU1	CPU2
getblk gives us unlocked, non-uptodate bh wait_on_buffer() does nothing
	read from device locks it and starts IO
we zero it out.
	on-disk data overwrites our zeroes.
we mark it dirty bdflush writes the old data (_not_ zeroes) back to disk.

Result: crap in metadata block. Proposed fix: lock_buffer()/unlock_buffer() around memset()/mark_buffer_uptodate() instead of wait_on_buffer() before them.

Suppose /dev/hda1 is owned by root.disks and permissions are 640. It is mounted read-write.

Process foo belongs to pfy.staff. PFY is included into disks, but doesn't have root. I claim that he should be unable to cause fs corruption on /dev/hda1.

Currently foo _can_ cause such corruption, even though it has nothing resembling write permissions for device in question.

IMO it is wrong. I'm not saying that it's a real security problem. I'm not saying that PFY is not idiot or that his actions make any sense. However, I think that situation when he can do that without write access to device is just plain wrong.

Note that I think all these arguments are fairly bogus. Doing things like "dump" on a live filesystem is stupid and dangerous (in my opinion it is stupid and dangerous to use "dump" at _all_, but that's a whole 'nother discussion in itself), and there really are no valid uses for opening a block device that is already mounted. More importantly, I don't think anybody actually does.

The fact that you _can_ do so makes the patch valid, and I do agree with Al on the "least surprise" issue. I've already applied the patch, in fact. But the fact is that nobody should ever do the thing that could cause problems.

I have been experiencing these same problems since version 2.4.0. Although, I think it has improved a little in 2.4.4, it still locks up. The problem seems to be related to memory management and/or swap, and is seems to do it primarily on machines with over 128Mb of RAM. Although, I have not tested systematically enough to confirm this.

I have been monitoring the memory usage constantly with the gnome memory usage meter and noticed that as swap grows it is never freed back up. I can kill off most of the large applications, such as netscape, xemacs, etc, and little or no memory and swap will be freed. Once swap is full after a few days, my machine will lock up.

If I turn swap off all together or turn it off and back on periodically to clear the swap before it gets full, I do not seem to experience the lockups.

I am running on an AMD K6-400 with 256 Mb RAM but we have experienced these problems with various other machines as well.

As most of you probably know, we've got criticism a couple of weeks ago about our Linux kernel patch policy causing the LVM vanilla kernel code to differ from the one we release directly.

In order to avoid this difference we provide smaller patches more often now. We have started already with a subset of about 50 necessary patches.

Even though we get kind support from Alan Cox to get those QAed and integrated, the pure amount of patches will take at least a couple of weeks to make it in.

This leads to the dilemma, that trying to avoid further differences between our LVM releases and the stock kernel code would force us into postponing the pending LVM 1.0 release accordingly which OTOH is incovenient for the LVM user base.

In regard to this situation we'ld like to know about your oppinion on the following request: is it acceptable to release 1.0 soon *before* all patches to reach the 1.0 code status are in vanilla (presumed that we provide them with our release as we always did before)?

We'll gather your answers for some days and will send the conclusion to the lists.

This fixes a bug in the autoconfig_startech_uarts function in serial.c. The problem is that 0's are written to the baud rate registers in order to detect an XR16C850 or XR16C854. This makes the Exar ST16C654 go kablooey. Saving and restoring the baud rate registers after the test fixes it.

I'm assuming that the XR16C85[04] detection works as is and doesn't need the original baud rate restored. If I'm wrong, I'll rewrite the patch.

Linus Torvalds has requested a moratorium on new device number assignments. His hope is that a new and better method for device space handing will emerge as a result.

Alan Cox has requested that I maintain a forked registry for his -ac kernel patch tree. I have agreed to do so once I have forked off the "final" version of the registry for Linus' tree. At that time I will process the backlog for the benefit of the -ac registry only. Please have patience until I can get that to happen.

Please note that this is not my decision (in fact, I have serious concerns with it.) In particular, /dev namespace coordination still applies.

Here's my suggestion for a solution.

Once I work through a bunch of net driver problems, I want to release a snapshot block device driver (freezes a blkdev in time). For this, I needed a block major. After hearing about the device number freeze, I was wondering if this solution works:

Register block device using existing API, and obtain a dynamically assigned major number. Export a tiny ramfs which lists all device nodes. Mounted on /dev/snap, /dev/snap/0 would be the first blkdev for snap's dynamically assigned major. (Al Viro said he has skeleton code to create such an fs, IIRC)

This solution

1. keeps from grot-ing up /proc even more [I had considered proc_mknod() until viro talked me out of it]
2. does not require centrally assigned majors and minors.
3. does not require devfs. most distros ship without it afaik, and

switching to it is not an overnight process, and requires devfsd to be useful in the real world.

a 32-bit (or 64-bit) dev_t does NOT make it any easier to manage permissions or anything like that anyway. Look at the current mess /dev is. Imagine it an order of magnitude worse.

Big device numbers are _not_ a solution. I will accept a 32-bit one, but no more, and I will _not_ accept a "manage by hand" approach any more. The time has long since come to say "No". Which I've done. If you can't make it manage the thing automatically with a script, you won't get a hardcoded major device number just because you're lazy.

End of discussion.

I've been doubting whether to work on both the -ac kernels and the -linus tree, but this is a pretty good argument for sticking with -ac and just ignoring the -linus tree...

Lets see what happens...

Time will make that decision. Linus kindly gave us all the power to vote with our feet. One thing I absolutely refuse to do is to let a disagreemnt over some specific device implementation turn into an excuse for a wider difference in the trees.

So yes -ac might have static majors but the rest of it I intend to keep merging with Linus and tracking closely to his tree. Certainly not ignoring the -linus tree.

Linus, patch is the first chunk of rootfs stuff. I've tried to get it as small as possible - all it does is addition of absolute root on ramfs and necessary changes to mount_root/change_root/sys_pivot_root and follow_dotdot. Real root is mounted atop of the "absolute" one.

More interesting stuff lives in the next parts - once we have rootfs we can get rid of a lot of cruft in fs/super.c around mounting real root and switching it after initrd. In particular, we can get rid of the umount_root flag in do_umount() and kill_super() which allows much cleaner handling of vfsmounts. I'll try to feed this stuff in small and obvious pieces.

It's transparent to userland - the only visible effect is an extra line in /proc/mounts. Moreover, it's transparent to the kernel - the only functions that really care are those that do the first mount.

One point that might be better done differently - since we need ramfs for boot I've just made fs/Config.in declare CONFIG_RAMFS as define_bool CONFIG_RAMFS y. If ramfs grows (e.g. gets resource limits patches from -ac) we might be better off doing a minimal variant permanently in kernel (calling it rootfs) and making ramfs use rootfs methods. It's completely separate issue, so I've done it the simplest way for the time being.

• it makes fixing races in fs/super.c easier and we will need that in 2.4 (or, at least, backported to 2.4 at some point)
• it's backwards-compatible.
• it allows to kill tons of the ugliness in rd.c in obviously correct way, for values of obviously correct equal to "provably equivalent behaviour to the old code"

I think that it's OK for 2.4, but then I'm obviously biased (mostly by the fact that I know how much it allows to clean up without breaking any compatibility, including binary compatibility in the kernel). Up to you, indeed.

I've documented x86/i386/IA-32 Linux kernel init (after loaders). It's fairly large, so there may be too much detail here and I may cut back on it some if that seems to be needed.

Comments, feedback, corrections, and additions are welcome. As I say in the intro, hopefully some of you (or us) will find this useful/helpful.

It's viewable at http://rddunlap.home.att.net/linit/lin240_init_x86.html

Release 0.3.2 of JFS was made available today.

Drop 32 on May 18, 2001 (jfs-0.3.2-patch.tar.gz) includes fixes to the file system and utilities.

Function and Fixes in release 0.3.2

• Remove the warning message from fsck when partition is mounted read-only
• Fix for assert(mp->count) jfs_metapage.c 675! report as hardlink problem in drop 31 (dtDeleteUp was discarding the wrong metapage_t.)
• Fix seg fault problem while creating hard links.
• Fixed dbench hang, do to transaction locks not being freed.
• Added support to correctly handle read-only and remounting the file system.

For more details about the problems fixed, please see the README.

This bug unconditionally disables a configuration question -- and it's so old that it has propagated across three port files, without either of the people who did the cut and paste for the latter two noticing it.

This sort of thing would never ship in CML2, because the compiler would throw an undefined-symbol warning on BLK_DEV_ST. The temptation to engage in sarcastic commentary at the expense of people who still think CML2 is an unnecessary pain in the butt is great. But I will restrain myself. This time.

So a shortcoming of the CML1 tools justifies the CML2 language?

I guess the next bug found in the Python2 interpreter will justify writing CML3 in FORTRAN.