Quoting Chris Wilson <chris@xxxxxxxxxxxxxxxxxx>:
I believe the error is on the kernel side. The kernel should
convert the pointer. compat_ptr() doesn't convert the value, only
the type. The comment in arch/x86/include/asm/compat.h says:
That seems odd as the kernel expects a 32-bit address for the user
process here.
I guess I was mislead by that comment. I could not find any
information how a x86_64 kernel sees the userspace memory of a 32-bit
process.
Can you please attach a dmesg with drm.debug=7 and
--enable-debug=full Xorg.0.log?
I won't see that system until Tuesday. I'll give you the information
you ask, I'm just trying to understand the debugging data I have
already.
I know from strace that DRM_IOCTL_MODE_GETENCODER fails with -EINVAL.
I know from the debug printk in the kernel that drm_mode_getencoder()
gets 0 as the encoder ID and that's why it returns -EINVAL.
I know from the Xorg intel driver (I got the git master version of it,
recompiled it and got the same problem) that
DRM_IOCTL_MODE_GETCONNECTOR is called immediately before
DRM_IOCTL_MODE_GETENCODER in sna_output_init(), and that's the only
place where DRM_IOCTL_MODE_GETENCODER is called.
I know that the last call to drm_mode_getconnector() before
drm_mode_getencoder() copies exactly one encoder ID to the address
provided by the user. The address is something like 0xfnnnnnnn, i.e.
it's a 32-bit address at the end of the first 4Gb of memory. The
system has 16Gb. I understand it's an address on stack of the 32-bit
Xorg process.
put_user() doesn't fail, or drm_mode_getconnector() would return
-EFAULT, and I know that it returns 0.
The logic in drm_mode_getconnector() is such that encoder IDs are
copied last and if the encoder ID is zero, it's not copied. So I
don't see how the kernel could overwrite that value. However, gcc
could reorder something, but I doubt it would reorder put_user()
calls. Anyway, I'll try to add buffers around enc in
sna_output_init() to protect against memory corruption.
--
Regards,
Pavel Roskin
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/dri-devel
