ETXTBSY

[Jay R. Ashworth]

On Wed, Oct 26, 2005 at 07:21:23PM -0400, Jean-Pierre A. Radley wrote:
> >From a SCO engineer:
> | While I'm sympathetic and would also like to hear what the issues
> | are, I don't think this is likely to change.  This behavior has been
> | in Solaris, SunOS, and Unix System V for over 15 years, with lots of
> | systems and customers running just fine.

Clearly, no.  SCO 5 boxen won't do this wrong; anyone got one left to
test on?

> | There is an indivisible diamond here, which is the VM architecture
> | in System V Release 4, UW7, OSR6, Solaris, etc.  It has many, many
> | advantages over the previous VM design - performance, reliability,
> | scalability, ease of maintenance, extensibility, and so forth.  It's a
> | significant upgrade over earlier systems in and of itself, and it's an
> | enabler of many of the other technology upgrades that come along with
> | it.

I'm not actually an expert on this specific point, but Solaris is an
SVR*3* kernel, isn't it?

> | However, like all diamonds, it has flaws.  ETXTBSY is no longer
> | supported.

Let's be clear here:

"A possible failure mode, that of writing over a filesystem copy of a
binary which will be paged back in from if it's pages are flushed, is
no longer trapped for, and will probably allow your system to crash
without even the benefit of a panic trap."

> |              This is pretty much a result of one of the key aspects
> | of the VM design, which is that there is only one copy of a given
> | file page in the system for all uses.  Thus, any attempt to put back
> | ETXTBSY is going to be so expensive that it's not going to be worth
> | it unless there is some huge revenue opportunity that is going to be
> | lost simply because ETXTBSY is not supported.  This seems an unlikely
> | scenario.

Anyone with a clue dropping your product for Linux because you can't be
bothered to make it secure?  Yeah, I'd call that a revenue issue.

> | Now, how serious a flaw is the lack of ETXTBSY compared with the
> | advantages of the new design over the old?  Frankly, it seems very
> | minor.  Yes, it's annoying at first, and it takes some getting used
> | to, but once you get burned once or twice, you learn to work with it.

This is a Unix design engineer?  Did they hire him from Microsoft?

When all four wheels on his car lock up because of a bug in the ABS
controller and he spins under a truck, he'll get used to that, after it
happens once or twice?

> | As I say, I'm sympathetic.  I remember when this was introduced, and
> | there were a number of AT&T engineers who were unhappy with this
> | change, but it was accepted as a cost of moving forward.  It still
> | seems like the right tradeoff.

Yep; they're all three of George Carlin's kinds of stupid.

If users can even be permitted to write to files that the OS is going to
swap back in from, the possible security of the system is zero, if not
negative.

Since pure-text was originally intended to allow users to avoid having
20 different copies of the shell in the paging file simultaneously, I
hope no one who runs SCO 6 can't afford lots of RAM...

Cheers,
-- jra
-- 
Jay R. Ashworth                                                jra at baylink.com
Designer                          Baylink                             RFC 2100
Ashworth & Associates        The Things I Think                        '87 e24
St Petersburg FL USA      http://baylink.pitas.com             +1 727 647 1274

	"NPR has a lot in common with Nascar... we both turn to the left."
		- Peter Sagal, on Wait Wait, Don't Tell Me!