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]

Date:	Sat, 01 Nov 2008 08:11:38 +1100
From:	Nigel Cunningham <ncunningham@...a.org.au>
To:	Miklos Szeredi <miklos@...redi.hu>
Cc:	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 13:44 +0100, Miklos Szeredi wrote:
> 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.

Ok. So I'll shift it backwards in the calling chain a bit.

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

Let's get practical. You know fuse a lot better than me. Can you give me
the most complicated, ugly configuration you can think of, and I'll work
on making it freeze first time, every time.

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/