> 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 o
> > 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
> >
On Fri, 05 Sep 2014 08:41:52 -0700
"H. Peter Anvin" 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 w
> 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 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 specific
> purpose to
> 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
O_N
