Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755227Ab3CFVAG (ORCPT ); Wed, 6 Mar 2013 16:00:06 -0500 Received: from mail-vc0-f178.google.com ([209.85.220.178]:35207 "EHLO mail-vc0-f178.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753288Ab3CFVAE (ORCPT ); Wed, 6 Mar 2013 16:00:04 -0500 MIME-Version: 1.0 In-Reply-To: <20130306185304.GM1227@htj.dyndns.org> References: <20130304205307.GA13527@redhat.com> <4FA345DA4F4AE44899BD2B03EEEC2FA9286AEEB0@sacexcmbx05-prd.hq.netapp.com> <20130305082308.6607d4db@tlielax.poochiereds.net> <20130305174648.GF12795@htj.dyndns.org> <20130305174954.GG12795@htj.dyndns.org> <20130305140312.243cb094@tlielax.poochiereds.net> <20130305190923.GI12795@htj.dyndns.org> <20130305183941.19ff39ce@tlielax.poochiereds.net> <20130305234700.GE1227@htj.dyndns.org> <20130306181608.GA18687@redhat.com> <20130306185304.GM1227@htj.dyndns.org> Date: Wed, 6 Mar 2013 13:00:02 -0800 X-Google-Sender-Auth: R63k8RBhSYfwx1SzmibKgNoWH5Q Message-ID: Subject: Re: LOCKDEP: 3.9-rc1: mount.nfs/4272 still has locks held! From: Linus Torvalds To: Tejun Heo Cc: Oleg Nesterov , Jeff Layton , "Myklebust, Trond" , Mandeep Singh Baines , Ming Lei , "J. Bruce Fields" , Linux Kernel Mailing List , "linux-nfs@vger.kernel.org" , "Rafael J. Wysocki" , Andrew Morton , Ingo Molnar , Al Viro Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1289 Lines: 28 On Wed, Mar 6, 2013 at 10:53 AM, Tejun Heo wrote: > Hello, Oleg. > > On Wed, Mar 06, 2013 at 07:16:08PM +0100, Oleg Nesterov wrote: >> And how SIGFREEZE can help? If we want to interrupt the sleeps in NFS/RPC >> layer we can simply add TASK_WAKEFREEZE (can be used with TASK_KILLABLE) >> and change freeze_task() to do signal_wake_up_state(TASK_WAKEFREEZE). > > Oh yeah, we don't need another signal. We just need sigpending state > and a wakeup. I wasn't really going into details. The important > point is that for code paths outside signal/ptrace, freezing could > look and behave about the same as signal delivery. Don't we already do that? The whole "try_to_freeze()" in get_signal_to_deliver() is about exactly this. See fake_signal_wake_up(). You still have kernel threads (that don't do signals) to worry about, so it doesn't make things go away. And you still have issues with latency of disk wait, which is, I think, the reason for that "freezable_schedule()" in the NFS code to begin with. Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/