From mboxrd@z Thu Jan 1 00:00:00 1970 From: Fernando Luis Vazquez Cao Subject: Re: [PATCH] fsfreeze: tell hung_task about processes put to sleep Date: Mon, 15 Oct 2012 12:24:59 +0900 Message-ID: <507B820B.3000908@lab.ntt.co.jp> References: <1350035252.6500.2.camel@nexus.lab.ntt.co.jp> <20121013010613.GP2739@dastard> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: Al Viro , Ingo Molnar , Jan Kara , linux-fsdevel@vger.kernel.org To: Dave Chinner Return-path: Received: from tama500.ecl.ntt.co.jp ([129.60.39.148]:50244 "EHLO tama500.ecl.ntt.co.jp" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751915Ab2JODZZ (ORCPT ); Sun, 14 Oct 2012 23:25:25 -0400 In-Reply-To: <20121013010613.GP2739@dastard> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On 2012/10/13 10:06, Dave Chinner wrote: > On Fri, Oct 12, 2012 at 06:47:32PM +0900, Fernando Luis V=E1zquez Cao= wrote: >> Any process attempting to write to a frozen filesystem uninterruptib= ly and >> unkillably waits for the filesystem to be thawed. This wait is of un= bounded >> length. Ignore such waits in the hung_task detector. > Filesystems should not be frozen for long enough to trigger the hung > task detector under normal usage. IMO, if you are freezing a > filesystem for that long, then you're either doing something wrong > or something has gone wrong, and in either case I think we should be > emitting warnings... The problem is that in production systems situations where a filesystem remains brozen for long periods are not uncommon. A typical example is as follows: the control daemon or script that controls the freeze/thaw using the fsfreeze ioctls dies, the next day the system administrator finds the system log flooded with kernel stack dumps (of course, since fsfreeze lacks check ioctls there is no easy way for the administrator to find out what is going on) or, if hung_task_panic happened to be set, is welcomed with a panic message. IMHO, this behaviour is not appropriate (nothing has gone wrong with the kernel after all) and my patch fixes it. If we were to emit warning in such cases, it certainly should not be through hung_task (panics and stack dumps from seemingly arbitrary tasks are not what a system administrator needs). We would need to add some kind of per-superblock timer for fsfreeze (this could arguably be useful for thaw_bdev initiated freezes, where a failure to thaw the filesystem reasonably fast can be indicative of a kernel problem), which I think is overkill and have no plans to implement. Ingo, who is maintaining hung_task? If accepted, would this patch go through your tree? Thanks, =46ernando -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel= " in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html