Tim Waugh (tim@cyberelk.demon.co.uk)
Fri, 19 Mar 1999 23:07:57 +0000 (GMT)
Okay guys, I need some ideas here.
I've put a tmw8 out there that's not much better than tmw7, but it should
at least compile and link.
There's at least one major problem in there though.
As you have probably gathered, I'm working on non-blocking implementations
of the port->ops block transfers. The idea is that you call
compat_write_block, giving it a function pointer and a handle, and it
returns 'immediately' and gives you a callback when it's finished doing
the actual transfer.
What the printer driver does is essentially this:
char *kbuf = kmalloc (PAGE_SIZE, GFP_KERNEL);
copy_from_user (kbuf, buf, count);
parport_claim_or_block (dev);
while (bytes_left) {
bytes = parport_write (port, kbuf);
kbuf += bytes, bytes_left -= bytes;
if (signal_pending (current))
break;
}
parport_release (dev);
kfree (kbuf);
return count - bytes_left;
All well and good. parport_write calls compat_write_block and waits for a
callback.. or a signal.
If a signal happens, parport_write returns immediately, and it has no
choice but to say that it transferred all it was told to. This is a
problem in itself.
It gets worse because the parport is then released and the memory is
freed. The compat_write_block stuff is still going on in between
scheduling, and so it sees port->cad disappear, and it sees its buffer
disappear. It generally goes bang at that stage.
Can someone think of a way of coping with this that doesn't involve (a)
parport_release failing, (b) signals being delayed, or (c) abolishing
non-blocking operation altogether?
Roger Schreiter, if you are on this list again yet: how did you cope with
this issue?
Thanks,
Tim.
*/
-- To unsubscribe, send mail to: linux-parport-request@torque.net --
-- with the single word "unsubscribe" in the body of the message. --
This archive was generated by hypermail 2.0b3 on Sun 28 Mar 1999 - 17:03:34 EST