> The only purpose of down_try_lock() followed by up() seems to be to wake > up a possible reader. This patch replaces it with a wake-queue. There is > no locking around cpumask_empty() and the test is re-done in case there > was no hit. > With wait_event_interruptible_lock_irq(,&data_saved_lock) we would probably > be able to get rid of the `retry` label. However we still can return CPU > X which is valid now but later (after the lock dropped) the event may > have been removed because the CPU went offline. Do you have ia64 h/w to test this - or do you need me to try it out to make sure the reality matches the expected behavior? > And this brings me to the following question: Do you really want to drop all > entries for a CPU that goes offline? Wouldn't it make sense to keep that entry > even if the CPU is offline now? From what I understand MCA can send such an > interrupt / entry due to a memory error. Wouldn't it be important to keep this > information until userspace decides to remove it (despite the online state of > the CPU)? Machine checks and soft offline don't really work well together. As you say the machine check may be broadcast, and there is no mechanism for soft offline to tell the h/w not to bother this logical cpu with such events. On x86 we recently added code to do_machine_check() to quietly return if we are called on an "offline" cpu. -Tony -- To unsubscribe from this list: send the line "unsubscribe linux-ia64" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
|