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 anddangerous content by MailScanner, and isbelieved to be clean.
ÿôèº{.nÇ+?·?®??+%?Ëÿ±éÝjw¦j)p?Øÿº{.nÇ+?·¤z¹Þ?w°n'¬þÚ qªí?Ïç?ùb?ìÿ¢¸?æ¬z·?vØ^¶m§ÿÿ?êçzYÞÁ¸?³ú+?ñ@
