lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <Pine.LNX.4.62.0707061431360.1203@pademelon.sonytel.be>
Date:	Fri, 6 Jul 2007 14:47:57 +0200 (CEST)
From:	Geert Uytterhoeven <Geert.Uytterhoeven@...ycom.com>
To:	Linux Kernel Development <linux-kernel@...r.kernel.org>
cc:	Linux/PPC Development <linuxppc-dev@...abs.org>,
	Hiroaki Fuse <Hiroaki_Fuse@...scei.sony.co.jp>
Subject: Too verbose compat_ioctl messages?

	Hi,

Fuse-san discovered that running the umount that's part of busybox on a PS3
with a recent kernel causes an error message to be printed on the console:

| ioctl32(busybox:1340): Unknown cmd fd(3) cmd(00004c01){t:'L';sz:0} arg(00000000) on /dev/sda1 

On older kernels (e.g. 2.6.16), this doesn't happen.

It can easily be reproduced by installing busybox and running

| busybox umount /mountpoint

on a mounted filesystem (except when using the loop device).

Apparently Busybox uses the LOOP_CLR_FD ioctl when unmounting a file system,
which is supported by the loop device only.
On other block device types, this ioctl is not supported:
  - With a 64-bit application, the block layer returns ENOTTY (Inappropriate
    ioctl for device), while the SCSI layer returns EINVAL (Invalid argument)
  - With a 32-bit application, the compat_ioctl code returns EINVAL (Invalid
    argument) and prints an error on the console (for the first 50
    occurrencies, cfr. fs/compat_ioctl.c:compat_sys_ioctl())

As I understand, compat_ioctl_error() is used to inform the user about ioctl
values that are not yet handled by the compat_ioctl layer. However, LOOP_CLR_FD
doesn't need to be handled (no data to convert between 32-bit and 64-bit), and
it's perfectly valid for a block device to not implement it.
So it's confusing to print this error message.

Is there anything we can do about this?

With kind regards,
 
Geert Uytterhoeven
Software Architect

Sony Network and Software Technology Center Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium
 
Phone:    +32 (0)2 700 8453	
Fax:      +32 (0)2 700 8622	
E-mail:   Geert.Uytterhoeven@...ycom.com	
Internet: http://www.sony-europe.com/
 	
Sony Network and Software Technology Center Europe	
A division of Sony Service Centre (Europe) N.V.	
Registered office: Technologielaan 7 · B-1840 Londerzeel · Belgium	
VAT BE 0413.825.160 · RPR Brussels	
Fortis Bank Zaventem · Swift GEBABEBB08A · IBAN BE39001382358619

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ