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:	Thu, 25 Aug 2011 17:59:57 +0200
From:	Tejun Heo <tj@...nel.org>
To:	Oleg Nesterov <oleg@...hat.com>
Cc:	rjw@...k.pl, menage@...gle.com, linux-kernel@...r.kernel.org,
	arnd@...db.de
Subject: Re: [PATCH 06/16] freezer: make exiting tasks properly unfreezable

Hello, Oleg.

On Wed, Aug 24, 2011 at 04:14:31PM +0200, Oleg Nesterov wrote:
> > Hmmm... can it cause disk IOs after that point?  I skimmed through and
> > couldn't spot one
> 
> I am not sure. But, say, exit_files(). We can't know what f_op->flush()
> f_op->release() can do in general. Even without i/o the exiting task can
> do a lot of different things.

Yeah, what 'freeze' should do is a bit vague on the edges, I think.
The freezer can't really halt the whole system operation including
IOs.  Tasks aren't the only source which can kick those off.  There
are other asynchronous sources, timers, IRQs and bottom halves.  For
actual disk IOs to at least SCSI/IDE devices, freezing isn't even
necessary.  Queue processing is suspended via device suspend
mechanism.  There were several drivers which didn't have proper device
suspend mechanism implemented (maybe we should implement generic queue
quiescing in block layer) but I don't know whether they are still like
that.

Anyways, freezing has never been a full solution to quiescing the
system prior to entering hibernation.  It does make sense for userland
processes but depending on it for quiescing kernel activities
including IO can't be reliable.  It should really be achieved by
device suspend (and maybe some midlayer suspending too) and I think
we're already pretty close to that.  Rafael, can you please enlighten
us on the subject?

Another freezer user is the cgroup, for this, allowing killing to
finish is quite useful as it can be used for runaway cgroup control.

Thanks.

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