Re: BUG? atleast >=2.6.19-rc5, x86 chroot on x86_64

Re: BUG? atleast >=2.6.19-rc5, x86 chroot on x86_64

[Chuck Ebbert]

In-Reply-To: <1165409880.15706.9.camel@localhost>

On Wed, 06 Dec 2006 13:58:00 +0100, Kasper Sandberg wrote:

> > Kasper, what problems (other that the annoying message) are you having?
> if it had only been the messages i wouldnt have complained.
> the thing is, when i get these messages, the app provoking them acts
> very strange, and in some cases, my system simply hardlocks.

You can try the patch I sent you to see if it fixes the Wine app.
(David thought I was proposing it for the mainline kernel but I just
wanted to see whether it made a difference.)

As for the lockups, there are possibly other bugs lurking in 2.6.19.

-- 
Chuck
"Even supernovas have their duller moments."

Re: BUG? atleast >=2.6.19-rc5, x86 chroot on x86_64

[Kasper Sandberg]

On Mon, 2006-12-11 at 03:27 -0500, Chuck Ebbert wrote:
> In-Reply-To: <1165409880.15706.9.camel@localhost>
> 
> On Wed, 06 Dec 2006 13:58:00 +0100, Kasper Sandberg wrote:
> 
> > > Kasper, what problems (other that the annoying message) are you having?
> > if it had only been the messages i wouldnt have complained.
> > the thing is, when i get these messages, the app provoking them acts
> > very strange, and in some cases, my system simply hardlocks.
> 
> You can try the patch I sent you to see if it fixes the Wine app.
> (David thought I was proposing it for the mainline kernel but I just
> wanted to see whether it made a difference.)

do you think it may be a bug in the kernel? the stuff with wine that
gets thrown in the kernel messages? cause if it is, i ofcourse wish to
help by testing. one more thing, im 100% positive wine does NOT have
access to any fat32, cause i entirely removed the only disk having such
a filesystem, and it still likes to give this, however the last few
times i havent observed the app going nuts :)

> 
> As for the lockups, there are possibly other bugs lurking in 2.6.19.
yes, when the using-much-ram-perhaps-even-swap thing was mentioned i
came to think, cause i do happen to use alarmingly much swap. i noticed
a ~5 second lockup (where it actually returned to normal again) when i
reached ~50mb free ram, and this was outside the chroot.


> 

Re: BUG? atleast >=2.6.19-rc5, x86 chroot on x86_64

[Chuck Ebbert]

In-Reply-To: <1165984783.23819.7.camel@localhost>

On Wed, 13 Dec 2006 05:39:43 +0100, Kasper Sandberg wrote:

> do you think it may be a bug in the kernel? the stuff with wine that
> gets thrown in the kernel messages?

Let's just say the behavior has changed.  It now returns
-EINVAL instead of -ENOTTY when the msdos IOCTLs fail.

> im 100% positive wine does NOT have
> access to any fat32, cause i entirely removed the only disk having such
> a filesystem, and it still likes to give this

That's when this happens: running certain programs that try
msdos-type IOCTLs on native Linux filesystems.

> however the last few
> times i havent observed the app going nuts

If there aren't any other problems you can just turn off the logging.

Did you change something else?

Anyway, here is a much simpler patch that restores the previous
behavior (but leaves the message.)  However if you aren't having
any problems now other than the messages maybe there's no real
problem after all?

--- 2.6.19.1-64smp.orig/fs/compat.c
+++ 2.6.19.1-64smp/fs/compat.c
@@ -444,7 +444,11 @@ asmlinkage long compat_sys_ioctl(unsigne
 
 		if (++count <= 50)
 			compat_ioctl_error(filp, fd, cmd, arg);
-		error = -EINVAL;
+
+		if (cmd == 0x82187201)
+			error = -ENOTTY;
+		else
+			error = -EINVAL;
 	}
 
 	goto out_fput;
-- 
MBTI: IXTP

Re: BUG? atleast >=2.6.19-rc5, x86 chroot on x86_64

[Kasper Sandberg]

On Wed, 2006-12-13 at 02:50 -0500, Chuck Ebbert wrote:
> In-Reply-To: <1165984783.23819.7.camel@localhost>
> 
> On Wed, 13 Dec 2006 05:39:43 +0100, Kasper Sandberg wrote:
> 
> > do you think it may be a bug in the kernel? the stuff with wine that
> > gets thrown in the kernel messages?
> 
> Let's just say the behavior has changed.  It now returns
> -EINVAL instead of -ENOTTY when the msdos IOCTLs fail.
> 
> > im 100% positive wine does NOT have
> > access to any fat32, cause i entirely removed the only disk having such
> > a filesystem, and it still likes to give this
> 
> That's when this happens: running certain programs that try
> msdos-type IOCTLs on native Linux filesystems.
ohhh :) well wine may do that :)
> 
> > however the last few
> > times i havent observed the app going nuts
> 
> If there aren't any other problems you can just turn off the logging.
> 
> Did you change something else?
i did upgrade from rc5 to final

> 
> Anyway, here is a much simpler patch that restores the previous
> behavior (but leaves the message.)  However if you aren't having
> any problems now other than the messages maybe there's no real
> problem after all?

well the hardlock problem still occurs, however that, (as i believe has
veen the semi-conclusion in this thread) arent related?

> 
> --- 2.6.19.1-64smp.orig/fs/compat.c
> +++ 2.6.19.1-64smp/fs/compat.c
> @@ -444,7 +444,11 @@ asmlinkage long compat_sys_ioctl(unsigne
>  
>  		if (++count <= 50)
>  			compat_ioctl_error(filp, fd, cmd, arg);
> -		error = -EINVAL;
> +
> +		if (cmd == 0x82187201)
> +			error = -ENOTTY;
> +		else
> +			error = -EINVAL;
>  	}
>  
>  	goto out_fput;

Re: BUG? atleast >=2.6.19-rc5, x86 chroot on x86_64

[Alan]

On Wed, 13 Dec 2006 02:50:01 -0500
Chuck Ebbert <76306.1226@compuserve.com> wrote:

> In-Reply-To: <1165984783.23819.7.camel@localhost>
> 
> On Wed, 13 Dec 2006 05:39:43 +0100, Kasper Sandberg wrote:
> 
> > do you think it may be a bug in the kernel? the stuff with wine that
> > gets thrown in the kernel messages?
> 
> Let's just say the behavior has changed.  It now returns
> -EINVAL instead of -ENOTTY when the msdos IOCTLs fail.

For an unknown ioctl the correct return is -ENOTTY. For an invalid ioctl
(known but wrong parameters) it may be -EINVAL.

> Anyway, here is a much simpler patch that restores the previous
> behavior (but leaves the message.)  However if you aren't having
> any problems now other than the messages maybe there's no real
> problem after all?

As far as I can see from a quick review the code should return -ENOTTY
in this situation not -EINVAL, for all unhandled ioctls.

Alan

Re: BUG? atleast >=2.6.19-rc5, x86 chroot on x86_64

[Chuck Ebbert]

In-Reply-To: <26586.1165356671@redhat.com>

On Tue, 05 Dec 2006 22:11:11 +0000, David Howells wrote:

> > I only have 32-bit userspace.  When I run your program against
> > a directory on a JFS filesystem (msdos ioctls not supported)
> > I get this on vanilla 2.6.19:
> 
> Can I just check?  You're using an x86_64 CPU in 64-bit mode with a 64-bit
> kernel, but with a completely 32-bit userspace?

It's FC5 i386 so there's no way any 64-bit userspace code is in there.
(I have a cross-compiler only for building kernels.)  Having a pure
32-bit userspace lets me switch between i386 and x86_64 kernels
without having to maintain two separate Linux installs.

> A question for you: Why is userspace assuming that it'll get ENOTTY rather
> than EINVAL?

I'm not sure it is, but that's what it used to get.

Kasper, what problems (other that the annoying message) are you having?

-- 
Chuck
"Even supernovas have their duller moments."

Re: BUG? atleast >=2.6.19-rc5, x86 chroot on x86_64

[Kasper Sandberg]

On Tue, 2006-12-05 at 21:31 -0500, Chuck Ebbert wrote:
> In-Reply-To: <26586.1165356671@redhat.com>
> 
> On Tue, 05 Dec 2006 22:11:11 +0000, David Howells wrote:
> 
> > > I only have 32-bit userspace.  When I run your program against
> > > a directory on a JFS filesystem (msdos ioctls not supported)
> > > I get this on vanilla 2.6.19:
> > 
> > Can I just check?  You're using an x86_64 CPU in 64-bit mode with a 64-bit
> > kernel, but with a completely 32-bit userspace?
> 
> It's FC5 i386 so there's no way any 64-bit userspace code is in there.
> (I have a cross-compiler only for building kernels.)  Having a pure
> 32-bit userspace lets me switch between i386 and x86_64 kernels
> without having to maintain two separate Linux installs.
> 
> > A question for you: Why is userspace assuming that it'll get ENOTTY rather
> > than EINVAL?
> 
> I'm not sure it is, but that's what it used to get.
> 
> Kasper, what problems (other that the annoying message) are you having?
if it had only been the messages i wouldnt have complained.
the thing is, when i get these messages, the app provoking them acts
very strange, and in some cases, my system simply hardlocks.

and i am very very sure its because of this, i can run with the kernel
(atleast with rc5 i had that long) for 10 days, and then chroot in, run
the 32bit apps, and within hours of using, hardlock.

wine seems to be worst at provoking hardlock, however i encountered one
i am sure was caused by java(the 32bit one inside chroot).

as i said in my post yesterday, my chroot doesent have access to my vfat
partitions, so i dont believe thats it.
> 

Re: BUG? atleast >=2.6.19-rc5, x86 chroot on x86_64

[David Howells]

Kasper Sandberg <lkml@metanurb.dk> wrote:

> and i am very very sure its because of this, i can run with the kernel
> (atleast with rc5 i had that long) for 10 days, and then chroot in, run
> the 32bit apps, and within hours of using, hardlock.

What do you mean by "hardlock"?  Do you mean the application has to be killed,
or do you mean the kernel is stuck and the machine has to be rebooted?

David

Re: BUG? atleast >=2.6.19-rc5, x86 chroot on x86_64

[Kasper Sandberg]

On Wed, 2006-12-06 at 13:08 +0000, David Howells wrote:
> Kasper Sandberg <lkml@metanurb.dk> wrote:
> 
> > and i am very very sure its because of this, i can run with the kernel
> > (atleast with rc5 i had that long) for 10 days, and then chroot in, run
> > the 32bit apps, and within hours of using, hardlock.
> 
> What do you mean by "hardlock"?  Do you mean the application has to be killed,
> or do you mean the kernel is stuck and the machine has to be rebooted?
i mean the kernel itself, two of the times it has happened to me, magic
sysrq havent even been able to reboot for me, i had to hit the button on
my tower.

when i the very first time encountered this, it was with regedit, the
app went nuts, and then it frooze, i had to kill -9 it, and then an hour
later i noticed the kernel messages.
> 
> David
> 

Re: BUG? atleast >=2.6.19-rc5, x86 chroot on x86_64

[David Howells]

Kasper Sandberg <lkml@metanurb.dk> wrote:

> > What do you mean by "hardlock"?  Do you mean the application has to be killed,
> > or do you mean the kernel is stuck and the machine has to be rebooted?
> i mean the kernel itself, two of the times it has happened to me, magic
> sysrq havent even been able to reboot for me, i had to hit the button on
> my tower.

That's got to be some other problem.  There's no way this ioctl error message
change should cause the kernel to die - applications, yes; but not the kernel.

David

Re: BUG? atleast >=2.6.19-rc5, x86 chroot on x86_64

[Kasper Sandberg]

On Wed, 2006-12-06 at 16:48 +0000, David Howells wrote:
> Kasper Sandberg <lkml@metanurb.dk> wrote:
> 
> > > What do you mean by "hardlock"?  Do you mean the application has to be killed,
> > > or do you mean the kernel is stuck and the machine has to be rebooted?
> > i mean the kernel itself, two of the times it has happened to me, magic
> > sysrq havent even been able to reboot for me, i had to hit the button on
> > my tower.
> 
> That's got to be some other problem.  There's no way this ioctl error message
> change should cause the kernel to die - applications, yes; but not the kernel.
Okay, do you have an idea what it can be then? it have to be something
in relation to 32bit emulation, cause it happens only when using 32bit
apps.
> 
> David
> 

Re: BUG? atleast >=2.6.19-rc5, x86 chroot on x86_64

[Andi Kleen]

> and i am very very sure its because of this, i can run with the kernel
> (atleast with rc5 i had that long) for 10 days, and then chroot in, run
> the 32bit apps, and within hours of using, hardlock.

Early AMD K8 platforms had a hardware bug that could have caused
such hardlocks when running 32bit code under 64bit (independent of anything 
the kernel does). If you have such a board/CPU try a BIOS update.

-Andi

Re: BUG? atleast >=2.6.19-rc5, x86 chroot on x86_64

[Kasper Sandberg]

On Wed, 2006-12-06 at 22:29 +0100, Andi Kleen wrote:
> > and i am very very sure its because of this, i can run with the kernel
> > (atleast with rc5 i had that long) for 10 days, and then chroot in, run
> > the 32bit apps, and within hours of using, hardlock.
> 
> Early AMD K8 platforms had a hardware bug that could have caused
> such hardlocks when running 32bit code under 64bit (independent of anything 
> the kernel does). If you have such a board/CPU try a BIOS update.
well, 2.6.18 were 100% stable, none of these issues.

however you have caught my attention, cause i have one of the first
amd64's, a 3200+ 1mb cache, socket 754. and an asus board. ill try find
a floppy and upgrade the bios if there are updates available.
> 
> -Andi
> 

Re: BUG? atleast >=2.6.19-rc5, x86 chroot on x86_64

[Chuck Ebbert]

In-Reply-To: <4701.1165328393@redhat.com>

On Tue, 05 Dec 2006 14:19:53 +0000, David Howells wrote:
> > Here is a patch to reverse that.  Kasper, can you test it?
> > (Your filesystem is on a FAT/VFAT volume, I assume.)
> 
> Please don't revert that patch.  If you do, you'll break CONFIG_BLOCK=n.
> 
> Can you compile and run the attached program as both 32-bit and 64-bit?

I only have 32-bit userspace.  When I run your program against
a directory on a JFS filesystem (msdos ioctls not supported)
I get this on vanilla 2.6.19:

$ ./vfat_ioctl32.ex .
268 : 82187201, 82187202
268 : 82187201, 82187202
Calling VFAT_IOCTL_READDIR_BOTH32
ioctl: Invalid argument
Calling VFAT_IOCTL_READDIR_BOTH
ioctl: Invalid argument

After reverting the msdos compat ioctls patch it changes to:

$ ./vfat_ioctl32.ex .
268 : 82187201, 82187202
268 : 82187201, 82187202
Calling VFAT_IOCTL_READDIR_BOTH32
ioctl: Inappropriate ioctl for device
Calling VFAT_IOCTL_READDIR_BOTH
ioctl: Inappropriate ioctl for device

> | i have only tested with >=rc5, thw folling, as an example, appears in
> | dmesg:
> | ioctl32(regedit.exe:11801): Unknown cmd fd(9) cmd(82187201){02}
> | arg(00221000) on /home/redeeman
> | ioctl32(regedit.exe:11801): Unknown cmd fd(9) cmd(82187201){02}
> | arg(00221000) on /home/redeeman/.wine/drive_c/windows/system32
> | ioctl32(regedit.exe:11801): Unknown cmd fd(9) cmd(82187201){02}
> | arg(00221000) on /home/redeeman/.wine/drive_c/windows/system
> 
> How do you get that? 

I get those messages when the ioctl call returns 'invalid argument.'

In fs/compat.s::compat_sys_ioctl() you can see it changing the
return value after it prints the message:

                static int count;

                if (++count <= 50)
                        compat_ioctl_error(filp, fd, cmd, arg);
                error = -EINVAL;

So apparently this is a feature?

-- 
Chuck
"Even supernovas have their duller moments."

Re: BUG? atleast >=2.6.19-rc5, x86 chroot on x86_64

[David Howells]

Chuck Ebbert <76306.1226@compuserve.com> wrote:

> I only have 32-bit userspace.  When I run your program against
> a directory on a JFS filesystem (msdos ioctls not supported)
> I get this on vanilla 2.6.19:

Can I just check?  You're using an x86_64 CPU in 64-bit mode with a 64-bit
kernel, but with a completely 32-bit userspace?

> I only have 32-bit userspace.  When I run your program against
> a directory on a JFS filesystem (msdos ioctls not supported)
> I get this on vanilla 2.6.19:

Wait!  You're using JFS, not VFAT?  Oh... I see.

Okay: It's not the MSDOS/VFAT patch that's wrong.  Please don't revert that.
It's the compat ioctl code that's "wrong".

So compat_sys_ioctl() used to return ENOTTY (ENOIOCTLCMD internally) because
the MSDOS ioctl was listed as one that could be translated but it didn't apply
to JFS.

But now, since all the block-based filesystem ioctls have been removed from
that list, you now get EINVAL, not ENOTTY.

> So apparently this is a feature?

Unfortunately, I think it has to be.  We could add a master list of ioctls to
be issued with particular errors if the driver doesn't support them, but is it
worth it?

A question for you: Why is userspace assuming that it'll get ENOTTY rather
than EINVAL?

David

Re: BUG? atleast >=2.6.19-rc5, x86 chroot on x86_64

[Chuck Ebbert]

In-Reply-To: <20061204192018.2a61814f.akpm@osdl.org>

On Mon, 4 Dec 2006 19:20:18 -0800, Andrew Morton wrote:

> On Tue, 05 Dec 2006 03:36:09 +0100
> Kasper Sandberg <lkml@metanurb.dk> wrote:
> 
> > i know i said i suspected this was another bug, but i have revised my
> > suspecisions, and i do believe its in relation to x86 chroot on x86_64
> > install, as it has happened with more stuff now, inside the chroot, and
> > only inside the chroot, while the same apps dont do it outside chroot.
> > 
> > 2.6.19 release is affected too

> > > > ioctl32(regedit.exe:11801): Unknown cmd fd(9) cmd(82187201){02}
> > > > arg(00221000) on /home/redeeman
> > > > ioctl32(regedit.exe:11801): Unknown cmd fd(9) cmd(82187201){02}
> > > > arg(00221000) on /home/redeeman/.wine/drive_c/windows/system32

> Possibly some ioctl got removed.  I don't know why it would only occur
> within a chrooted environment.
> 
> Possibly one could work out what's going on by reverse-engineering x86_64
> ioctl command 0x82187201, but unfortunately I don't have time to do that. 

That is VFAT_IOCTL_READDIR_BOTH32

This patch:
        [PATCH] BLOCK: Move the msdos device ioctl
                compat stuff to the msdos driver [try #6]

may have caused this.

Here is a patch to reverse that.  Kasper, can you test it?
(Your filesystem is on a FAT/VFAT volume, I assume.)


[Revert] [PATCH] BLOCK: Move the msdos device ioctl compat stuff to the msdos driver [try #6]

Reverts:

Move the msdos device ioctl compat stuff from fs/compat_ioctl.c to the msdos
driver so that the msdos header file doesn't need to be included.

Signed-Off-By: David Howells <dhowells@redhat.com>
Signed-off-by: Jens Axboe <axboe@kernel.dk>

committer: Jens Axboe <axboe@nelson.home.kernel.dk> 1159642350 +0200


 fs/compat_ioctl.c |   49 +++++++++++++++++++++++++++++++++++++++++++++++
 fs/fat/dir.c      |   56 ------------------------------------------------------
 2 files changed, 49 insertions(+), 56 deletions(-)

--- 2.6.19.0.2-32.orig/fs/compat_ioctl.c
+++ 2.6.19.0.2-32/fs/compat_ioctl.c
@@ -107,6 +107,7 @@
 #include <linux/nbd.h>
 #include <linux/random.h>
 #include <linux/filter.h>
+#include <linux/msdos_fs.h>
 #include <linux/pktcdvd.h>
 
 #include <linux/hiddev.h>
@@ -1945,6 +1946,51 @@ static int mtd_rw_oob(unsigned int fd, u
 	return err;
 }	
 
+#define	VFAT_IOCTL_READDIR_BOTH32	_IOR('r', 1, struct compat_dirent[2])
+#define	VFAT_IOCTL_READDIR_SHORT32	_IOR('r', 2, struct compat_dirent[2])
+
+static long
+put_dirent32 (struct dirent *d, struct compat_dirent __user *d32)
+{
+        if (!access_ok(VERIFY_WRITE, d32, sizeof(struct compat_dirent)))
+                return -EFAULT;
+
+        __put_user(d->d_ino, &d32->d_ino);
+        __put_user(d->d_off, &d32->d_off);
+        __put_user(d->d_reclen, &d32->d_reclen);
+        if (__copy_to_user(d32->d_name, d->d_name, d->d_reclen))
+		return -EFAULT;
+
+        return 0;
+}
+
+static int vfat_ioctl32(unsigned fd, unsigned cmd, unsigned long arg)
+{
+	struct compat_dirent __user *p = compat_ptr(arg);
+	int ret;
+	mm_segment_t oldfs = get_fs();
+	struct dirent d[2];
+
+	switch(cmd)
+	{
+        	case VFAT_IOCTL_READDIR_BOTH32:
+                	cmd = VFAT_IOCTL_READDIR_BOTH;
+                	break;
+        	case VFAT_IOCTL_READDIR_SHORT32:
+                	cmd = VFAT_IOCTL_READDIR_SHORT;
+                	break;
+	}
+
+	set_fs(KERNEL_DS);
+	ret = sys_ioctl(fd,cmd,(unsigned long)&d);
+	set_fs(oldfs);
+	if (ret >= 0) {
+		ret |= put_dirent32(&d[0], p);
+		ret |= put_dirent32(&d[1], p + 1);
+	}
+	return ret;
+}
+
 #ifdef CONFIG_BLOCK
 struct raw32_config_request
 {
@@ -2513,6 +2559,9 @@ HANDLE_IOCTL(SONET_GETFRSENSE, do_atm_io
 HANDLE_IOCTL(BLKBSZGET_32, do_blkbszget)
 HANDLE_IOCTL(BLKBSZSET_32, do_blkbszset)
 HANDLE_IOCTL(BLKGETSIZE64_32, do_blkgetsize64)
+/* vfat */
+HANDLE_IOCTL(VFAT_IOCTL_READDIR_BOTH32, vfat_ioctl32)
+HANDLE_IOCTL(VFAT_IOCTL_READDIR_SHORT32, vfat_ioctl32)
 /* Raw devices */
 HANDLE_IOCTL(RAW_SETBIND, raw_ioctl)
 HANDLE_IOCTL(RAW_GETBIND, raw_ioctl)
--- 2.6.19.0.2-32.orig/fs/fat/dir.c
+++ 2.6.19.0.2-32/fs/fat/dir.c
@@ -20,7 +20,6 @@
 #include <linux/dirent.h>
 #include <linux/smp_lock.h>
 #include <linux/buffer_head.h>
-#include <linux/compat.h>
 #include <asm/uaccess.h>
 
 static inline loff_t fat_make_i_pos(struct super_block *sb,
@@ -742,65 +741,10 @@ static int fat_dir_ioctl(struct inode * 
 	return ret;
 }
 
-#ifdef CONFIG_COMPAT
-#define	VFAT_IOCTL_READDIR_BOTH32	_IOR('r', 1, struct compat_dirent[2])
-#define	VFAT_IOCTL_READDIR_SHORT32	_IOR('r', 2, struct compat_dirent[2])
-
-static long fat_compat_put_dirent32(struct dirent *d,
-				    struct compat_dirent __user *d32)
-{
-        if (!access_ok(VERIFY_WRITE, d32, sizeof(struct compat_dirent)))
-                return -EFAULT;
-
-        __put_user(d->d_ino, &d32->d_ino);
-        __put_user(d->d_off, &d32->d_off);
-        __put_user(d->d_reclen, &d32->d_reclen);
-        if (__copy_to_user(d32->d_name, d->d_name, d->d_reclen))
-		return -EFAULT;
-
-        return 0;
-}
-
-static long fat_compat_dir_ioctl(struct file *file, unsigned cmd,
-				 unsigned long arg)
-{
-	struct compat_dirent __user *p = compat_ptr(arg);
-	int ret;
-	mm_segment_t oldfs = get_fs();
-	struct dirent d[2];
-
-	switch (cmd) {
-	case VFAT_IOCTL_READDIR_BOTH32:
-		cmd = VFAT_IOCTL_READDIR_BOTH;
-		break;
-	case VFAT_IOCTL_READDIR_SHORT32:
-		cmd = VFAT_IOCTL_READDIR_SHORT;
-		break;
-	default:
-		return -ENOIOCTLCMD;
-	}
-
-	set_fs(KERNEL_DS);
-	lock_kernel();
-	ret = fat_dir_ioctl(file->f_dentry->d_inode, file,
-			    cmd, (unsigned long) &d);
-	unlock_kernel();
-	set_fs(oldfs);
-	if (ret >= 0) {
-		ret |= fat_compat_put_dirent32(&d[0], p);
-		ret |= fat_compat_put_dirent32(&d[1], p + 1);
-	}
-	return ret;
-}
-#endif /* CONFIG_COMPAT */
-
 const struct file_operations fat_dir_operations = {
 	.read		= generic_read_dir,
 	.readdir	= fat_readdir,
 	.ioctl		= fat_dir_ioctl,
-#ifdef CONFIG_COMPAT
-	.compat_ioctl	= fat_compat_dir_ioctl,
-#endif
 	.fsync		= file_fsync,
 };
 
-- 
Chuck
"Even supernovas have their duller moments."

Re: BUG? atleast >=2.6.19-rc5, x86 chroot on x86_64

[David Howells]

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

Chuck Ebbert <76306.1226@compuserve.com> wrote:

> Here is a patch to reverse that.  Kasper, can you test it?
> (Your filesystem is on a FAT/VFAT volume, I assume.)

Please don't revert that patch.  If you do, you'll break CONFIG_BLOCK=n.

Can you compile and run the attached program as both 32-bit and 64-bit?

On my x86_64 test box, I did:

	[root@andromeda ~]# mkfs.vfat /dev/sda5
	[root@andromeda ~]# mount /dev/sda5 /mnt
	[root@andromeda ~]# mkdir /mnt/a
	[root@andromeda ~]# /tmp/ioctl /mnt/a		# 32-bit
	268 : 82187201, 82187202
	268 : 82187201, 82187202
	Calling VFAT_IOCTL_READDIR_BOTH32
	Calling VFAT_IOCTL_READDIR_BOTH
	[root@andromeda ~]# /tmp/ioctl /mnt/a		# 64-bit
	280 : 82307201, 82307202
	268 : 82187201, 82187202
	Calling VFAT_IOCTL_READDIR_BOTH32
	ioctl: Inappropriate ioctl for device
	Calling VFAT_IOCTL_READDIR_BOTH

Which is what I'd expect (the 64-bit ioctl does not support the 32-bit
function).  Tracing the 64-bit version shows that the right numbers are being
given to the syscall, though strace decodes them as the same symbol if not in
raw mode:

	[root@andromeda ~]# strace -eioctl -eraw=ioctl /tmp/ioctl /mnt/a
	280 : 82307201, 82307202
	268 : 82187201, 82187202
	Calling VFAT_IOCTL_READDIR_BOTH32
	ioctl(0x3, 0x82187201, 0x7fff9cec36c0)  = -1 (errno 25)
	ioctl: Inappropriate ioctl for device
	Calling VFAT_IOCTL_READDIR_BOTH
	ioctl(0x3, 0x82307201, 0x7fff9cec3490)  = 0x1
	Process 3410 detached

Applying the attached patch to the kernel produces the following elements in
the log for the 32-bit compilation:

	==> fat_compat_dir_ioctl(82187201,ffa803b8)
	==> fat_dir_ioctl(82307201,ffff810036a97ca8)
	<== fat_dir_ioctl() = 1
	<== fat_compat_dir_ioctl() = 1
	==> fat_compat_dir_ioctl(82187201,ffa801a0)
	==> fat_dir_ioctl(82307201,ffff810036a97ca8)
	<== fat_dir_ioctl() = 1
	<== fat_compat_dir_ioctl() = 1

and this for the 64-bit compilation:

	==> fat_dir_ioctl(82187201,7fff031f69f0)
	call fat_generic_ioctl()
	<== fat_dir_ioctl() = -25
	==> fat_dir_ioctl(82307201,7fff031f67c0)
	<== fat_dir_ioctl() = 1

Which is entirely what I'd expect.

However, it's possible that the 64-bit kernel interface used to allow the
32-bit calls.  If that's the case could you be running a 64-bit program
somewhere in your 32-bit chroot?

| i have only tested with >=rc5, thw folling, as an example, appears in
| dmesg:
| ioctl32(regedit.exe:11801): Unknown cmd fd(9) cmd(82187201){02}
| arg(00221000) on /home/redeeman
| ioctl32(regedit.exe:11801): Unknown cmd fd(9) cmd(82187201){02}
| arg(00221000) on /home/redeeman/.wine/drive_c/windows/system32
| ioctl32(regedit.exe:11801): Unknown cmd fd(9) cmd(82187201){02}
| arg(00221000) on /home/redeeman/.wine/drive_c/windows/system

How do you get that?  I don't see anything like that.  I've tried:

	echo 1 >/proc/sys/kernel/compat-log

But that doesn't seem to do anything.

David


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: ioctl.c --]
[-- Type: text/x-c, Size: 3054 bytes --]

#include <stdlib.h>
#include <stdio.h>
#include <fcntl.h>
#include <unistd.h>
#include <sys/ioctl.h>

#define _IOC_NRBITS	8
#define _IOC_TYPEBITS	8
#define _IOC_SIZEBITS	14
#define _IOC_DIRBITS	2

#define _IOC_NRMASK	((1 << _IOC_NRBITS)-1)
#define _IOC_TYPEMASK	((1 << _IOC_TYPEBITS)-1)
#define _IOC_SIZEMASK	((1 << _IOC_SIZEBITS)-1)
#define _IOC_DIRMASK	((1 << _IOC_DIRBITS)-1)

#define _IOC_NRSHIFT	0
#define _IOC_TYPESHIFT	(_IOC_NRSHIFT+_IOC_NRBITS)
#define _IOC_SIZESHIFT	(_IOC_TYPESHIFT+_IOC_TYPEBITS)
#define _IOC_DIRSHIFT	(_IOC_SIZESHIFT+_IOC_SIZEBITS)

#define _IOC_NONE	0U
#define _IOC_WRITE	1U
#define _IOC_READ	2U

#define _IOC(dir,type,nr,size) \
	(((dir)  << _IOC_DIRSHIFT) | \
	 ((type) << _IOC_TYPESHIFT) | \
	 ((nr)   << _IOC_NRSHIFT) | \
	 ((size) << _IOC_SIZESHIFT))

extern unsigned int __invalid_size_argument_for_IOC;
#define _IOC_TYPECHECK(t) \
	((sizeof(t) == sizeof(t[1]) && \
	  sizeof(t) < (1 << _IOC_SIZEBITS)) ? \
	  sizeof(t) : __invalid_size_argument_for_IOC)

#define _IO(type,nr)		_IOC(_IOC_NONE,(type),(nr),0)
#define _IOR(type,nr,size)	_IOC(_IOC_READ,(type),(nr),(_IOC_TYPECHECK(size)))
#define _IOW(type,nr,size)	_IOC(_IOC_WRITE,(type),(nr),(_IOC_TYPECHECK(size)))
#define _IOWR(type,nr,size)	_IOC(_IOC_READ|_IOC_WRITE,(type),(nr),(_IOC_TYPECHECK(size)))
#define _IOR_BAD(type,nr,size)	_IOC(_IOC_READ,(type),(nr),sizeof(size))
#define _IOW_BAD(type,nr,size)	_IOC(_IOC_WRITE,(type),(nr),sizeof(size))
#define _IOWR_BAD(type,nr,size)	_IOC(_IOC_READ|_IOC_WRITE,(type),(nr),sizeof(size))

#define	VFAT_IOCTL_READDIR_BOTH32	_IOR('r', 1, struct compat_dirent[2])
#define	VFAT_IOCTL_READDIR_SHORT32	_IOR('r', 2, struct compat_dirent[2])
#define VFAT_IOCTL_READDIR_BOTH		_IOR('r', 1, struct dirent [2])
#define VFAT_IOCTL_READDIR_SHORT	_IOR('r', 2, struct dirent [2])

typedef unsigned short u16;
typedef signed int s32;
typedef unsigned int u32;
typedef long		__kernel_off_t;
typedef s32		compat_off_t;

struct compat_dirent {
	u32		d_ino;
	compat_off_t	d_off;
	u16		d_reclen;
	char		d_name[256];
};

struct dirent {
	long		d_ino;
	__kernel_off_t	d_off;
	unsigned short	d_reclen;
	char		d_name[256]; /* We must not include limits.h! */
};

#define O_DIRECTORY	00200000	/* must be a directory */

int main(int argc, char *argv[])
{
	struct compat_dirent cdire[2];
	struct dirent dire[2];
	int fd;

	printf("%zu : %lx, %lx\n",
	       sizeof(struct dirent),
	       (unsigned long) VFAT_IOCTL_READDIR_BOTH,
	       (unsigned long) VFAT_IOCTL_READDIR_SHORT);
	printf("%zu : %lx, %lx\n",
	       sizeof(struct compat_dirent),
	       (unsigned long) VFAT_IOCTL_READDIR_BOTH32,
	       (unsigned long) VFAT_IOCTL_READDIR_SHORT32);

	for (argv++; *argv; argv++) {
		fd = open(*argv, O_DIRECTORY | O_RDONLY);
		if (fd < 0) {
			perror(*argv);
			exit(1);
		}

		printf("Calling VFAT_IOCTL_READDIR_BOTH32\n");
		if (ioctl(fd, VFAT_IOCTL_READDIR_BOTH32, cdire) < 0)
			perror("ioctl");
		printf("Calling VFAT_IOCTL_READDIR_BOTH\n");
		if (ioctl(fd, VFAT_IOCTL_READDIR_BOTH, dire) < 0)
			perror("ioctl");
		close(fd);
	}

	return 0;
}

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #3: ioctl.diff --]
[-- Type: text/x-patch, Size: 1365 bytes --]

diff --git a/fs/fat/dir.c b/fs/fat/dir.c
index 69c439f..eadaef1 100644
--- a/fs/fat/dir.c
+++ b/fs/fat/dir.c
@@ -704,6 +704,8 @@ static int fat_dir_ioctl(struct inode * 
 	struct dirent __user *d1;
 	int ret, short_only, both;
 
+	printk("==> fat_dir_ioctl(%x,%lx)\n", cmd, arg);
+
 	switch (cmd) {
 	case VFAT_IOCTL_READDIR_SHORT:
 		short_only = 1;
@@ -714,7 +716,9 @@ static int fat_dir_ioctl(struct inode * 
 		both = 1;
 		break;
 	default:
-		return fat_generic_ioctl(inode, filp, cmd, arg);
+		printk("call fat_generic_ioctl()\n");
+		ret = fat_generic_ioctl(inode, filp, cmd, arg);
+		goto out;
 	}
 
 	d1 = (struct dirent __user *)arg;
@@ -739,6 +743,8 @@ static int fat_dir_ioctl(struct inode * 
 	mutex_unlock(&inode->i_mutex);
 	if (ret >= 0)
 		ret = buf.result;
+out:
+	printk("<== fat_dir_ioctl() = %d\n", ret);
 	return ret;
 }
 
@@ -769,6 +775,8 @@ static long fat_compat_dir_ioctl(struct 
 	mm_segment_t oldfs = get_fs();
 	struct dirent d[2];
 
+	printk("==> fat_compat_dir_ioctl(%x,%lx)\n", cmd, arg);
+
 	switch (cmd) {
 	case VFAT_IOCTL_READDIR_BOTH32:
 		cmd = VFAT_IOCTL_READDIR_BOTH;
@@ -790,6 +798,7 @@ static long fat_compat_dir_ioctl(struct 
 		ret |= fat_compat_put_dirent32(&d[0], p);
 		ret |= fat_compat_put_dirent32(&d[1], p + 1);
 	}
+	printk("<== fat_compat_dir_ioctl() = %d\n", ret);
 	return ret;
 }
 #endif /* CONFIG_COMPAT */

Re: BUG? atleast >=2.6.19-rc5, x86 chroot on x86_64

[Kasper Sandberg]

On Tue, 2006-12-05 at 14:19 +0000, David Howells wrote:
> Chuck Ebbert <76306.1226@compuserve.com> wrote:
> 
> > Here is a patch to reverse that.  Kasper, can you test it?
> > (Your filesystem is on a FAT/VFAT volume, I assume.)

I do have a fat32 filesystem mounted using the vfat driver (the msdos
one arent compiled in), however the chroot in no way has access to this,
and i dont see how ANY 32bit apps can have attempted to access it, ill
go so far as say im certain they havent.

> 
> Please don't revert that patch.  If you do, you'll break CONFIG_BLOCK=n.
okay, i will not.

> 
> Can you compile and run the attached program as both 32-bit and 64-bit?
Yes, i will conduct tests, however it will have to wait till atleast
tomorow (cant garantuee anything though, i have lots of work to do).
> 
> On my x86_64 test box, I did:
> 
> 	[root@andromeda ~]# mkfs.vfat /dev/sda5
> 	[root@andromeda ~]# mount /dev/sda5 /mnt
> 	[root@andromeda ~]# mkdir /mnt/a
> 	[root@andromeda ~]# /tmp/ioctl /mnt/a		# 32-bit
> 	268 : 82187201, 82187202
> 	268 : 82187201, 82187202
> 	Calling VFAT_IOCTL_READDIR_BOTH32
> 	Calling VFAT_IOCTL_READDIR_BOTH
> 	[root@andromeda ~]# /tmp/ioctl /mnt/a		# 64-bit
> 	280 : 82307201, 82307202
> 	268 : 82187201, 82187202
> 	Calling VFAT_IOCTL_READDIR_BOTH32
> 	ioctl: Inappropriate ioctl for device
> 	Calling VFAT_IOCTL_READDIR_BOTH
> 
> Which is what I'd expect (the 64-bit ioctl does not support the 32-bit
> function).  Tracing the 64-bit version shows that the right numbers are being
> given to the syscall, though strace decodes them as the same symbol if not in
> raw mode:
> 
> 	[root@andromeda ~]# strace -eioctl -eraw=ioctl /tmp/ioctl /mnt/a
> 	280 : 82307201, 82307202
> 	268 : 82187201, 82187202
> 	Calling VFAT_IOCTL_READDIR_BOTH32
> 	ioctl(0x3, 0x82187201, 0x7fff9cec36c0)  = -1 (errno 25)
> 	ioctl: Inappropriate ioctl for device
> 	Calling VFAT_IOCTL_READDIR_BOTH
> 	ioctl(0x3, 0x82307201, 0x7fff9cec3490)  = 0x1
> 	Process 3410 detached
> 
> Applying the attached patch to the kernel produces the following elements in
> the log for the 32-bit compilation:
> 
> 	==> fat_compat_dir_ioctl(82187201,ffa803b8)
> 	==> fat_dir_ioctl(82307201,ffff810036a97ca8)
> 	<== fat_dir_ioctl() = 1
> 	<== fat_compat_dir_ioctl() = 1
> 	==> fat_compat_dir_ioctl(82187201,ffa801a0)
> 	==> fat_dir_ioctl(82307201,ffff810036a97ca8)
> 	<== fat_dir_ioctl() = 1
> 	<== fat_compat_dir_ioctl() = 1
> 
> and this for the 64-bit compilation:
> 
> 	==> fat_dir_ioctl(82187201,7fff031f69f0)
> 	call fat_generic_ioctl()
> 	<== fat_dir_ioctl() = -25
> 	==> fat_dir_ioctl(82307201,7fff031f67c0)
> 	<== fat_dir_ioctl() = 1
> 
> Which is entirely what I'd expect.
> 
> However, it's possible that the 64-bit kernel interface used to allow the
> 32-bit calls.  If that's the case could you be running a 64-bit program
> somewhere in your 32-bit chroot?
I am basically positive that i am not running 64bit stuff within my
32bit chroot, however i will check to make absolutely sure.
> 
> | i have only tested with >=rc5, thw folling, as an example, appears in
> | dmesg:
> | ioctl32(regedit.exe:11801): Unknown cmd fd(9) cmd(82187201){02}
> | arg(00221000) on /home/redeeman
> | ioctl32(regedit.exe:11801): Unknown cmd fd(9) cmd(82187201){02}
> | arg(00221000) on /home/redeeman/.wine/drive_c/windows/system32
> | ioctl32(regedit.exe:11801): Unknown cmd fd(9) cmd(82187201){02}
> | arg(00221000) on /home/redeeman/.wine/drive_c/windows/system
> 
> How do you get that?  I don't see anything like that.  I've tried:
all i did was run wine's regedit inside my 32bit chroot.
> 
> 	echo 1 >/proc/sys/kernel/compat-log
> 
> But that doesn't seem to do anything.
> 
> David
> 

BUG? atleast >=2.6.19-rc5, x86 chroot on x86_64

[Kasper Sandberg]

Hello..

it appears some sort of bug has gotten into .19, in regards to x86
emulation on x86_64.

i have only tested with >=rc5, thw folling, as an example, appears in
dmesg:
ioctl32(regedit.exe:11801): Unknown cmd fd(9) cmd(82187201){02}
arg(00221000) on /home/redeeman
ioctl32(regedit.exe:11801): Unknown cmd fd(9) cmd(82187201){02}
arg(00221000) on /home/redeeman/.wine/drive_c/windows/system32
ioctl32(regedit.exe:11801): Unknown cmd fd(9) cmd(82187201){02}
arg(00221000) on /home/redeeman/.wine/drive_c/windows/system
ioctl32(regedit.exe:11801): Unknown cmd fd(9) cmd(82187201){02}
arg(00221000) on /home/redeeman/.wine/drive_c/windows
ioctl32(regedit.exe:11801): Unknown cmd fd(9) cmd(82187201){02}
arg(00221000) on /home/redeeman
ioctl32(regedit.exe:11801): Unknown cmd fd(9) cmd(82187201){02}
arg(00221000) on /home/redeeman/.wine/drive_c/windows
ioctl32(regedit.exe:11801): Unknown cmd fd(9) cmd(82187201){02}
arg(00221000) on /home/redeeman
ioctl32(regedit.exe:11801): Unknown cmd fd(9) cmd(82187201){02}
arg(00221000) on /home/redeeman/.wine/drive_c/windows
ioctl32(regedit.exe:11801): Unknown cmd fd(9) cmd(82187201){02}
arg(00221000) on /home/redeeman
ioctl32(regedit.exe:11801): Unknown cmd fd(9) cmd(82187201){02}
arg(00221000) on /home/redeeman/.wine/drive_c/windows
ioctl32(regedit.exe:11801): Unknown cmd fd(9) cmd(82187201){02}
arg(00221000) on /home/redeeman/.wine/drive_c/windows/fonts
ioctl32(regedit.exe:11801): Unknown cmd fd(9) cmd(82187201){02}
arg(00221000) on /home/redeeman/.wine/drive_c/windows
ioctl32(regedit.exe:11801): Unknown cmd fd(9) cmd(82187201){02}
arg(00221000) on /home/redeeman/.wine/drive_c/windows/fonts
ioctl32(regedit.exe:11801): Unknown cmd fd(9) cmd(82187201){02}
arg(00221000) on /home/redeeman/.wine/drive_c/windows
ioctl32(regedit.exe:11801): Unknown cmd fd(9) cmd(82187201){02}
arg(00221000) on /home/redeeman/.wine/drive_c/windows
ioctl32(regedit.exe:11801): Unknown cmd fd(9) cmd(82187201){02}
arg(00221000) on /home/redeeman/.wine/drive_c/windows/fonts
ioctl32(regedit.exe:11801): Unknown cmd fd(9) cmd(82187201){02}
arg(00221000) on /home/redeeman/.wine/drive_c/windows
ioctl32(regedit.exe:11801): Unknown cmd fd(9) cmd(82187201){02}
arg(00221000) on /home/redeeman/.wine/drive_c/windows/fonts
ioctl32(regedit.exe:11801): Unknown cmd fd(9) cmd(82187201){02}
arg(00221000) on /home/redeeman/.wine/drive_c/windows
ioctl32(regedit.exe:11801): Unknown cmd fd(9) cmd(82187201){02}
arg(00221000) on /home/redeeman/.wine/drive_c/windows/fonts
ioctl32(regedit.exe:11801): Unknown cmd fd(9) cmd(82187201){02}
arg(00221000) on /home/redeeman/.wine/drive_c/windows
ioctl32(regedit.exe:11801): Unknown cmd fd(9) cmd(82187201){02}
arg(00221000) on /home/redeeman/.wine/drive_c/windows/fonts
ioctl32(regedit.exe:11801): Unknown cmd fd(9) cmd(82187201){02}
arg(00221000) on /home/redeeman/.wine/drive_c/windows/system32
ioctl32(regedit.exe:11801): Unknown cmd fd(9) cmd(82187201){02}
arg(00221000) on /home/redeeman
ioctl32(regedit.exe:11801): Unknown cmd fd(9) cmd(82187201){02}
arg(00221000) on /home/redeeman/.wine/drive_c/windows/system32
ioctl32(regedit.exe:11801): Unknown cmd fd(9) cmd(82187201){02}
arg(00221000) on /home/redeeman/.wine/drive_c/windows/system
ioctl32(regedit.exe:11801): Unknown cmd fd(9) cmd(82187201){02}
arg(00221000) on /home/redeeman/.wine/drive_c/windows
ioctl32(regedit.exe:11801): Unknown cmd fd(9) cmd(82187201){02}
arg(00221000) on /home/redeeman/.wine/drive_c/windows/system32
ioctl32(regedit.exe:11801): Unknown cmd fd(9) cmd(82187201){02}
arg(00221000) on /home/redeeman/.wine/drive_c/windows
ioctl32(regedit.exe:11801): Unknown cmd fd(9) cmd(82187201){02}
arg(00221000) on /home/redeeman/.wine/drive_c/windows/system32
ioctl32(regedit.exe:11801): Unknown cmd fd(9) cmd(82187201){02}
arg(00221000) on /home/redeeman
ioctl32(regedit.exe:11801): Unknown cmd fd(9) cmd(82187201){02}
arg(00221000) on /home/redeeman/.wine/drive_c/windows/system32
ioctl32(regedit.exe:11801): Unknown cmd fd(9) cmd(82187201){02}
arg(00221000) on /home/redeeman/.wine/drive_c/windows/system
ioctl32(regedit.exe:11801): Unknown cmd fd(9) cmd(82187201){02}
arg(00221000) on /home/redeeman/.wine/drive_c/windows
ioctl32(regedit.exe:11801): Unknown cmd fd(9) cmd(82187201){02}
arg(00221000) on /home/redeeman/.wine/drive_c/windows/system32
ioctl32(regedit.exe:11801): Unknown cmd fd(9) cmd(82187201){02}
arg(00221000) on /home/redeeman/.wine/drive_c/windows
ioctl32(regedit.exe:11801): Unknown cmd fd(9) cmd(82187201){02}
arg(00221000) on /home/redeeman/.wine/drive_c/windows/system32
ioctl32(regedit.exe:11801): Unknown cmd fd(9) cmd(82187201){02}
arg(00221000) on /home/redeeman
ioctl32(regedit.exe:11801): Unknown cmd fd(9) cmd(82187201){02}
arg(00221000) on /home/redeeman/.wine/drive_c/windows/system32
ioctl32(regedit.exe:11801): Unknown cmd fd(9) cmd(82187201){02}
arg(00221000) on /home/redeeman/.wine/drive_c/windows/system
ioctl32(regedit.exe:11801): Unknown cmd fd(9) cmd(82187201){02}
arg(00221000) on /home/redeeman/.wine/drive_c/windows
ioctl32(regedit.exe:11801): Unknown cmd fd(9) cmd(82187201){02}
arg(00221000) on /home/redeeman/.wine/drive_c/windows/system32
ioctl32(regedit.exe:11801): Unknown cmd fd(9) cmd(82187201){02}
arg(00221000) on /home/redeeman/.wine/drive_c/windows
ioctl32(regedit.exe:11801): Unknown cmd fd(9) cmd(82187201){02}
arg(00221000) on /home/redeeman/.wine/drive_c/windows/system32
ioctl32(regedit.exe:11801): Unknown cmd fd(9) cmd(82187201){02}
arg(00221000) on /home/redeeman/.wine/drive_c/windows/system32
ioctl32(regedit.exe:11801): Unknown cmd fd(9) cmd(82187201){02}
arg(00221000) on /home/redeeman/.wine/drive_c/windows/system32
ioctl32(explorer.exe:11806): Unknown cmd fd(8) cmd(82187201){02}
arg(00222000) on /home/redeeman/.wine/drive_c/windows/system32
ioctl32(explorer.exe:11806): Unknown cmd fd(8) cmd(82187201){02}
arg(00222000) on /home/redeeman/.wine/drive_c/windows
ioctl32(explorer.exe:11806): Unknown cmd fd(8) cmd(82187201){02}
arg(00222000) on /home/redeeman/.wine/drive_c/windows/fonts
ioctl32(explorer.exe:11806): Unknown cmd fd(8) cmd(82187201){02}
arg(00222000) on /home/redeeman/.wine/drive_c/windows

however it doesent seem to affect the regedit and explorer.exe, some
applications when run within wine does some VERY weird shit, i have even
observed a few hardlock which i suspect may be due to this.


im sorry to say that i havent had time to do a git bisect, but i thought
i'd report it anyway.

mvh.
Kasper Sandberg

Re: BUG? atleast >=2.6.19-rc5, x86 chroot on x86_64

[Andrew Morton]

On Wed, 22 Nov 2006 15:29:02 +0100
Kasper Sandberg <lkml@metanurb.dk> wrote:

> it appears some sort of bug has gotten into .19, in regards to x86
> emulation on x86_64.
> 
> i have only tested with >=rc5, thw folling, as an example, appears in
> dmesg:
> ioctl32(regedit.exe:11801): Unknown cmd fd(9) cmd(82187201){02}
> arg(00221000) on /home/redeeman
> ioctl32(regedit.exe:11801): Unknown cmd fd(9) cmd(82187201){02}
> arg(00221000) on /home/redeeman/.wine/drive_c/windows/system32

Try

	echo 0 > /proc/sys/kernel/compat-log

I don't _think_ we did anything to change the logging in there.  Which kernel
version were you using previously (the one which didn't do this)?

Re: BUG? atleast >=2.6.19-rc5, x86 chroot on x86_64

[Kasper Sandberg]

On Wed, 2006-11-22 at 15:25 -0800, Andrew Morton wrote:
> On Wed, 22 Nov 2006 15:29:02 +0100
> Kasper Sandberg <lkml@metanurb.dk> wrote:
> 
> > it appears some sort of bug has gotten into .19, in regards to x86
> > emulation on x86_64.
> > 
> > i have only tested with >=rc5, thw folling, as an example, appears in
> > dmesg:
> > ioctl32(regedit.exe:11801): Unknown cmd fd(9) cmd(82187201){02}
> > arg(00221000) on /home/redeeman
> > ioctl32(regedit.exe:11801): Unknown cmd fd(9) cmd(82187201){02}
> > arg(00221000) on /home/redeeman/.wine/drive_c/windows/system32
> 
> Try
> 
> 	echo 0 > /proc/sys/kernel/compat-log
> 
this appears to make the logging stop, however, it still acts somewhat
weird, and i am somewhat certain its because of this. this appears to be
able to cause hardlocks.
> I don't _think_ we did anything to change the logging in there.  Which kernel
> version were you using previously (the one which didn't do this)?
.18
> 
> 

Re: BUG? atleast >=2.6.19-rc5, x86 chroot on x86_64

[Kasper Sandberg]

i know i said i suspected this was another bug, but i have revised my
suspecisions, and i do believe its in relation to x86 chroot on x86_64
install, as it has happened with more stuff now, inside the chroot, and
only inside the chroot, while the same apps dont do it outside chroot.

2.6.19 release is affected too

On Wed, 2006-11-22 at 15:25 -0800, Andrew Morton wrote:
> On Wed, 22 Nov 2006 15:29:02 +0100
> Kasper Sandberg <lkml@metanurb.dk> wrote:
> 
> > it appears some sort of bug has gotten into .19, in regards to x86
> > emulation on x86_64.
> > 
> > i have only tested with >=rc5, thw folling, as an example, appears in
> > dmesg:
> > ioctl32(regedit.exe:11801): Unknown cmd fd(9) cmd(82187201){02}
> > arg(00221000) on /home/redeeman
> > ioctl32(regedit.exe:11801): Unknown cmd fd(9) cmd(82187201){02}
> > arg(00221000) on /home/redeeman/.wine/drive_c/windows/system32
> 
> Try
> 
> 	echo 0 > /proc/sys/kernel/compat-log
> 
> I don't _think_ we did anything to change the logging in there.  Which kernel
> version were you using previously (the one which didn't do this)?
> 
> -
> 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/
> 

Re: BUG? atleast >=2.6.19-rc5, x86 chroot on x86_64

[Kasper Sandberg]

On Tue, 2006-12-05 at 03:36 +0100, Kasper Sandberg wrote:
> i know i said i suspected this was another bug, but i have revised my
> suspecisions, and i do believe its in relation to x86 chroot on x86_64
> install, as it has happened with more stuff now, inside the chroot, and
> only inside the chroot, while the same apps dont do it outside chroot.
and by that (so that theres no confusion), i mean that with the x86_64
binaries of the same application dont crash it, but the x86 binaries in
the chroot does :)
> 
> 2.6.19 release is affected too
> 
> On Wed, 2006-11-22 at 15:25 -0800, Andrew Morton wrote:
> > On Wed, 22 Nov 2006 15:29:02 +0100
> > Kasper Sandberg <lkml@metanurb.dk> wrote:
> > 
> > > it appears some sort of bug has gotten into .19, in regards to x86
> > > emulation on x86_64.
> > > 
> > > i have only tested with >=rc5, thw folling, as an example, appears in
> > > dmesg:
> > > ioctl32(regedit.exe:11801): Unknown cmd fd(9) cmd(82187201){02}
> > > arg(00221000) on /home/redeeman
> > > ioctl32(regedit.exe:11801): Unknown cmd fd(9) cmd(82187201){02}
> > > arg(00221000) on /home/redeeman/.wine/drive_c/windows/system32
> > 
> > Try
> > 
> > 	echo 0 > /proc/sys/kernel/compat-log
> > 
> > I don't _think_ we did anything to change the logging in there.  Which kernel
> > version were you using previously (the one which didn't do this)?
> > 
> > -
> > 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/
> > 
> 
> -
> 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/
> 

Re: BUG? atleast >=2.6.19-rc5, x86 chroot on x86_64

[Andrew Morton]

On Tue, 05 Dec 2006 03:36:09 +0100
Kasper Sandberg <lkml@metanurb.dk> wrote:

> i know i said i suspected this was another bug, but i have revised my
> suspecisions, and i do believe its in relation to x86 chroot on x86_64
> install, as it has happened with more stuff now, inside the chroot, and
> only inside the chroot, while the same apps dont do it outside chroot.
> 
> 2.6.19 release is affected too

Please don't top-post.

> On Wed, 2006-11-22 at 15:25 -0800, Andrew Morton wrote:
> > On Wed, 22 Nov 2006 15:29:02 +0100
> > Kasper Sandberg <lkml@metanurb.dk> wrote:
> > 
> > > it appears some sort of bug has gotten into .19, in regards to x86
> > > emulation on x86_64.
> > > 
> > > i have only tested with >=rc5, thw folling, as an example, appears in
> > > dmesg:
> > > ioctl32(regedit.exe:11801): Unknown cmd fd(9) cmd(82187201){02}
> > > arg(00221000) on /home/redeeman
> > > ioctl32(regedit.exe:11801): Unknown cmd fd(9) cmd(82187201){02}
> > > arg(00221000) on /home/redeeman/.wine/drive_c/windows/system32
> > 
> > Try
> > 
> > 	echo 0 > /proc/sys/kernel/compat-log
> > 
> > I don't _think_ we did anything to change the logging in there.  Which kernel
> > version were you using previously (the one which didn't do this)?

Possibly some ioctl got removed.  I don't know why it would only occur
within a chrooted environment.

Possibly one could work out what's going on by reverse-engineering x86_64
ioctl command 0x82187201, but unfortunately I don't have time to do that. 

Also unfortunately there appears to be an assumption that unless I
personally can immediately and straightforwardly identify a bug-owner, I
personally own the bug.  The best I can suggest is that you raise a report
at bugzilla.kernel.org so this issue gets ignored in a more organised
fashion.

Sorry.

Re: BUG? atleast >=2.6.19-rc5, x86 chroot on x86_64

[David Howells]

Andrew Morton <akpm@osdl.org> wrote:

> Possibly one could work out what's going on by reverse-engineering x86_64
> ioctl command 0x82187201, but unfortunately I don't have time to do that. 

strace can do that.

David