21:43 <liquidAcid> what's the right way to access userspace data in an ioctl? just dereferencing the pointer or is copy_from_user the safe approach?

23:16 <javier__> liquidAcid: you must use copy_from_user for that

23:17 <liquidAcid> javier__, hmm, this fails here for me

23:17 <liquidAcid> if struct size is 24, then it returns 24 as well

23:21 <javier__> liquidAcid: hmm, are you sure you are passing a valid pointer?

23:22 <liquidAcid> yes

23:22 <liquidAcid> direct access works just fine

23:22 <javier__> liquidAcid: that's really weird...

23:26 <liquidAcid> hmm, don't see that done in e.g. i915 as well

23:26 <liquidAcid> it's always direct access

23:42 <javier__> liquidAcid: right, because drm_ioctl() does it

23:42 <javier__> same for copy_to_user()

23:43 <javier__> liquidAcid: that will explain why it fails, because is already a kernel and not user space address so access_ok() fails

23:44 <liquidAcid> ah, ok

23:44 <javier__> liquidAcid: http://lxr.free-electrons.com/source/drivers/gpu/drm/drm_ioctl.c#L714 fyi

23:44 <liquidAcid> i looked at some stackoverflow posts about ioctls and copy_from_user and i got the impression that i should check this

23:44 <javier__> liquidAcid: well you should if your driver has a callback for a ioctl

23:45 <javier__> but it seems there is an indirection level for DRM drivers

23:48 <javier__> liquidAcid: I mean, DRM drivers don't register a struct file_operations with an .ioctl callback but instead defines a set of DRM specific ioctl handlers and the core register the drm_ioctl

23:52 <javier__> liquidAcid: on a second look DRM drivers do register file ops but the .ioctl handler is drm_ioctl, instead of a driver specific ioctl

23:53 <javier__> but you get the idea, the core handles the copy_{from,to}_user so drivers don't have to deal with that

23:54 <liquidAcid> that's one problem less to worry about i guess :)

23:55 <javier__> :)