linux-kernel - Re: [PATCH 1/7] Freezer: Read PF_BORROWED

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, 12 May 2007 13:46:22 +0530
From:	Gautham R Shenoy <ego@...ibm.com>
To:	"Rafael J. Wysocki" <rjw@...k.pl>
Cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	LKML <linux-kernel@...r.kernel.org>,
	Oleg Nesterov <oleg@...sign.ru>, Pavel Machek <pavel@....cz>,
	"Eric W. Biederman" <ebiederm@...ssion.com>
Subject: Re: [PATCH 1/7] Freezer: Read PF_BORROWED_MM in a nonracy way

On Sat, May 12, 2007 at 02:01:41AM +0200, Rafael J. Wysocki wrote:
> 
> > So you migt as well not return any value at all, since the returned value 
> > is apparently meaningless once the lock has been released.
> 
> No, it is not meaningless.

Right.

Agreed that the returned value might not necessarily reflect the
current state of thread in question. Can it pose any problems?

Case : is_user_space() returns 0: 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
We think the thread is a kernel thread.
So we don't count this thread when the case is FREEZER_USER_SPACE. 

Now this thread can perform an execve() and enter the 
userspace. It might not freeze.
So we would be declaring that all the userspace threads have been frozen,
when actually we might have this one li'l unfrozen devil from the 
userspace. 

Do we care? 
For cpu hotplug, I don't think so.

Because, like Oleg pointed out,  we know we'll anyway freeze all the 
leftover threads while handling the case FREEZER_KERNEL_THREADS.

But I am not sure if this is the case with suspend/hibernate, since we
need to do a sys_sync() between try_freeze_tasks(FREEZE_USER_SPACE) and
try_to_freeze_tasks(FREEZE_KERNEL_THREADS).

Case:is_user_space() returns 1:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
We think the thread is from userspace.
We count this thread when the case is FREEZER_USER_SPACE. Now the
thread enters the kernel space by either doing a daemonize() or exit().

The freezer code loops *atleast* twice before declaring the system
frozen. So if this metamorphosis occurs between iteration i and
iteration i+1, in i+1, we note that this thread is now a kernel thread,
and don't count it anymore.

However, between the 'i'th and 'i+1'th interation, if this thread calls
try_to_freeze(), it'll enter the refrigerator. We now have a cold
kernel thread when we were trying to freeze only userspace.

So, the question should be, are we clearing the TIF_FREEZING flag in places
where the thread can become a kernel thread and eventually call try_to_freeze.
I won't expect an exiting thread to call try_to_freeze, but a
daemonize()ed thread can.

So should we perform that check in reparent_to_kthreadd() ?
We are protected by the tasklist_lock there, no?

> 
> Rafael

Thanks and Regards
gautham.
-- 
Gautham R Shenoy
Linux Technology Center
IBM India.
"Freedom comes with a price tag of responsibility, which is still a bargain,
because Freedom is priceless!"
-
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/