* Paul Mackerras <paulus@xxxxxxxxx> wrote: > Ingo Molnar writes: > > > * Martin Schwidefsky <schwidefsky@xxxxxxxxxx> wrote: > > > I overlooked a case in the powerpc version of read_persistent_lock. > > > New patch: > > > > the patches are already committed and this patch doesnt apply - > > mind sending a delta fix against tip:master: > > Is that going to leave us with a bisection breakage on powerpc > once this stuff goes upstream? If so please fold the fix into the > original patch. Do you ask Linus to rebase the upstream kernel as well, if the powerpc or x86 build happens to break? There's more than a dozen such cases per development cycle triggering on my tests alone. If not, why not? The thing is, we'll probably redo this portion of the timer tree as i found other problems in testing, but generally the disadvantages of a build breakage with a very small non-bisectability window has to be weighed against the disadvantages of a rebase (which are significant). The equation does not automatically flip in favor of a rebase as you seem to suggest - in fact it generally goes _against_ a rebase. Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-tip-commits" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
|