On Tue, 10 Jan 2017, Mason wrote: > On 10/01/2017 14:13, Greg Kroah-Hartman wrote: > > On Mon, Jan 09, 2017 at 05:07:06PM +0100, Greg Kroah-Hartman wrote: > >> On Mon, Jan 09, 2017 at 04:53:51PM +0100, Mason wrote: > >>> Hello Thomas, > >>> > >>> Link to the original report: > >>> https://marc.info/?l=linux-arm-kernel&m=148173152524746&w=2 > >>> > >>> I do see the two patches in linux-next: > >>> > >>> 9bf11ecce5a2 > >>> c1a9eeb938b5 > >> > >> These are both in 4.10-rc1, and I see no reason why I couldn't take them > >> in stable right now, but I'll wait for Thomas's ack. > > > > The first one was already in my list to include, the second one is > > dirt-simple, so I'll queue it up now as well. > > If the kernel hadn't crashed in tick_broadcast_setup_oneshot() > then the issue of the dummy timer being too early in the list > wouldn't have been caught, right? It's the other way round. If we would have kept that timer late in the list then we wouldn't have seen the issue that tick_broadcast_setup_oneshot() missed the NULL pointer check. The first patch which moves it late was just to restore the state before the hotplug changes. But that's not a fix at all. The real one is the NULL pointer check. I kept that patch because it does not make any sense to install that dummy timer _before_ all other options are exhausted. > So I'm wondering if it didn't make sense to WARN when bc is NULL > in tick_broadcast_setup_oneshot? (Instead of silently bailing out.) No. If the broadcast device is installed late everything will still work, while dereferencing a NULL pointer doesn't work at all. Thanks, tglx -- To unsubscribe from this list: send the line "unsubscribe stable" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html