Linux on ARM based TI OMAP SoCs
 help / color / mirror / Atom feed
From: "Rafael J. Wysocki" <rjw@sisk.pl>
To: "Dasgupta, Romit" <romit@ti.com>
Cc: Pavel Machek <pavel@ucw.cz>,
	"linux-omap@vger.kernel.org" <linux-omap@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-pm@lists.linux-foundation.org"
	<linux-pm@lists.linux-foundation.org>
Subject: Re: [PATCH 1/1] PM: Thaws refrigerated and to be exited kernel threads
Date: Mon, 9 Nov 2009 13:06:38 +0100	[thread overview]
Message-ID: <200911091306.38148.rjw@sisk.pl> (raw)
In-Reply-To: <B85A65D85D7EB246BE421B3FB0FBB59301DE3B67A0@dbde02.ent.ti.com>

On Monday 09 November 2009, Dasgupta, Romit wrote:
> > Really? I believe the "ktrhead_should_stop" is new rule, and code does
> > not seem to follow it. Actually, for example audit does not seem to
> > use kthread_should_stop() at all...
> > 
> > ./kernel/rtmutex-tester.c-
> > ./kernel/rtmutex-tester.c-		/* Wait for the next 
> > command to be executed */
> > ./kernel/rtmutex-tester.c-		schedule();
> > ./kernel/rtmutex-tester.c:		try_to_freeze();
> > ./kernel/rtmutex-tester.c-
> > ./kernel/rtmutex-tester.c-		if (signal_pending(current))
> > ./kernel/rtmutex-tester.c-			flush_signals(current);
> > --
> Not a new rule. For these threads you listed no one stops them by sending 
> 'kthread_stop' so the problem does not arise! But for the threads that are 
> stopped by invoking kthread_stop they do check kthread_should_stop. 

At the moment we don't have the rule that kernel threads should exit
immediately after kthread_stop() is called for them, which your patch implies
for freezable kernel threads.

Now, I think we might require the freezable kernel threads to exit as soon as
ktrhead_should_stop() is true for them, but (a) that needs to be documented
(please note it also applies to freezable workqueues) and (b) the existing
freezable kernel threads need to be audited, so we're sure they follow this
rule.  Also, it might lead to subtle problems if someone overlooks this
rule in the future.

So, I'd rather not introduce such a rule if there's no other way to fix the
problem at hand.

BTW, in future please describe the motivation for a change in the changelog
or people will wonder what the change is for.  In particular, if it fixes a
problem, please describe the problem and why you think your approach is
appropriate for fixing it.

Thanks,
Rafael

      reply	other threads:[~2009-11-09 12:05 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-11-06  9:36 [PATCH 1/1] PM: Thaws refrigerated and to be exited kernel threads Dasgupta, Romit
2009-11-07 16:54 ` Pavel Machek
2009-11-08  4:22   ` Dasgupta, Romit
2009-11-08  8:27     ` Pavel Machek
2009-11-08 11:00       ` Dasgupta, Romit
2009-11-08 11:10       ` Dasgupta, Romit
2009-11-09  8:31         ` Pavel Machek
2009-11-09  9:18           ` Dasgupta, Romit
2009-11-09 12:06             ` Rafael J. Wysocki [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200911091306.38148.rjw@sisk.pl \
    --to=rjw@sisk.pl \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-omap@vger.kernel.org \
    --cc=linux-pm@lists.linux-foundation.org \
    --cc=pavel@ucw.cz \
    --cc=romit@ti.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox