From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S932689AbbCDPOj (ORCPT <rfc822;w@1wt.eu>);
	Wed, 4 Mar 2015 10:14:39 -0500
Received: from mail-la0-f44.google.com ([209.85.215.44]:41987 "EHLO
	mail-la0-f44.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S932150AbbCDPOh (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Wed, 4 Mar 2015 10:14:37 -0500
MIME-Version: 1.0
In-Reply-To: <20150302043828.GA2516@mguzik>
References: <20150214185524.GA16579@p183.telecom.by>
	<20150216093852.GB4749@quack.suse.cz>
	<20150218073455.GA1752@p183.telecom.by>
	<20150218091323.GA4614@quack.suse.cz>
	<CACVxJT9E7Z5Q4=F1bOEXiZ4rrWFrm5_X0Hcj-oHP-Jach8gBXw@mail.gmail.com>
	<20150220121522.GC6293@quack.suse.cz>
	<20150228142235.GA19552@p183.telecom.by>
	<20150228142557.GB19552@p183.telecom.by>
	<20150228213126.GM4251@dastard>
	<20150302043828.GA2516@mguzik>
Date: Wed, 4 Mar 2015 18:14:35 +0300
Message-ID: <CACVxJT-O4RspyH7O_eENZCmEv6ZdMt+=A5WRsdag-=5uOSvYew@mail.gmail.com>
Subject: Re: [PATCH v3] fs: record task name which froze superblock
From: Alexey Dobriyan <adobriyan@gmail.com>
To: Mateusz Guzik <mguzik@redhat.com>
Cc: Dave Chinner <david@fromorbit.com>, Jan Kara <jack@suse.cz>,
        Andrew Morton <akpm@linux-foundation.org>,
        Al Viro <viro@zeniv.linux.org.uk>,
        Linux Kernel <linux-kernel@vger.kernel.org>,
        linux-fsdevel <linux-fsdevel@vger.kernel.org>, swhiteho@redhat.com,
        cluster-devel@redhat.com
Content-Type: text/plain; charset=UTF-8
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Mon, Mar 2, 2015 at 7:38 AM, Mateusz Guzik <mguzik@redhat.com> wrote:

> As explained below, this one task name is already very useful and likely
> covers majority of real life use cases.
>
> While working in support we were getting a lot of vmcores where hung task
> detector panicked the kernel because a lot of tasks were blocked
> in UN state trying to write to frozen filesystems. I presume OP has
> similar story.

Yes, the intended "use" case is 1 freezer which hopefully covers
majority of bug reports.

> Some back on forth commuication almost always revealed one process e.g.
> freezing stuff and then blocking itself trying to access it. While we
> could see it blocked, we had no presumptive evidence to pin freezing on
> it. A matching name, while still not 100% conclusive, would be ok enough
> to push the case forward and avoid a rountrip of systemap scripts
> showing freezer process tree.