On Wed, 2 Oct 2002, Bruce Evans wrote: > On Mon, 30 Sep 2002, Daniel Eischen wrote: > > > - ret = set_fpcontext(td, &ucp->uc_mcontext); > > - if (ret != 0) > > - return (ret); > > + /* > > + * Intentionally ignore the error to keep binary > > + * compatibility with applications that fiddle with > > + * the FPU save area in the context. The kernel > > + * now saves the FPU state in the context, but it > > + * gets corrupted by those applications that try > > + * to work around the kernel NOT saving it. > > + */ > > + (void)set_fpcontext(td, &ucp->uc_mcontext); > > bcopy(&ucp->uc_mcontext.mc_fs, regs, sizeof(*regs)); > > } > > > > ... > > I think this is a bit too simple. If set_fpcontext() fails then the > interrupted code may resume with a garbage FP context (most likely > whatever is in the PCB). Snipped parts of the patch back out the > temporary hack of forcing of the state to the PCB in sendsig(), so > the resumed FP context is quite like likely to be garbage.
We could keep a copy of the original state (saved in sendsig) in the PCB and load it from the PCB if the state in the ucontext was deemed invalid. Either that or just mark the PCB as uninitialized so it would get a clean state. > I think not using the parts of the state that is corrupted by > applications would work better (basically the same as the temporary > hack, except it would waste time instead of space). The space > wastage would be approximately 28 * 4 bytes. This would be wasted > forever or until the struct is versioned better. I'm not sure this works because the 4.x version of libc_r copies the ucontext to save the state of an interrupted thread (signals are delivered on an alternate signal stack forcing the library to save the context so the signal stack can be reused). So a sigreturn() will give you a partially valid context. I think we need to either force a clean state or keep a copy of the state saved in the ucontext in the PCB as a backup. Or make a new sigaction and sigreturn. -- Dan Eischen To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
