linux-kernel - Re: [PATCH v3 22/22] thermal/intel_powerclamp: Convert the kthread to kthread worker API

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: <20160112101129.GN731@pathway.suse.cz>
Date:	Tue, 12 Jan 2016 11:11:29 +0100
From:	Petr Mladek <pmladek@...e.com>
To:	Jacob Pan <jacob.jun.pan@...ux.intel.com>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	Oleg Nesterov <oleg@...hat.com>, Tejun Heo <tj@...nel.org>,
	Ingo Molnar <mingo@...hat.com>,
	Peter Zijlstra <peterz@...radead.org>,
	Steven Rostedt <rostedt@...dmis.org>,
	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>,
	Josh Triplett <josh@...htriplett.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Jiri Kosina <jkosina@...e.cz>, Borislav Petkov <bp@...e.de>,
	Michal Hocko <mhocko@...e.cz>, linux-mm@...ck.org,
	Vlastimil Babka <vbabka@...e.cz>, linux-api@...r.kernel.org,
	linux-kernel@...r.kernel.org, Zhang Rui <rui.zhang@...el.com>,
	Eduardo Valentin <edubezval@...il.com>,
	linux-pm@...r.kernel.org
Subject: Re: [PATCH v3 22/22] thermal/intel_powerclamp: Convert the kthread
 to kthread worker API

On Mon 2016-01-11 18:17:18, Jacob Pan wrote:
> On Fri, 8 Jan 2016 17:49:31 +0100
> Petr Mladek <pmladek@...e.com> wrote:
> 
> > Is the __preempt_schedule() a problem? It allows to switch the process
> > when needed. I thought that it was safe because try_to_freeze() might
> > have slept as well.
> > 
> not a problem. i originally thought queue_kthread_work() may add
> delay but it doesn't since there is no other work on this kthread.

Great.
 
> > > - vulnerable to future changes of queuing work  
> > 
> > The question is if it is safe to sleep, freeze, or even migrate
> > the system between the works. It looks like because of the
> > try_to_freeze() and schedule_interrupt() calls in the original code.
> > 
> > BTW: I wonder if the original code correctly handle freezing after
> > the schedule_timeout(). It does not call try_to_freeze()
> > there and the forced idle states might block freezing.
> > I think that the small overhead of kthread works is worth
> > solving such bugs. It makes it easier to maintain these
> > sleeping states.
> it is in a while loop, so try_to_freeze() gets called. Am I missing
> something?

But it might take some time until try_to_freeze() is called.
If I get it correctly. try_to_freeze_tasks() wakes freezable
tasks to get them into the fridge. If clamp_thread() is waken
from that schedule_timeout_interruptible(), it still might inject
the idle state before calling try_to_freeze(). It means that freezer
needs to wait "quite" some time until the kthread ends up in the
fridge.

Hmm, even my conversion does not solve this entirely. We might
need to call freezing(current) in the

   while (time_before(jiffies, target_jiffies)) {

cycle. And break injecting the idle state when freezing is requested.

Or do I miss something, please?

Best Regards,
Petr







Best Regards,
Petr