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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
