From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1762298AbXGEUes (ORCPT ); Thu, 5 Jul 2007 16:34:48 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1760618AbXGEUed (ORCPT ); Thu, 5 Jul 2007 16:34:33 -0400 Received: from smtp-out001.kontent.com ([81.88.40.215]:55005 "EHLO smtp-out.kontent.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1760246AbXGEUec convert rfc822-to-8bit (ORCPT ); Thu, 5 Jul 2007 16:34:32 -0400 From: Oliver Neukum To: Miklos Szeredi Subject: Re: [linux-pm] Re: [PATCH] Remove process freezer from suspend to RAM pathway Date: Thu, 5 Jul 2007 22:34:29 +0200 User-Agent: KMail/1.9.7 Cc: pavel@ucw.cz, paulus@samba.org, stern@rowland.harvard.edu, johannes@sipsolutions.net, rjw@sisk.pl, linux-pm@lists.linux-foundation.org, linux-kernel@vger.kernel.org, mjg59@srcf.ucam.org, benh@kernel.crashing.org References: <18059.10554.955290.148535@cargo.ozlabs.ibm.com> <200707052138.56920.oliver@neukum.org> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8BIT Content-Disposition: inline Message-Id: <200707052234.30021.oliver@neukum.org> Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Am Donnerstag, 5. Juli 2007 schrieb Miklos Szeredi: > > Am Donnerstag, 5. Juli 2007 schrieb Miklos Szeredi: > > > > > Actually fuse allows SIGKILL, because it's always fatal, and the > > > > > syscall may not be restarted. > > > > > > > > I think you want to stick try_to_freeze() at the same places where you > > > > do SIGKILL handling. That should solve the 'syslogd is unfreezeable' > > > > problem. > > > > > > I could, but it would not solve the general problem.  Namely, that the > > > presence of fuse imposes a certain ordering in which userspace tasks > > > have to be frozen.  And it is not possible to know this ordering. > > > > Actually, why do you need this? There is no absolute need that you > > finish the request. You must either finish the request or let yourself > > be frozen. > > > > A quick look through fuse reveals principally request_wait_answer() > > And maybe a few other places. Is there some hidden reason you cannot > > handle being frozen here? > > Yes, fuse could handle being frozen there. However that would only > solve part of the problem: an operation waiting for a reply could be > holding a VFS mutex and some other task may be blocked on that mutex. > > How would you solve freezing those tasks? OK, you made me reach for literatur on theoretical computer science. IMHO the range of actions a fuse server is inherently limited. You must never ever block on a lock one of your clients is holding. In this case the limitation is not influenced by the freezer. The freezer introduces a further limitation in that the server can freeze before the client, which must not be. You can prevent that by freezing the servers last. In principle you might have dependencies between servers and you won't catch that, true. You won't catch servers blocking on IPC, but you are balancing on the edge of deadlock with fuse anyway. Regards Oliver