Reproducible bug in 2.4.9-ac10 (NTFS 1.1.18)

Reproducible bug in 2.4.9-ac10 (NTFS 1.1.18)

[José Luis Domingo López]

Hello kernel gurus:

I've experienced a rather nasty bug in NTFS read-only driver 1.1.18 as
present on vanilla linux kernel 2.4.9-ac10. The bug can be triggered with
a simple "find /" command, and it makes the machine to reject any further
access to disks, but SysRq and network still work OK. The same test (which
I'll detail in more detail below) causes no problems with vanilla linux
kernel 2.4.9 (+ LVM 1.0.1 + devfs patch v.183), which includes NTFS driver
version 1.1.6 (compiled just with RO support).

The test setup is as follows: machine in single user mode, no modules
loaded except for ntfs.o and nls_iso8859-1.o. devfs is compiled in but not
mounted on boot. Root filesystem (/dev/hda5) is of type ext2. Windows 2000
workstation partition (/dev/hda1) is mounted read-only on /mnt/win2k. For
the test, / is remounted read-only (to avoid looong fsck's on reboot :).

A simple "find /" goes as expected until it enters /mnt/win2k, where
suddlenly the disks stop being accesed by the operating system. On both
test I've done so far, the problem happens just after the directory
"/mnt/win2k/Archivos de programa/Archivos comunes/Microsoft
Shared/Stationery" (Archivos de programa == Program files, Archivos
comunes == Common files). The machine still replies to pings, even gives
you a "connect" when, for example, telnet to port 25, but no activity on
the disks take place. SysRq still works, but any operation that tries to
access to disks fail (SysRq+S or SysRq+U don't work).

I repeated the same test, but this time I "straced" it (strace find /). As
said before, the machine stops accesing disks on the same directory as
before. The last few lines from strace follow:

write(1,"/mnt/win2k/Archivos de programa"..., 96/mnt/win2k/Archivos de
programa/Archivos comunes/Microsoft Shared/SpeechEngines/TTS/wttss22.dll
) = 96
chdir("..") = 0
lstat64(0x8050ca0,0xbfffee9c) = 0
chdir("..") = 0
lstat64(0x8050ca0,0xbfff04c) = 0
lstat64(0x8057eea,0xbffff15c) = 0
write(1,"/mnt/win2k/Archivos de programa/"...,77/mnt/win2k/Archivos de
programa/Archivos comunes/Microsoft Shared/Stationery
) = 77
open("Stationery",O_RDONLY|O_NONBLOCK|0x18000) = 4
fstat64(0x4,0xbfffef6c) = 0
shmat(4,0x8057eea,0x2ptrace:umoven:Input/output error
) = ?
ipc_subcall(0x4,0x80582e0,0x400,0

And the system "hangs" there (I had to take note of the trace by hand, but
I think I didn't miss anything). As said before, no problems with kernel
2.4.9 and driver 1.1.16.

Installed libc6 is version 2.2.4-1 (Debian Woody version).

If there are further tests needed to identify the problem, let me know and
I'll do them with great pleasure :)

-- 
José Luis Domingo López
Linux Registered User #189436     Debian GNU/Linux Potato (P166 64 MB RAM)
 
jdomingo EN internautas PUNTO org  => ¿ Spam ? Atente a las consecuencias
jdomingo AT internautas DOT   org  => Spam at your own risk

Re: Reproducible bug in 2.4.9-ac10 (NTFS 1.1.18)

[Anton Altaparmakov]

Yep. This is fixed in NTFS 1.1.19 which is in 2.4.9-ac11 and later as well
as in 2.4.10-pre9 and later.

Anton

On Tue, 18 Sep 2001, José Luis Domingo López wrote:

> Hello kernel gurus:
> 
> I've experienced a rather nasty bug in NTFS read-only driver 1.1.18 as
> present on vanilla linux kernel 2.4.9-ac10. The bug can be triggered with
> a simple "find /" command, and it makes the machine to reject any further
> access to disks, but SysRq and network still work OK. The same test (which
> I'll detail in more detail below) causes no problems with vanilla linux
> kernel 2.4.9 (+ LVM 1.0.1 + devfs patch v.183), which includes NTFS driver
> version 1.1.6 (compiled just with RO support).
> 
> The test setup is as follows: machine in single user mode, no modules
> loaded except for ntfs.o and nls_iso8859-1.o. devfs is compiled in but not
> mounted on boot. Root filesystem (/dev/hda5) is of type ext2. Windows 2000
> workstation partition (/dev/hda1) is mounted read-only on /mnt/win2k. For
> the test, / is remounted read-only (to avoid looong fsck's on reboot :).
> 
> A simple "find /" goes as expected until it enters /mnt/win2k, where
> suddlenly the disks stop being accesed by the operating system. On both
> test I've done so far, the problem happens just after the directory
> "/mnt/win2k/Archivos de programa/Archivos comunes/Microsoft
> Shared/Stationery" (Archivos de programa == Program files, Archivos
> comunes == Common files). The machine still replies to pings, even gives
> you a "connect" when, for example, telnet to port 25, but no activity on
> the disks take place. SysRq still works, but any operation that tries to
> access to disks fail (SysRq+S or SysRq+U don't work).
> 
> I repeated the same test, but this time I "straced" it (strace find /). As
> said before, the machine stops accesing disks on the same directory as
> before. The last few lines from strace follow:
> 
> write(1,"/mnt/win2k/Archivos de programa"..., 96/mnt/win2k/Archivos de
> programa/Archivos comunes/Microsoft Shared/SpeechEngines/TTS/wttss22.dll
> ) = 96
> chdir("..") = 0
> lstat64(0x8050ca0,0xbfffee9c) = 0
> chdir("..") = 0
> lstat64(0x8050ca0,0xbfff04c) = 0
> lstat64(0x8057eea,0xbffff15c) = 0
> write(1,"/mnt/win2k/Archivos de programa/"...,77/mnt/win2k/Archivos de
> programa/Archivos comunes/Microsoft Shared/Stationery
> ) = 77
> open("Stationery",O_RDONLY|O_NONBLOCK|0x18000) = 4
> fstat64(0x4,0xbfffef6c) = 0
> shmat(4,0x8057eea,0x2ptrace:umoven:Input/output error
> ) = ?
> ipc_subcall(0x4,0x80582e0,0x400,0
> 
> And the system "hangs" there (I had to take note of the trace by hand, but
> I think I didn't miss anything). As said before, no problems with kernel
> 2.4.9 and driver 1.1.16.
> 
> Installed libc6 is version 2.2.4-1 (Debian Woody version).
> 
> If there are further tests needed to identify the problem, let me know and
> I'll do them with great pleasure :)
> 
> -- 
> José Luis Domingo López
> Linux Registered User #189436     Debian GNU/Linux Potato (P166 64 MB RAM)
>  
> jdomingo EN internautas PUNTO org  => ¿ Spam ? Atente a las consecuencias
> jdomingo AT internautas DOT   org  => Spam at your own risk
> 
> -
> 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/
> 

Best regards,

	Anton
-- 
Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @)
Linux NTFS maintainer / WWW: http://linux-ntfs.sf.net/
ICQ: 8561279 / WWW: http://www-stu.christs.cam.ac.uk/~aia21/