Staging: dt3155: Remove copy_to_user for ioctl's DT3155_{STOP|START}
PATCH 1/1 Staging: dt3155: Remove copy_to_user for ioctl's DT3155_{STOP|START}
The ioctl's DT3155_STOP and DT3155_START are defined with the macro _IO indicating that they have no parameters. They should not be using copy_to_user to return data to user space.
---
drivers/staging/dt3155/dt3155_drv.c +0 -4
@@ -570,8 +570,6 @@ static int dt3155_ioctl(struct inode *inode,return 0 ;quick_stop (minor); -if (copy_to_user (up, dts,sizeof (*dts))) -return -EFAULT ;return 0 ; }case DT3155_START :
@@ -593,8 +591,6 @@ static int dt3155_ioctl(struct inode *inode, }dt3155_init_isr (minor); -if (copy_to_user (up, dts,sizeof (*dts))) -return -EFAULT ;return 0 ; }default :
Quoted 3 lines · H Hartley Sweeten
The ioctl's
DT3155_STOPandDT3155_STARTare defined with the macro_IOindicating that they have no parameters. They should not be usingcopy_to_userto return data to user space.
This is not a reason for removing them. You should check what real users do/expect and base your reasoning on the top of that.
So could you investigate that?
regards,
Signature · 1 line
js
Quoted 9 lines · Jiri Slaby
Quoted 3 lines · H Hartley Sweeten
The ioctl's
DT3155_STOPandDT3155_STARTare defined with the macro_IOindicating that they have no parameters. They should not be usingcopy_to_userto return data to user space.This is not a reason for removing them. You should check what real users do/expect and base your reasoning on the top of that.
So could you investigate that?
I agree, we can't remove this, it changes the functionality of the kernel in a way that userspace might not be expecting.
thanks,
greg k-h