> I think I would prefer an interface which took a list of patch points, > or implemented only the aspects which are impossible to do in user space.
We already have all the code. Why not just use it? Note I'm not adding any new mechanism, just exporting the existing one. So the usual "do things in user space" arguments do not really apply here. Also this is subtle enough that there is definitely benefit from having only a single canonical code that does it. If we ever need any new errata workarounds for this they could be also all done in a single central place. > > All we really need in the kernel is the IPI broadcasts - the rest can be > done in user space, including intercepting SIGTRAP. For userspace it is > probably the best to just put a thread to sleep until the patching is > done, which can be done with a futex. I'm not sure that's worth it. IPIs are reasonably fast (a few 1000s cycles). Sleeping likely only becomes beneficial with much longer delays, like ms. But if the IPIs start taking ms we have much more problems. > One advantage with doing this in userspace is that the kernel doesn't > have to be responsible avoiding holding a thread due to a slightly > different SIGTRAP -- it will all come out after the signal handler is > restored, anyway. It's just some spinning, not a new task state. I don't think any task states make sense here. -Andi -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
