2.4.19pre8aa3

The main differences with the previous aa2 are:

o sparc64 should work now (untested)
o merged NUMA-Q NUMA arch support from IBM
o various other fixes also from -ac
o minor bdflush tuning difference to avoid char-writer in bonnie
to stall and to slowdown too much (can make a difference in real life)
o latest UML (also fixed initrd loading)
o really release initrd ram0 memory

URL full -aa patchkit:

	http://www.us.kernel.org/pub/linux/kernel/people/andrea/kernels/v2.4/2.4.19pre8aa3.gz
	http://www.us.kernel.org/pub/linux/kernel/people/andrea/kernels/v2.4/2.4.19pre8aa3/

Only the VM changes in the -aa patchkit against vanilla 2.4.19pre8 (ready for inclusion in mainline):

	http://www.us.kernel.org/pub/linux/kernel/people/andrea/patches/v2.4/2.4.19pre8/vm-35.gz
	http://www.us.kernel.org/pub/linux/kernel/people/andrea/patches/v2.4/2.4.19pre8/vm-35/

Diff between 2.4.19pre8aa2 and 2.4.19pre8aa3:

Only in 2.4.19pre8aa3: 00_bdflush-tuning-1

Put the mid watermark at 50% (near the high watermark so we don't stall too much).

Only in 2.4.19pre8aa3: 00_dnotify-cleanup-1

Dnotify cleanups (minor improvements actually) from 2.4.19pre8ac2.

Only in 2.4.19pre8aa3: 00_ext3-register-filesystem-lifo-1

Make sure to always try mounting with ext3 before ext2 (otherwise it's impossible to mount the real rootfs with ext3 if ext3 is a module loaded by an initrd and ext2 is linked into the kernel).

Only in 2.4.19pre8aa2: 00_initrd-free-1 Only in 2.4.19pre8aa3: 00_initrd-free-2

Backout wrong patch and insert the printk fix. However the unmount in /old keeps returning -EINVAL of course, that's at the very least misleading, it would also be nice some documentation on the exact semantics of MS_MOVE, tested mount --move under UML but it's not at all clear what's going on with the "/", ".", ".." and didn't had the time to reverse engeneer the semantics from the code in do_move_mount yet (started and I will continue in the next days, but interpreting the code with some basic lines of what I should expect would be faster). Printk fix from Al.

Only in 2.4.19pre8aa3: 00_reaper-thread-race-1

	SMP race fix that avoids losing reference of zombies with threads exits
	from 2.4.19pre8ac2.

Only in 2.4.19pre8aa3: 00_ufs-compile-1 Only in 2.4.19pre8aa3: 00_umem-compile-1

Compile fixes (ufs from Hubert Mantel).

Only in 2.4.19pre8aa2: 05_vm_10_read_write_tweaks-1 Only in 2.4.19pre8aa3: 05_vm_10_read_write_tweaks-2

Avoid backing out the flush_page_to_ram in this vm patch, the one on the pagecache is still needed before the memcpy on the pagecache during the early cow (would be cleaner to move it up, if Hugh wants to clean it up that's welcome, it will be an orthogonal patch, so far I just avoid to change that area in my changes, not high prio to clean it up as DaveM side it's more high prio to conver the users of flush_page_to_ram API to flush_dcache_page/icache new API during 2.5).

Only in 2.4.19pre8aa3: 21_pte-highmem-24-sparc64

Now -aa is suposed to work fine with sparc64 (still untested though).

Only in 2.4.19pre8aa2: 50_uml-patch-2.4.18-22.gz Only in 2.4.19pre8aa3: 50_uml-patch-2.4.18-25.gz Only in 2.4.19pre8aa3: 52_uml-sys-read-write-1 Only in 2.4.19pre8aa2: 59_uml-compat-2.5-1 Only in 2.4.19pre8aa3: 59_uml-compat-2.5-2 Only in 2.4.19pre8aa2: 62_tux-uml-1
Only in 2.4.19pre8aa3: 62_tux-uml-2

UML updates (in particular fixes initrd loading, in previous version read/write/lseek was calling glibc read/write/lseek on the host instead of sys_read/sys_write/sys_lseek :).

Only in 2.4.19pre8aa2: 91_zone_start_pfn-2 Only in 2.4.19pre8aa3: 91_zone_start_pfn-3

Convert all archs to the new API (including sparc64, guess why :).

Only in 2.4.19pre8aa3: 93_NUMAQ-1

	NUMA-Q support from Patricia Gaughen (very clean integration, I liked
	it).

Andrea

PS. Leaving in a few minutes to go watch the attack of the clones :)

Hmm, I don't think this is true. While I'm not an initrd user, people have been doing this with RH for quite some time. Note that it is not necessarily true that they get it _correct_ all the time, but eventually it works. Apparently you need to explicitly specify the root filesystem type for the initrd mount.

Note that I haven't seen the patch in question yet (mirrors don't have it), but somehow I don't think that changing the order of the registration is going to help. If they have both ext2 and ext3 as modules, and insmod ext3 first and ext2 second, you've just broken their setup. Similarly, (depending on how it is done) I imagine this would break kernels that have both ext3 and ext2 compiled in.

The only reasonable solution is to not guess at the root filesystem type and mount it with the correct type explicitly. I think the RH mkinitrd will check /etc/filesystems for the root fs and use the type there. If the user forgets to run mkinitrd after changing their kernel, there is not much you can do about that.

What _may_ be helpful is if ext2 printed a small warning that it is mounting a filesystem with a journal as ext2 and no journaling will be done, if the user really wanted to do that (normally they will not).

This will at least alert some users that their root filesystem is not being mounted as ext3 and eliminate a number of support requests on ext2-devel when initrd users are wondering why e2fsck is being run on their supposedly journaled filesystem. The fact that "mount" output shows ext3 as the filesystem type (while 'cat /proc/mounts' shows ext2) does nothing to help the user figure out what is wrong.

Cheers, Andreas
--
Andreas Dilger
http://www-mddsp.enel.ucalgary.ca/People/adilger/
http://sourceforge.net/projects/ext2resize/

Funny, I've been doing this for months.

Maybe you should look into pivot_mount(2) and pivot_mount(8) some day ?

Rik

Bravely reimplemented by the knights who say "NIH".

http://www.surriel.com/		http://distro.conectiva.com/

I'm not sure if you really understood what the problem is from my description above because your kind suggestion doesn't make sense to me.

First of all there's no pivot_mount but there's only pivot_root (never mind, it is clear you meant pivot_root).

Secondly pivot_root has nothing to do with handle_initrd.

Go read init/do_mounts.c::handle_initrd. There are only two ways:

1) you specified rootfstype=ext3, then the real rootfs will be mounted as ext3 and not as ext2, but the initrd must also be mountable by ext3 and that's not the case normally (the same rootfstype will apply to both the initrd and the real root fs, the fact rootfstype applies to both doesn't make sense but that's another issue and I don't want to be forced to use rootfstype anyways, I don't like having to pass an argument for something that can be done at runtime by the kernel).
2) you didn't specified rootfstype=, in such case ext2 will be tried first because it got registered first because ext2 is linked into the kernel and ext3 is a module

That's all, and that's an autodetection bug because ext3 must be always tried first, there's no point at all to try to mount with ext2 before ext3 (of course unless rootfstype= is specified).

If it works for you it means you regularly reboot with SYSRQ+B (or some workaround on those lines), and so ext2 doesn't mount and in turn ext3 is later tried. otherwise if ext2 mounts cleanly ext3 is _never_ tried and you cannot mount ext3 as rootfs without my patch that enforces the ordering.

Make sure to check with /proc/mounts that your rootfs is really using ext3 and not ext2, or you may not notice.

If it works for you it's probably because ext2 is a module too, or maybe more simply because ext3 is linked into the kernel.

Andrea

There's a third way, which is used on the initrd of most distros:

--- snip from linuxrc ----
mount --ro -t $rootfs $rootdev /sysroot
pivot_root /sysroot /sysroot/initrd
------

This way you can specify both the root fs and - if wanted - special mount options to the root fs. Then you pivot_root(2) to move the root fs to / and the (old) initrd to /initrd.

The initscripts then umount /initrd, after which the initrd data gets freed.

regards,

Rik

Bravely reimplemented by the knights who say "NIH".

http://www.surriel.com/		http://distro.conectiva.com/

I'm not using the full blown initrd of most distros that is aware of the mistery of life and of all the kernel bugs out there too, my own dumb linuxrc just says:

echo hello world

and then returns, and ext3 gets mounted as ext2 and that's a kernel bug, all other fs gets mounted correctly with my initrd, only ext3 gone wrong until I fixed it.

both lines are completly superflous, very misleading as well. I recommend to drop such two lines from all the full blown bug-aware linuxrc out there (of course after you apply the ordering fix to the kernel).

About the "special mount options", now since 2.4.19pre if you try to pass different flags to your mount in linuxrc and the kernel, you will fail to mount the real root fs, if you want to pass the "if wanted special mount options" they must be passed via the kernel parameter only, they cannot be inside the linuxrc knowledge or the kernel mount will fail.

you also need to call flushb /dev/ram0 to free the initrd memory after umount /initrd, if you do it in userspace without using the automation in do_mounts.c.

Andrea

Then I guess we found the problem. ;)

Personally I hope the special initrd code gets moved from kernelspace into userspace.

regards,

Rik

Bravely reimplemented by the knights who say "NIH".

http://www.surriel.com/		http://distro.conectiva.com/

disagreement, my initrd is not the problem. the kernel code is really explicit about what it will do with the real root fs, it will mount it by itself, I am definitely not required to mount it by myself within linuxrc, for sure not to workaround a bug in the kernel, and now in 2.4.19pre mounting it in linuxrc is even worse idea because the mount will likely fail at the first different mount option. linuxrc is allowed to just run exit(2) and the real root fs must still be mouned correctly, that is the linuxrc API.

I don't care about this part, if it gets changed I will update my initscripts to act accordingly, however requiring all linux users to update their init scripts in mid/late 2.4 is probably not a good idea, if you really want to drop such two lines then do it in 2.5 only (not recommended, still it's a gratuitous API change IMHO).

Andrea

Have you thought about reading Documentation/initrd.txt and following the described method? (last modified December 2000 according to the comments and the mtime on the file).

The method you're using has therefore been marked "obsolete" for almost two and a half years:

| Obsolete root change mechanism
| ------------------------------
| 
| The following mechanism was used before the introduction of pivot_root.
| Current kernels still support it, but you should _not_ rely on its
| continued availability.

Russell King ([email protected])                The developer of ARM Linux
             http://www.arm.linux.org.uk/personal/aboutme.html

Of course that's one and a half. initrd.txt changed in 2.4.0-test12 to be exact.

However, we shouldn't break the old initrd method in 2.4 - that's what 2.5 is for, but ext3 is a new feature introduced after in 2.4.9.

So, the question becomes - is it reasonable to expect new features introduced in a stable kernel series to work with obsolete methods that have already been replaced with far better solutions.

Russell King ([email protected])                The developer of ARM Linux
             http://www.arm.linux.org.uk/personal/aboutme.html

Hi

andrea> I'm not using the full blown initrd of most distros that is aware of the andrea> mistery of life and of all the kernel bugs out there too, my own dumb andrea> linuxrc just says:

andrea> echo hello world

andrea> and then returns, and ext3 gets mounted as ext2 and that's a kernel bug, andrea> all other fs gets mounted correctly with my initrd, only ext3 gone wrong andrea> until I fixed it.

andrea> both lines are completly superflous, very misleading as well. I andrea> recommend to drop such two lines from all the full blown bug-aware andrea> linuxrc out there (of course after you apply the ordering fix to the andrea> kernel).

I am missing something, or how do you pass the notail option to your reiserfs rootfs when the initrd is ext2.

Later, Juan.

In theory, practice and theory are the same, but in practice they 
are different -- Larry McVoy

I didn't noticed the API changed in the docs, so my suggestion of yesterday to remove such two lines is wrong sorry. I was only reading the kernel code and I was using my own old debugging initrd were I could reproduce the ext3 problem. Interestingly there's no way to guess the new API by only reading the kernel code like I was doing.

Andrea

fair enough (the new initrd API allows that, but it's very ugly that it is not dynamic from a kernel param like rootfstype would be, but it instead has to be written on disk within the initrd), however as said that's all due the brokeness of the rootfs params, they should apply only to the fianl real root dev, never to the initrd.

Andrea

There's another issue. The real root device might not be known at the time the initrd is first loaded.

This is the case in some installers, which seem to use pivot_root after the installer is done so the user doesn't need to reboot after the install is done...

Of course, the real root device won't be known until after the user has done the partitioning of the hard disk(s).

regards,

Rik

Bravely reimplemented by the knights who say "NIH".

http://www.surriel.com/		http://distro.conectiva.com/

Sure I see that, and that's also allowed by the new initrd API, and in such case you cannot make use of the two rootfs* params anyways because as you say you don't know what the wanted partitioning in advance.

What i'm saying is that if you want to add notail option to the root mount after you finished installing your system (so with a normally non interactive initrd) you can't make use of the rootfs* parameters to tweak the root mount during lilo (like you could do without initrd) because they're applied to both initrd and real root dev and that's clearly another bug (but not very important). And with the new initrd API such bug basically doesn't matter because the rootfstype will be forced in the static initrd image (while without initrd, or with the old initrd API + the bugfix that applies rootfs* only to the root dev I could make use of the rootfs* flags).

Andrea

it helps, it cures the autodetection bug for me.

can you elaborate what actually breaks in trying ext3 before ext2? That is the right thing to do always, if the fs is ext3 it must be mounted ext3 not ext2. If ext3 fails because the journal is missing, then ext2 will be used as expected, that's the right ordering.

First I hate to do something that can be very well done at runtime by the kernel accurately at ~zero cost. But anyways you can't workaround the problem with rootfstype, if you do you will be forced to use ext3 for the filesystem on the initrd too (for all the wrong reasons, but that's another problem and one that I'm not interested to fix because I pretend the autodetection to work always) and that's never the case normally, it doesn't even make any sense to use journaling on a ramdisk. initrd will be a minixfs or an ext2, never an ext3.

the issue is not to know about the fact the root fs is been mounted by ext2 despite it's an ext3, the issue is that after your learnt the bad news, you still cannot mount it as ext3 unless you use workarounds that somehow make the mount to fail as ext2 first, like a SYSRQ+B. The patch fixes this completly and permanently, no matter of the ext2/ext3 module/linked 4 possible combinations.

This is true, mount is very misleading in that case so the warning is a good idea, but this is orthogonal to my fix. And after my fix the warning will correctly happen only if the user doesn't have ext3 into his kernel. Now instead the warning would happen even with ext3 loaded as module into the kernel, and that's the bug.

Andrea

It is *very* common problem for people to think that their root fs is ext3 when in fact it is being mounted as ext2.

It seems that /etc/mtab incorrectly reports ext3, which doesn't help. The real truth is revealed in /proc/mounts. (Which has this irritating "/dev/root" thing in it, btw).

So anything we can do to simplify this problem for people would be really good. (It would be good if kernel.org came back, too, so we can see the patch ;))

And Andreas' idea of "Warning: mounting ext3 as as ext2" will help, too.

@@ -486,6 +486,9 @@ struct super_block * ext2_read_super (st
 		       bdevname(dev), i);
 		goto failed_mount;
 	}
+	if (EXT2_HAS_COMPAT_FEATURE(sb, EXT3_FEATURE_COMPAT_HAS_JOURNAL))
+		ext2_warning(sb, __FUNCTION__,
+			"mounting ext3 filesystem as ext2\n");
 	sb->s_blocksize_bits =
 		le32_to_cpu(EXT2_SB(sb)->s_es->s_log_block_size) + 10;
 	sb->s_blocksize = 1 << sb->s_blocksize_bits;

-

Here it is, it's short enough that I can post it here too. it falls into the obviously right category IMHO.

@@ -1736,7 +1736,7 @@
 
 static int __init init_ext3_fs(void)
 {
-        return register_filesystem(&ext3_fs_type);
+        return register_filesystem_lifo(&ext3_fs_type);
 }
 
 static void __exit exit_ext3_fs(void)

@@ -89,7 +89,7 @@
  *	unregistered.
  */
  
-int register_filesystem(struct file_system_type * fs)
+int __register_filesystem(struct file_system_type * fs, int lifo)
 {
 	int res = 0;
 	struct file_system_type ** p;

@@ -103,8 +103,14 @@
 	p = find_filesystem(fs->name);
 	if (*p)
 		res = -EBUSY;
-	else
-		*p = fs;
+	else {
+		if (!lifo)
+			*p = fs;
+		else {
+			fs->next = file_systems;
+			file_systems = fs;
+		}
+	}
 	write_unlock(&file_systems_lock);
 	return res;
 }

@@ -1077,7 +1077,9 @@
 		__MOD_DEC_USE_COUNT((fops)->owner);	\
 } while(0)
 
-extern int register_filesystem(struct file_system_type *);
+extern int __register_filesystem(struct file_system_type *, int);
+#define register_filesystem(fs) __register_filesystem(fs, 0)
+#define register_filesystem_lifo(fs) __register_filesystem(fs, 1)
 extern int unregister_filesystem(struct file_system_type *);
 extern struct vfsmount *kern_mount(struct file_system_type *);
 extern int may_umount(struct vfsmount *);

@@ -355,7 +355,7 @@
 EXPORT_SYMBOL(do_SAK);
 
 /* filesystem registration */
-EXPORT_SYMBOL(register_filesystem);
+EXPORT_SYMBOL(__register_filesystem);
 EXPORT_SYMBOL(unregister_filesystem);
 EXPORT_SYMBOL(kern_mount);
 EXPORT_SYMBOL(__mntput);

...

As the 2.4.19-pre mainline got your buffer throtteling changes I guess it has the same issues? Do you think it's worth to submit that patch to Marcelo even that late in the release cycle?

It seems to me you ignore the comments akpm put in the split patches you merged :) Not only the comment to this change is superflous now, but also I'd really like to get an answer to the remaining part of it as Andrew's comment about that part beeing buggy makes a lot of sense to me..

it is not very important, but of course it could go in too.

updated :)

well, as Andrew said it's a microoptimization, but it's not buggy. It is used to avoid marking a page referenced twice if somebody reads with an userspace buffer granularity smaller than PAGE_SIZE, the same optimization exists in the read side (there it is a bit more of a microoptimization because the writer never activates pages but the readers activates pages without such check).

Andrea