linux-kernel - Re: [linux-pm] Freezer: Don't count threads waiting for frozen filesystems.

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: <E1KvtMn-0004YD-00@pomaz-ex.szeredi.hu>
Date:	Fri, 31 Oct 2008 13:44:41 +0100
From:	Miklos Szeredi <miklos@...redi.hu>
To:	ncunningham@...a.org.au
CC:	miklos@...redi.hu, linux-pm@...ts.linux-foundation.org,
	linux-kernel@...r.kernel.org
Subject: Re: [linux-pm] Freezer: Don't count threads waiting for
	frozen	filesystems.

On Fri, 31 Oct 2008, Nigel Cunningham wrote:
> You don't. You just use FUSE_MIGHT_FREEZE to stop them before they take
> locks that might cause problems. So my suggestion is:

Before?  FUSE_MIGHT_FREEZE is called _after_ i_mutex is taken by the
VFS.

> 1) Stop new requests at FUSE_MIGHT_FREEZE
> 2) Handle existing requests by using freezer_do_not_count in
> request_send and request_send_nowait before the spin_lock and
> freezer_count after the spin_unlock.
> 
> With #2, we don't need to care about whether the request is completed
> before freezing completes or post-resume.
> 
> If the userspace process tries to use an already frozen fuse filesystem
> and gets frozen, that's okay because we'll sit waiting for an answer,
> not be counted by the freezer and so not contribute to any failure to
> freeze processes.
> 
> If the userspace process completes its work, we'll either get caught at
> the freezer_count (if we've already been told to freeze) or be gotten
> later, after exiting the fuse code.

Yes, this is the variant of categorizing sleeps to freezing and
non-freezing.  The problem is, you need to do that with all
mutex_lock(&inode->i_mutex) instances as well.  Try grepping for that
in fs/*.c!

It _is_ possible, it's just not practical.

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