From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756180AbcBISGJ (ORCPT ); Tue, 9 Feb 2016 13:06:09 -0500 Received: from mail-ig0-f179.google.com ([209.85.213.179]:37800 "EHLO mail-ig0-f179.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752763AbcBISGG (ORCPT ); Tue, 9 Feb 2016 13:06:06 -0500 MIME-Version: 1.0 In-Reply-To: <20160209175101.GB3741@mtj.duckdns.org> References: <1454551217.3677.27.camel@gmail.com> <20160205164923.GC4401@htj.duckdns.org> <1454705231.3819.151.camel@gmail.com> <20160205205456.GG4401@htj.duckdns.org> <1454705989.3819.158.camel@gmail.com> <20160205210606.GH4401@htj.duckdns.org> <1455031885.3807.74.camel@gmail.com> <20160209165024.GA3741@mtj.duckdns.org> <20160209175101.GB3741@mtj.duckdns.org> Date: Tue, 9 Feb 2016 10:06:04 -0800 X-Google-Sender-Auth: rjFfQDHgbSW0Os4rS-irebr0fro Message-ID: Subject: Re: Crashes with 874bbfe600a6 in 3.18.25 From: Linus Torvalds To: Tejun Heo Cc: Mike Galbraith , Michal Hocko , Jiri Slaby , Thomas Gleixner , Petr Mladek , Jan Kara , Ben Hutchings , Sasha Levin , Shaohua Li , LKML , stable , Daniel Bilik , Greg Kroah-Hartman Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Feb 9, 2016 at 9:51 AM, Tejun Heo wrote: >> >> (a) actually dequeue timers and work queues that are bound to a >> particular CPU when a CPU goes down. >> > This goes the same for work items and timers. If we want to do > explicit dequeueing or flushing of cpu-bound stuff on cpu down, we'll > have to either dedicate *_on() interfaces for correctness or introduce > a separate set of interfaces to use for optimization and correctness. We already do that. "add_timer_on()" for timers, and cpu != WORK_CPU_UNBOUND for work items. > Maybe we can get away with > declaring that _on() usages are absolute. I really think that anything else would be odd as hell. If you asked for a timer (or work) on a particular CPU, and you get it on another one, that's a bug. It's much better to just dequeue those entries and say "sorry, your CPU went away". Of course, we could play around with just run them early at CPU-down time (and anybody trying to requeue would get an error because the CPU is in the process of going down), but that sounds like more work for any users, and like a much more fundamental difference. The "just silently dequeue" makes more sense, and pairs well with anything that sets things up on CPU-up time (which a percpu entity will have to do anyway). > So, how about reverting 874bbfe6 and performing random foreign > queueing during -rc's for a couple cycles so that we can at least find > out the broken ones quickly in devel branch and backport fixes as > they're found? Yeah, that sounds good to me. Having some "cpu work/timer debug" config option that ends up spreading out non-cpu-specific timers and work in order to find bugs sounds like a good idea. And I don't think it should be limited to rc releases, I think lots of people might be willing to run that (the same way we had people - and even distributions - that did PAGEALLOC_DEBUG which is a lot bigger hammer). Linus