The point being that holding the tty lock across the _entire_ close
is equivalent to the current outcome, regardless of O_NONBLOCK.
I'm reluctant to start returning EGAIN for non-blocking tty opens
because no tty driver does that now, and I don't think userspace will
deal well with new
Yes - because if you think about it that tells you that nobody is hitting
it with the old code and it probably doesn't matter.
I don't understand this reply.
It's a matter of priorities. There are hundreds of potential security
holes turned up by scanners, 2,500+ filed bugs in kernel
So a problem that no one has ever complained about on _any_ arch is suddenly
a problem on a subset of Alpha cpus, but a problem I know exists on Alpha
isn't important because no one's filed a bug about it?
Yes - because if you think about it that tells you that nobody is hitting
it with the
Is *that* what we are talking about? I was added to this conversation
in the middle where it had already generalized, so I had no idea.
No, this is just what brought this craziness to my attention.
None of it is craziness. It's the real world leaking into the crazy
delusional world of
On Fri, 05 Sep 2014 08:41:52 -0700
H. Peter Anvin h...@zytor.com wrote:
On 09/05/2014 08:31 AM, Peter Hurley wrote:
Which is a bit ironic because I remember when Digital had a team
working on emulating native x86 apps on Alpha/NT.
Right, because the x86 architecture was obsolete and
I think the whole removing Alpha EV5 support is basically bonkers. Just
use set_bit in the tty layer. Alpha will continue to work as well as it
always has done and you won't design out support for any future processor
that turns out not to do byte aligned stores.
Alan
Is *that*
Besides updating the documentation, it may make sense to do something
arch-specific. Just bumping out storage on arches that don't need it
seems wasteful, as does generating bus locks on arches that don't need it.
Unfortunately, the code churn looks unavoidable.
The arch specific is pretty
On Tue, 05 Aug 2014 20:12:09 +0530
Vishal Mansur vman...@linux.vnet.ibm.com wrote:
EEH kernel services are inconsistently exported by the
kernel. eeh_check_failure is exported for any use, but
eeh_dev_check_failure is exported only for GPL use.
While eeh_check_failure is implemented for a
Before the patch, I believe tty_reopen() would return -EIO because
the TTY_CLOSING flag is set. After the patch, tty_open() blocks
on tty_lock() before calling tty_reopen(). AFAICT, this is independent
of O_NONBLOCK.
That would be a bug then. Returning -EIO is fine (if unfriendly). The
