From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S966876AbcCPPBA (ORCPT ); Wed, 16 Mar 2016 11:01:00 -0400 Received: from mail-pf0-f179.google.com ([209.85.192.179]:35961 "EHLO mail-pf0-f179.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S934685AbcCPPA4 (ORCPT ); Wed, 16 Mar 2016 11:00:56 -0400 Date: Wed, 16 Mar 2016 08:00:53 -0700 From: Tejun Heo To: Jan Kara Cc: Alan Stern , Peter Chen , florian@mickler.org, linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org, usb-storage@lists.one-eyed-alien.net, Jan Kara , jkosina@suse.cz Subject: Re: Freezable workqueue blocks non-freezable workqueue during the system resume process Message-ID: <20160316150053.GG6980@mtj.duckdns.org> References: <20160314072234.GC5213@quack.suse.cz> <20160315092543.GD17942@quack.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160315092543.GD17942@quack.suse.cz> User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hello, Jan, Alan. On Tue, Mar 15, 2016 at 10:25:43AM +0100, Jan Kara wrote: > > The kernel does suspend device drivers; that is, it invokes their > > suspend callbacks. But it doesn't "freeze" them in any sense. Once a > > driver has been suspended, it assumes it won't receive any I/O requests > > until it has been resumed. Therefore the kernel first has to prevent > > all the upper layers from generating such requests and/or sending them > > to the low-level drivers. > > OK, so Tejun and you should talk together because you both seem to want > something else... If I understand it right, Tejun wants suspended devices > to just queue requests that have been submitted after these devices were > suspended and complete them once they are resumed... Yeah, I suppose that's why we have the code base we do now. I don't think freezing kernel threads is the right mechanism to plug IO devices during suspend. It's way too error-prone and causes a dependency nightmare as it acts essentially as a system-wide lock. More complex drivers already plug themselves which are necessary no matter what as upper layers or some kthreads aren't the only sources of commands to devices. We can plug at block layer for IOs coming down from higher layers. We can even provide a mechanism to plug certain kthreads if necessary but they should be contained in the driver - e.g. the suspend callback specifically blocking certain specific kthreads - instead of the vague "the system is generally stopped now and it seems to work most of the time" that we're doing now. Thanks. -- tejun