Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756141AbYJ2Xn2 (ORCPT ); Wed, 29 Oct 2008 19:43:28 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1753034AbYJ2XnU (ORCPT ); Wed, 29 Oct 2008 19:43:20 -0400 Received: from fxip-0047f.externet.hu ([88.209.222.127]:33234 "EHLO pomaz-ex.szeredi.hu" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752464AbYJ2XnT (ORCPT ); Wed, 29 Oct 2008 19:43:19 -0400 To: stern@rowland.harvard.edu CC: miklos@szeredi.hu, rjw@sisk.pl, linux-kernel@vger.kernel.org, ncunningham@crca.org.au, linux-pm@lists.linux-foundation.org In-reply-to: (message from Alan Stern on Wed, 29 Oct 2008 16:37:30 -0400 (EDT)) Subject: Re: [linux-pm] Freezer: Don't count threads waiting for frozen filesystems. References: Message-Id: From: Miklos Szeredi Date: Thu, 30 Oct 2008 00:43:09 +0100 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1987 Lines: 45 On Wed, 29 Oct 2008, Alan Stern wrote: > I discussed this last summer with Rafael. It's a lot harder than it > looks, for all sorts of reasons. For example, what about user tasks > that have access to memory-mapped I/O regions? What about them? Freezing doesn't seem to help with that. > > c) is slightly tricky, but could be done for example by setting a flag > > on open: FMODE_NO_SUSPEND_DISABLE (better name required), saying that > > implementation is responsible for getting the suspend disable magic > > right. > > > > For starters this flag could be set for all non-device opens (maybe all > > non-char-dev opens?), solving the fuse vs. freezer issues without any > > complicated trickery. > > I don't know. There are other interfaces too, like sysfs attributes, > that would have to be handled specially. On the whole, the freezer > seems much, much simpler. OK, then non-device files on "regular" filesystems. > Regarding fuse, something like Nigel's scheme for preventing new > requests and then waiting for old requests to complete might work out. > Especially if you combine it with a strategy for making the freezer > back and retry after a delay when something goes wrong. I don't think it will work out, because to be able to do this some ordering between freezing the filesystems must be done. But this is basically impossible, for all the same reasons it's impossible to order the freezing of userspace tasks. Also this is not just a fuse issue: we have userspace network devices, we have userspace USB drivers, etc, affected by this problem. If there _is_ a solution with the freezer that does solve all of this, I haven't yet heard it. But yeah, in the end the simpler solution should win. Miklos -- 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/