LinuxLists.cc - BUG? atleast >=2.6.19-rc5, x86 chroot on x86

[permalink] [raw]

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

On Wed, 2006-11-22 at 15:25 -0800, Andrew Morton wrote:
> On Wed, 22 Nov 2006 15:29:02 +0100
> Kasper Sandberg <[email protected]> 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
>
>

2006-11-26 18:07:57

[permalink] [raw]

Subject: Re: BUG? atleast >=2.6.19-rc5, x86 chroot on x86_64| perhaps duplicate bug report?

On Wed, 2006-11-22 at 15:25 -0800, Andrew Morton wrote:
> On Wed, 22 Nov 2006 15:29:02 +0100
> Kasper Sandberg <[email protected]> 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)?
>

it just struck me, that this may be the same bug Jesper Juhl has
discovered (atleast the hardlock part), as i read that thread, it strike
me that whenever i have hardlocks from this, its when i in wine runs
stuff that uses basically all my ram, and MAY even touch my swap.

just an idea.

>

2006-11-26 19:52:10

by Alistair John Strachan

[permalink] [raw]

Subject: Re: BUG? atleast >=2.6.19-rc5, x86 chroot on x86_64| perhaps duplicate bug report?

On Sunday 26 November 2006 18:07, Kasper Sandberg wrote:
> On Wed, 2006-11-22 at 15:25 -0800, Andrew Morton wrote:
> > On Wed, 22 Nov 2006 15:29:02 +0100
> >
> > Kasper Sandberg <[email protected]> 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)?
>
> it just struck me, that this may be the same bug Jesper Juhl has
> discovered (atleast the hardlock part), as i read that thread, it strike
> me that whenever i have hardlocks from this, its when i in wine runs
> stuff that uses basically all my ram, and MAY even touch my swap.

I see this same ioctl32 warning on a few apps running inside Wine, but I've
not had any hard locks. On the contrary, everything works fine.

I guess it would be nice to know which ioctl it is that doesn't have a compat
wrapper on x86-64, 82187201 is a bit cryptic.

HTH.

--
Cheers,
Alistair.

Final year Computer Science undergraduate.
1F2 55 South Clerk Street, Edinburgh, UK.

2006-11-26 22:56:51

[permalink] [raw]

Subject: Re: BUG? atleast >=2.6.19-rc5, x86 chroot on x86_64| perhaps duplicate bug report?

On Sun, 2006-11-26 at 19:52 +0000, Alistair John Strachan wrote:
> On Sunday 26 November 2006 18:07, Kasper Sandberg wrote:
> > On Wed, 2006-11-22 at 15:25 -0800, Andrew Morton wrote:
> > > On Wed, 22 Nov 2006 15:29:02 +0100
> > >
> > > Kasper Sandberg <[email protected]> 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)?
> >
> > it just struck me, that this may be the same bug Jesper Juhl has
> > discovered (atleast the hardlock part), as i read that thread, it strike
> > me that whenever i have hardlocks from this, its when i in wine runs
> > stuff that uses basically all my ram, and MAY even touch my swap.
>
> I see this same ioctl32 warning on a few apps running inside Wine, but I've
> not had any hard locks. On the contrary, everything works fine.
thats why i have come to suspect it may not be the ioctl thing that
causes the hardlocks, as i read that other thread
>
> I guess it would be nice to know which ioctl it is that doesn't have a compat
> wrapper on x86-64, 82187201 is a bit cryptic.
yes, it did not say these things on .18 :)

how do i get more verbose information on what exactly it is?
>
> HTH.
>

2006-12-05 02:36:16

[permalink] [raw]

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

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 <[email protected]> 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 [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>

2006-12-05 02:59:27

[permalink] [raw]

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

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 <[email protected]> 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 [email protected]
> > 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 [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>

2006-12-05 03:20:29

by Andrew Morton

[permalink] [raw]

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

On Tue, 05 Dec 2006 03:36:09 +0100
Kasper Sandberg <[email protected]> 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 <[email protected]> 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.

2006-12-05 09:40:26

[permalink] [raw]

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

In-Reply-To: <[email protected]>

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

> On Tue, 05 Dec 2006 03:36:09 +0100
> Kasper Sandberg <[email protected]> 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 <[email protected]>
Signed-off-by: Jens Axboe <[email protected]>

committer: Jens Axboe <[email protected]> 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."

2006-12-05 14:17:49

[permalink] [raw]

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

Andrew Morton <[email protected]> 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

2006-12-05 14:20:35

[permalink] [raw]

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

Attachments:

(No filename) (2.79 kB)
ioctl.c (2.98 kB)
ioctl.diff (1.33 kB)
Download all attachments

2006-12-05 20:40:01

[permalink] [raw]

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

In-Reply-To: <[email protected]>

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."

2006-12-05 22:11:55

[permalink] [raw]

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

Chuck Ebbert <[email protected]> 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

2006-12-06 00:11:37

[permalink] [raw]

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

On Tue, 2006-12-05 at 14:19 +0000, David Howells wrote:
> Chuck Ebbert <[email protected]> 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
>

2006-12-06 02:37:29

[permalink] [raw]

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

In-Reply-To: <[email protected]>

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."

2006-12-06 12:58:09

[permalink] [raw]

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

On Tue, 2006-12-05 at 21:31 -0500, Chuck Ebbert wrote:
> In-Reply-To: <[email protected]>
>
> 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.
>

2006-12-06 13:09:39

[permalink] [raw]

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

Kasper Sandberg <[email protected]> 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

2006-12-06 16:06:35

[permalink] [raw]

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

On Wed, 2006-12-06 at 13:08 +0000, David Howells wrote:
> Kasper Sandberg <[email protected]> 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
>

2006-12-06 16:49:21

[permalink] [raw]

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

Kasper Sandberg <[email protected]> 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

2006-12-06 20:05:57

[permalink] [raw]

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

On Wed, 2006-12-06 at 16:48 +0000, David Howells wrote:
> Kasper Sandberg <[email protected]> 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
>

2006-12-06 21:29:17

by Andi Kleen

[permalink] [raw]

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

> 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

2006-12-06 22:19:19

[permalink] [raw]

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

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
>

2006-12-11 08:35:32

[permalink] [raw]

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

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."

2006-12-13 04:58:45

[permalink] [raw]

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

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.

>

2006-12-13 07:55:27

[permalink] [raw]

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

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

2006-12-13 08:05:41