From: Johannes Thumshirn
> Sent: 10 February 2017 07:46
> On 02/09/2017 06:20 PM, Scott Bauer wrote:
> > When CONFIG_KASAN is enabled, compilation fails:
Does CONFIG_KASAN allocate guard stack space around everything that
is passed by address?
That sounds completely brain-dead.
There are a lot of functions that have an 'int *' argument to return
a single value - and are never going to do anything else.
...
> > Moved all the ioctl structures off the stack and dynamically activate
> > using _IOC_SIZE()
...
>
> > - if (copy_from_user(&session, arg, sizeof(session)))
> > - return -EFAULT;
> > - return opal_erase_locking_range(dev, &session);
> > + ioctl_ptr = kzalloc(cmd_size, GFP_KERNEL);
> > + if (!ioctl_ptr)
> > + return -ENOMEM;
> > + if (copy_from_user(ioctl_ptr, arg, cmd_size)) {
> > + ret = -EFAULT;
> > + goto out;
> > }
>
> Can't we use memdup_user() instead of kzalloc() + copy_from_user()?
You either want the copy_from_user() or the memzero() not both.
ISTM there could be two 'library' functions, maybe:
void *get_ioctl_buf(unsigned int cmd, long arg)
to malloc the buffer, memzero/copy_from_user, returns -EFAULT if copy fails.
int put_ioctl_buf(int rval, unsigned int cmd, const void *buf)
does copy_to_user() if rval >= 0 and IOR_READ, then frees buf.
return value is rval unless the copyout fails.
David
