[PATCHSET] 2.4.19-pre8-jp12

[PATCHSET] 2.4.19-pre8-jp12

[Jörg Prante]

Linux kernel patch set 2.4.19pre8-jp12  

This is the twelvth release of the -jp patch set. 

http://infolinux.de/jp12/

Status: 15 May 2002 00:45 CEST 

Changes from jp11 to jp12 

Updates: XFS update to CVS as of 13 May 2002, new IDE convert all 10, 
Alsa compile fix, IDE CD DMA upgrade. New patches included in this 
version: Momchil Velikov/Christoph Hellwig's radix tree pagecache 
(adapted to work with rmap/preempt/lockbreak and XFS), Jens Axboe's 
IDE tagged command queue support, Robert Love's latest additional 
miscellanous scheduler patches. 

Known Issues 

The miroSound PCM20 radio audio driver depends on OSS sound include 
file and is no longer compileable. IDE CD should be fixed. I did not 
find the bug but it could be in the IDE patch, or some interaction 
with it I did not understand. Anyway, cdfs does not work, it will 
mount, but oops when stat()ing a directory. The drive will be locked 
until reboot. This is caused by an interaction between the new code 
in IDE, supermount, and cdfs and must be investigated. 

What is it? 

The -jp kernels are development kernels for testing purpose only. They 
will appear regularly two or three times a month. Their purpose is to 
provide a service for developers who can't keep up to date with the 
latest kernel and patch versions, but want to test new features and 
evaluate enhancements that are not to be expected for inclusion into 
the mainstream 2.4 kernel. 

Download 
 
http://infolinux.de/jp12/patch-2.4.19-pre8-jp12.tar.bz2 


Patch set overview

01_kernel-sound-remove-0-pre8  34_llseek
01_kernel-sound-remove-1-pre7  35_mount
01_kernel-sound-remove-2-pre6  36_device
01_kernel-sound-remove-3-pre5  37_supermount
01_kernel-sound-remove-4-pre4  38_xfs-kdb-from-cvs-04May2002
01_kernel-sound-remove-5-pre3  39_xfs-13May2002
01_kernel-sound-remove-6-pre2  40_xfs-kdb-adapt
01_kernel-sound-remove-7-core  41_xfs-kdb-fixups
02_alsa-sound-0.9.0rc1         42_jfs-1.0.14-0
03_alsa-adapt                  43_jfs-1.0.14-15
04_TIOCGDEV                    44_jfs-1.0.15-16
05_boot-time-ioremap           45_jfs-1.0.16-17
06_via-northbridge-fixup       46_jfs-adapt
07_jiffies-for-i386            47_ftpfs-0.6.2
08_rmap-13                     48_cdfs-0.5b
09_rmap13a                     49_cdfs-0.5bc
10_sched-O1-K3                 50_patch-int-2.4.18.2
11_up-apic-fix                 51_loop-jari
12_remove-wake-up-sync         52_grsecurity-1.9.5-pre3
13_need-resched-abstraction    53_grsecurity-adapt
14_frozen-lock                 54_i2c-2.6.3
15_sched-yield                 55_lmsensors-2.6.3
16_more-sched-yield            56_freeswan-1.97
17_need-resched-check          57_ide-cd-dma-4
18_maxrtprio-1                 58_lowlatency-mini
19_maxrtprio                   59_lowlatency-fixes-5
20_migration-thread            60_mmx-init
21_updated-migration-init      61_p4-xeon
22_misc-stuff                  62_x86-fast-pte
23_preempt-2.4.19pre8          63_acpi-20020503
24_lockbreak                   64_acpi-pciirq-17
25_ide-all-convert-10          65_remove-khttpd
26_md-locks                    66_tux2-final-A3
27_raid-split                  67_sis-740-961
28_md-part                     68_radix-tree-pagecache-2.4.19pre5ac3
29_mdp-major                   69_radix-tree-pagecache-xfs-fix
30_autofs4                     70_block-tag-2.4.19pre8
31_isrdonly                    71_ide-tag-2.4.19pre8
32_new-stat                    98_tkparse-4096
33_mediactl                    99_VERSION

More info available at 

http://infolinux.de/jp12


Jörg Prante 
joerg@infolinux.de 

Re: [PATCHSET] 2.4.19-pre8-jp12

[Pozsar Balazs]

I tried it. First I had a lot of compile problems (everything as module),
I had to disable at least 5 drivers (sorry I don't know exactly which were
them).
After compiling, depmod -a says:

unresolved symbols in
/drivers/char/drm/sis.o
/drivers/hotplug/pcihpacpi.o
/net/tux/tux.o

So even tux is unusable :(.


But the worst problem for is supermount:
# mount -t supermount -o dev=/dev/cdrom none /mnt/cdrom
# ls -l /mnt/cdrom
ls: .: Stale NFS handle                (~or something similar)
[...]                                  (and it lists the file)

But:
# cd /mnt/cdrom
# ls -l
ls: .: Stale NFS handle
#                                      (and it doesn't even list the files)



On Wed, 15 May 2002, [iso-8859-15] Jörg Prante wrote:

> Linux kernel patch set 2.4.19pre8-jp12
>
> This is the twelvth release of the -jp patch set.
>
> http://infolinux.de/jp12/
>
> Status: 15 May 2002 00:45 CEST
>
> Changes from jp11 to jp12
>
> Updates: XFS update to CVS as of 13 May 2002, new IDE convert all 10,
> Alsa compile fix, IDE CD DMA upgrade. New patches included in this
> version: Momchil Velikov/Christoph Hellwig's radix tree pagecache
> (adapted to work with rmap/preempt/lockbreak and XFS), Jens Axboe's
> IDE tagged command queue support, Robert Love's latest additional
> miscellanous scheduler patches.
>
> Known Issues
>
> The miroSound PCM20 radio audio driver depends on OSS sound include
> file and is no longer compileable. IDE CD should be fixed. I did not
> find the bug but it could be in the IDE patch, or some interaction
> with it I did not understand. Anyway, cdfs does not work, it will
> mount, but oops when stat()ing a directory. The drive will be locked
> until reboot. This is caused by an interaction between the new code
> in IDE, supermount, and cdfs and must be investigated.
>
> What is it?
>
> The -jp kernels are development kernels for testing purpose only. They
> will appear regularly two or three times a month. Their purpose is to
> provide a service for developers who can't keep up to date with the
> latest kernel and patch versions, but want to test new features and
> evaluate enhancements that are not to be expected for inclusion into
> the mainstream 2.4 kernel.
>
> Download
>
> http://infolinux.de/jp12/patch-2.4.19-pre8-jp12.tar.bz2
>
>
> Patch set overview
>
> 01_kernel-sound-remove-0-pre8  34_llseek
> 01_kernel-sound-remove-1-pre7  35_mount
> 01_kernel-sound-remove-2-pre6  36_device
> 01_kernel-sound-remove-3-pre5  37_supermount
> 01_kernel-sound-remove-4-pre4  38_xfs-kdb-from-cvs-04May2002
> 01_kernel-sound-remove-5-pre3  39_xfs-13May2002
> 01_kernel-sound-remove-6-pre2  40_xfs-kdb-adapt
> 01_kernel-sound-remove-7-core  41_xfs-kdb-fixups
> 02_alsa-sound-0.9.0rc1         42_jfs-1.0.14-0
> 03_alsa-adapt                  43_jfs-1.0.14-15
> 04_TIOCGDEV                    44_jfs-1.0.15-16
> 05_boot-time-ioremap           45_jfs-1.0.16-17
> 06_via-northbridge-fixup       46_jfs-adapt
> 07_jiffies-for-i386            47_ftpfs-0.6.2
> 08_rmap-13                     48_cdfs-0.5b
> 09_rmap13a                     49_cdfs-0.5bc
> 10_sched-O1-K3                 50_patch-int-2.4.18.2
> 11_up-apic-fix                 51_loop-jari
> 12_remove-wake-up-sync         52_grsecurity-1.9.5-pre3
> 13_need-resched-abstraction    53_grsecurity-adapt
> 14_frozen-lock                 54_i2c-2.6.3
> 15_sched-yield                 55_lmsensors-2.6.3
> 16_more-sched-yield            56_freeswan-1.97
> 17_need-resched-check          57_ide-cd-dma-4
> 18_maxrtprio-1                 58_lowlatency-mini
> 19_maxrtprio                   59_lowlatency-fixes-5
> 20_migration-thread            60_mmx-init
> 21_updated-migration-init      61_p4-xeon
> 22_misc-stuff                  62_x86-fast-pte
> 23_preempt-2.4.19pre8          63_acpi-20020503
> 24_lockbreak                   64_acpi-pciirq-17
> 25_ide-all-convert-10          65_remove-khttpd
> 26_md-locks                    66_tux2-final-A3
> 27_raid-split                  67_sis-740-961
> 28_md-part                     68_radix-tree-pagecache-2.4.19pre5ac3
> 29_mdp-major                   69_radix-tree-pagecache-xfs-fix
> 30_autofs4                     70_block-tag-2.4.19pre8
> 31_isrdonly                    71_ide-tag-2.4.19pre8
> 32_new-stat                    98_tkparse-4096
> 33_mediactl                    99_VERSION
>
> More info available at
>
> http://infolinux.de/jp12
>
>
> Jörg Prante
> joerg@infolinux.de
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>

-- 
Balazs Pozsar

Re: [PATCHSET] 2.4.19-pre8-jp12

[Tomas Szepe]

> But the worst problem for is supermount:
> # mount -t supermount -o dev=/dev/cdrom none /mnt/cdrom
> # ls -l /mnt/cdrom
> ls: .: Stale NFS handle                (~or something similar)
> [...]                                  (and it lists the file)

Hmmm.. I've been seeing this problem in the latest -ac kernels too.

Basically, a while after mounting the CD a ls on any subdir of the
mount will complain about a 'stale NFS handle' and the device has
to be remounted.

T.

Re: [PATCHSET] 2.4.19-pre8-jp12

[Pozsar Balazs]

> > But the worst problem for is supermount:
> > # mount -t supermount -o dev=/dev/cdrom none /mnt/cdrom
> > # ls -l /mnt/cdrom
> > ls: .: Stale NFS handle                (~or something similar)
> > [...]                                  (and it lists the file)
>
> Hmmm.. I've been seeing this problem in the latest -ac kernels too.
>
> Basically, a while after mounting the CD a ls on any subdir of the
> mount will complain about a 'stale NFS handle' and the device has
> to be remounted.

I thougth it wasn't Jorg's fault :). Unfortunately I immediately get this
message :(.

-- 
Balazs Pozsar

Re: [PATCHSET] 2.4.19-pre8-jp12

[Robinson Maureira Castillo]

On Thu, 16 May 2002, Tomas Szepe wrote:

> > But the worst problem for is supermount:
> > # mount -t supermount -o dev=/dev/cdrom none /mnt/cdrom
> > # ls -l /mnt/cdrom
> > ls: .: Stale NFS handle                (~or something similar)
> > [...]                                  (and it lists the file)
> 
> Hmmm.. I've been seeing this problem in the latest -ac kernels too.
> 
> Basically, a while after mounting the CD a ls on any subdir of the
> mount will complain about a 'stale NFS handle' and the device has
> to be remounted.
> 
> T.
> 

I'm getting the same with ftpfs, both in jp11 and jp12. Remounting doesn't 
change a thing, it just shows me the root tree, I can cd into directories 
if I know the name, but all I got is those nice 'stale NFS handle' as a 
response from ls

Regards

Rob.

Re: [PATCHSET] 2.4.19-pre8-jp12

[Jörg Prante]

> I tried it. First I had a lot of compile problems (everything as module),
> I had to disable at least 5 drivers (sorry I don't know exactly which were
> them).

Hi Pozsar, can you please give me some hints what the module names are.
I could add a note to the homepage, or even fix the issue.

> So even tux is unusable :(.

No it's not unusuable. You have to compile it into the kernel. But thank you 
for the info. I try to reproduce the building weaknesses.

Jörg

Re: [PATCHSET] 2.4.19-pre8-jp12

[Jörg Prante]

> But the worst problem for is supermount:
> # mount -t supermount -o dev=/dev/cdrom none /mnt/cdrom
> # ls -l /mnt/cdrom
> ls: .: Stale NFS handle                (~or something similar)
> [...]                                  (and it lists the file)
>
> But:
> # cd /mnt/cdrom
> # ls -l
> ls: .: Stale NFS handle
> #                                      (and it doesn't even list the files)

Hi Pozsar, this is a known supermount bug. I got this as well. Supermount is 
a patch for 2.4.18pre8 kernel, not for 2.4.19preX. See also

http://www.mandrake.com/en/archives/cooker/2002-04/msg00086.php

I will try my best to figure out what is happening. The open(".",...) call to 
supermount returns -1 and this gives "stale NFS handle", but 
open("/mnt/cdrom", ...) gives "3" or a positive number. I think the text of 
the message is misleading, it has nothing to do with NFS.

Jörg

[PATCH 2.4.19pre8][RFC] remove-NFS-close-to-open from VFS (was Re: [PATCHSET] 2.4.19-pre8-jp12)

[Jörg Prante]

[-- Attachment #1: Type: text/plain, Size: 1822 bytes --]


Hi!

Robinson Maureira Castillo <rmaureira@alumno.inacap.cl> wrote:
> On Thu, 16 May 2002, Tomas Szepe wrote:
> > > But the worst problem for is supermount:
> > > # mount -t supermount -o dev=/dev/cdrom none /mnt/cdrom
> > > # ls -l /mnt/cdrom
> > > ls: .: Stale NFS handle                (~or something similar)
> > > [...]                                  (and it lists the file)
> >
> > Hmmm.. I've been seeing this problem in the latest -ac kernels too.
> >
> > Basically, a while after mounting the CD a ls on any subdir of the
> > mount will complain about a 'stale NFS handle' and the device has
> > to be remounted.
> >
> > T.
>
> I'm getting the same with ftpfs, both in jp11 and jp12. Remounting doesn't
> change a thing, it just shows me the root tree, I can cd into directories
> if I know the name, but all I got is those nice 'stale NFS handle' as a
> response from ls

I traced it down. The trouble exists since 2.4.19-pre4. Trond Myklebust 
touched the VFS in order to send dentry revalidation events to NFS. 

http://www.geocrawler.com/archives/3/789/2002/3/100/8078826/

But Trond's patch conflicts with almost all non-standard virtual or remote 
mount file systems (supermount, cdfs, ftpfs, and maybe autofs). I don't know 
if the cdfs oops I observed now for a while is related.

Is it possible to leave the VFS layer untouched? Or restrict the dentry 
revalidation to NFS and let other remote file systems coexist, i.e. without 
revalidation calls? 

Or is it recommended to write fixes for the file systems stated above, 
because they now have wrong assumptions about the VFS behavior? 

Anyway, while these questions arise, I request to remove Trond's patch since 
the patch changes too much for 2.4 stable kernel series.

Attached is a revert patch against 2.4.19-pre8 for Marcelo.

Thanks 

Jörg

[-- Attachment #2: remove-NFS-close-to-open.patch --]
[-- Type: text/x-diff, Size: 1086 bytes --]

diff -urN linux-2.4.19-pre3/fs/namei.c linux-/fs/namei.c
--- linux-2.4.19-pre3/fs/namei.c	Wed Mar 20 14:03:50 2002
+++ linux/fs/namei.c	Wed Mar 20 14:04:40 2002
@@ -457,7 +457,7 @@
 	while (*name=='/')
 		name++;
 	if (!*name)
+		goto return_base;
-		goto return_reval;
 
 	inode = nd->dentry->d_inode;
 	if (current->link_count)
@@ -576,7 +576,7 @@
 				inode = nd->dentry->d_inode;
 				/* fallthrough */
 			case 1:
+				goto return_base;
-				goto return_reval;
 		}
 		if (nd->dentry->d_op && nd->dentry->d_op->d_hash) {
 			err = nd->dentry->d_op->d_hash(nd->dentry, &this);
@@ -627,19 +627,6 @@
 			nd->last_type = LAST_DOT;
 		else if (this.len == 2 && this.name[1] == '.')
 			nd->last_type = LAST_DOTDOT;
-return_reval:
-		/*
-		 * We bypassed the ordinary revalidation routines.
-		 * Check the cached dentry for staleness.
-		 */
-		dentry = nd->dentry;
-		if (dentry && dentry->d_op && dentry->d_op->d_revalidate) {
-			err = -ESTALE;
-			if (!dentry->d_op->d_revalidate(dentry, 0)) {
-				d_invalidate(dentry);
-				break;
-			}
-		}
 return_base:
 		return 0;
 out_dput:

Re: [PATCH 2.4.19pre8][RFC] remove-NFS-close-to-open from VFS (was Re: [PATCHSET] 2.4.19-pre8-jp12)

[Alan Cox]

> Is it possible to leave the VFS layer untouched? Or restrict the dentry 
> revalidation to NFS and let other remote file systems coexist, i.e. without 
> revalidation calls? 

Really the other file systems want fixing - that revalidation is a real bug
fix and the situation could occur for other network file systems too

[PATCH] fixing supermount for > 2.4.19pre4

[Jörg Prante]

[-- Attachment #1: Type: text/plain, Size: 603 bytes --]

Hi,

in 2.4.19pre4, the dentry revalidation has been patched, and the VFS behavior 
has changed due to an NFS bugfix. All non-standard remote file systems (like 
supermount, ftpfs, etc.) are in conflict with the patch and may not operate 
correctly.

Alan Cox pointed out that non-standard remote file systems should get fixed 
for 2.4.19. So, here is my quick hack for supermount 0.7 that changes the 
return policy in the d_revalidate operation. Supermount should work now in 
2.4.19pre4 kernels and higher.

Other file systems with similar revalidate policy can get fixed accordingly.

Cheers,

Jörg

[-- Attachment #2: supermount-2.4.19pre8-fix.patch --]
[-- Type: text/x-diff, Size: 936 bytes --]

--- linux/fs/supermount/dentry_operations.c.orig	Fri May 17 00:36:21 2002
+++ linux/fs/supermount/dentry_operations.c	Fri May 17 01:16:06 2002
@@ -25,8 +25,9 @@
 
 	dump_dentry(dentry);
 
-	if (!subfs_go_online(dentry->d_sb))
-		goto bad_dentry;
+	if (!subfs_go_online(dentry->d_sb)) {
+		goto out;
+    }
 	spin_lock(&dcache_lock);
 	if (dentry->d_inode && is_inode_obsolete(dentry->d_inode)) {
 		supermount_debug("found old dentry: **%s**",
@@ -36,20 +37,21 @@
 	}
 	spin_unlock(&dcache_lock);
 	subd = get_subfs_dentry(dentry);
-	if (IS_ERR(subd))
+	if (IS_ERR(subd)) {
 		goto bad_dentry;
+	}
 
 	if (subd->d_op && subd->d_op->d_revalidate) {
 		supermount_debug("lowlevel revalidate");
 		rc = subd->d_op->d_revalidate(subd, flags);
 	}
 	dput(subd);
+	goto out;
+bad_dentry:
+	rc = 0;
 out:
 	subfs_go_inactive(dentry->d_sb);
 	return rc;
-bad_dentry:
-	rc = 0;
-	goto out;
 }
 
 struct dentry_operations supermount_dir_dops = {

Re: [PATCH 2.4.19pre8][RFC] remove-NFS-close-to-open from VFS (was Re: [PATCHSET] 2.4.19-pre8-jp12)

[Tomas Szepe]

> > Is it possible to leave the VFS layer untouched? Or restrict the dentry 
> > revalidation to NFS and let other remote file systems coexist, i.e. without 
> > revalidation calls? 
> 
> Really the other file systems want fixing - that revalidation is a real bug
> fix and the situation could occur for other network file systems too

I was able to reproduce the bug on a reiserfs root on one of my machines today.

T.

Re: [PATCH 2.4.19pre8][RFC] remove-NFS-close-to-open from VFS (was Re: [PATCHSET] 2.4.19-pre8-jp12)

[Jan Harkes]

On Thu, May 16, 2002 at 11:13:01PM +0100, Alan Cox wrote:
> > Is it possible to leave the VFS layer untouched? Or restrict the dentry 
> > revalidation to NFS and let other remote file systems coexist, i.e. without 
> > revalidation calls? 
> 
> Really the other file systems want fixing - that revalidation is a real bug
> fix and the situation could occur for other network file systems too

And I thought I broke something with my latest changes in Coda. This
'bugfix' is hitting us hard. In some cases we hand down quite volatile
objects, files that are involved in a conflict, fake expanded directory
trees during the repair/examination of such conflicts.

These object are passed down with a 'no-cache' flag, which uses
dentry_revalidate to skip the cached lookup from the dcache but forces
all lookups to be passed through to the Coda filesystem. This bugfix
causes breakage, instead of forcing a new filesystem lookup, the VFS
simply returns ESTALE.

AFAIK, before the fix, failing dentry revalidate meant 'the lookup path
in the dcache is probably invalid, please double check with the
filesystem'. And now it means, 'the lookup path is invalid, return failure'.

Jan

Re: [PATCHSET] 2.4.19-pre8-jp12

[Greg KH]

On Thu, May 16, 2002 at 09:47:14AM +0200, Pozsar Balazs wrote:
> 
> I tried it. First I had a lot of compile problems (everything as module),
> I had to disable at least 5 drivers (sorry I don't know exactly which were
> them).
> After compiling, depmod -a says:
> 
> unresolved symbols in
> /drivers/hotplug/pcihpacpi.o

What is the unresolved symbol here?  acpi_walk_something_or_other?

Do you really want to use this driver (i.e. do you have a machine that
has a ACPI PCI Hotplug controller?)

thanks,

greg k-h