Messages in this thread | | | Subject | Re: BUG? atleast >=2.6.19-rc5, x86 chroot on x86_64 | From | Kasper Sandberg <> | Date | Wed, 06 Dec 2006 01:11:29 +0100 |
| |
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 >
- 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/
| |