Possible deadlock in serial.c
Gary Thomas
gary@mlbassoc.com
Wed May 21 16:31:00 GMT 2003
On Wed, 2003-05-21 at 10:15, David Marqvar (DAM) wrote:
> In function
>
> static Cyg_ErrNo
> serial_get_config(cyg_io_handle_t handle, cyg_uint32 key, void
> *xbuf,
> cyg_uint32 *len)
> {
>
> Shouldn't the #ifdef and call to restart_rx( chan, false ); be added to the
> case below?
>
> case CYG_IO_GET_CONFIG_SERIAL_INPUT_FLUSH:
> // Flush any buffered input
> if (in_cbuf->len == 0) break; // Nothing to do if not buffered
> cyg_drv_mutex_lock(&in_cbuf->lock); // Stop any further input
> processing
> cyg_drv_dsr_lock();
> if (in_cbuf->waiting) {
> in_cbuf->abort = true;
> cyg_drv_cond_signal(&in_cbuf->wait);
> in_cbuf->waiting = false;
> }
> in_cbuf->get = in_cbuf->put = in_cbuf->nb = 0; // Flush buffered
> input
> cyg_drv_dsr_unlock();
> cyg_drv_mutex_unlock(&in_cbuf->lock);
> #ifdef CYGPKG_IO_SERIAL_FLOW_CONTROL
> restart_rx( chan, false );
> #endif
> break;
>
>
> If the serial input buffer is full, and the serial device has been told to
> stop rx, the serial driver should restart rx if the input buffer is flushed.
> Otherwise no data will never be received after that, thus no reads to the
> input buffer (through where the rx could be restarted) -> deadlock.
>
> Or?
>
> Will your changes to the serial driver (and the headerfile) be committed to
> the 2.0-branch too in a near future?
> (My suggestion)
>
> Please write back if I should file a patch for this.
This looks reasonable to me and I have applied the change (patch
attached).
I don't think that there will be any patches made to the 2.0 branch
now that it has been "released".
--
Gary Thomas <gary@mlbassoc.com>
MLB Associates
-------------- next part --------------
A non-text attachment was scrubbed...
Name: diffs
Type: text/x-patch
Size: 1884 bytes
Desc: not available
URL: <http://sourceware.org/pipermail/ecos-patches/attachments/20030521/7db4a80a/attachment.bin>
More information about the Ecos-patches
mailing list