Hi,
(Is this OT? http://sourceforge.net/forum/forum.php?forum_id=7052
doesn't show much activity...)
Debian Sid, e2fsprogs 1.41.8-1
Home-rolled 64-bit 2.6.30 with 32-bit userland
Is this ioctl32() error caused by a "disconnect" between kernel and
userland?
Thanks
$ df -T /
Filesystem Type 1K-blocks Used Available Use% Mounted on
/dev/sdb2 ext3 34606072 8585632 24262528 27% /
# filefrag -v /bin/cp
Filesystem type is: ef53
Filesystem cylinder groups is approximately 265
File size of /bin/cp is 92476 (23 blocks, blocksize 4096)
ext logical physical expected length flags
Calling get_bmap for block 0
Aborted
[92747.137445] ioctl32(filefrag:17217): Unknown cmd fd(3)
cmd(c020660b){t:'f';sz:32} arg(ffca4c38) on /bin/cp
--
Scooty Puff, Sr
The Doom-Bringer
Ron Johnson wrote:
> Hi,
>
> (Is this OT? http://sourceforge.net/forum/forum.php?forum_id=7052
> doesn't show much activity...)
>
> Debian Sid, e2fsprogs 1.41.8-1
> Home-rolled 64-bit 2.6.30 with 32-bit userland
>
> Is this ioctl32() error caused by a "disconnect" between kernel and
> userland?
>
> Thanks
>
> $ df -T /
> Filesystem Type 1K-blocks Used Available Use% Mounted on
> /dev/sdb2 ext3 34606072 8585632 24262528 27% /
>
> # filefrag -v /bin/cp
> Filesystem type is: ef53
> Filesystem cylinder groups is approximately 265
> File size of /bin/cp is 92476 (23 blocks, blocksize 4096)
> ext logical physical expected length flags
> Calling get_bmap for block 0
> Aborted
>
> [92747.137445] ioctl32(filefrag:17217): Unknown cmd fd(3)
> cmd(c020660b){t:'f';sz:32} arg(ffca4c38) on /bin/cp
It's a bug, I sent a patch...
http://marc.info/?l=linux-ext4&m=124768937928420&w=2
-Eric
On Mon, Jul 20, 2009 at 04:49:04PM -0500, Ron Johnson wrote:
> Hi,
>
> (Is this OT? http://sourceforge.net/forum/forum.php?forum_id=7052
> doesn't show much activity...)
>
> Debian Sid, e2fsprogs 1.41.8-1
> Home-rolled 64-bit 2.6.30 with 32-bit userland
Should be fixed in e2fsprogs 1.41.8-2
- Ted
On 2009-07-20 21:03, Theodore Tso wrote:
> On Mon, Jul 20, 2009 at 04:49:04PM -0500, Ron Johnson wrote:
>> Hi,
>>
>> (Is this OT? http://sourceforge.net/forum/forum.php?forum_id=7052
>> doesn't show much activity...)
>>
>> Debian Sid, e2fsprogs 1.41.8-1
>> Home-rolled 64-bit 2.6.30 with 32-bit userland
>
> Should be fixed in e2fsprogs 1.41.8-2
ff seems to work now, but I still get this in dmesg:
[188883.274547] ioctl32(filefrag:7086): Unknown cmd fd(3)
cmd(c020660b){t:'f';sz:32} arg(ffacb808) on /some/large/file
--
Scooty Puff, Sr
The Doom-Bringer
Ron Johnson wrote:
> On 2009-07-20 21:03, Theodore Tso wrote:
>> On Mon, Jul 20, 2009 at 04:49:04PM -0500, Ron Johnson wrote:
>>> Hi,
>>>
>>> (Is this OT? http://sourceforge.net/forum/forum.php?forum_id=7052
>>> doesn't show much activity...)
>>>
>>> Debian Sid, e2fsprogs 1.41.8-1
>>> Home-rolled 64-bit 2.6.30 with 32-bit userland
>> Should be fixed in e2fsprogs 1.41.8-2
>
> ff seems to work now, but I still get this in dmesg:
>
> [188883.274547] ioctl32(filefrag:7086): Unknown cmd fd(3)
> cmd(c020660b){t:'f';sz:32} arg(ffacb808) on /some/large/file
>
Huh, did we miss a compat ioctl for fiemap.... looks like so. I'll look
into that tomorrow, thanks.
-Eric
On Jul 21, 2009 19:57 -0500, Eric Sandeen wrote:
> Ron Johnson wrote:
> > On 2009-07-20 21:03, Theodore Tso wrote:
> >> On Mon, Jul 20, 2009 at 04:49:04PM -0500, Ron Johnson wrote:
> >>> Hi,
> >>>
> >>> (Is this OT? http://sourceforge.net/forum/forum.php?forum_id=7052
> >>> doesn't show much activity...)
> >>>
> >>> Debian Sid, e2fsprogs 1.41.8-1
> >>> Home-rolled 64-bit 2.6.30 with 32-bit userland
> >> Should be fixed in e2fsprogs 1.41.8-2
> >
> > ff seems to work now, but I still get this in dmesg:
> >
> > [188883.274547] ioctl32(filefrag:7086): Unknown cmd fd(3)
> > cmd(c020660b){t:'f';sz:32} arg(ffacb808) on /some/large/file
>
> Huh, did we miss a compat ioctl for fiemap.... looks like so. I'll look
> into that tomorrow, thanks.
Sigh, I wish there was some sort of automatic ioctl parser tool that
would report if the ioctl will need compat handling or not. I thought
the fiemap structs didn't need any compat handling because they are
properly sized/aligned and w/o pointers...
Cheers, Andreas
--
Andreas Dilger
Sr. Staff Engineer, Lustre Group
Sun Microsystems of Canada, Inc.
Andreas Dilger wrote:
> On Jul 21, 2009 19:57 -0500, Eric Sandeen wrote:
>> Ron Johnson wrote:
>>> On 2009-07-20 21:03, Theodore Tso wrote:
>>>> On Mon, Jul 20, 2009 at 04:49:04PM -0500, Ron Johnson wrote:
>>>>> Hi,
>>>>>
>>>>> (Is this OT? http://sourceforge.net/forum/forum.php?forum_id=7052
>>>>> doesn't show much activity...)
>>>>>
>>>>> Debian Sid, e2fsprogs 1.41.8-1
>>>>> Home-rolled 64-bit 2.6.30 with 32-bit userland
>>>> Should be fixed in e2fsprogs 1.41.8-2
>>> ff seems to work now, but I still get this in dmesg:
>>>
>>> [188883.274547] ioctl32(filefrag:7086): Unknown cmd fd(3)
>>> cmd(c020660b){t:'f';sz:32} arg(ffacb808) on /some/large/file
>> Huh, did we miss a compat ioctl for fiemap.... looks like so. I'll look
>> into that tomorrow, thanks.
>
> Sigh, I wish there was some sort of automatic ioctl parser tool that
> would report if the ioctl will need compat handling or not. I thought
> the fiemap structs didn't need any compat handling because they are
> properly sized/aligned and w/o pointers...
They are properly sized yep but I think they still have to be flagged:
/* pointer to compatible structure or no argument */
#define COMPATIBLE_IOCTL(cmd) \
{ (cmd), do_ioctl32_pointer },
I have to remind myself how this all works, despite doing a bunch of
ioctl32 work for xfs last year :)
I think adding COMPATIBLE_IOCTL(FS_IOC_FIEMAP); to fs/compat_ioctl.c
should be enough, I'll try to get it tested tomorrow.
-Eric
-Eric
On 2009-07-22 23:51, Eric Sandeen wrote:
[snip]
>
> I think adding COMPATIBLE_IOCTL(FS_IOC_FIEMAP); to fs/compat_ioctl.c
> should be enough, I'll try to get it tested tomorrow.
If the tarball/git tree can be installed under /usr/local, I'd be
glad to test it too.
--
Scooty Puff, Sr
The Doom-Bringer
Ron Johnson wrote:
> On 2009-07-22 23:51, Eric Sandeen wrote:
> [snip]
>> I think adding COMPATIBLE_IOCTL(FS_IOC_FIEMAP); to fs/compat_ioctl.c
>> should be enough, I'll try to get it tested tomorrow.
>
> If the tarball/git tree can be installed under /usr/local, I'd be
> glad to test it too.
>
It'd be a kernel patch, not userspace.
And sorry, didn't get to it today....
-Eric
Eric Sandeen <[email protected]> writes:
>
> /* pointer to compatible structure or no argument */
> #define COMPATIBLE_IOCTL(cmd) \
> { (cmd), do_ioctl32_pointer },
The modern way to do this is to use the ->compat_ioctl VFS
method. COMPATIBLE_IOCTL etc are all obsolete.
> I think adding COMPATIBLE_IOCTL(FS_IOC_FIEMAP); to fs/compat_ioctl.c
> should be enough, I'll try to get it tested tomorrow.
Nope, add a ->compat_ioctl
When your ioctl is already a unlocked_ioctl you can just use
the same function. If not convert to unlocked_ioctl first.
-Andi
--
[email protected] -- Speaking for myself only.
Andi Kleen wrote:
> Eric Sandeen <[email protected]> writes:
>> /* pointer to compatible structure or no argument */
>> #define COMPATIBLE_IOCTL(cmd) \
>> { (cmd), do_ioctl32_pointer },
>
>
> The modern way to do this is to use the ->compat_ioctl VFS
> method. COMPATIBLE_IOCTL etc are all obsolete.
>
>> I think adding COMPATIBLE_IOCTL(FS_IOC_FIEMAP); to fs/compat_ioctl.c
>> should be enough, I'll try to get it tested tomorrow.
>
> Nope, add a ->compat_ioctl
>
> When your ioctl is already a unlocked_ioctl you can just use
> the same function. If not convert to unlocked_ioctl first.
>
> -Andi
Ok thanks, I knew I needed to revisit it. ;)
-Eric
On Fri, Jul 24, 2009 at 06:26:56PM +0200, Andi Kleen wrote:
> > /* pointer to compatible structure or no argument */
> > #define COMPATIBLE_IOCTL(cmd) \
> > { (cmd), do_ioctl32_pointer },
>
>
> The modern way to do this is to use the ->compat_ioctl VFS
> method. COMPATIBLE_IOCTL etc are all obsolete.
>
> > I think adding COMPATIBLE_IOCTL(FS_IOC_FIEMAP); to fs/compat_ioctl.c
> > should be enough, I'll try to get it tested tomorrow.
>
> Nope, add a ->compat_ioctl
>
> When your ioctl is already a unlocked_ioctl you can just use
> the same function. If not convert to unlocked_ioctl first.
fiemap is handled in generic code and never enters ->whatever_ioctl.
Because of that there are only two ways to handle it:
(1) add it to the static translation table in fs/compat_ioctl.c
(2) add a special case to compat_sys_ioctl
Number one is the much simpler solution for a fully compatible ioctl.