Oleg Nesterov <[EMAIL PROTECTED]> writes:
> Ah yes, we still need to export kthreadd_task... I just worried about subtle
> dependency this patch adds... This "kthreadd_task = find_task_by_pid" assumes
> that init/main.c:init() takes lock_kernel() before the first kthread_create().
There is a smal
On 04/11, Eric W. Biederman wrote:
>
> Oleg Nesterov <[EMAIL PROTECTED]> writes:
>
> > On 04/11, Eric W. Biederman wrote:
> >>
> >> @@ -435,8 +436,12 @@ static void __init setup_command_line(char
> >> *command_line)
> >> static void noinline rest_init(void)
> >>__releases(kernel_lock)
> >>
Oleg Nesterov <[EMAIL PROTECTED]> writes:
> On 04/11, Eric W. Biederman wrote:
>>
>> @@ -435,8 +436,12 @@ static void __init setup_command_line(char
>> *command_line)
>> static void noinline rest_init(void)
>> __releases(kernel_lock)
>> {
>> +int pid;
>> kernel_thread(init, NULL,
On Wednesday, 11 April 2007 16:36, Oleg Nesterov wrote:
> On 04/11, Gautham R Shenoy wrote:
> > On Wed, Apr 11, 2007 at 03:48:05PM +0400, Oleg Nesterov wrote:
> > > On 04/11, Gautham R Shenoy wrote:
> > > >
> > > > On Wed, Apr 11, 2007 at 12:13:34PM +0200, Rafael J. Wysocki wrote:
> > > > >
> > >
On 04/11, Eric W. Biederman wrote:
>
> @@ -435,8 +436,12 @@ static void __init setup_command_line(char *command_line)
> static void noinline rest_init(void)
> __releases(kernel_lock)
> {
> + int pid;
> kernel_thread(init, NULL, CLONE_FS | CLONE_SIGHAND);
> numa_default_poli
On Wed, 11 Apr 2007 12:27:59 -0600
[EMAIL PROTECTED] (Eric W. Biederman) wrote:
> + strcpy(tsk->comm, "kthreadd");
We have this dopey set_task_comm() thing which is there to avoid
races when userspace is looking at this task's name via /proc.
It obviously doesn't matter in this case, but I s
Currently there is a circular reference between work queue initialization
and kthread initialization. This prevents the kthread infrastructure from
initializing until after work queues have been initialized.
We want the properties of tasks created with kthread_create to be as close
as possible
Andrew Morton <[EMAIL PROTECTED]> writes:
> argh. Your description freely confuddles the terms "kernel thread" and
> "kthread". Can we not do that? Henceforth the term "kernel thread" refers
> to something which was started with kernel_thread() and "kthread" refers to
> something which was crea
Oleg Nesterov <[EMAIL PROTECTED]> writes:
> On 04/10, Eric W. Biederman wrote:
>>
>> +int kthreadd(void *unused)
>> +{
>> +/* Setup a clean context for our children to inherit. */
>> +kthreadd_setup();
>> +
>> +current->flags |= PF_NOFREEZE;
>> +
>> +for (;;) {
>> +wai
Oleg Nesterov <[EMAIL PROTECTED]> writes:
> On 04/10, Eric W. Biederman wrote:
>>
>> static int kthread(void *_create)
>> {
>> struct kthread_create_info *create = _create;
>> int (*threadfn)(void *data);
>> void *data;
>> -sigset_t blocked;
>> int ret = -EINTR;
>>
>>
On 04/11, Gautham R Shenoy wrote:
> On Wed, Apr 11, 2007 at 03:48:05PM +0400, Oleg Nesterov wrote:
> > On 04/11, Gautham R Shenoy wrote:
> > >
> > > On Wed, Apr 11, 2007 at 12:13:34PM +0200, Rafael J. Wysocki wrote:
> > > >
> > > > It should be calling try_to_freeze() somewhere anyway. We may nee
On Wednesday, 11 April 2007 15:31, Gautham R Shenoy wrote:
> On Wed, Apr 11, 2007 at 03:48:05PM +0400, Oleg Nesterov wrote:
> > On 04/11, Gautham R Shenoy wrote:
> > >
> > > On Wed, Apr 11, 2007 at 12:13:34PM +0200, Rafael J. Wysocki wrote:
> > > >
> > > > It should be calling try_to_freeze() some
On Wed, Apr 11, 2007 at 03:48:05PM +0400, Oleg Nesterov wrote:
> On 04/11, Gautham R Shenoy wrote:
> >
> > On Wed, Apr 11, 2007 at 12:13:34PM +0200, Rafael J. Wysocki wrote:
> > >
> > > It should be calling try_to_freeze() somewhere anyway. We may need to
> > > freeze
> > > all tasks in some cas
On 04/10, Eric W. Biederman wrote:
>
> static int kthread(void *_create)
> {
> struct kthread_create_info *create = _create;
> int (*threadfn)(void *data);
> void *data;
> - sigset_t blocked;
> int ret = -EINTR;
>
> - kthread_exit_files();
> -
> - /* Copy da
On 04/10, Eric W. Biederman wrote:
>
> +int kthreadd(void *unused)
> +{
> + /* Setup a clean context for our children to inherit. */
> + kthreadd_setup();
> +
> + current->flags |= PF_NOFREEZE;
> +
> + for (;;) {
> + wait_event(kthread_create_work,
> +
On 04/11, Gautham R Shenoy wrote:
>
> On Wed, Apr 11, 2007 at 12:13:34PM +0200, Rafael J. Wysocki wrote:
> >
> > It should be calling try_to_freeze() somewhere anyway. We may need to
> > freeze
> > all tasks in some cases.
>
> How about
> for (;;) {
> try_to_freeze();
>
> ?
Why?
> This
On Wed, Apr 11, 2007 at 12:13:34PM +0200, Rafael J. Wysocki wrote:
>
> It should be calling try_to_freeze() somewhere anyway. We may need to freeze
> all tasks in some cases.
How about
for (;;) {
try_to_freeze();
?
This change allows us to make all the worker threads freezeable by defa
On Wednesday, 11 April 2007 09:03, Andrew Morton wrote:
> On Tue, 10 Apr 2007 23:44:36 -0600 [EMAIL PROTECTED] (Eric W. Biederman)
> wrote:
>
> > Currently there is a circular reference between work queue initialization
> > and kthread initialization. This prevents the kernel thread
> > infrast
On Tue, 10 Apr 2007 23:44:36 -0600 [EMAIL PROTECTED] (Eric W. Biederman) wrote:
> Currently there is a circular reference between work queue initialization
> and kthread initialization. This prevents the kernel thread
> infrastructure from initializing until after work queues have been
> initial
Currently there is a circular reference between work queue initialization
and kthread initialization. This prevents the kernel thread
infrastructure from initializing until after work queues have been
initialized.
For kernel threads we want something that is as close as possible to the
init_tas
20 matches
Mail list logo