On Wednesday 09 July 2008, Hinko Kocevar wrote:
> This is second stab at the ussp driver.
> I'm not sure about the TTY_NORMAL that was in port->tty->flip.flag_buf_ptr
> under the USSP_READ - should this flag character be inserted into the flip
> buffer after the data bytes, as seen in the patch?
>
From what I know, TTY_NORMAL refers to a regular, non-control character. But
look at my comments for that section.
> case TIOCSSOFTCAR:
> - if ((rc = verify_area(VERIFY_READ, (void *) arg,
> - sizeof(int))) == 0) {
> - get_user(ival, (unsigned int *) arg);
> - tty->termios->c_cflag =
> - (tty->termios->c_cflag & ~CLOCAL) |
> - (ival ? CLOCAL : 0);
> - }
> + get_user(ival, (unsigned int *) arg);
You need to verify the return value. If not zero, then return -EFAULT.
> + case TCSETS:
> + ussp_dprintk (DEBUG_IOCTL, "TCSETS -- what to do
> here!?\n"); + break;
> +
> int rc;
> struct ussp_operation op;
> struct ussp_port *port;
> + char *buff;
> func_enter();
>
> port = filp->private_data;
> @@ -1011,13 +1009,20 @@
> break;
> case USSP_READ:
> ussp_dprintk (DEBUG_IOCTL, "USSP_READ %d\n", (int)op.len);
> - rc = copy_from_user (port->tty->flip.char_buf_ptr, buf +
> sizeof(struct ussp_operation), op.len);
> - memset(port->tty->flip.flag_buf_ptr, TTY_NORMAL, op.len);
Hmm, this original code does not make sense to me. First copying from
userspace into the tty buffer, then zeroying it out?
Also, it looks like a proprietary ioctl, so maybe you could just remove it...
> - port->tty->flip.count += op.len;
> - port->tty->flip.char_buf_ptr += op.len;
> - port->tty->flip.flag_buf_ptr += op.len;
> + buff = kmalloc((int)op.len, GFP_KERNEL);
> + rc = copy_from_user (buff, buf + sizeof(struct
> ussp_operation), op.len); + if (rc)
> + {
> + kfree(buff);
> + return -ENOMEM;
Usually its -EFAULT.
Thanks,
tavi
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
