There is a userland tool called inputattach which binds a serial port to
a specific device lets say a touch screen. serport
(CONFIG_SERIO_SERPORT) is the couterpart in the kernel. So the userland
does the following:
- 1. open("/dev/ttySx", O_RDWR | O_NOCTTY | O_NONBLOCK);
- 2. setline()
- 3. ioctl(fd, TIOCSETD, &ldisc); with ldisc = N_MOUSE
if the ldisc class is not set (yet), it calls serport_ldisc_open()
which allocates a little bit of memory.
- 4. ioctl(fd, SPIOCSTYPE, &devt) with devt beeing the device the user
wants to attach
- 5. read(fd, NULL, 0);
this attaches the device, calls its ->connect function and the program
stays here for as long as the driver has to remain attached and
working.
- 6. ioctl(fd, TIOCSETD, &ldisc); with ldisc = 0.
this calls serport_ldisc_close() and the extra memory is gone.
- 7. close()
Now the program remains in step 5. If the user starts it again then it
behaves a little different:
- step 3 does nothing because the correct ldisc is allready set.
tty_set_ldisc() discovers that (tty->ldisc->ops->num == ldisc) is true
(Check the no-op case) so nothing happens.
- in step 5 serport_ldisc_read() discovers that it allready performing a
read() and returns with -EBUSY.
- step 6 deallocates memory which was allocated by the other process.
Now we have the struct serport freed but the first process is still
using it.
Any idea how to fix it? I've seen that it is possible to manually bind
devices via /sys so maybe we could remove serport. However I'm not sure
if this kind of bug also affects other ldisc classes.
Sebastian
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
