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