From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752850AbcCYIdl (ORCPT ); Fri, 25 Mar 2016 04:33:41 -0400 Received: from www.linutronix.de ([62.245.132.108]:42405 "EHLO Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752570AbcCYIdh (ORCPT ); Fri, 25 Mar 2016 04:33:37 -0400 Date: Fri, 25 Mar 2016 09:32:05 +0100 (CET) From: Thomas Gleixner To: Tejun Heo cc: nick , jiangshanlai@gmail.com, linux-kernel@vger.kernel.org Subject: Re: Workqueue change with commit id,1bd04bf6f breaks mpt3sas scsi driver In-Reply-To: <20160324193914.GC7822@mtj.duckdns.org> Message-ID: References: <56F350C0.5070000@gmail.com> <20160324193914.GC7822@mtj.duckdns.org> User-Agent: Alpine 2.11 (DEB 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Linutronix-Spam-Score: -1.0 X-Linutronix-Spam-Level: - X-Linutronix-Spam-Status: No , -1.0 points, 5.0 required, ALL_TRUSTED=-1,SHORTCIRCUIT=-0.0001 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 24 Mar 2016, Tejun Heo wrote: > On Wed, Mar 23, 2016 at 10:28:16PM -0400, nick wrote: > > Seems that commit id, 1bd04bf6f breaks the mpt3sas driver according to this bug report: > > https://bugzilla.kernel.org/show_bug.cgi?id=114611. Seems that the driver is fine as > > have inspection all the driver functions are wrappers around queue_delayed_work and > > according to the person's debugging this commit breaks it. However they are not sure > > if it's the driver or the timer subsystem. I am assuming it's the timer subsystem as > > the driver is just using wrapper functions around core workqueue functions with irqs > > disabled and a spin lock held. > > Hmmm... 1bd04bf6f68d ("timer: Remove FIFO "guarantee"") doesn't look > like an easy change to undo and it sounds like the driver was already > (subtly) broken even before the commit given that ordered workqueues > are not affine to any CPU and timer expirations across different CPUs > aren't strictly ordered. Unfortunately, the only way forward seems to > be implementing ordering from the driver's side. The changelog explains in detail, that the FIFO "guarantee" did not exist for a long time. Certainly that commit removed the last reminders of that so called guarantee, but anything relying on FIFO ordering of the timer wheel was broken before that commit. Just because it "worked" before that commit does not mean it was correct. Thanks, tglx