Re: [RFC] I/O error handling for userspace

Jesse Barnes
2004-12-06T16:13:04Z

On Monday, December 6, 2004 4:42 am, Hidetoshi Seto wrote:
> > - /* TLB error is only exist in this SAL error record */
> > - recover = (psp->tc && !(psp->cc || psp->bc || psp->rc || psp->uc))
> > - /* other error recovery */
> > - || (ia64_mca_ucmc_extension
> > - && ia64_mca_ucmc_extension(
> > - IA64_LOG_CURR_BUFFER(SAL_INFO_TYPE_MCA),
> > - &ia64_sal_to_os_handoff_state,
> > - &ia64_os_to_sal_handoff_state));
>
> Where the ia64_mca_ucmc_extension had go? ... vanished? :-(

Oops, that was accidental. I'll fix it up.

>
> > + /* TLB errors are fixed up before we get here, so recover */
> > + if (psp->tc) {
> > + recover = 1;
> > + goto return_to_sal;
> > + }
> > +
>
> I'm not sure because I hadn't get any logs on crazy error situation, but
> isn't it possible that an error log have both of tc and
> another(cc|bc|rc|uc)? Why we could omit "!(psp->cc || psp->bc || psp->rc ||
> psp->uc)" ?

I'm not sure either, I'll readd the check to make sure we haven't taken
another error too.

> > + spin_unlock(&io_range_list_lock);
> > +
> > + return_to_sal:
>
> force_sig_info() takes spinlock in it... I think calling this isn't safe on
> MCA.

You're right, hmm, maybe I have to create a new kernel thread to wakeup and
send the signals with? Any suggestions here? Using a thread would
invalidate the assumptions I'm making in userspace, since the thread that
caused the MCA might resume and get the SIGBUS too late to do anything with
it. Maybe I just need a version of force_sig_info that does a trylock
instead and returns a value saying whether the signal was delivered.

> The rest part of the patch (for legacies) seems to be
> functionally-independent. I don't have enough ideas for legacy-maps, but I
> guess you have done good work.

Yeah, I could split that out, that might make more sense. Thanks for looking!

Jesse