From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Luis R. Rodriguez" Subject: Re: [Regression/XFS/PM] Freeze tasks failed in xfsaild Date: Mon, 13 Nov 2017 21:14:14 +0100 Message-ID: <20171113201414.GD16026@wotan.suse.de> References: <20171113103139.GA18936@yu-chen.sh.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Received: from mx2.suse.de ([195.135.220.15]:39661 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753414AbdKMUOR (ORCPT ); Mon, 13 Nov 2017 15:14:17 -0500 Content-Disposition: inline In-Reply-To: <20171113103139.GA18936@yu-chen.sh.intel.com> Sender: linux-pm-owner@vger.kernel.org List-Id: linux-pm@vger.kernel.org To: Yu Chen Cc: Michal Hocko , Hendrik Woltersdorf , Dave Chinner , "Rafael J. Wysocki" , "Darrick J. Wong" , Jiri Kosina , Len Brown , Rui Zhang , Dan Williams , Yu Chen , linux-xfs@vger.kernel.org, linux-pm@vger.kernel.org, inux-kernel@vger.kernel.org On Mon, Nov 13, 2017 at 06:31:39PM +0800, Yu Chen wrote: > The xfs-buf/dm-1 should be freezed according to > commit 8018ec083c72 ("xfs: mark all internal workqueues > as freezable"), thus a easier way might be have to revert > commit 18f1df4e00ce ("xfs: Make xfsaild freezeable > again") for now, after this reverting the xfsaild/dm-1 > becomes non-freezable again, thus pm does not see this > thread - unless we find a graceful way to treat xfsaild/dm-1 > as 'frozen' if it is waiting for an already 'frozen' task, > or if the filesystem freeze is added in. > > Any comments would be much appreciated. Reverting 18f1df4e00ce ("xfs: Make xfsaild freezeable again") would break the proper form of the kthread for it to be freezable. This "form" is not defined formally, and sadly its just a form learned throughout years over different kthreads in the kernel. I'm also not convinced all our hibernation / suspend woes would be fixed by reverting this commit, its why I worked instead on formalizing a proper freeze / thaw, which a lot of filesystems already implement prior to system hibernation / suspend / resume [0]. I'll be respinning this series without the last patch, provided I'm able to ensure I don't need the ext[234] hack I did in that thread. Can you test the first 3 patches *only* on that series and seeing if that helps on your XFS front as well? [0] https://lkml.kernel.org/r/20171003185313.1017-1-mcgrof@kernel.org Luis