[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <200801310053.03056.phillips@phunq.net>
Date: Thu, 31 Jan 2008 00:53:02 -0800
From: Daniel Phillips <phillips@...nq.net>
To: Theodore Tso <tytso@....edu>
Cc: Takashi Sato <t-sato@...jp.nec.com>, linux-ext4@...r.kernel.org,
linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [RFC] ext3 freeze feature
On Friday 25 January 2008 05:33, Theodore Tso wrote:
> and then detect the
> deadlock case where the process holding the file descriptor used to
> freeze the filesystem gets frozen because it attempted to write to the
> filesystem --- at which point it gets some kind of signal (which
> defaults to killing the process), and the filesystem is unfrozen and
> as part of the unfreeze you wake up all of the processes that were put
> to sleep for touching the frozen filesystem.
Hi Ted,
There are a few holes:
* The process may try to handle the signal and end up blocking on
the filesystem again.
* The process might pass the fd to another process by forking or
fd passing.
* The process holding the fd might be trying to take a lock held
by another process that is blocked on the filesystem, and infinite
variations on that theme.
Remembering the task that did the ioctl might work out better than
remembering the fd. Or just not try to be so fancy and rely on the
application to take appropriate measures to ensure it will not access
the filesystem, such as memlocking and not execing.
The freezer also needs to run in PF_MEMALLOC mode or similar
unless it can be sure it will not cause pageout to the frozen filesystem
under low memory conditions.
Regards,
Daniel
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists