tech-kern archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: Status of revivesa

On Fri, Sep 26, 2008 at 11:15:23PM -0700, Bill Stouder-Studenmund wrote:
> On Sat, Sep 27, 2008 at 06:33:46AM +0200, Quentin Garnier wrote:
> > On Fri, Sep 26, 2008 at 08:44:29PM -0700, Bill Stouder-Studenmund wrote:
> > [...]
> > > 
> > > I would appreciate debugging assistance. The exact specifics of upcall 
> > > delivery are things that I'd hoped to leave as-was & have work. It is the 
> > > one area I'm not too strong at.
> > 
> > I have bad news, at least for 3.x users.  I know very well the
> > difference between 3.x and 4.x because I did the commit (and the lengthy
> > debugging before that) that produces the behaviour.
> > 
> > libpthread used to use hard-coded values for the initial context of new
> > threads or upcall handlers.  That didn't work under COMPAT_NETBSD32
> > because the order of the GDT entries was different, thus the hard-coded
> > values were illegal.  So I changed that to use the current values for
> > the segment registers.
> So the NetBSD 3.X libpthread had a problem w/ COMPAT_NETBSD32, and the 
> NetBSD 4.X did not. But non-COMPAT_NETBSD32 usage didn't notice a 
> difference.

Yes, because the order in the GDT wasn't changed.  The problem of
netbsd32 is that said order was different on amd64 and on i386.

> > What happens now is that the order of GDT entries changed in i386.  See
> > revision 1.42 of sys/arch/i386/include/segments.h, and that make the
> > value of CS used by 3.x's libpthread invalid (selecting GUDATA instead
> > of GUCODE).
> Then this change, between 4.x and 5.x, changed things such that 
> non-COMPAT_NETBSD32 now notices the issue fixed above.

It's not "now".  If I hadn't made that change, even 4.x libpthread would
just not work on current i386!

> > Andrew will have to confirm, but the comments say that the new order is
> > mandatory for sysenter.  That said, AFAIK, we don't use sysenter by
> > default.  The only way to use it is to compile libc with -DI686_LIBC, so
> > we have the option of providing the compatibility as long as the user
> > accepts not to use sysenter.
> My "perfect world" solution would be to make the sysenter-compatible 
> reshuffling an option and make COMPAT_30_PTHREAD or some such another 
> option, and make the two incompatible. That way an admin can clearly 
> select which way to go. If either were a default, I'd make the sysenter 
> one default. :-)

I see two issues with that (though I'd really like to use that

  - there may be 3rd party application that play the same naughty games
    as the old libpthread, e.g. by storing a ucontext at some point and
    re-using it later.  I think of interpreted languages that can be
    compiled for faster execution.  COMPAT_30_PTHREAD would introduce a
    very weird failure case.

  - if we ever decide to make a libci686 and load it through
    games, COMPAT_30_NETBSD will become a real burden.

The first point is not so bad;  I don't even have any evidence such a
bad application exists (but wandering around pkgsrc you see scary stuff
though).  As for the second one, it won't apply to 5.0 anyway, so we're
safe for a while, and we might have a way out later (for instance, if we
are to ever bump libc, we could bury SA again).

> The upshot, though, is that this means that revivesa didn't break this. So 
> does anyone else have any issues that should be examined before a merge? 
> The only one I see is to verify that I'm not really seeing a crash of 
> named on boot.

Well, at least that one is a different issue.

Quentin Garnier - -
"See the look on my face from staying too long in one place
[...] every time the morning breaks I know I'm closer to falling"
KT Tunstall, Saving My Face, Drastic Fantastic, 2007.

Attachment: pgp4E2m7u6xKA.pgp
Description: PGP signature

Home | Main Index | Thread Index | Old Index