On Tue, 03 Apr 2018 19:03:28 PDT (-0700), Linus Torvalds wrote: > On Tue, Apr 3, 2018 at 6:51 PM, Palmer Dabbelt <pal...@sifive.com> wrote: >> >> Thanks! The linked patch set should be fully bisectable, while this one >> will fail on some ARM randconfigs. > > If it's only some (not very realistic) randconfigs, I suspect an > incremental fix is probably the easier solution, rather than redoing > that whole branch.
They're randconfigs that can't be selected via menuconfig so maybe that's not a big deal (and it's why I missed it in the first place). I'm a big fan of the sorts of automated build tools that find all my bugs, which is why I was willing to jump through some hoops to make the patch set bisectable. > So mind at least sending that incremental fix on top of the branch to > Thomas and making his life easier if he decides to go that way? I'm treating this as the cover letter to that patch set. I've build tested this with the same set of configs as my full patch set (arm defconfig, arm64 defconfig, openrisc defconfig, and a failing arm config from the 0-day robot) but only after the final patch was applied -- it's not bisectable anyway. I've dropped the various acknowledgements, as this is a bit messy and I don't want to sign any else up as agreeing with it :). I have follow-on patches to convert arm, arm64, and openrisc to GENERIC_IRQ_MULTI_HANDLER and then remove the MULTI_IRQ_HANDLER, but since they're not strictly part of this cleanup I'll submit those via a more normal process if you end up taking these patches. This is available as a more pull request smelling method via git://git.kernel.org/pub/scm/linux/kernel/git/palmer/linux.git palmer-for-linus-4.17-ugly_irq It's on top of the full IRQ pull request. After doing everything I feel like it might have been a bit better to base this only on top of the broken patch (so git bisect could have a bit more info to avoid entering the broken region), but I feel like that's splitting hairs at this point. > And if Thomas is busy doing something else (*), and I come back to > this tomorrow as-is, I'd want to pull his tree and just apply the > incremental fix anyway, so it makes sense to send it to me as well. > > Linus > > (*) I have long since accepted that some people have a life outside of > kernel development too, and don't always reply immediately. I may not > _understand_ it, but I am resigned to the fact. Ah, well, I guess in this case it's all really my fault: While I generally try to avoid having a life, I recently went outside to attend ELC and managed to catch the flu, which resulted in me missing Thomas' complaints of me breaking things. I can't promise that won't happen again :).