This is fixed now. The change involved mods to the following files:
linux/fs/xfs/xfs_dmapi.c
linux/include/linux/dmapi_kern.h
linux/fs/xfs_dmapi/dmapi_private.h
linux/fs/xfs_dmapi/dmapi_sysent.c
And a matching change to the dmapi library. I'm not going to bother sending
all of this out as a single patch--I'd rather that you just grab the latest
stuff.
I changed invis I/O to be able to open files with O_LARGEFILE, then I changed
the kernel<>library interface to be able to send 64bit types, and things got a
bit involved.
Because this is an incompatible change in the kernel<>library interface, I've
changed the name of the dmapi device from /proc/fs/xfs_dmapi to
/proc/fs/xfs_dmapi_v1. That should prevent an accidental mixing of library
and kernel versions that might lead to core dumps or panics.
So, when you update your kernel, you have to update the libdm library, too.
If you're just using the shared lib, then your application does not have to be
rebuilt.
Dean
>From: Dean Roehrich <roehrich@xxxxxxxxxxxxxxxxxxxxxxxx>
>
>>From: "James A Goodwin" <jagoodwi@xxxxxxxxxx>
>>We were noticing some EINVAL errors coming from dm_read_invis() on our XFS
>>1.1 system. It looks like the sys_dmapi_args_t structure that is used to
>>pass data from the DMAPI library to the kernel is using long ints to store
>>the offset and length of the read. It turns out that we were trying to
>>read some data just past a 2GB offset, and that value in a signed long int
>>is interpreted as a fairly large negative number, which explains the EINVAL
>>return code.
>>
>>Is this something that can be changed by recompiling with certain flags set
>>(the kernel and the dmapi library), or am I simply hosed?
>
>I think it needs more than a recompile. Probably have to change the 'long' to
>'unsigned long long'. The library already uses large enough types, maybe
>it'll work.
>
>The bug list grows...
>
>Dean
|