From: Nigel Cunningham <ncunningham@cyclades.com>
To: Patrick Mochel <mochel@digitalimplant.org>,
Christoph Lameter <christoph@lameter.com>
Cc: Linux-pm mailing list <linux-pm@lists.osdl.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [linux-pm] [PATCH] Workqueue freezer support.
Date: Mon, 08 Aug 2005 10:46:55 +1000 [thread overview]
Message-ID: <1123462015.3969.98.camel@localhost> (raw)
In-Reply-To: <Pine.LNX.4.50.0508052148280.19501-100000@monsoon.he.net>
Hi.
Sorry for the slow response. Busy still.
On Sat, 2005-08-06 at 15:06, Patrick Mochel wrote:
> On Fri, 5 Aug 2005, Nigel Cunningham wrote:
>
> > Hi.
> >
> > I finally found some time to finish this off. I don't really like the
> > end result - the macros looked clearer to me - but here goes. If it
> > looks okay, I'll seek sign offs from each of the affected driver
> > maintainers and from Ingo. Anyone else?
>
> What are your feelings about this: http://lwn.net/Articles/145417/ ?
I'm sure it could work, but I do worry a little about the possibilities
for exploits. It seems to me that if someone can get root, they an
insmod a module that could schedule any kind of work via any process.
Tracing that sort of security hole could be intractable. Christoph, is
that something you've considered/have thoughts on? Perhaps I'm just
being paranoid :>
> It seems like a cleaner way to do things. How would these patches change
> if that were merged?
We would still need some way to mark which threads to freeze, so we'd
still need the same sort of thing as far as kthread_run etc goes.
We'd also still mark unfreezable threads with NOFREEZE and not mark
other threads, so no change there.
The first substantial change I can see would be switching from
try_to_freeze to try_todo_list (could this be 'run_todo_list'? Try
implies failure is possible - if it is possible, why do we ignore
whether it fails?).
The second substantial change would be in the area of the refrigeration
code itself, ala Christoph's patch.
One more question regarding Christoph's patch - would it be worth moving
the refrigerator related code from sched.h to a separate file? We
already have so many things that depend on sched.h, and this will add
more. It will also make maintenance less painful because you won't have
to recompile everything that depends on sched.h when all you did was
modify (say) freezing().
> Concerning the patch specifically:
>
> > diff -ruNp 400-workthreads.patch-old/include/linux/kthread.h 400-workthreads.patch-new/include/linux/kthread.h
> > --- 400-workthreads.patch-old/include/linux/kthread.h 2004-11-03 21:51:12.000000000 +1100
> > +++ 400-workthreads.patch-new/include/linux/kthread.h 2005-08-03 11:52:01.000000000 +1000
> > @@ -23,10 +23,20 @@
> > *
> > * Returns a task_struct or ERR_PTR(-ENOMEM).
> > */
> > +struct task_struct *__kthread_create(int (*threadfn)(void *data),
> > + void *data,
> > + unsigned long freezer_flags,
> > + const char namefmt[],
> > + va_list * args);
> > +
>
> When comparing this to this:
>
> > diff -ruNp 400-workthreads.patch-old/include/linux/workqueue.h 400-workthreads.patch-new/include/linux/workqueue.h
> > --- 400-workthreads.patch-old/include/linux/workqueue.h 2005-06-20 11:47:30.000000000 +1000
> > +++ 400-workthreads.patch-new/include/linux/workqueue.h 2005-08-03 11:49:34.000000000 +1000
> > @@ -51,9 +51,12 @@ struct work_struct {
> > } while (0)
> >
> > extern struct workqueue_struct *__create_workqueue(const char *name,
> > - int singlethread);
> > -#define create_workqueue(name) __create_workqueue((name), 0)
> > -#define create_singlethread_workqueue(name) __create_workqueue((name), 1)
> > + int singlethread,
> > + unsigned long freezer_flag);
> > +#define create_workqueue(name) __create_workqueue((name), 0, 0)
> > +#define create_nofreeze_workqueue(name) __create_workqueue((name), 0, PF_NOFREEZE)
> > +#define create_singlethread_workqueue(name) __create_workqueue((name), 1, 0)
> > +#define create_nofreeze_singlethread_workqueue(name) __create_workqueue((name), 1, PF_NOFREEZE)
>
> And to this:
>
>
> > static struct task_struct *create_workqueue_thread(struct workqueue_struct *wq,
> > - int cpu)
> > + int cpu,
> > + unsigned long freezer_flags)
> > {
>
> There is a slight discrepancy in the API changes. Obviously, we don't want
> to change every caller of create_workqueue() to support this. But, perhaps
> you could standardize the handling of the freezer flags (by e.g. creating
> a separate _nofreeze version for each).
Missed that one, sorry.
> Also, functions that take a va_list parameter pass the structure (array)
> rather than the pointer. See the definition of vprintk() in
> include/linux/kernel.h for an example.
Thanks for the pointer.
Nigel
>
> Thanks,
>
>
> Pat
>
> ______________________________________________________________________
> _______________________________________________
> linux-pm mailing list
> linux-pm@lists.osdl.org
> https://lists.osdl.org/mailman/listinfo/linux-pm
--
Evolution.
Enumerate the requirements.
Consider the interdependencies.
Calculate the probabilities.
next prev parent reply other threads:[~2005-08-08 0:47 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-07-21 5:17 [PATCH] Workqueue freezer support Nigel Cunningham
2005-07-21 15:38 ` [linux-pm] " Pavel Machek
2005-07-21 15:42 ` Ingo Molnar
2005-07-21 15:44 ` Pavel Machek
2005-07-21 19:42 ` Patrick Mochel
2005-07-22 3:02 ` Nigel Cunningham
2005-08-05 12:12 ` Nigel Cunningham
2005-08-06 5:06 ` Patrick Mochel
2005-08-08 0:46 ` Nigel Cunningham [this message]
2005-08-08 1:27 ` Con Kolivas
2005-08-08 1:38 ` Nigel Cunningham
2005-08-08 12:18 ` Nigel Cunningham
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=1123462015.3969.98.camel@localhost \
--to=ncunningham@cyclades.com \
--cc=christoph@lameter.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@lists.osdl.org \
--cc=mochel@digitalimplant.org \
/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