This is the mail archive of the
ecos-patches@sources.redhat.com
mailing list for the eCos project.
RE: Race conditions in serial_select
- From: Jay Foster <jay at systech dot com>
- To: 'Andrew Lunn' <andrew at lunn dot ch>, "Gaer, A." <Andreas dot Gaer at baslerweb dot com>
- Cc: ecos-patches at ecos dot sourceware dot org
- Date: Mon, 20 Jun 2005 14:59:46 -0700
- Subject: RE: Race conditions in serial_select
I took a look at this change for considering whether to apply it to my code
base. It looks like there may now be a deadlock problem with the new code.
In the serial.c file, the code obtains and releases the locks as follows:
cyg_drv_mutex_lock(...);
...
cyg_drv_dsr_lock(...);
...
cyg_drv_dsr_unlock(...);
...
cyg_drv_mutex_unlock(...);
With the change in serial_select(), the order is reversed (i.e. the DSR lock
is aquired before the mutex lock). This can lead to a deadlock condition.
Would not just the DSR lock be sufficient?
Jay Foster
-----Original Message-----
From: Andrew Lunn [mailto:andrew@lunn.ch]
Sent: Monday, June 20, 2005 11:15 AM
To: Gaer, A.
Cc: ecos-patches@ecos.sourceware.org
Subject: Re: Race conditions in serial_select
On Fri, Jun 17, 2005 at 11:47:09AM +0200, Gaer, A. wrote:
> Hello all!
>
> The serial_select() implementation from
> "io/serial/current/src/common/serial.c" doesn't care about concurrent
access
> to the cbuf structure. This leads to race conditions when the serial DSR
> routine changes the counters in this structure while select checks for
> "cbuf->nb == 0". As a result, user threads that sleep because of a select
> call will not be woken up, even if data arrives. Also access to this
> structure isn't implemented thread-safe because of missing mutex locks.
The
> attached patch fixes this problems.
Thanks
Andrew