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: <4F27311C.5020200@linux.vnet.ibm.com>
Date:	Tue, 31 Jan 2012 05:39:00 +0530
From:	"Srivatsa S. Bhat" <srivatsa.bhat@...ux.vnet.ibm.com>
To:	Tejun Heo <tj@...nel.org>
CC:	rjw@...k.pl, pavel@....cz, len.brown@...el.com,
	linux-pm@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 2/4] PM/Freezer: Make thaw_processes() thaw only userspace
 tasks

On 01/31/2012 05:00 AM, Tejun Heo wrote:

> On Tue, Jan 31, 2012 at 04:44:48AM +0530, Srivatsa S. Bhat wrote:
>> Currently the situation is:
>>
>> freeze_processes() - freezes only userspace tasks
>> freeze_kernel_threads() - freezes only kernel threads
>> thaw_kernel_threads() - thaws only kernel threads
>> thaw_processes() - thaws *everything* (both userspace tasks and kernel threads)
> 
> Umm... I don't really get this.  Why is this a problem?  The list is
> not even correct.  freeze_kernel_threads() doesn't freeze "only"
> kernel threads.  It freezes all threads "including" kernel threads and


Oh, you are are right - the list is incorrect. I guess I got carried away
thinking about thaw_kernel_threads().

> that's only natural because you can't freeze kernel threads without
> freezing userland threads and of course you can't thaw userland
> threads without thawing kernel threads.
>

> The system simply won't work if you do it otherwise and making them

> disjoint operations increases the chance of bugs.  These operations
> are naturally enclosed within each other and trying to break them
> apart isn't a good idea.
> 


Yeah, I get it now.. Thanks for the explanation!

> What's the problem you're trying to solve here?  I don't really see
> code clean up.  Code is different but not necessarily cleaner and FWIW
> it seems more unnatural and brittle to me.
> 


The thing is that, I wanted to avoid a bug in the patch posted at
https://lkml.org/lkml/2012/1/29/47 as explained in the link.

So I guess I should have simply done:

freeze_kernel_threads() calls thaw_kernel_threads() upon error.
The caller of freeze_kernel_threads() will call thaw_processes() if
necessary.

This way even the SNAPSHOT_CREATE_IMAGE ioctl would remain safe.

I'll think it through again and post an updated patch.
Thank you very much for the review!

Regards,
Srivatsa S. Bhat

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