Stuart MacDonald wrote:
From: "David Brownell" <[EMAIL PROTECTED]>
What happens when a semaphore is freed from under a sleeping holder?
Bad Stuff. It's not legal. Oopses could happen ...
Including the sleeping holder never waking up? 'Cause I saw that too.
That's Bad Stuff, yes. Probab
From: "David Brownell" <[EMAIL PROTECTED]>
> > What happens when a semaphore is freed from under a sleeping holder?
> Bad Stuff. It's not legal. Oopses could happen ...
Including the sleeping holder never waking up? 'Cause I saw that too.
> Basically you need to decouple some "disconnect" proce
Are device disconnect routines run in interrupt context?
No, khubd (or rmmod, or sometimes apmd) calls them from
a task context. A disconnect() can sleep, though it should
avoid doing so for very long.
What happens when a semaphore is freed from under a sleeping holder?
Bad Stuff. It's n
Attached is a patch that changes the 2.5.x disconnect to be similar to
2.4.x disconnect. This doesn't fix the race, but does shrink the
window such that I've never seen it trigger, even under testing
designed to do that.
There doesn't seem to be a good way to fix the race. The fix should be
to hav
Here's the sequence:
- serial_disconnect in
- serial_disconnect acquires per-port semaphore
- serial_write in
- serial_write sleeps on semaphore
- serial_disconnect sets driver_data = NULL (but _write is already in!)
- serial_disconnect releases semaphore
***
- serial_disconnect frees memory conta
