Added Kamil (hope I got the right one - the spinics.net archive obfuscates the e-mail addresses). >> - if ((flags & MF_ACTION_REQUIRED) && t == current) { >> + if ((flags & MF_ACTION_REQUIRED) && t->mm == current->mm) { >> si.si_code = BUS_MCEERR_AR; >> - ret = force_sig_info(SIGBUS, &si, t); >> + ret = force_sig_info(SIGBUS, &si, current); >> } else { >> /* >> * Don't use force here, it's convenient if the signal >> -- >> 1.8.4.1 > Very interesting. I remembered there was a thread about AO error. Here is > the link: http://www.spinics.net/lists/linux-mm/msg66653.html. > According to this link, I have two concerns: > > 1) how to handle the similar scenario like it in this link. I mean once > the main thread doesn't handle AR error but a thread does this, if SIGBUS > can't be handled at once. > 2) why that patch isn't merged. From that thread, Naoya should mean > "acknowledge" :-). That's an interesting thread ... and looks like it helps out in a case where there are only AO signals. But the "AR" case complicates things. Kamil points out at the start of the thread: > Also, do I understand it correctly that "action required" faults *must* be > handled by the thread that triggered the error? I guess it makes sense for > it to be that way, even if it circumvents the "dedicated handling thread" > idea... this is absolutely true ... in the BUS_MCEERR_AR case the current thread is executing an instruction that is attempting to consume poison data ... and we cannot let that instruction retire, so we have to signal that thread - if it can fix the problem by mapping a new page to the location that was lost, and refilling it with the right data - the handler can return to resume - otherwise it can longjmp() somewhere or exit. This means that the idea of having a multi-threaded application where just one thread has a SIGBUS handler and we gently steer the BUS_MCEERR_AO signals to that thread to be handled is flawed. Every thread needs to have a SIGBUS handler - so that we can handle the "AR" case. [Digression: what does happen to a process with a thread with no SIGBUS handler if we in fact send it a SIGBUS? Does just that thread die (default action for SIGBUS)? Or does the whole process get killed? If just one thread is terminated ... then perhaps someone could write a recovery aware application that worked like this - though it sounds like that would be working blindfold with one hand tied behind your back. How would the remaining threads know why their buddy just died? The siginfo_t describing the problem isn't available] If we want steerable AO signals to a dedicated thread - we'd have to use different signals for AO & AR. So every thread can have an AR handler, but just one have the AO handler. Or something more exotic with prctl to designate the preferred target for AO signals? Or just live with the fact that every thread needs a handler for AR ... and have the application internally pass AO activity from the thread that originally got the SIGBUS to some worker thread. -Tony -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx"> email@xxxxxxxxx </a>