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: <E1KuRN4-0002gS-Hq@pomaz-ex.szeredi.hu>
Date:	Mon, 27 Oct 2008 13:38:58 +0100
From:	Miklos Szeredi <miklos@...redi.hu>
To:	ncunningham@...a.org.au
CC:	rjw@...k.pl, 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 Mon, 27 Oct 2008, Nigel Cunningham wrote:
> Hi.
> 
> On Mon, 2008-10-27 at 12:37 +0100, Rafael J. Wysocki wrote:
> > Well, I guess it's better if you post the entire thing so that we can see
> > what the role of the $subject patch is in it, even if this patch finally gets
> > merged separately.
> 
> Ah.. that makes me see how vfs_check_frozen was getting triggered...
> (fs/namei.c, below).

Nigel, thanks for the patch, it makes thinks a lot clearer.

>From a quick look through the patch it seems to solve a bunch of cases
where new fuse requests during the freezing could cause problems.  But
it doesn't do anything with requests that are already under way when
the freezing starts, which would still result in all the same
problems.

Take this scenario:

 1) process A does rename("/mnt/fuse/a", "/mnt/fuse/b")
 2) request goes to process B serving the fuse filesystem
 3) filesystems are frozen, no new fuse requests
 4) processes are frozen, let's say B first, then A
 5) freezing A will fail, since it's still waiting for the request to finish

Several solutions have been posted, none of which really solve the problem:

 a) Let's tag fuse server processes and freeze them later.  This is
 basically impossible, because many processes could be interoperating
 and there's no way to know which is depending on which (example:
 sshfs uses ssh for communication, which possibly relies on openvpn
 process for packet transmission).

 b) While waiting for replies to fuse request, allow process to
 freeze.  Does not fully solve the problem, as VFS might be holding
 locks, and other processes waiting for those locks will not be
 freezable.

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/