lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1225444253.6574.21.camel@nigel-laptop>
Date:	Fri, 31 Oct 2008 20:10:53 +1100
From:	Nigel Cunningham <ncunningham@...a.org.au>
To:	Miklos Szeredi <miklos@...redi.hu>
Cc:	stern@...land.harvard.edu, linux-pm@...ts.linux-foundation.org,
	linux-kernel@...r.kernel.org
Subject: Re: [linux-pm] Freezer: Don't count threads waiting for frozen
	filesystems.

Hi.

On Fri, 2008-10-31 at 09:49 +0100, Miklos Szeredi wrote:
> On Fri, 31 Oct 2008, Nigel Cunningham wrote:
> > I'm not sure that's true. You see, I'm thinking of this as not that
> > different to the problem of unmounting filesystems. There, too, we need
> > to unmount in a particular order, and let transactions on each
> > filesystem stop cleanly before we can unmount them. Even if there are
> > differences, perhaps looking at how we handle unmounting will help with
> > handling freezing.
> 
> There's nothing magic about umount, it just uses a refcount on the fs.
> 
> But umount changes the namespace, that's the big difference.  For
> example if a process is accessing path P which has a component inside
> the mount, it _will_ get different results before and after the
> umount.  This is not acceptable for freezing.
> 
> For freezing to work with such a refcounting scheme, we'd have to
> count _future_ uses of the fs as well, not just current ones, which is
> obviously impossible.

I must be missing something. If you're freezing future users of the
filesystem before they can start anything new, doesn't that deal with
this problem?

Regards,

Nigel

--
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ