2001-07-13 20:46:38

by Gary Lyons

[permalink] [raw]
Subject: ioctl bug?


Hello,

I think I have found a bug in the kernel.

starting with 2.4.5ac23 and continuing through both 2.4.6 and
2.v.6-ac2 Whenever I try to do a lsattr or chattr on a directory
I get:

"Inappropriate ioctl for device While reading flags"

on 2.4.5-ac19 I have no problem.

My computer is a pentium 3 with an asus motherboard, i810E
chipset,and ide drives. running redhat 7.1 and the hard drive
is WDC WD600AB

I am more then happy to supply any more information if necessary
and

Thanks,

Gary

--
Where humor is concerned there are no standards -- no one can say what
is good or bad, although you can be sure that everyone will.
-- John Kenneth Galbraith




2001-07-13 21:03:49

by Gary Lyons

[permalink] [raw]
Subject: Re: ioctl bug?

On Sat, 14 Jul 2001, Chris Wedgwood wrote:

>
> what filesystem? ext2 I assume?

Yes. sorry about leaving that out.

Gary


--
Nothing astonishes men so much as common sense and plain dealing.
-- Ralph Waldo Emerson


2001-07-13 21:01:49

by Chris Wedgwood

[permalink] [raw]
Subject: Re: ioctl bug?

On Fri, Jul 13, 2001 at 03:43:15PM -0500, Gary Lyons wrote:

starting with 2.4.5ac23 and continuing through both 2.4.6 and
2.v.6-ac2 Whenever I try to do a lsattr or chattr on a directory
I get:

"Inappropriate ioctl for device While reading flags"

on 2.4.5-ac19 I have no problem.

My computer is a pentium 3 with an asus motherboard, i810E
chipset,and ide drives. running redhat 7.1 and the hard drive
is WDC WD600AB

I am more then happy to supply any more information if necessary
and

what filesystem? ext2 I assume?



--cw

2001-07-13 21:09:29

by Chris Wedgwood

[permalink] [raw]
Subject: Re: ioctl bug?

On Fri, Jul 13, 2001 at 04:00:24PM -0500, Gary Lyons wrote:

Yes. sorry about leaving that out.

strace -fblah lsattr some-dir/

(where some-dir is empty)

and then show us what 'blah' looks like



--cw

2001-07-13 21:13:21

by Chris Wedgwood

[permalink] [raw]
Subject: Re: ioctl bug?

On Sat, Jul 14, 2001 at 09:09:05AM +1200, Chris Wedgwood wrote:
On Fri, Jul 13, 2001 at 04:00:24PM -0500, Gary Lyons wrote:

Yes. sorry about leaving that out.

strace -fblah lsattr some-dir/

(where some-dir is empty)

actually, make sure at least one file is in there


--cw

2001-07-13 21:28:41

by Christoph Hellwig

[permalink] [raw]
Subject: Re: ioctl bug?

Hi Gary,

In article <[email protected]> you wrote:
> On Sat, 14 Jul 2001, Chris Wedgwood wrote:
>
>>
>> what filesystem? ext2 I assume?
>
> Yes. sorry about leaving that out.

In Al's rewrite of the ext2 directory code that went into 2.4.6-pre
(and 2.4.5-ac) ioctl on dirs got lost. Just readd the ioctl line
in the fops declaration in dir.c.

Christoph

--
Whip me. Beat me. Make me maintain AIX.

2001-07-13 21:28:11

by Gary Lyons

[permalink] [raw]
Subject: Re: ioctl bug?

On Sat, 14 Jul 2001, Chris Wedgwood wrote:

> On Sat, Jul 14, 2001 at 09:09:05AM +1200, Chris Wedgwood wrote:
>
> strace -fblah lsattr some-dir/
>
> (where some-dir is empty)
>
> actually, make sure at least one file is in there

Ok here it is but I should mention that Aan Cox just sent me an
email saying he already has a patch for this.

Thanks
Gary
--
"UNIX *is* user-friendly.... It's just picky about who it's friends
with!"
--anonymous

-------output of strace -oblah lsattr ttt/-------------


execve("/usr/bin/lsattr", ["lsattr", "ttt/"], [/* 40 vars */]) = 0
uname({sys="Linux", node="raptor.umaryland.edu", ...}) = 0
brk(0) = 0x8049180
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40017000
open("/etc/ld.so.preload", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=93618, ...}) = 0
old_mmap(NULL, 93618, PROT_READ, MAP_PRIVATE, 3, 0) = 0x40018000
close(3) = 0
open("/lib/libext2fs.so.2", O_RDONLY) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0p8\0\000"..., 1024) = 1024
fstat64(3, {st_mode=S_IFREG|0755, st_size=86714, ...}) = 0
old_mmap(NULL, 73824, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x4002f000
mprotect(0x40040000, 4192, PROT_NONE) = 0
old_mmap(0x40040000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0x10000) = 0x40040000
close(3) = 0
open("/lib/libe2p.so.2", O_RDONLY) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\200\17"..., 1024) = 1024
fstat64(3, {st_mode=S_IFREG|0755, st_size=18313, ...}) = 0
old_mmap(NULL, 16800, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x40042000
mprotect(0x40045000, 4512, PROT_NONE) = 0
old_mmap(0x40045000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0x2000) = 0x40045000
old_mmap(0x40046000, 416, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x40046000
close(3) = 0
open("/lib/libcom_err.so.2", O_RDONLY) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0@\t\0\000"..., 1024) = 1024
fstat64(3, {st_mode=S_IFREG|0755, st_size=8196, ...}) = 0
old_mmap(NULL, 8368, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x40047000
mprotect(0x40048000, 4272, PROT_NONE) = 0
old_mmap(0x40048000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0) = 0x40048000
close(3) = 0
open("/lib/i686/libc.so.6", O_RDONLY) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\200\302"..., 1024) = 1024
fstat64(3, {st_mode=S_IFREG|0755, st_size=5634864, ...}) = 0
old_mmap(NULL, 1242920, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x4004a000
mprotect(0x40170000, 38696, PROT_NONE) = 0
old_mmap(0x40170000, 24576, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0x125000) = 0x40170000
old_mmap(0x40176000, 14120, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x40176000
close(3) = 0
munmap(0x40018000, 93618) = 0
getpid() = 2501
lstat64("ttt/", {st_mode=S_IFDIR|0775, st_size=4096, ...}) = 0
open("ttt/", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = 3
fstat64(3, {st_mode=S_IFDIR|0775, st_size=4096, ...}) = 0
fcntl64(3, F_SETFD, FD_CLOEXEC) = 0
brk(0) = 0x8049180
brk(0x804a1c8) = 0x804a1c8
brk(0x804b000) = 0x804b000
getdents64(3, /* 3 entries */, 4096) = 80
lstat64("ttt//.", {st_mode=S_IFDIR|0775, st_size=4096, ...}) = 0
lstat64("ttt//..", {st_mode=S_IFDIR|0700, st_size=20480, ...}) = 0
lstat64("ttt//qwerty", {st_mode=S_IFREG|0664, st_size=0, ...}) = 0
open("ttt//qwerty", O_RDONLY|O_NONBLOCK) = 4
ioctl(4, EXT2_IOC_GETFLAGS, 0xbffff5c8) = 0
close(4) = 0
open("ttt//qwerty", O_RDONLY|O_NONBLOCK) = 4
ioctl(4, EXT2_IOC_GETVERSION, 0xbffff5c8) = 0
close(4) = 0
fstat64(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 1), ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40018000
ioctl(1, TCGETS, {B38400 opost isig icanon echo ...}) = 0
write(1, "------------ ttt//qwerty\n", 25) = 25
getdents64(3, /* 0 entries */, 4096) = 0
close(3) = 0
munmap(0x40018000, 4096) = 0
_exit(0) = ?




2001-07-13 21:40:23

by Andreas Dilger

[permalink] [raw]
Subject: Re: ioctl bug?

Gary writes:
> I think I have found a bug in the kernel.
>
> starting with 2.4.5ac23 and continuing through both 2.4.6 and
> 2.v.6-ac2 Whenever I try to do a lsattr or chattr on a directory
> I get:
>
> "Inappropriate ioctl for device While reading flags"

Yet another case of Linux pro-active bug-fixing. I have already sent
a patch for this to Linus and Alan. It seems I CC'd ext2-devel, but
not linux-kernel.

Here is the patch again. It was likely caused by Al Viro's major
overhaul of the ext2 directory code, to move it into the page cache.

Cheers, Andreas
===========================================================================
--- linux-2.4.6.orig/fs/ext2/dir.c Thu Jun 28 14:28:24 2001
+++ linux-2.4.6-aed/fs/ext2/dir.c Tue Jul 10 22:59:12 2001
@@ -576,5 +576,6 @@
struct file_operations ext2_dir_operations = {
read: generic_read_dir,
readdir: ext2_readdir,
+ ioctl: ext2_ioctl,
fsync: ext2_sync_file,
};
--
Andreas Dilger \ "If a man ate a pound of pasta and a pound of antipasto,
\ would they cancel out, leaving him still hungry?"
http://www-mddsp.enel.ucalgary.ca/People/adilger/ -- Dogbert