> > What stops a parallel open or close changing ASYNC_INITIALIZED after you
> > test and before you lock ?
>
> Yeah, I should do the whole thing under the mutex.
Can you use test_bit() as well. I'm trying to gradually push all the code
that way so people habitually use set_bit() and we don't get any (more)
races where some compile situations and architectures otherwise create
load to register
register ored with constant
write back
> Not related to this particular issue, but the fact that close() can powerdown
> the hardware is quite bad. Today it is always possible to use open,close
> sequence on /dev/ttyXXXX, and polling would break if close() deinitializes the
> hardware (e.g. via uart_change_pm()).
One of the long term goals of tty_port has always ben to have an object
with the lifetime of the physical port so this kind of thing can be fixed.
> In console= case, serial core handles the issue via uart_console(), checking
> if
> the port is used for console, preventing it to power down the hardware. We can
> do the same, or make tty_find_polling_driver() refcount individual
> ports/lines.
> But the issue is orthogonal to this particular patch, although needs to be
> fixed some day.
Agreed - however you'll need a separate refcount than the main tty one
for this, because we still need to do a hangup() on the final "tty" close
even if the hardware is 'pinned' for a debugger.
Alan
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Kgdb-bugreport mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/kgdb-bugreport
