Re: Freezable workqueue blocks non-freezable workqueue during the system resume process

From: Tejun Heo <tj@kernel.org>
To: Jan Kara <jack@suse.cz>
Cc: Peter Chen <hzpeterchen@gmail.com>,
	Alan Stern <stern@rowland.harvard.edu>,
	florian@mickler.org, linux-usb@vger.kernel.org,
	linux-kernel@vger.kernel.org,
	usb-storage@lists.one-eyed-alien.net, Jan Kara <jack@suse.com>,
	jkosina@suse.cz
Subject: Re: Freezable workqueue blocks non-freezable workqueue during the system resume process
Date: Fri, 11 Mar 2016 12:56:10 -0500	[thread overview]
Message-ID: <20160311175610.GL24046@htj.duckdns.org> (raw)
In-Reply-To: <20160303093310.GC2307@quack.suse.cz>

Hello, Jan.

On Thu, Mar 03, 2016 at 10:33:10AM +0100, Jan Kara wrote:
> > Ugh... that's nasty.  I wonder whether the right thing to do is making
> > writeback workers non-freezable.  IOs are supposed to be blocked from
> > lower layer anyway.  Jan, what do you think?
> 
> Well no, at least currently IO is not blocked in lower layers AFAIK - for
> that you'd need to freeze block devices & filesystems and there are issues

At least libata does and I think SCSI does too, but yeah, there
probably are drivers which depend on block layer blocking IOs, which
btw is a pretty fragile way to go about as upper layers might not be
the only source of activities.

> with that (Jiri Kosina was the last one which was trying to make this work
> AFAIR). And I think you need to stop writeback (and generally any IO) to be
> generated so that it doesn't interact in a strange way with device drivers
> being frozen. So IMO until suspend freezes filesystems & devices properly
> you have to freeze writeback workqueue.

I still think the right thing to do is plugging that block layer or
low level drivers.  It's like we're trying to plug multiple sources
when we can plug the point where they come together anyway.

Thanks.

-- 
tejun