This is the mail archive of the ecos-patches@sources.redhat.com mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]